idnits 2.17.1 draft-xu-isakmp-app-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 22 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1825' on line 321 looks like a reference -- Missing reference section? 'ISAKMP' on line 314 looks like a reference -- Missing reference section? 'PA97' on line 318 looks like a reference -- Missing reference section? 'RFC2065' on line 324 looks like a reference -- Missing reference section? 'MSST97' on line 245 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Yongnan Xu 2 Nov. 18, 1997 University of Missouri - Kansas City 3 draft-xu-isakmp-app-00.txt Lein Harn 4 Racal Datacom Group 6 The ISAKMP Applications on Security Related Failure Handling 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of 6 months 16 and may be updated, replaced, or may become obsolete by documents at 17 any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as work in progress. 20 To view the entire list of current Internet-Draft, please check the 21 lid-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net(US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 A Security Association is a set of security related information 29 between two or more entities. The Internet Security Association and 30 Key Management Protocol defines procedures and packet formats to 31 authenticate a communicating peer, and establish, negotiate, modify 32 and delete Security Associations. This document describes a new 33 ISAKMP application that utilizes ISAKMP negotiation functions to 34 handle security operation failures of other security protocols. 36 Table of Contents 38 1. Introduction...................................................2 39 2. The Need for ISAKMP Failure Handling...........................2 40 3. Security Failure Handling Transaction..........................4 41 4. Security Failure Handling Payload..............................5 42 5. Notify Message Types...........................................6 43 6. Security Considerations........................................7 44 7. References.....................................................7 45 8. Contact........................................................7 47 1. Introduction 49 A Security Association (SA) is a set of information that can be 50 considered a contract between two or more entities. SAs contain all 51 the information required for execution of various network security 52 services, such as the IP layer services, transport or application 53 layer services, or self-protection of negotiation traffic. The 54 information must be agreed upon and shared between all the peer 55 entities. All entities must adhere to the SA for secure 56 communications to be possible. [RFC1825] defines some parameters for 57 IP security. A Security Association normally includes, such as 58 encryption algorithm and algorithm mode, authentication algorithm 59 and algorithm mode, key size, cryptographic synchronization or 60 initialization vectors, lifetime of the keys, source address(es) of 61 the Security Association, sensitivity level, etc. Other protocols 62 that provide algorithm and mechanism independent security must 63 define their requirements for SA attributes. 65 The Internet Security Association and Key Management Protocol or 66 ISAKMP [ISAKMP] defines procedures and packet formats to 67 authenticate a communicating peer, and establish, negotiate, modify 68 and delete Security Associations (SA). ISAKMP also defines payloads 69 for exchanging key generation and authentication data. These 70 formats provide a consistent framework for transferring key and 71 authentication data which is independent of the key generation 72 technique, encryption algorithm and authentication mechanism. All of 73 these are necessary to establish and maintain secure communications 74 in an Internet environment. ISAKMP is intended to support the 75 negotiation of SAs for security protocols at all layers of the 76 network stack. 78 ISAKMP is a two-phase negotiation procedure. In the first phase, two 79 entities agree on how to protect further negotiation traffic between 80 themselves, establishing an "ISAKMP SA". This ISAKMP SA is then used 81 to protect the negotiations for the "Protocol SA" being requested. 82 The second phase of negotiation is used to establish security 83 associations for other security protocols. The security associations 84 established by ISAKMP during this phase can be used by a security 85 protocol to protect many message/data exchanges. ISAKMP is defined 86 for exchange of Security Associations before the real data 87 exchanges. It should have no regular ISAKMP activities during the 88 period of subsequent data exchanges. 90 Since its strong negotiation functions, ISAKMP can be extended to 91 other applications. [PA97] describes a new ISAKMP mode that can be 92 used to configure secure hosts. This configuration may take place 93 between a gateway, an end-host client, or a configuration manager. 94 For example, this can be used to configure multi-protocol IP tunnels 95 securely. 97 2. The Need for Failure Handling 98 Security related failures may occur during data exchange periods of 99 security protocols. There are two categories of security failures: 100 connection failure and content failure. Connection failure means 101 that a transmission connection is interrupted, that is, disconnected 102 from network problems. The regular network connection functions 103 should take the responsibility to recover the connection when the 104 network problems disappear; but the data exchanges may not be 105 recovered correctly if this is a connection with security 106 operations. The parties may fail to maintain security parameters 107 during the period of disconnection. 109 In practical implementation, digital signatures usually include 110 Time-to-Live parameters [RFC2065]. It is the data between the time 111 it was originally signed and the time the signature should be 112 verified. A legal digital signature may fail to verify when a 113 connection is interrupted by network transmission problems. Another 114 example of connection failures is the lifetime of keys. A data 115 exchange may still fail if lifetime parameters are expired due to 116 the transmission interruption and no update is made for them after 117 the regular network transmission is recovered. Negotiation 118 functions are needed to recover and update the security parameters 119 including Time-to-Live. 121 Content Failure means that the data exchange parties could not get 122 expecting results based on the required security operations, such as 123 digital signature verification failure. In this case, the connection 124 is still valid; but the security protocol may repeatedly try to re- 125 send the same data and finally disconnect if no any mechanisms to 126 improve the security operations. This security failure is different 127 from transmission errors, which will be checked and handled by 128 security protocols or other data communication protocols, such as 129 link layer protocols. 131 One practical example of content failure is multiple-key encryption. 132 A sender may encrypt different parts of a large message using 133 different keys or forward a batch ciphertext file for multiple 134 users. The similar operations are not uncommon in electronic 135 commerce. A receiver may fail to decode a part of the message, so it 136 will usually give up the whole message if no any mechanism to 137 improve the result. Negotiation operations can provide an efficient 138 way to adjust and improve current operation environment for next 139 computation result instead of simply re-send the whole message or 140 reestablish a new connection. For example, the parties may negotiate 141 and continue the decryption by only re-send the false one. 143 Although security failure handling functions can be parts of the 144 security communication protocols that use ISAKMP for SA negotiation, 145 it is a reasonable and simple solution to centralize those 146 responsibilities by utilizing ISAKMP's negotiation functions. As if 147 each security protocol can actually perform its own SA negotiation, 148 ISAKMP is introduced to support SAs negotiation for security 149 protocols at all layers of the network stack (e.g., IPSEC, TLS, 150 TLSP, OSPF, etc.). Since ISAKMP is a basic supporting protocol for 151 all other security protocols, this method will reduce the amount of 152 duplicated security failure handling functionality within each 153 security protocol. This extension centralizes the security failure 154 handling management while each security protocol keeps its own 155 transmission error handling functions. 157 3. Security Failure Handling Transaction 159 A Failure Handling Transaction is a complete procedure for peer 160 parties to notify security operation failures or response solutions 161 during data exchange period. Although a Security Failure Handling 162 Transaction is performed after establishment of an ISAKMP Phase 1 163 and 2 Security Association, it uses the similar procedure as phase 2 164 to negotiate security failure handling. It uses two one-way ISAKMP 165 Informational Exchanges. Each exchange has a standard ISAKMP header 166 and only one special Notification payload. 168 # Initiator Responder 169 --- ----------- ----------- 170 (1) HDR*, N --> 171 (2) <-- HDR*, N 173 HDR: ISAKMP header 174 N: Notification payload 175 *: Payload encryption after the ISAKMP header 177 Figure 1: Failure Handling Transaction 179 The first Informational Exchange is used to notify security 180 operation failure, which is consisted of ISAKMP header and a 181 Notification payload (see section 4). The second Informational 182 Exchange is used to response the notification and reply a solution, 183 which is consisted of ISAKMP header and a Notification payload. 185 For content failure, a security protocol may invoke this transaction 186 directly. At this point, ISAKMP phase 1 and 2 have completed and the 187 ISAKMP header can be protected by Protocol SA from ISAKMP phase 2. A 188 batch encryption, for example, uses different keys for different 189 parts of a message. A receiver of the message may initiate this 190 transaction to indicate a part of the message could not be decrypted 191 successfully instead of request retransmission of the whole message. 193 For connection failure, the peers may try to fix the failure by 194 using the same procedure of the content failure. If not successfully 195 for several times, the peers should initiate a Protocol SA 196 Modification procedure (ISAKMP phase 2 negotiation) to create a new 197 SA. The creation of a new SA is protected by the existing ISAKMP SA. 198 Lifetime of the keys and some other parameters, for example, may be 199 expired or deleted by one party due to the connection failure. The 200 peers initiate this transaction to update Protocol SAs including 201 Lifetime of keys. 203 4. Security Failure Handling Payload 205 Security Failure Handling uses ISAKMP Notification Payload to 206 transmit informational data and instructions, such as error 207 conditions, to a protocol peer. One example for this type of 208 notification is to indicate why a digital signature was rejected. 209 Only one notification payload may be present in one direction in a 210 security failure handling transaction. 212 [ISAKMP] defines the standard Notification Payload format. The 213 payload type for the Notification Payload is eleven (11). This 214 section gives the special values for each field of a payload, which 215 Security Failure Handling exchange uses. 217 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 ! Next Payload ! RESERVED ! Payload Length ! 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 ! Domain of Interpretation (DOI) ! 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 ! Protocol-ID ! SPI Size ! Notify Message Type ! 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 ! ! 227 ~ Notification Data ~ 228 ! ! 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: Notification Payload Format for Security Failure Handling 233 The Notification Payload fields for Security Failure Handling are 234 defined as follows: 236 o Next Payload (1 octet) - Since only one payload is allowed, this 237 field will be 0. 239 o RESERVED (1 octet) - Unused, set to 0. 241 o Payload Length (2 octets) - Length in octets of the current 242 payload, including the generic payload header. 244 o Domain of Interpretation (4 octets) - DOI is described in 245 Section 2.1 in ISAKMP [MSST97]. For the Internet, the DOI is (1). 247 o Protocol-Id (1 octet) - Specifies the protocol identifier which 248 invokes ISAKMP for current notification. Examples might include 249 IPSEC ESP, IPSEC AH, OSPF, TLS, etc. 251 o SPI Size (1 octet) - No SPI for security failure handling. Set 252 to 0. 254 o Notify Message Type (2 octets) - Specifies the type of 255 notification message (see section 5). Additional text, is placed 256 in the Notification Data field. 258 o Notification Data (variable length) - Informational or error 259 data transmitted in addition to the Notify Message Type. 261 5. Notify Message Types 263 Notification information can be error messages specifying why a 264 security operation fails. It can also be status data that a process 265 wishes to communicate with a peer process. [ISAKMP] defines a list 266 of error messages. To support security failure handling, the list 267 should be extended to have more error messages plus actions. The 268 table below lists the original and extended ISAKMP Notification 269 messages, which may be used by security related failure handling. 271 ___Errors/Actions_____________Value__ 272 DOI-NOT-SUPPORTED 2 273 INVALID-COOKIE 4 274 INVALID-MAJOR-VERSION 5 275 INVALID-MINOR-VERSION 6 276 INVALID-EXCHANGE-TYPE 7 277 INVALID-FLAGS 8 278 INVALID-MESSAGE-ID 9 279 INVALID-PROTOCOL-ID 10 280 PAYLOAD-MALFORMED 16 281 INVALID-KEY-INFORMATION 17 282 INVALID-ID-INFORMATION 18 283 INVALID-CERT-ENCODING 19 284 INVALID-CERTIFICATE 20 285 BAD-CERT-REQUEST-SYNTAX 21 286 INVALID-CERT-AUTHORITY 22 287 INVALID-HASH-INFORMATION 23 288 AUTHENTICATION-FAILED 24 289 INVALID-SIGNATURE 25 290 ADDRESS-NOTIFICATION 26 291 RE-SEND 27 292 BY-PASS 28 293 RESERVED (Future Use) 29 - 8191 294 Private Use 8192 - 16383 296 In a batch digital signature transaction, for example, the Initiator 297 may receive multiple signatures in one data exchange, and one of the 298 signatures fails to verify. The Initiator will notify the sender by 299 having error type 25 (INVALID-SIGNATURE) in Notify Message Type 300 field and the invalid signature transmitted in Notification Data 301 field of the payload. The Responder may reply to the Initiator by 302 having action type 28 (BY-PASS) in Notify Message Type field to 303 indicate that the invalid signature transmitted should be ignored at 304 this time. More error message and action types should be extended in 305 future. 307 6. Security Considerations 309 This entire draft discusses a new ISAKMP application to allow 310 entities in the network to handle security failures. 312 7. References 314 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, 315 "Internet Security Association and Key Management Protocol", draft- 316 ietf-ipsec-isakmp-08, July 26, 1997 318 [PA97] R. Pereira, S. Anand, "The ISAKMP Configuration Mode", draft- 319 ietf-ipsec-isakmp-mode-cfg-01.txt, November 12, 1997 321 [RFC1825] R. Atkinson, "Security Architecture for the Internet 322 Protocol", RFC 1825, August 1995 324 [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System Security 325 Extensions", RFC 2065, January 1997. 327 8. Contact: 329 Yongnan Xu 330 ynxu@cstp.umkc.edu 332 Lern Harn 333 Lein_Harn_at_HP3@usa.racal.com