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]
