Internet DRAFT - draft-xu-isakmp-app


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, (Europe), (Pacific Rim), East Coast), or (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]