IPSEC Working Group Scott Kelly, INTERNET-DRAFT RedCreek Communications draft-ietf-ipsec-notifymsg-00.txt June, 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 Expires December, 1999 [Page 1] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 Table of Contents 1. Overview ............................................. 3 1.1 Requirements Terminology ......................... 3 1.2 Reader Prerequisites ............................. 4 1.3 Document Organization ............................ 4 2. ISAKMP NOTIFY Error Messages ......................... 4 2.1 INVALID-PAYLOAD-TYPE ............................. 4 2.2 DOI-NOT-SUPPORTED ................................ 5 2.3 SITUATION-NOT-SUPPORTED .......................... 5 2.4 INVALID-COOKIE ................................... 6 2.5 INVALID-MAJOR-VERSION ............................ 6 2.6 INVALID-MINOR-VERSION ............................ 6 2.7 INVALID-EXCHANGE-TYPE ............................ 7 2.8 INVALID-FLAGS .................................... 7 2.9 INVALID-MESSAGE-ID ............................... 8 2.10 INVALID-PROTOCOL-ID .............................. 8 2.11 INVALID-SPI ...................................... 9 2.12 INVALID-TRANSFORM-ID ............................. 9 2.13 ATTRIBUTES-NOT-SUPPORTED ......................... 10 2.14 NO-PROPOSAL-CHOSEN ............................... 10 2.15 BAD-PROPOSAL-SYNTAX .............................. 11 2.16 PAYLOAD-MALFORMED ................................ 11 2.17 INVALID-KEY-INFORMATION .......................... 12 2.18 INVALID-ID-INFORMATION ........................... 12 2.19 INVALID-CERT-ENCODING ............................ 13 2.20 INVALID-CERTIFICATE .............................. 13 2.21 CERT-TYPE-UNSUPPORTED ............................ 14 2.22 INVALID-CERT-AUTHORITY ........................... 14 2.23 INVALID-HASH-INFORMATION ......................... 14 2.24 AUTHENTICATION-FAILED ............................ 15 2.25 INVALID-SIGNATURE ................................ 15 2.26 ADDRESS-NOTIFICATION ............................. 16 2.27 NOTIFY-SA-LIFETIME ............................... 16 2.28 CERTIFICATE-UNAVAILABLE .......................... 17 2.29 UNSUPPORTED-EXCHANGE-TYPE ........................ 17 2.30 UNEQUAL-PAYLOAD-LENGTHS .......................... 17 3. ISAKMP Notify Status messages ......................... 18 3.1 CONNECTED ........................................ 18 4. Security Considerations .............................. 18 5. Editors' Addresses ................................... 19 References .............................................. 19 Full Copyright Statement ................................ 19 Kelly Expires December, 1999 [Page 2] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 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 some cases, it is difficult to determine which SA corresponds the received NOTIFY message. Such determination requires specific NOTIFY payload contents. 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 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, Kelly Expires December, 1999 [Page 3] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 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 At present, 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. 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]. 2.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 in notify data When present, the Notification Payload MUST have the following format: Kelly Expires December, 1999 [Page 4] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 o Payload Length - set to length of payload + size of data (var) o DOI - set to the current DOI for this negotiation o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to INVALID-PAYLOAD-TYPE o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject payload 2.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 in notify payload DOI field When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload o DOI - set to the subject (unsupported) DOI o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to DOI-NOT-SUPPORTED o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - empty 2.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, situation in notify data 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 included in SA payload with situation o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to SITUATION-NOT-SUPPORTED o SPI - set to empty or to the sender's inbound IPSEC SPI Kelly Expires December, 1999 [Page 5] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 o Notification Data - contains unsupported situation value 2.4 INVALID-COOKIE The INVALID-COOKIE error message may be used to communicate that an invalid ISAKMP cookie was received. Phase: 1 or 2 Differentiator: Cookies, message ID invalid cookie in notify data 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 IPSEC DOI (1) o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-COOKIE o SPI - empty o Notification Data - contains the invalid cookie (size may be derived from payload length 2.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 in notify data When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (5) o DOI - set to DOI under which message was received o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-MAJOR-VERSION o SPI - empty o Notification Data - contains the message ID, followed by the invalid version octet 2.6 INVALID-MINOR-VERSION Kelly Expires December, 1999 [Page 6] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 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 in notify data, invalid version in notify data When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (1) o DOI - set to DOI under which message was received o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-MINOR-VERSION o SPI - empty o Notification Data - contains the invalid version octet 2.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 When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (1) o DOI - set to DOI under which message was received o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-EXCHANGE-TYPE o SPI - empty o Notification Data - contains the invalid exchange type octet 2.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. Phase: 1 or 2 Kelly Expires December, 1999 [Page 7] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 Differentiator: Cookies, message ID invalid flags in notify data When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (1) o DOI - set to DOI under which message was received o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-FLAGS o SPI - empty o Notification Data - contains the flags octet with only the unknown/invalid flags bits set (valid bits masked off) 2.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 When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload o DOI - set to DOI under which message was received o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-MESSAGE-ID o SPI - empty o Notification Data - empty In this case, the invalid message ID is contained in the ISAKMP header of the notify message. 2.10 INVALID-PROTOCOL-ID The INVALID-PROTOCOL-ID error message may be used to communicate that an invalid or unrecognized protocol ID was received as part of a proposal payload. Phase: 1 or 2 Differentiator: Cookies, message ID, proposal payload When present, the Notification Payload MUST have the following Kelly Expires December, 1999 [Page 8] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 format: o Payload Length - set to length of payload + size of data (var) o DOI - set to DOI of received packet o Protocol ID - set to invalid protocol ID value o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-PROTOCOL-ID o SPI - empty o Notification Data - contains the proposal payload in which the unrecognized protocol ID was found. 2.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, SPI 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 DOI of received packet o Protocol ID - set to selected Protocol ID from offending SA proposal o SPI Size - set to zero (0) o Notify Message Type - set to INVALID-SPI o SPI - empty o Notification Data - contains the proposal payload in which the invalid SPI was found. 2.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 When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (2) o DOI - set to DOI of received packet o Protocol ID - set to Protocol ID from proposal containing Kelly Expires December, 1999 [Page 9] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 subject transform ID o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to INVALID-TRANSFORM-ID o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the transform number, followed by the invalid transform ID. [note: could include whole transform payload, but this would include SA attrs] 2.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 Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, attributes 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 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 sender's inbound IPSEC SPI o Notification Data - contains an ISAKMP attribute list consisting of the unsupported attributes 2.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 When present, the Notification Payload MUST have the following Kelly Expires December, 1999 [Page 10] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 format: o Payload Length - set to length of payload 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 NO-PROPOSAL-CHOSEN o SPI - set to the two ISAKMP cookies o Notification Data - empty 2.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: 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) Phase: 1 or 2 Differentiator: Cookies, message ID, proposal/transform payload 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero (0) (SPI is in proposal) o Notify Message Type - set to BAD-PROPOSAL-SYNTAX o SPI - empty o Notification Data - contains the improperly-formed proposal or transform payload [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] 2.16 PAYLOAD-MALFORMED The PAYLOAD-MALFORMED error message may be used to communicate that a malformed payload was received. Kelly Expires December, 1999 [Page 11] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 Phase: 1 or 2 Differentiator: Cookies, message ID, malformed payload 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 DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to PAYLOAD-MALFORMED o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the offending payload [Note: This overlaps with BAD-PROPOSAL-SYNTAX...] 2.17 INVALID-KEY-INFORMATION The INVALID-KEY-INFORMATION error message may be used to communicate that the key exchange type specified by the key exchange payload is not supported. Phase: 1 or 2 Differentiator: Cookies, message ID, KE payload 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to INVALID-KEY-INFORMATION o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject key exchange payload 2.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 Differentiator: Cookies, message ID, SPI, ID payload When present, the Notification Payload MUST have the following Kelly Expires December, 1999 [Page 12] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 format: o Payload Length - set to length of payload + size of data (var) o DOI - set to DOI of received packet o Protocol ID - set to PROTO_ISAKMP o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to INVALID-ID-INFORMATION o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains subject ID payload 2.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 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to INVALID-CERT-ENCODING o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the certificate payload 2.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. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, CERT payload 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to INVALID-CERTIFICATE o SPI - set to empty or to the sender's inbound IPSEC SPI Kelly Expires December, 1999 [Page 13] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 o Notification Data - contains subject certificate payload 2.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 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to CERT-TYPE-UNSUPPORTED o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject certificate payload 2.22 INVALID-CERT-AUTHORITY The INVALID-CERT-AUTHORITY error message may be used to communicate that the Certificate Authority in a certificate payload is invalid or improperly formatted. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, CERT payload 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to INVALID-CERT-AUTHORITY o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject certificate payload 2.23 INVALID-HASH-INFORMATION The INVALID-HASH-INFORMATION error message may be used to communicate that the required hash type is not supported. Kelly Expires December, 1999 [Page 14] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, hash payload When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (1) o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to INVALID-HASH-INFORMATION o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject hash payload 2.24 AUTHENTICATION-FAILED The AUTHENTICATION-FAILED error message may be used to communicate that that the authentication operation (hash) produced an incorrect result. 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 o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero (0)or four (4) (one IPSEC SPI) o Notify Message Type - set to AUTHENTICATION-FAILED o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - empty 2.25 INVALID-SIGNATURE The INVALID-SIGNATURE error message may be used to communicate that the required signature type is not supported. 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 (var) Kelly Expires December, 1999 [Page 15] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to INVALID-SIGNATURE o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject signature payload 2.26 ADDRESS-NOTIFICATION The ADDRESS-NOTIFICATION error message may be used to communicate ??? [what is this used for?] Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, address info? 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to ADDRESS-NOTIFICATION o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains ??? 2.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, 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero(0) o Notify Message Type - set to NOTIFY-SA-LIFETIME o SPI - empty o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime Kelly Expires December, 1999 [Page 16] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 2.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 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 DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero (0) or four (4) (one IPSEC SPI) o Notify Message Type - set to CERTIFICATE-UNAVAILABLE o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the subject certificate request 2.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 When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (5) o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to UNSUPPORTED-EXCHANGE-TYPE o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the message ID, followed by the invalid exchange type octet 2.30 UNEQUAL-PAYLOAD-LENGTHS The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate that message length in the ISAKMP header does not match the sum of the actual payload lengths. Phase: 1 or 2 Kelly Expires December, 1999 [Page 17] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 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 (4) o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to zero (0) or four (4)(one IPSEC SPI) o Notify Message Type - set to UNEQUAL-PAYLOAD-LENGTHS o SPI - set to empty or to the sender's inbound IPSEC SPI o Notification Data - contains the actual payload length as a 32-bit unsigned value. 3. 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]. 3.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 (var) o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to 4 (size of the IPSEC SPI) o Notify Message Type - set to CONNECTED o SPI - set to the the sender's inbound IPSEC SPI o Notification Data - empty 4. Security Considerations [This needs substantial filling out with a disclaimer regarding unencrypted and unauthenticated notify messages, a discussion of which notify messages are protected and which aren't, etc.] 5. Editors' Addresses Kelly Expires December, 1999 [Page 18] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 Scott Kelly RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: skelly@redcreek.com Telephone: +1 (510) 745-3969 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 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. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. Kelly Expires December, 1999 [Page 19] Internet Draft draft-ietf-ipsec-notifymsg-00.txt June, 1999 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 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 Expires December, 1999 [Page 20]