Internet Draft IPSEC Working Group Scott Kelly, RedCreek INTERNET-DRAFT Tero Kivinen, SSH draft-ietf-ipsec-notifymsg-02.txt October, 1999 Content Requirements for ISAKMP Notify Messages Status of This Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments on this document should be sent to the IETF IPsec WG discussion list (ipsec@lists.tislabs.com). Abstract The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. Kelly, Kivinen Expires April, 2000 [Page 1] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Table of Contents 1. Overview ............................................. 3 1.1 Requirements Terminology ......................... 3 1.2 Reader Prerequisites ............................. 4 1.3 Document Organization ............................ 4 2. General Formatting Considerations .................... 4 3. ISAKMP NOTIFY Error Messages ......................... 7 3.1 INVALID-PAYLOAD-TYPE ............................. 7 3.2 DOI-NOT-SUPPORTED ................................ 8 3.3 SITUATION-NOT-SUPPORTED .......................... 8 3.4 INVALID-COOKIE ................................... 9 3.5 INVALID-MAJOR-VERSION ............................ 9 3.6 INVALID-MINOR-VERSION ............................ 10 3.7 INVALID-EXCHANGE-TYPE ............................ 10 3.8 INVALID-FLAGS .................................... 11 3.9 INVALID-MESSAGE-ID ............................... 11 3.10 INVALID-PROTOCOL-ID .............................. 12 3.11 INVALID-SPI ...................................... 12 3.12 INVALID-TRANSFORM-ID ............................. 13 3.13 ATTRIBUTES-NOT-SUPPORTED ......................... 13 3.14 NO-PROPOSAL-CHOSEN ............................... 14 3.15 BAD-PROPOSAL-SYNTAX .............................. 14 3.16 PAYLOAD-MALFORMED ................................ 15 3.17 INVALID-KEY-INFORMATION .......................... 16 3.18 INVALID-ID-INFORMATION ........................... 16 3.19 INVALID-CERT-ENCODING ............................ 17 3.20 INVALID-CERTIFICATE .............................. 17 3.21 CERT-TYPE-UNSUPPORTED ............................ 18 3.22 INVALID-CERT-AUTHORITY ........................... 18 3.23 INVALID-HASH-INFORMATION ......................... 19 3.24 AUTHENTICATION-FAILED ............................ 19 3.25 INVALID-SIGNATURE ................................ 20 3.26 ADDRESS-NOTIFICATION ............................. 20 3.27 NOTIFY-SA-LIFETIME ............................... 21 3.28 CERTIFICATE-UNAVAILABLE .......................... 22 3.29 UNSUPPORTED-EXCHANGE-TYPE ........................ 22 3.30 UNEQUAL-PAYLOAD-LENGTHS .......................... 22 4. ISAKMP Notify Status messages ......................... 23 4.1 CONNECTED ........................................ 23 4. Security Considerations .............................. 24 5. Editors' Addresses ................................... 24 References .............................................. 25 Full Copyright Statement ................................ 25 Kelly, Kivinen Expires April, 2000 [Page 2] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 1. Overview The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In many cases, it is difficult to determine which SA corresponds to the received NOTIFY message. Such determination requires that additional information be placed in the notification data section of the NOTIFY payload. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no content or formatting requirements are currently specified for ISAKMP NOTIFY messages. Many of the ISAKMP NOTIFY messages may apply to either phase 1 or phase 2 negotiations. In some cases, the context of the message makes clear what transaction it refers to, e.g. if the NOTIFY message pertains to the ISAKMP (phase 1) SA upon which it is received. However, there are cases in which ambiguities may arise. For example, there may be multiple phase 2 SAs negotiated using a single phase 1 SA, and these may be simultaneously under negotiation. A NOTIFY message received via the parent phase 1 SA may apply to any of the phase 2 SAs, but the receiver may not be able to determine which. In order to be truly useful, NOTIFY messages must, at minimum, allow the receiver to determine which transaction the message corresponds to. As indicated above, in some cases this information may be entirely derived from information contained in the ISAKMP header (cookies and message ID). However, in many cases, and in particular with respect to phase 2 negotiations, the correct context cannot be ascertained without additional information. In some of those cases, the relevant information may be carried in the predefined notify payload fields. In others, this is not enough, and in such cases additional information may be carried in the notify payload data field. In addition to the need to determine which SA a NOTIFY message corresponds to, it would also be useful to know more precisely what problem was encountered. For example, an INVALID-PAYLOAD message would be far more useful if one could determine exactly which payload was at issue. Such additional data would be very useful when diagnosing error conditions, and also would provide useful information for auditing purposes. This document provides content and format recommendations for ISAKMP NOTIFY messages which are aimed at providing the additional granularity required to make these messages truly useful. 1.1 Requirements Terminology Kelly, Kivinen Expires April, 2000 [Page 3] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 1.2 Reader Prerequisites [RFC2407], [RFC2408], and [RFC2409] are prerequisites to understanding the material presented here. While not strictly necessary, reader familiarity with [RFC2401], [RFC2402], [RFC2406], and with general IP security concepts will further facilitate understanding. 1.3 Document Organization In the following section is a discussion of general format considerations for all notify messages. Following that, the NOTIFY messages are presented in 2 sections: ISAKMP error messages, and ISAKMP status messages. It is possible that a later revision of this document will address IPSEC error/status messages, but some of those NOTIFY message types are currently addressed in [RFC2407]. Within each section, messages are detailed in individual subsections. Following the example of [RFC2407], each message payload is detailed field-by-field. Where appropriate, additional information regarding the circumstances under which each message arises, along with relative payload variations under those circumstances, is included. 2. General Formatting Considerations The ISAKMP notify payload contains a number of fields meant to convey contextual information regarding the event precipitating the message. Following is an enumeration of the notify payload fields: (payload type/length fields omitted) o Domain of Interpretation (4 octets) - Identifies the DOI under which this notification is taking place. o Protocol-Id (1 octet) - Specifies the protocol identifier for the current notification. Examples might include ISAKMP, IPSEC ESP, IPSEC AH, OSPF, TLS, etc. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. o Notify Message Type (2 octets) - Specifies the type of notification message. Kelly, Kivinen Expires April, 2000 [Page 4] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 o SPI (variable length) - Security Parameter Index. The receiving entity's SPI. The length of this field is determined by the SPI Size field. o Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. In many cases, the information contained in the notify payload is insufficient to fully identify the session or transaction for which the error(s) occurred, and in these cases the Notification Data field MAY be used to convey additional information. In order to provide for uniform processing of the notification data field, class attributes are defined below for ISAKMP NOTIFY messages, and notification data MUST be encoded using these attributes. Attribute encoding is discussed in [RFC2408], and that discussion is not repeated here, except for the following notes. Attribute encoding types are either Basic (B) or Variable-length (V). Encoding of these attributes is defined in the [RFC2408] as Type/Value (Basic) and Type/Length/Value (Variable-length). Attributes described as Basic MUST NOT be encoded as Variable. Variable attributes MAY be encoded as basic attributes if their value can fit into two octets. Attribute Classes Encoding Type Description Value Type -------------------------------------------------------- Type of Offending Payload 1 B Offending Payload Data 2 V Error Position Offset 3 B Error Text Describing the Problem 4 V Error Text Language 5 V Message Id of the Offending Negotiation 6 V Exchange Type of Negotiation 7 B Invalid Flag Bits 8 B Suggested Proposal 9 V Notification Attribute Version 10 B ------------------------------------------------------- Values 11-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties. Attribute Type Descriptions Kelly, Kivinen Expires April, 2000 [Page 5] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Type of Offending Payload Payload type of the offending payload encoded as a 16 bit integer. Offending Payload Data Offending payload data including the generic header. Note that next payload type in the notify payload itself points to the next payload beyond the notification data. Likewise, the next payload type in the offending payload contains the value placed there by the original sender, and does not reference any payloads within the notify message. Error Position Offset Byte offset of the error position from the beginning of the offending payload. Presence of this attribute implies the presence of the offending payload data attribute. That is, when this attribute is present, there MUST also be a corresponding offending payload attribute. Error Text Describing the Problem Text describing the problem. (ISO-10646 UTF-8 encoding). Error Text Language Error text language tag (as defined in RFC 1766). When this attribute is present, there MUST also be a corresponding error text attribute. Message Id of the Offending Negotiation Message id of the offending negotiation encoded has 4 byte value. Exchange Type of Negotiation Exchange type of the offending negotiation. Encoded as 16 bit integer. Invalid Flag Bits Invalid flags (valid flags are masked out) Encoded as 16 bit integer. Suggested Proposal Optional proposal suggestion to be used in case of failed negotiation due to policy mismatch. Notification Attribute Version Indicates the version of this document from which encodings were derived. MUST be the first attribute in the notification data if notification data is included, and MUST contain the value 0x0001. Because this attribute is always first, it can Kelly, Kivinen Expires April, 2000 [Page 6] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 be used as a magic cookie, i.e. if the notification data begins with bytes 0x80, 0x0A, 0x00, 0x01, then it most likely follows the formatting guidelines described in this document. Note that implementations may not recognize some or all of these attributes, and in some cases, inclusion of some attributes within specific notify messages will be optional. In such cases, implementations MUST ignore unrecognized attributes. 3. ISAKMP NOTIFY Error Messages This section contains NOTIFY error messages which are usually specific to ISAKMP (phase 1) Security Associations (SAs). Some of these messages may also apply to the negotiation of IPSec (phase 2) SAs. In such cases, provision is made for use of the appropriate SPI (and other) values. These NOTIFY message types are defined in [RFC2408]. 3.1 INVALID-PAYLOAD-TYPE The INVALID-PAYLOAD-TYPE error message may be used to communicate that an unrecognized or invalid payload type was received. Phase: 1 or 2 Differentiators: Cookies vs SPI, Subject payload (and/or type) Message ID Payloads: All When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (var) o DOI - set to the current DOI if available, or set to zero (0) to indicate ISAKMP DOI. o Protocol ID - set to selected Protocol ID from chosen SA if available; set to zero (0) to indicate ISAKMP SA. o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to INVALID-PAYLOAD-TYPE o SPI - set to empty or to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the type of the offending payload, and MAY contain the offending payload, the message ID associated with the payload, and error text describing the Kelly, Kivinen Expires April, 2000 [Page 7] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 problem. 3.2 DOI-NOT-SUPPORTED The DOI-NOT-SUPPORTED error message may be used to communicate that an unrecognized or unsupported DOI value was received. Phase: 1 or 2 Differentiators: Cookies vs SPI, Protocol ID, subject DOI, message ID Payloads: SA When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to DOI-NOT-SUPPORTED o SPI - set to empty or to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the offending payload and the message ID associated with the payload. It MAY also contain the error position offset, and error text describing the problem. 3.3 SITUATION-NOT-SUPPORTED The SITUATION-NOT-SUPPORTED error message may be used to communicate that an unrecognized or unsupported situation value was received. Phase: 1 or 2 Differentiator: Cookies vs SPI, Protocol ID, offending payload, message ID Payloads: SA When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to ISAKMP DOI o Protocol ID - set to zero (0) o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to SITUATION-NOT-SUPPORTED o SPI - set to empty or to the ISAKMP cookies for the failed negotiation. Kelly, Kivinen Expires April, 2000 [Page 8] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 o Notification Data - SHOULD contain the offending payload and the message ID associated with the payload. It MAY also contain the error position offset, and error text describing the problem. 3.4 INVALID-COOKIE The INVALID-COOKIE error message may be used to communicate that an invalid ISAKMP cookie was received. Invalid cookies are those cookies for which there is no matching SA. This message applies to a few different situations: o one of the cookies in the pair is not valid o neither of the cookies in the pair are valid Phase: 1 or 2 Differentiator: Cookies, message ID invalid cookie(s) in SPI field Payloads: ISAKMP header When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to INVALID-COOKIE o SPI - set to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the message ID of the offending negotiation, and MAY contain error text describing the problem. 3.5 INVALID-MAJOR-VERSION The INVALID-MAJOR-VERSION error message may be used to communicate that this portion of the ISAKMP version is invalid or unsupported. Phase: 1 or 2 Differentiator: Cookies, message ID invalid version Payloads: ISAKMP header When present, the Notification Payload MUST have the following format: Kelly, Kivinen Expires April, 2000 [Page 9] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to INVALID-MAJOR-VERSION o SPI - set to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the message ID of the offending negotiation, and MAY contain error text describing the problem. 3.6 INVALID-MINOR-VERSION The INVALID-MINOR-VERSION error message may be used to communicate that this portion of the ISAKMP version is invalid or unsupported. Phase: 1 or 2 Differentiator: Cookies, message ID, invalid version Payloads: ISAKMP header When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to INVALID-MINOR-VERSION o SPI - set to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the message ID of the offending negotiation, and MAY contain error text describing the problem. 3.7 INVALID-EXCHANGE-TYPE The INVALID-EXCHANGE-TYPE error message may be used to communicate that that an unrecognized or invalid ISAKMP exchange type was received. Phase: 1 or 2 Differentiator: Cookies, message ID invalid exchange type in notify data Payloads: ISAKMP header When present, the Notification Payload MUST have the following Kelly, Kivinen Expires April, 2000 [Page 10] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 format: o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to INVALID-EXCHANGE-TYPE o SPI - set to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the message ID of the offending negotiation and the invalid exchange type, and MAY contain error text describing the problem. 3.8 INVALID-FLAGS The INVALID-FLAGS error message may be used to communicate that one or more of the received ISAKMP header flags were unrecognized or invalid. Cases where flags are invalid include the following: o The encryption bit is unset/set when it should/shouldn't be o The commit bit is unset/set when it should/shouldn't be o The auth-only bit is unset/set when it should/shouldn't be Phase: 1 or 2 Differentiator: Cookies, message ID invalid flags Payloads: ISAKMP header When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to INVALID-FLAGS o SPI - set to the ISAKMP cookies for the failed negotiation. o Notification Data - contains the flags octet with only the unknown/invalid flags bits set (valid bits masked off) 3.9 INVALID-MESSAGE-ID The INVALID-MESSAGE-ID error message may be used to communicate that the message ID in the received message is unrecognized or invalid. Phase: 1 or 2 Differentiator: Cookies, message ID Kelly, Kivinen Expires April, 2000 [Page 11] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Payloads: ISAKMP header When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to 0 (ISAKMP DOI) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to INVALID-MESSAGE-ID o SPI - set to the ISAKMP cookies for the failed negotiation. o Notification Data - SHOULD contain the message ID of the offending negotiation, and MAY contain error text describing the problem. 3.10 INVALID-PROTOCOL-ID The INVALID-PROTOCOL-ID error message may be used to communicate that an invalid or unsupported protocol ID was received as part of a proposal payload. Phase: 1 or 2 Differentiator: message ID, proposal payload Payloads: Proposal When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-PROTOCOL-ID o SPI - empty o Notification Data - SHOULD contain the offending SA payload, error offset position, and the message ID from the offending negotiation. It MAY contain error text describing the problem. 3.11 INVALID-SPI The INVALID-SPI error message may be used to communicate that an invalid SPI was received as part of a proposal payload. Phase: 1 or 2 Differentiator: Cookies, message ID, offending payload Payloads: Proposal Kelly, Kivinen Expires April, 2000 [Page 12] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-SPI o SPI - set to empty o Notification Data - SHOULD contain the offending SA payload, error offset position, and the message ID from the offending negotiation. It MAY contain error text describing the problem. 3.12 INVALID-TRANSFORM-ID The INVALID-TRANSFORM-ID error message may be used to communicate that an invalid or unrecognized (unimplemented?) transform was received as part of a proposal. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI Payloads: Transform When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-TRANSFORM-ID o SPI - empty o Notification Data - SHOULD contain the offending SA payload, error offset position, and the message ID from the offending negotiation. It MAY contain error text describing the problem. 3.13 ATTRIBUTES-NOT-SUPPORTED The ATTRIBUTES-NOT-SUPPORTED error message may be used to communicate that unrecognized or unsupported attributes were received as part of a proposal. Currently, this message may result from one of the following events: o unacceptable group in IKE new-group-mode negotiation o conflicting lifetime attributes are detected o invalid or unsupported SA attributes are received Kelly, Kivinen Expires April, 2000 [Page 13] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, attributes Payloads: SA When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from subject SA o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to ATTRIBUTES-NOT-SUPPORTED o SPI - set to empty or to the target entity's IPSec SPI; if present, the SPI MUST be from the same proposal payload contains the offending transform. o Notification Data - SHOULD contain the offending SA payload, error offset position, and the message ID from the offending negotiation. It MAY contain error text describing the problem. 3.14 NO-PROPOSAL-CHOSEN The NO-PROPOSAL-CHOSEN error message may be used to communicate that none of the received proposals are acceptable to the responder. Phase: 1 or 2 Differentiator: Cookies, message ID Payloads: SA When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (4) o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from subject SA o SPI Size - set to sixteen (16) o Notify Message Type - set to NO-PROPOSAL-CHOSEN o SPI - set to ISAKMP cookies o Notification Data - SHOULD contain the message ID of the offending negotiation, and MAY contain error text describing the problem. MAY also contain a proposal suggestion. 3.15 BAD-PROPOSAL-SYNTAX The BAD-PROPOSAL-SYNTAX error message may be used to communicate that a received proposal is improperly formed. This message may be precipitated by the following events (among others): Kelly, Kivinen Expires April, 2000 [Page 14] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 o a reserved field in a proposal payload does not contain zero (0) o a reserved field in a transform payload does not contain zero (0) o responder returns SA payload containing multiple proposals o responder returns multiple (or no) transforms o initiator attempts to negotiate multiple quick mode SAs but responder only answers to one of them. Phase: 1 or 2 Differentiator: Cookies, message ID, proposal/transform payload Payloads: Generic Payload Header, Proposal, Transform When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) or sixteen (16) o Notify Message Type - set to BAD-PROPOSAL-SYNTAX o SPI - empty or ISAKMP cookies o Notification Data - SHOULD contain the offending SA payload, error offset position, and the message ID from the offending negotiation. It MAY contain error text describing the problem. [Note: There's an ambiguity here due to overloading this error type. It would be resolved by adding a BAD-TRANSFORM-SYNTAX error, and only using this one for proposals. Alternatively, we could add an identifier to this message to distinguish between the two cases] 3.16 PAYLOAD-MALFORMED The PAYLOAD-MALFORMED error message may be used to communicate that a malformed payload was received. This includes proposals, transforms, or attributes that are syntactically incorrect. Phase: 1 or 2 Differentiator: Cookies, message ID, malformed payload Payloads: Generic Payload Header, Proposal, Transform When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to ISAKMP DOI (0) Kelly, Kivinen Expires April, 2000 [Page 15] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 o Protocol ID - set to selected Protocol ID from subject SA if available, else set to protocol PROTO_ISAKMP o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) o Notify Message Type - set to PAYLOAD-MALFORMED o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; otherwise, contains SPI associated with Protocol ID if applicable, or nothing. o Notification Data - SHOULD contain the type of the offending payload, the payload data, the error position offset, and the message ID of the offending negotiation. It MAY contain error text describing the problem. [Note: This overlaps with BAD-PROPOSAL-SYNTAX...] 3.17 INVALID-KEY-INFORMATION The INVALID-KEY-INFORMATION error message may be used to communicate that the key exchange payload is not the correct size. Phase: 1 or 2 Differentiator: Cookies, message ID, KE payload Payloads: Key Exchange When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to ISAKMP DOI (0) o Protocol ID - set to selected Protocol ID from subject SA if available, else set to protocol PROTO_ISAKMP o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) o Notify Message Type - set to INVALID-KEY-INFORMATION o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; otherwise, contains SPI associated with Protocol ID if applicable, or nothing. o Notification Data - SHOULD contain the offending payload, the error position offset, and the message ID of the offending negotiation. It MAY contain error text describing the problem. 3.18 INVALID-ID-INFORMATION The INVALID-ID-INFORMATION error message may be used to communicate that the identification type of the ID payload is not supported. Phase: 1 or 2 Kelly, Kivinen Expires April, 2000 [Page 16] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Differentiator: Cookies, message ID, SPI, ID payload Payloads: ID When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from subject SA if phase 2, else set to protocol PROTO_ISAKMP o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) o Notify Message Type - set to INVALID-ID-INFORMATION o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; otherwise, contains SPI associated with Protocol ID if applicable, or nothing. o Notification Data - SHOULD contain the offending payload, the error position offset, and the message ID of the offending negotiation. It MAY contain error text describing the problem. 3.19 INVALID-CERT-ENCODING The INVALID-CERT-ENCODING error message may be used to communicate that the encoding of a received certificate payload is not valid. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, CERT payload Payloads: Certificate, Certificate Request When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to INVALID-CERT-ENCODING o SPI - set to empty or to the ISAKMP cookies o Notification Data - SHOULD contain the offending certificate payload, error position offset, and Message ID. It MAY contain error text describing the problem. 3.20 INVALID-CERTIFICATE The INVALID-CERTIFICATE error message may be used to communicate that the data in a certificate payload is invalid or improperly formatted. Kelly, Kivinen Expires April, 2000 [Page 17] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, CERT payload Payloads: Certificate When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to INVALID-CERTIFICATE o SPI - set to empty or to the ISAKMP cookies o Notification Data - SHOULD contain the offending certificate payload, error position offset, and Message ID. It MAY contain error text describing the problem. 3.21 CERT-TYPE-UNSUPPORTED The CERT-TYPE-UNSUPPORTED error message may be used to communicate that the encoding of a received certificate payload is not supported. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, CERT payload Payloads: Certificate Request When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to CERT-TYPE-UNSUPPORTED o SPI - set to empty or to the ISAKMP cookies o Notification Data - SHOULD contain the offending certificate request payload, error position offset, and Message ID. It MAY contain error text describing the problem. 3.22 INVALID-CERT-AUTHORITY The INVALID-CERT-AUTHORITY error message may be used to communicate that the Certificate Authority in a certificate request payload is invalid or improperly formatted. Phase: 1 Kelly, Kivinen Expires April, 2000 [Page 18] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Differentiator: Cookies, message ID, SPI, CERT-REQ payload Payloads: Certificate Request When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or sixteen (16) o Notify Message Type - set to INVALID-CERT-AUTHORITY o SPI - set to empty or to the ISAKMP cookies o Notification Data - SHOULD contain the offending certificate request payload, error position offset, and Message ID. It MAY contain error text describing the problem. 3.23 INVALID-HASH-INFORMATION The INVALID-HASH-INFORMATION error message may be used to communicate that that the hash size is incorrect. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, hash payload Payloads: Hash When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA or PROTO_ISAKMP o SPI Size - set to either zero (0), four (4), or sixteen (16) o Notify Message Type - set to INVALID-HASH-INFORMATION o SPI - set to empty, the target entity's IPSec SPI, or the ISAKMP cookies o Notification Data - SHOULD contain the offending hash payload error position offset, and Message ID. It MAY contain error text describing the problem. 3.24 AUTHENTICATION-FAILED The AUTHENTICATION-FAILED error message may be used to communicate that that the authentication operation (hash) produced an incorrect result. Kelly, Kivinen Expires April, 2000 [Page 19] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Phase: 1 or 2 Differentiator: Cookies, message ID, SPI Payloads: Hash, Signature When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA or PROTO_ISAKMP o SPI Size - set to either zero (0), four (4), or sixteen (16) o Notify Message Type - set to AUTHENTICATION-FAILED o SPI - set to empty, the target entity's IPSec SPI, or the ISAKMP cookies o Notification Data - SHOULD contain the Message ID of the offending payload. It MAY contain error text describing the problem. 3.25 INVALID-SIGNATURE The INVALID-SIGNATURE error message may be used to communicate that the signature is the wrong size. NOTE: If signature verification fails, AUTHENTICATION-FAILED is sent. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI Payloads: Signature When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA or PROTO_ISAKMP o SPI Size - set to either zero (0), four (4), or sixteen (16) o Notify Message Type - set to INVALID-SIGNATURE o SPI - set to empty, the target entity's IPSec SPI, or the ISAKMP cookies o Notification Data - SHOULD contain the offending Message ID. It MAY contain error text describing the problem. 3.26 ADDRESS-NOTIFICATION The ADDRESS-NOTIFICATION error message may be used to communicate Kelly, Kivinen Expires April, 2000 [Page 20] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 that an invalid address was received in the ID payload. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, address info? Payloads: ID When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA or PROTO_ISAKMP o SPI Size - set to either zero (0), four (4), or sixteen (16) o Notify Message Type - set to ADDRESS-NOTIFICATION o SPI - set to empty, the target entity's IPSec SPI, or the ISAKMP cookies o Notification Data - SHOULD contain the offending ID payload and the associated message ID. It MAY contain error text describing the problem. 3.27 NOTIFY-SA-LIFETIME The NOTIFY-SA-LIFETIME message may be used to communicate that a lifetime which is shorter than the one requested will be enforced. Phase: 1 Differentiator: Cookies, message ID, Payloads: Transform When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to four (4) or sixteen (16) o Notify Message Type - set to NOTIFY-SA-LIFETIME o SPI - set to the target entity's IPSec SPI, or the ISAKMP cookies o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime WARNING: the attribute classes for the ISAKMP attribute list are defined in the ISAKMP DOI document (RFC2407). This message type is included here for completeness. Kelly, Kivinen Expires April, 2000 [Page 21] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 3.28 CERTIFICATE-UNAVAILABLE The CERTIFICATE-UNAVAILABLE error message may be used to communicate that the requested certificate is unavailable. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, CERT-REQ payload Payloads: Certificate Request When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) or sixteen (16) o Notify Message Type - set to CERTIFICATE-UNAVAILABLE o SPI - set to empty or to the ISAKMP cookies o Notification Data - SHOULD contain the subject certificate request payload and the associated message ID. MAY contain error text describing the problem. 3.29 UNSUPPORTED-EXCHANGE-TYPE The UNSUPPORTED-EXCHANGE-TYPE error message may be used to communicate that the requested exchange type is not supported. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, exchange type Payloads: ISAKMP header When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to 0 o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to sixteen (16) o Notify Message Type - set to UNSUPPORTED-EXCHANGE-TYPE o SPI - set to ISAKMP cookies o Notification Data - SHOULD contain the message ID of the offending negotiation and the offending exchange type. MAY contain error text describing the problem. 3.30 UNEQUAL-PAYLOAD-LENGTHS Kelly, Kivinen Expires April, 2000 [Page 22] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate that the message length in the ISAKMP header does not match the sum of the actual payload lengths. It may also be used when data attributes overflow their encapsulating payload boundaries. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet or zero (0) o Protocol ID - set to PROTO_ISAKMP or selected Protocol ID from chosen SA o SPI Size - set to four (4) or (16) o Notify Message Type - set to UNEQUAL-PAYLOAD-LENGTHS o SPI - set to the target entity's IPSec SPI or the ISAKMP cookies o Notification Data - SHOULD contain the type of the offending payload. It MAY contain the offending payload, the associated message ID, the error position offset, and error text describing the problem. 4. ISAKMP Notify Status messages This section contains NOTIFY status messages which are specific to ISAKMP, or phase 1 Security Associations (SAs). These NOTIFY message types are defined in [RFC2408]. 4.1 CONNECTED The CONNECTED status message may be used to communicate that the IPSEC protocol (phase 2) SA has been established. When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP or selected Protocol ID from chosen SA o SPI Size - set to zero (0), four (4) or sixteen (16) o Notify Message Type - set to CONNECTED o SPI - set to the selected SPI o Notification Data - empty Kelly, Kivinen Expires April, 2000 [Page 23] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 4. Security Considerations In general, accepting unauthenticated NOTIFY messages renders an implementation susceptible to numerous attacks, both passive and active. In such cases, there is no assurance whatsoever that these messages are not being sent by an attacker intent upon mounting a simple denial of service attack, or perhaps a more sophisticated attack. Hence, applications MUST NOT rely upon information provided by such unprotected exchanges. Furthermore, the inclusion of variable notification payloads within unprotected messages presents a significant denial of service opportunity to a hostile adversary. Thus, implementations which choose to inspect unprotected notification data are well advised to limit the amount of processing expended upon such packets. In cases where received payloads are copied into notification data, if the original payload was encrypted, the resulting notify message MUST be encrypted with at least the same level of protection that the original payload had. Otherwise, numerous attacks are possible. 5. Editors' Addresses Scott Kelly RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: skelly@redcreek.com Telephone: +1 (510) 745-3969 Tero Kivinen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: kivinen@ssh.fi The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@lists.tislabs.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@MIT.EDU Kelly, Kivinen Expires April, 2000 [Page 24] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Massachusetts Institute of Technology References [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2409] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Acknowledgements The editors would like to acknowledge all the helpful comments received from numerous members of the IPSec working group, including S. Frankel of NIST, T. Zegman of Checkpoint, D. Mason of Network Associates, V. Smyslov of Trustworks, and A. Potluri of TRI. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Kelly, Kivinen Expires April, 2000 [Page 25] Internet Draft draft-ietf-ipsec-notifymsg-02.txt October, 1999 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kelly, Kivinen Expires April, 2000 [Page 26]