[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                               Yongnan Xu
Nov. 18, 1997                      University of Missouri - Kansas City
draft-xu-isakmp-app-00.txt                                    Lein Harn
                                                    Racal Datacom Group

     The ISAKMP Applications on Security Related Failure Handling

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of 6 months
   and may be updated, replaced, or may become obsolete by documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as work in progress.

   To view the entire list of current Internet-Draft, please check the
   lid-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net(US East Coast), or
   ftp.isi.edu (US West Coast).


   A Security Association is a set of security related information
   between two or more entities. The Internet Security Association and
   Key Management Protocol defines procedures and packet formats to
   authenticate a communicating peer, and establish, negotiate, modify
   and delete Security Associations.  This document describes a new
   ISAKMP application that utilizes ISAKMP negotiation functions to
   handle security operation failures of other security protocols.

Table of Contents

   1. Introduction...................................................2
   2. The Need for ISAKMP Failure Handling...........................2
   3. Security Failure Handling Transaction..........................4
   4. Security Failure Handling Payload..............................5
   5. Notify Message Types...........................................6
   6. Security Considerations........................................7
   7. References.....................................................7
   8. Contact........................................................7

Y. Xu and L. Harn                                             [Page 1]

INTERNET-DRAFT                                            November, 97

1.      Introduction

   A Security Association (SA) is a set of information that can be
   considered a contract between two or more entities. SAs contain all
   the information required for execution of various network security
   services, such as the IP layer services, transport or application
   layer services, or self-protection of negotiation traffic.  The
   information must be agreed upon and shared between all the peer
   entities. All entities must adhere to the SA for secure
   communications to be possible. [RFC1825] defines some parameters for
   IP security.  A Security Association normally includes, such as
   encryption algorithm and algorithm mode, authentication algorithm
   and algorithm mode, key size, cryptographic synchronization or
   initialization vectors, lifetime of the keys, source address(es) of
   the Security Association, sensitivity level, etc. Other protocols
   that provide algorithm and mechanism independent security must
   define their requirements for SA attributes.

   The Internet Security Association and Key Management Protocol or
   ISAKMP [ISAKMP] defines procedures and packet formats to
   authenticate a communicating peer, and establish, negotiate, modify
   and delete Security Associations (SA). ISAKMP also defines payloads
   for exchanging key generation and authentication data.  These
   formats provide a consistent framework for transferring key and
   authentication data which is independent of the key generation
   technique, encryption algorithm and authentication mechanism. All of
   these are necessary to establish and maintain secure communications
   in an Internet environment. ISAKMP is intended to support the
   negotiation of SAs for security protocols at all layers of the
   network stack.

   ISAKMP is a two-phase negotiation procedure. In the first phase, two
   entities agree on how to protect further negotiation traffic between
   themselves, establishing an "ISAKMP SA". This ISAKMP SA is then used
   to protect the negotiations for the "Protocol SA" being requested.
   The second phase of negotiation is used to establish security
   associations for other security protocols. The security associations
   established by ISAKMP during this phase can be used by a security
   protocol to protect many message/data exchanges. ISAKMP is defined
   for exchange of Security Associations before the real data
   exchanges. It should have no regular ISAKMP activities during the
   period of subsequent data exchanges.

   Since its strong negotiation functions, ISAKMP can be extended to
   other applications. [PA97] describes a new ISAKMP mode that can be
   used to configure secure hosts. This configuration may take place
   between a gateway, an end-host client, or a configuration manager.
   For example, this can be used to configure multi-protocol IP tunnels

2.       The Need for Failure Handling

Y. Xu and L. Harn                                             [Page 2]

INTERNET-DRAFT                                            November, 97

   Security related failures may occur during data exchange periods of
   security protocols. There are two categories of security failures:
   connection failure and content failure. Connection failure means
   that a transmission connection is interrupted, that is, disconnected
   from network problems. The regular network connection functions
   should take the responsibility to recover the connection when the
   network problems disappear; but the data exchanges may not be
   recovered correctly if this is a connection with security
   operations. The parties may fail to maintain security parameters
   during the period of disconnection.

   In practical implementation, digital signatures usually include
   Time-to-Live parameters [RFC2065]. It is the data between the time
   it was originally signed and the time the signature should be
   verified. A legal digital signature may fail to verify when a
   connection is interrupted by network transmission problems. Another
   example of connection failures is the lifetime of keys. A data
   exchange may still fail if lifetime parameters are expired due to
   the transmission interruption and no update is made for them after
   the regular network transmission is recovered.  Negotiation
   functions are needed to recover and update the security parameters
   including Time-to-Live.

   Content Failure means that the data exchange parties could not get
   expecting results based on the required security operations, such as
   digital signature verification failure. In this case, the connection
   is still valid; but the security protocol may repeatedly try to re-
   send the same data and finally disconnect if no any mechanisms to
   improve the security operations. This security failure is different
   from transmission errors, which will be checked and handled by
   security protocols or other data communication protocols, such as
   link layer protocols.

   One practical example of content failure is multiple-key encryption.
   A sender may encrypt different parts of a large message using
   different keys or forward a batch ciphertext file for multiple
   users. The similar operations are not uncommon in electronic
   commerce. A receiver may fail to decode a part of the message, so it
   will usually give up the whole message if no any mechanism to
   improve the result. Negotiation operations can provide an efficient
   way to adjust and improve current operation environment for next
   computation result instead of simply re-send the whole message or
   reestablish a new connection. For example, the parties may negotiate
   and continue the decryption by only re-send the false one.

   Although security failure handling functions can be parts of the
   security communication protocols that use ISAKMP for SA negotiation,
   it is a reasonable and simple solution to centralize those
   responsibilities by utilizing ISAKMP's negotiation functions. As if
   each security protocol can actually perform its own SA negotiation,
   ISAKMP is introduced to support SAs negotiation for security
   protocols at all layers of the network stack (e.g., IPSEC, TLS,

Y. Xu and L. Harn                                             [Page 3]

INTERNET-DRAFT                                            November, 97

   TLSP, OSPF, etc.). Since ISAKMP is a basic supporting protocol for
   all other security protocols, this method will reduce the amount of
   duplicated security failure handling functionality within each
   security protocol. This extension centralizes the security failure
   handling management while each security protocol keeps its own
   transmission error handling functions.

3.      Security Failure Handling Transaction

   A Failure Handling Transaction is a complete procedure for peer
   parties to notify security operation failures or response solutions
   during data exchange period. Although a Security Failure Handling
   Transaction is performed after establishment of an ISAKMP Phase 1
   and 2 Security Association, it uses the similar procedure as phase 2
   to negotiate security failure handling. It uses two one-way ISAKMP
   Informational Exchanges. Each exchange has a standard ISAKMP header
   and only one special Notification payload.

    #       Initiator                        Responder
   ---     -----------                      -----------
   (1)       HDR*, N      -->
   (2)                              <--      HDR*, N

                HDR:    ISAKMP header
                N:      Notification payload
                *:      Payload encryption after the ISAKMP header

        Figure 1:       Failure Handling Transaction

   The first Informational Exchange is used to notify security
   operation failure, which is consisted of ISAKMP header and a
   Notification payload (see section 4). The second Informational
   Exchange is used to response the notification and reply a solution,
   which is consisted of ISAKMP header and a Notification payload.

   For content failure, a security protocol may invoke this transaction
   directly. At this point, ISAKMP phase 1 and 2 have completed and the
   ISAKMP header can be protected by Protocol SA from ISAKMP phase 2. A
   batch encryption, for example, uses different keys for different
   parts of a message. A receiver of the message may initiate this
   transaction to indicate a part of the message could not be decrypted
   successfully instead of request retransmission of the whole message.

   For connection failure, the peers may try to fix the failure by
   using the same procedure of the content failure. If not successfully
   for several times, the peers should initiate a Protocol SA
   Modification procedure (ISAKMP phase 2 negotiation) to create a new

Y. Xu and L. Harn                                             [Page 4]

INTERNET-DRAFT                                            November, 97

   SA. The creation of a new SA is protected by the existing ISAKMP SA.
   Lifetime of the keys and some other parameters, for example, may be
   expired or deleted by one party due to the connection failure. The
   peers initiate this transaction to update Protocol SAs including
   Lifetime of keys.

4.       Security Failure Handling Payload

   Security Failure Handling uses ISAKMP Notification Payload to
   transmit informational data and instructions, such as error
   conditions, to a protocol peer. One example for this type of
   notification is to indicate why a digital signature was rejected.
   Only one notification payload may be present in one direction in a
   security failure handling transaction.

   [ISAKMP] defines the standard Notification Payload format. The
   payload type for the Notification Payload is eleven (11). This
   section gives the special values for each field of a payload, which
   Security Failure Handling exchange uses.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   ! Next Payload  !   RESERVED    !         Payload Length        !
   !              Domain of Interpretation  (DOI)                  !
   !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
   !                                                               !
   ~                       Notification Data                       ~
   !                                                               !

   Figure 2: Notification Payload Format for Security Failure Handling

   The Notification Payload fields for Security Failure Handling are
   defined as follows:

   o  Next Payload (1 octet) - Since only one payload is allowed, this
      field will be 0.

   o  RESERVED (1 octet) - Unused, set to 0.

   o  Payload Length (2 octets) - Length in octets of the current
      payload, including the generic payload header.

   o  Domain of Interpretation (4 octets) - DOI is described in
      Section 2.1 in ISAKMP [MSST97]. For the Internet, the DOI is (1).

Y. Xu and L. Harn                                             [Page 5]

INTERNET-DRAFT                                            November, 97

   o  Protocol-Id (1 octet) - Specifies the protocol identifier which
      invokes ISAKMP for current notification.  Examples might include

   o  SPI Size (1 octet) - No SPI for security failure handling. Set
      to 0.

   o  Notify Message Type (2 octets) - Specifies the type of
      notification message (see section 5). Additional text, is placed
      in the Notification Data field.

   o  Notification Data (variable length) - Informational or error
      data transmitted in addition to the Notify Message Type.

5.      Notify Message Types

   Notification information can be error messages specifying why a
   security operation fails. It can also be status data that a process
   wishes to communicate with a peer process. [ISAKMP] defines a list
   of error messages. To support security failure handling, the list
   should be extended to have more error messages plus actions. The
   table below lists the original and extended ISAKMP Notification
   messages, which may be used by security related failure handling.

                  DOI-NOT-SUPPORTED              2
                  INVALID-COOKIE                 4
                  INVALID-MAJOR-VERSION          5
                  INVALID-MINOR-VERSION          6
                  INVALID-EXCHANGE-TYPE          7
                  INVALID-FLAGS                  8
                  INVALID-MESSAGE-ID             9
                  INVALID-PROTOCOL-ID            10
                  PAYLOAD-MALFORMED              16
                  INVALID-KEY-INFORMATION        17
                  INVALID-ID-INFORMATION         18
                  INVALID-CERT-ENCODING          19
                  INVALID-CERTIFICATE            20
                  BAD-CERT-REQUEST-SYNTAX        21
                  INVALID-CERT-AUTHORITY         22
                  INVALID-HASH-INFORMATION       23
                  AUTHENTICATION-FAILED          24
                  INVALID-SIGNATURE              25
                  ADDRESS-NOTIFICATION           26
                  RE-SEND                        27
                  BY-PASS                        28
                  RESERVED (Future Use)       29 - 8191
                  Private Use              8192 - 16383

Y. Xu and L. Harn                                             [Page 6]

INTERNET-DRAFT                                            November, 97

   In a batch digital signature transaction, for example, the Initiator
   may receive multiple signatures in one data exchange, and one of the
   signatures fails to verify. The Initiator will notify the sender by
   having error type 25 (INVALID-SIGNATURE) in Notify Message Type
   field and the invalid signature transmitted in Notification Data
   field of the payload. The Responder may reply to the Initiator by
   having action type 28 (BY-PASS) in Notify Message Type field to
   indicate that the invalid signature transmitted should be ignored at
   this time. More error message and action types should be extended in

6.      Security Considerations

   This entire draft discusses a new ISAKMP application to allow
   entities in the network to handle security failures.

7.      References

   [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner,
   "Internet Security Association and Key Management Protocol", draft-
   ietf-ipsec-isakmp-08, July 26, 1997

   [PA97] R. Pereira, S. Anand, "The ISAKMP Configuration Mode", draft-
   ietf-ipsec-isakmp-mode-cfg-01.txt, November 12, 1997

   [RFC1825] R. Atkinson, "Security Architecture for the Internet
   Protocol", RFC 1825, August 1995

   [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System Security
   Extensions", RFC 2065, January 1997.

8.      Contact:

   Yongnan Xu

   Lern Harn

Y. Xu and L. Harn                                             [Page 7]