[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal to formalize the Notification Data field
-----BEGIN PGP SIGNED MESSAGE-----
Many discussions this week in NC, and two weeks ago in Boston
revealed that many want more information in the notification
messages. Specificially, which payload failed, and where the problem
is (in the case of bad protocols or transforms within an SA payload).
At meeting on Tuesday (for which I posted some notes) I volunteered
to write some text. I have sent it to a couple of people, and gotten
some oral and email feedback. Here is it for everyone to mull over.
Although this changes bits on the wire, it changes bits that were
up to this point undefined, and compliant implementations should have
been ignoring if they failed to understand it.
I am undecided if, given my proposals to identify some bits in the
Notification Type if we need rfc821 style result codes or not as
well. I have included them here. I have not made any attempt to define
them better. I am not attached to them, but was discussed on Tuesday.
As Ted points out, we need to add an additional Notify. I had called
it REQUESTED-CERT-UNAVAILABLE. Ted called it something else.
With ISAKMP-09 (expected today, right Doug?), cert request payloads contain
only a single request. If multiple certs are desired, or permitted,
then multiple payloads can be included. If no cert of the desired type
is available, a notify with REQUESTED-CERT-UNAVAILABLE is returned
(rather than silence as before), and the cert request is included to
inform the sender which cert was unavailable.
The severity field would indicate permanent (e.g. doesn't exist) or
temporary (e.g. LDAP server down).
ipsec-doi-07 changes:
4.6.3 IPSEC Notify Message Types
ISAKMP defines eight blocks of Notify Message codes with sections
for errors and status codes. ISAKMP reserves two blocks for itself,
four blocks for private use, and asks the DOI to define error
and a status blocks.
Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192
Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
REQUESTED-CERT-UNAVAILABLE 24579
Notification Status Messages MUST be sent under the protection of an
ISAKMP SA: either as a payload in the last Main Mode exchange; in a
separate Informational Exchange after Main Mode or Aggressive Mode
processing is complete; or as a payload in any Quick Mode exchange.
These messages MUST NOT be sent in Aggressive Mode exchanges unless
the authentication mode is RSA Encryption, since Aggressive Mode does
not otherwise provide the necessary protection to bind the Notify
Status Message to the exchange.
Implementation Note: the ISAKMP protocol does not guarantee delivery
of Notification Status messages when sent in an ISAKMP Informational
Exchange. To ensure receipt of any particular message, the sender
SHOULD include a Notification Payload in a defined Main Mode, Quick
Mode, or Aggressive exchange which is protected by a retransmission
timer.
ISAKMP also defines a notification data area for the DOI to define.
The IPsec DOI defines the following structure to contain it
results. Note: this structure is used for both ISAKMP defined
notify types and for IPSEC DOI defined notify types when the notify
message payload indicates the IPSEC DOI.
3 2 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! bad-prot-id ! RESERVED ! faulty payload length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RESERVED ! offset of fault !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ payload at fault ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! severity code! module code ! error num ! ascii space !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ error text ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o bad-prot-id (1 octet) - Identifier for the payload type of
the payload that was at fault.
This is a payload type as defined in section 3.1 of [ISAKMP] for the
following messages:
INVALID-PAYLOAD-TYPE
PAYLOAD-MALFORMED
INVALID-KEY-INFORMATION
INVALID-ID-INFORMATION
INVALID-CERT-ENCODING
INVALID-CERTIFICATE
BAD-CERT-REQUEST-SYNTAX
INVALID-CERT-AUTHORITY
INVALID-HASH-INFORMATION
INVALID-TRANSFORM-ID
INVALID-PROTOCOL-ID
DOI-NOT-SUPPORTED
SITUATION-NOT-SUPPORTED
INVALID-SIGNATURE
INVALID-SPI
No payload should be included for the following notify types. The
payload length should be zero, and the bad-prot-id should be zero.
INVALID-COOKIE
INVALID-MAJOR-VERSION
INVALID-MINOR-VERSION
INVALID-EXCHANGE-TYPE
INVALID-FLAGS
INVALID-MESSAGE-ID
INVALID-PROTOCOL-ID
INITIAL-CONTACT
The following messages have not yet been categorized.
AUTHENTICATION-FAILED
ADDRESS-NOTIFICATION
ATTRIBUTES-NOT-SUPPORTED
NO-PROPOSAL-CHOSEN
BAD-PROPOSAL-SYNTAX
The following messages have notification data which is defined
elsewhere in this document:
RESPONDER-LIFETIME
REPLAY-STATUS
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the included faulty
payload, including the faulty payloads' generic payload header, the
bad-prot-id, RESERVED, this field, and the fault offset.
o Fault offset (2 octets) - offset from the beginning of the payload
at which the fault was found.
o faulty payload (variable number of octets) - a copy of the payload
which caused the notify to be sent. The payload MAY be
truncated after the section pointed to by the fault
offset. This is useful when large payloads have faults near
the beginning, but the payload is large. An implementation
MUST send at least 8 bytes past the fault offset, and SHOULD
send the entire faulty payload, truncating only at the next
generic header (e.g next transform in a SA proposal)
o severity code (1 octets) - an integer encoded as a single ascii
value. See RFC821, appendix E.
"1" Positive Preliminary reply
"2" Positive Completion reply
"3" Positive Intermediate reply
"4" Transient Negative Completion reply
"5" Permanent Negative Completion reply
o module code - identifies which subsystem is involved (to be defined!)
o error code - number.
o space - The ASCII space value, integer 32.
o error text - a human readable message, encoded in UTF8. One "line" of
text only. Suggested limit is 77 glyphs.
] At cottage, to clean up trees broken by ice: things okay tho | SSH IPsec [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQBVAwUBNQBmIR4XQavxnHg9AQHWIQH/az/kCRe3a2+wdl9FQ7gvPNRoGgfXoLdH
ME1vu3tWgaNDmVGzQTZUP6ETxGYojFDov6IudPJ7D9k1psxuB87iqg==
=+7E0
-----END PGP SIGNATURE-----
Follow-Ups: