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). Abstract 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 securely. 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 IPSEC ESP, IPSEC AH, OSPF, TLS, etc. 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. ___Errors/Actions_____________Value__ 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 future. 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 ynxu@cstp.umkc.edu Lern Harn Lein_Harn_at_HP3@usa.racal.com Y. Xu and L. Harn [Page 7]