< draft-ietf-ipsec-isakmp-06.txt		draft-ietf-ipsec-isakmp-07.txt >
	IPSEC Working Group Douglas Maughan, Mark Schertler		IPSEC Working Group Douglas Maughan, Mark Schertler
	INTERNET-DRAFT Mark Schneider, Jeff Turner		INTERNET-DRAFT Mark Schneider, Jeff Turner
	draft-ietf-ipsec-isakmp-06.txt, .ps November 22, 1996		draft-ietf-ipsec-isakmp-07.txt, .ps February 21, 1997
	Expire in six months		Expire in six months
	Internet Security Association and Key Management Protocol (ISAKMP)		Internet Security Association and Key Management Protocol (ISAKMP)
	Abstract		Abstract
	This memo describes a protocol utilizing security concepts		This memo describes a protocol utilizing security concepts
	necessary for establishing Security Associations (SA) and crypto-		necessary for establishing Security Associations (SA) and crypto-
	graphic keys in an Internet environment. A Security Association		graphic keys in an Internet environment. A Security Association
	protocol that negotiates, establishes, modifies and deletes		protocol that negotiates, establishes, modifies and deletes
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21		2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21		2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21
	2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21		2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21
	2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21		2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21
	3 ISAKMP Payloads 22		3 ISAKMP Payloads 22
	3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22		3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22
	3.2 Payload Generic Header . . . . . . . . . . . . . . . . . . . . . 25		3.2 Payload Generic Header . . . . . . . . . . . . . . . . . . . . . 25
	3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 25
	3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 26		3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 26
	3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 27		3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 27
	3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 28		3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 29
	3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 30		3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 30
	3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 30		3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 31
	3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 31		3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 32
	3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 33		3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 33
	3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 34		3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 35		3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 35
	3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36		3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 36		3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 37
	3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 38		3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 39
	3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 39		3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 40
	4 ISAKMP Exchanges 41		4 ISAKMP Exchanges 41
	4.1 Security Association Establishment . . . . . . . . . . . . . . . 41		4.1 Security Association Establishment . . . . . . . . . . . . . . . 41
	4.1.1Security Association Establishment Examples . . . . . . . . . 42		4.1.1Security Association Establishment Examples . . . . . . . . . 43
	4.2 Security Association Modification . . . . . . . . . . . . . . . . 44		4.2 Security Association Modification . . . . . . . . . . . . . . . . 45
	4.3 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 45		4.3 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 46
	4.3.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		4.3.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 46		4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 47		4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 48
	4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 49		4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 50
	4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 50		4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
	4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 51		4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 52
	5 ISAKMP Payload Processing 52		5 ISAKMP Payload Processing 53
	5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 52		5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 53
	5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 52		5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 53
	5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 54		5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 55
	5.4 Security Association Payload Processing . . . . . . . . . . . . . 55		5.4 Security Association Payload Processing . . . . . . . . . . . . . 56
	5.4.1Proposal Payload Processing . . . . . . . . . . . . . . . . . 57		5.4.1Proposal Payload Processing . . . . . . . . . . . . . . . . . 58
	5.4.2Transform Payload Processing . . . . . . . . . . . . . . . . . 58		5.4.2Transform Payload Processing . . . . . . . . . . . . . . . . . 59
	5.5 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 59		5.5 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 60
	5.6 Identification Payload Processing . . . . . . . . . . . . . . . . 60		5.6 Identification Payload Processing . . . . . . . . . . . . . . . . 61
	5.7 Certificate Payload Processing . . . . . . . . . . . . . . . . . 61		5.7 Certificate Payload Processing . . . . . . . . . . . . . . . . . 62
	5.8 Certificate Request Payload Processing . . . . . . . . . . . . . 62		5.8 Certificate Request Payload Processing . . . . . . . . . . . . . 63
	5.9 Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 63		5.9 Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 64
	5.10Signature Payload Processing . . . . . . . . . . . . . . . . . . 64		5.10Signature Payload Processing . . . . . . . . . . . . . . . . . . 65
	5.11Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 65		5.11Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 66
	5.12Notification Payload Processing . . . . . . . . . . . . . . . . . 66		5.12Notification Payload Processing . . . . . . . . . . . . . . . . . 67
	5.13Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 66		5.13Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 67
	6 Conclusions 68		6 Conclusions 69
	A ISAKMP Security Association Attributes 69		A ISAKMP Security Association Attributes 70
	A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 69		A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 70
	A.2 Assigned Values for the Internet IP Security DOI . . . . . . . . 69		A.2 Assigned Values for the Internet IP Security DOI . . . . . . . . 70
	A.2.1Internet IP Security DOI Assigned Value . . . . . . . . . . . 69		A.2.1Internet IP Security DOI Assigned Value . . . . . . . . . . . 70
	A.2.2Supported Security Protocols . . . . . . . . . . . . . . . . . 69		A.2.2Supported Security Protocols . . . . . . . . . . . . . . . . . 70
	B Defining a new Domain of Interpretation 71		B Defining a new Domain of Interpretation 72
	B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71		B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
	B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 72		B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 73
	B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 72		B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 73
	B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 72		B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 73
	B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 72		B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 73
	B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 72		B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 73
	List of Figures		List of Figures
	1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 18		1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 18
	2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22		2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22
	3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 25		3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 25
	4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 26		4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 26
	5 Security Association Payload . . . . . . . . . . . . . . . . . . 27		5 Security Association Payload . . . . . . . . . . . . . . . . . . 27
	6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 28		6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 28
	7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 29		7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 29
	8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 30		8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 30
	9 Identification Payload Format . . . . . . . . . . . . . . . . . . 31		9 Identification Payload Format . . . . . . . . . . . . . . . . . . 31
	10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 32		10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 32
	11 Certificate Request Payload Format . . . . . . . . . . . . . . . 33		11 Certificate Request Payload Format . . . . . . . . . . . . . . . 34
	12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 34		12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 35
	13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 35		13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 36
	14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 36		14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 37
	15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 37		15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 38
	16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 40		16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 40
	1 Introduction		1 Introduction
	This document describes an Internet Security Association and Key Manage-		This document describes an Internet Security Association and Key Manage-
	ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen-		ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen-
	tication, key management, and security associations to establish the re-		tication, key management, and security associations to establish the re-
	quired security for government, commercial, and private communications on		quired security for government, commercial, and private communications on
	the Internet.		the Internet.
	skipping to change at page 18, line 26 ¶		skipping to change at page 18, line 26 ¶
	! Transport Protocol (TCP / UDP) !		! Transport Protocol (TCP / UDP) !
	+----------+ !---------------------------------------------!		+----------+ !---------------------------------------------!
	! Security ! <----> ! IP !		! Security ! <----> ! IP !
	! Protocol ! !---------------------------------------------!		! Protocol ! !---------------------------------------------!
	+----------+ ! Link Layer Protocol !		+----------+ ! Link Layer Protocol !
	+---------------------------------------------+		+---------------------------------------------+
	Figure 1: ISAKMP Relationships		Figure 1: ISAKMP Relationships
	themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to pro-		themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to pro-
	tect the negotiations for the Protocol SA being requested.		tect the negotiations for the Protocol SA being requested. Two ISAKMP
			servers can negotiate (and have active) multiple ISAKMP SAs.
	The second phase of negotiation is used to establish security associa-		The second phase of negotiation is used to establish security associa-
	tions for other security protocols. This second phase can be used to pro-		tions for other security protocols. This second phase can be used to pro-
	tect many security associations. The security associations established		tect many security associations. The security associations established
	by ISAKMP during this phase can be used by a security protocol to protect		by ISAKMP during this phase can be used by a security protocol to protect
	many message/data exchanges.		many message/data exchanges.
	While the two-phased approach has a higher start-up cost for most simple		While the two-phased approach has a higher start-up cost for most simple
	scenarios, there are several reasons that it is beneficial for most cases.		scenarios, there are several reasons that it is beneficial for most cases.
	skipping to change at page 22, line 16 ¶		skipping to change at page 22, line 16 ¶
	in the ISAKMP Header (described in section 3.1) Initiator and Responder		in the ISAKMP Header (described in section 3.1) Initiator and Responder
	cookie fields. These fields are 8 octets in length, thus, requiring a		cookie fields. These fields are 8 octets in length, thus, requiring a
	generated cookie to be 8 octets.		generated cookie to be 8 octets.
	3 ISAKMP Payloads		3 ISAKMP Payloads
	ISAKMP payloads provide modular building blocks for constructing ISAKMP		ISAKMP payloads provide modular building blocks for constructing ISAKMP
	messages. The presence and ordering of payloads in ISAKMP is defined by		messages. The presence and ordering of payloads in ISAKMP is defined by
	and dependent upon the Exchange Type Field located in the ISAKMP Header		and dependent upon the Exchange Type Field located in the ISAKMP Header
	(see Figure 2). The ISAKMP payload types are discussed in sections 3.4		(see Figure 2). The ISAKMP payload types are discussed in sections 3.4
	through 3.15.		through 3.15. The descriptions of the ISAKMP payloads, messages, and ex-
			changes (see Section 4) are shown using network byte ordering. Addition-
			ally, all ISAKMP payloads MUST be aligned at 4-byte multiples.
	3.1 ISAKMP Header Format		3.1 ISAKMP Header Format
	An ISAKMP message has a fixed header format, shown in Figure 2, followed		An ISAKMP message has a fixed header format, shown in Figure 2, followed
	by a variable number of payloads. A fixed header simplifies parsing, pro-		by a variable number of payloads. A fixed header simplifies parsing, pro-
	viding the benefit of protocol parsing software that is less complex and		viding the benefit of protocol parsing software that is less complex and
	easier to implement. The fixed header contains the information required		easier to implement. The fixed header contains the information required
	by the protocol to maintain state, process payloads and possibly prevent		by the protocol to maintain state, process payloads and possibly prevent
	denial of service or replay attacks.		denial of service or replay attacks.
	skipping to change at page 23, line 35 ¶		skipping to change at page 23, line 37 ¶
	Nonce (NONCE) 10		Nonce (NONCE) 10
	Notification (N) 11		Notification (N) 11
	Delete (D) 12		Delete (D) 12
	RESERVED 13- 127		RESERVED 13- 127
	Private USE 128 - 255		Private USE 128 - 255
	o Major Version (4 bits) - indicates the major version of the ISAKMP		o Major Version (4 bits) - indicates the major version of the ISAKMP
	protocol in use. Implementations based on this version of the ISAKMP		protocol in use. Implementations based on this version of the ISAKMP
	Internet-Draft MUST set the Major Version to 1. Implementations		Internet-Draft MUST set the Major Version to 1. Implementations
	based on previous versions of ISAKMP Internet-Drafts MUST set the		based on previous versions of ISAKMP Internet-Drafts MUST set the
	Major Version to 0.		Major Version to 0. Implementations SHOULD never accept packets with
			a major version number larger than its own.
	o Minor Version (4 bits) - indicates the minor version of the ISAKMP		o Minor Version (4 bits) - indicates the minor version of the ISAKMP
	protocol in use. Implementations based on this version of the ISAKMP		protocol in use. Implementations based on this version of the ISAKMP
	Internet-Draft MUST set the Minor Version to 0. Implementations		Internet-Draft MUST set the Minor Version to 0. Implementations
	based on previous versions of ISAKMP Internet-Drafts MUST set the		based on previous versions of ISAKMP Internet-Drafts MUST set the
	Minor Version to 1.		Minor Version to 1. Implementations SHOULD never accept packets with
			a minor version number larger than its own, given the major version
			numbers are identical.
	o Exchange Type (1 octet) - indicates the type of exchange being used.		o Exchange Type (1 octet) - indicates the type of exchange being used.
	This dictates the message and payload orderings in the ISAKMP		This dictates the message and payload orderings in the ISAKMP
	exchanges.		exchanges.
	____Exchange_Type______Value___		____Exchange_Type______Value___
	NONE 0		NONE 0
	Base 1		Base 1
	Identity Protection 2		Identity Protection 2
	Authentication Only 3		Authentication Only 3
	skipping to change at page 24, line 46 ¶		skipping to change at page 24, line 46 ¶
	Commit Bit MUST wait for an Informational Exchange that the SA		Commit Bit MUST wait for an Informational Exchange that the SA
	establishment was successful before proceeding with encrypted		establishment was successful before proceeding with encrypted
	traffic communication.		traffic communication.
	o Message ID (4 octets) - Unique Message Identifier used to identify		o Message ID (4 octets) - Unique Message Identifier used to identify
	protocol state during Phase 2 negotiations. This value is randomly		protocol state during Phase 2 negotiations. This value is randomly
	generated by the initiator of the Phase 2 negotiation. During Phase		generated by the initiator of the Phase 2 negotiation. During Phase
	1 negotiations, the value MUST be set to 0.		1 negotiations, the value MUST be set to 0.
	o Length (4 octets) - Length of total message (header + payloads) in		o Length (4 octets) - Length of total message (header + payloads) in
	octets.		octets. Encryption can expand the size of an ISAKMP message. This
			issue is addressed in [IPDOI] and [IO-Res].
	3.2 Payload Generic Header		3.2 Payload Generic Header
	Each ISAKMP payload defined in sections 3.4 through 3.15 begins with a		Each ISAKMP payload defined in sections 3.4 through 3.15 begins with a
	generic header, shown in Figure 3.2, which provides a payload "chaining"		generic header, shown in Figure 3.2, which provides a payload "chaining"
	capability and clearly defines the boundaries of a payload.		capability and clearly defines the boundaries of a payload.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 25, line 37 ¶		skipping to change at page 25, line 37 ¶
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
	3.3 Data Attributes		3.3 Data Attributes
	There are several instances within ISAKMP where it is necessary to repre-		There are several instances within ISAKMP where it is necessary to repre-
	sent Data Attributes. An example of this is the Security Association (SA)		sent Data Attributes. An example of this is the Security Association (SA)
	Attributes contained in the Transform payload (described in section 3.6).		Attributes contained in the Transform payload (described in section 3.6).
	These Data Attributes are not an ISAKMP payload, but are contained within		These Data Attributes are not an ISAKMP payload, but are contained within
	ISAKMP payloads.The format of the Data Attributes provides the flexibility		ISAKMP payloads. The format of the Data Attributes provides the flexi-
	for representation of many different types of information.		bility for representation of many different types of information. There
			can be multiple Data Attributes within a payload. This is done using the
			Attribute Format bit described below. The length of the Data Attributes
			will either be 4 octets or defined by the Attribute Length field.
	The Data Attributes fields are defined as follows:		The Data Attributes fields are defined as follows:
	o Attribute Type (2 octets) - Unique identifier for each type of		o Attribute Type (2 octets) - Unique identifier for each type of
	attribute. These attributes are defined as part of the DOI-specific		attribute. These attributes are defined as part of the DOI-specific
	information.		information.
	The most significant bit, or Attribute Format (AF), indicates whether
	the data attributes follow the Type/Length/Value (TLV) format or a
	shortened Type/Value (TV) format. If the AF bit is a zero (0), then
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	!A! Attribute Type ! AF=0 Attribute Length !		!A! Attribute Type ! AF=0 Attribute Length !
	!F! ! AF=1 Attribute Value !		!F! ! AF=1 Attribute Value !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. AF=0 Attribute Value .		. AF=0 Attribute Value .
	. AF=1 Not Transmitted .		. AF=1 Not Transmitted .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Data Attributes		Figure 4: Data Attributes
			The most significant bit, or Attribute Format (AF), indicates whether
			the data attributes follow the Type/Length/Value (TLV) format or a
			shortened Type/Value (TV) format. If the AF bit is a zero (0), then
	the Data Attributes are of the Type/Length/Value (TLV) form. If the		the Data Attributes are of the Type/Length/Value (TLV) form. If the
	AF bit is a one (1), then the Data Attributes are of the Type/Value		AF bit is a one (1), then the Data Attributes are of the Type/Value
	form.		form.
	o Attribute Length (2 octets) - Length in octets of the Attribute		o Attribute Length (2 octets) - Length in octets of the Attribute
	Value. When the AF bit is a one (1), the Attribute Value is only 2		Value. When the AF bit is a one (1), the Attribute Value is only 2
	octets and the Attribute Length field is not present.		octets and the Attribute Length field is not present.
	o Attribute Value (variable length) - Value of the attribute associated		o Attribute Value (variable length) - Value of the attribute associated
	with the DOI-specific Attribute Type. If the AF bit is a zero (0),		with the DOI-specific Attribute Type. If the AF bit is a zero (0),
	this field has a variable length defined by the Attribute Length		this field has a variable length defined by the Attribute Length
	field and the field is right justified with zeros prepended for word		field. If the Attribute Value is not aligned at a 4-byte multiple,
	alignment. If the Attribute Value is not word aligned, the remaining		the field is right justified and the remaining bits MUST be prepended
	bits MUST be filled with 0. If the AF bit is a one (1), the		with 0 for 4-byte alignment. If the AF bit is a one (1), the
	Attribute Value has a length of 2 octets.		Attribute Value has a length of 2 octets.
	3.4 Security Association Payload		3.4 Security Association Payload
	The Security Association Payload is used to negotiate security attributes		The Security Association Payload is used to negotiate security attributes
	and to indicate the Domain of Interpretation (DOI) and Situation under		and to indicate the Domain of Interpretation (DOI) and Situation under
	which the negotiation is taking place. Figure 5 shows the format of the		which the negotiation is taking place. Figure 5 shows the format of the
	Security Association payload.		Security Association payload.
	The Security Association Payload fields are defined as follows:		The Security Association Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next		o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the		payload in the message. If the current payload is the last in the
	message, then this field will be 0.		message, then this field will be 0. This field MUST NOT contain the
			values for the Proposal or Transform payloads as they are considered
	o RESERVED (1 octet) - Unused, set to 0.		part of the security association negotiation. For example, this
	o Payload Length (2 octets) - Length in octets of the entire Security
	Association proposal, including the generic payload header, SA
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Domain of Interpretation (DOI) !		! Domain of Interpretation (DOI) !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Situation ~		~ Situation ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Security Association Payload		Figure 5: Security Association Payload
	payload, all Proposal payloads, and all Transform payloads associated		field would contain the value "10" (Nonce payload) in the first
	with the proposed Security Association.		message of a Base Exchange (see Section 4.4) and the value "0" in the
			first message of an Identity Protect Exchange (see Section 4.5).
			o RESERVED (1 octet) - Unused, set to 0.
			o Payload Length (2 octets) - Length in octets of the entire Security
			Association payload, including the SA payload, all Proposal payloads,
			and all Transform payloads associated with the proposed Security
			Association.
	o Domain of Interpretation (4 octets) - Identifies the DOI (as		o Domain of Interpretation (4 octets) - Identifies the DOI (as
	described in Section 2.1) under which this negotiation is taking		described in Section 2.1) under which this negotiation is taking
	place. For the Internet, the DOI is one (1). Other DOI's can be		place. For the Internet, the DOI is one (1). Other DOI's can be
	defined using the description in appendix B.		defined using the description in appendix B.
	o Situation (variable length) - A DOI-specific field that identifies		o Situation (variable length) - A DOI-specific field that identifies
	the situation under which this negotiation is taking place. The		the situation under which this negotiation is taking place. The
	Situation is used to make policy decisions regarding the security		Situation is used to make policy decisions regarding the security
	attributes being negotiated. Specifics for the IETF IP Security DOI		attributes being negotiated. Specifics for the IETF IP Security DOI
	Situation are detailed in [IPDOI].		Situation are detailed in [IPDOI].
	The payload type for the Security Association Payload is one (1).		The payload type for the Security Association Payload is one (1).
	3.5 Proposal Payload		3.5 Proposal Payload
	The Proposal Payload contains information used during Security Associa-		The Proposal Payload contains information used during Security Associa-
	tion negotiation. The proposal consists of security mechanisms, or trans-		tion negotiation. The proposal consists of security mechanisms, or trans-
	forms, to be used to secure the communications channel. Figure 6 shows		forms, to be used to secure the communications channel. Figure 6 shows
	the format of the Proposal Payload. A description of its use can be found		the format of the Proposal Payload. A description of its use can be found
	in section 4.1.
	The Proposal Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the
	message, then this field will be 0.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Proposal # ! Protocol-Id ! # of Transforms !		! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! SPI (8 octets) !		! SPI (variable) !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: Proposal Payload Format		Figure 6: Proposal Payload Format
			in section 4.1.
			The Proposal Payload fields are defined as follows:
			o Next Payload (1 octet) - Identifier for the payload type of the next
			payload in the message. This field MUST only contain the value "2"
			or "0". If there are additional Proposal payloads in the message,
			then this field will be 2. If the current Proposal payload is the
			last within the security association proposal, then this field will
			be 0.
	o RESERVED (1 octet) - Unused, set to 0.		o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the entire Proposal,		o Payload Length (2 octets) - Length in octets of the entire Proposal
	including the generic payload header, the Proposal payload, and all		payload, including the Proposal payload, and all Transform payloads
	Transform payloads associated with this proposal.		associated with this proposal. In the event there are multiple
			proposals with the same proposal number (see section 4.1), the
			Payload Length field only applies to the current Proposal payload and
			not to all Proposal payloads.
	o Proposal # (1 octet) - Identifies the Proposal number for the current		o Proposal # (1 octet) - Identifies the Proposal number for the current
	payload. A description of the use of this field is found in section		payload. A description of the use of this field is found in section
	4.1.		4.1.
	o Protocol-Id (1 octet) - Specifies the protocol identifier for the		o Protocol-Id (1 octet) - Specifies the protocol identifier for the
	current negotiation. Examples might include IPSEC ESP, IPSEC AH,		current negotiation. Examples might include IPSEC ESP, IPSEC AH,
	OSPF, TLS, etc.		OSPF, TLS, etc.
	o # of Transforms (2 octets) - Specifies the number of transforms for		o SPI Size (1 octet) - Length in octets of the SPI as defined by the
			Protocol-Id.
			o # of Transforms (1 octet) - Specifies the number of transforms for
	the Proposal. Each of these is contained in a Transform payload.		the Proposal. Each of these is contained in a Transform payload.
	o SPI (8 octets) - The sending entity's SPI.		o SPI (variable) - The sending entity's SPI.
	The payload type for the Proposal Payload is two (2).		The payload type for the Proposal Payload is two (2).
	3.6 Transform Payload		3.6 Transform Payload
	The Transform Payload contains information used during Security Associa-		The Transform Payload contains information used during Security Associa-
	tion negotiation. The Transform payload consists of security mechanisms,		tion negotiation. The Transform payload consists of security mechanisms,
	or transforms, to be used to secure the communications channel. The		or transforms, to be used to secure the communications channel. The
	Transform payload also contains the security association attributes asso-		Transform payload also contains the security association attributes asso-
	ciated with the specific transform. These SA attributes are DOI-specific.		ciated with the specific transform. These SA attributes are DOI-specific.
	Figure 7 shows the format of the Transform Payload. A description of its		Figure 7 shows the format of the Transform Payload. A description of its
	use can be found in section 4.1.		use can be found in section 4.1.
	The Transform Payload fields are defined as follows:
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Transform # ! Transform-Id ! RESERVED2 !		! Transform # ! Transform-Id ! RESERVED2 !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ SA Attributes ~		~ SA Attributes ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: Transform Payload Format		Figure 7: Transform Payload Format
			The Transform Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next		o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the		payload in the message. This field MUST only contain the value "3"
	message, then this field will be 0.		or "0". If there are additional Transform payloads in the message,
			then this field will be 3. If the current Transform payload is the
			last within the proposal, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.		o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header, Transform values, and all SA		including the generic payload header, Transform values, and all SA
	Attributes.		Attributes.
	o Transform # (1 octet) - Identifies the Transform number for the		o Transform # (1 octet) - Identifies the Transform number for the
	current payload. If there is more than one transform proposed for a		current payload. If there is more than one transform proposed for a
	specific protocol within the Proposal payload, then each Transform		specific protocol within the Proposal payload, then each Transform
	skipping to change at page 31, line 44 ¶		skipping to change at page 32, line 11 ¶
	o RESERVED2 (3 octets) - Unused, set to 0.		o RESERVED2 (3 octets) - Unused, set to 0.
	o Identification Data (variable length) - Contains identity		o Identification Data (variable length) - Contains identity
	information. The values for this field are DOI-specific and the		information. The values for this field are DOI-specific and the
	format is specified by the ID Type field.		format is specified by the ID Type field.
	The payload type for the Identification Payload is five (5).		The payload type for the Identification Payload is five (5).
	3.9 Certificate Payload		3.9 Certificate Payload
	The Certificate Payload provides a means to transport certificates via		The Certificate Payload provides a means to transport certificates or
	ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD		other certificate-related information via ISAKMP and can appear in any
	be included in an exchange whenever an appropriate directory service (e.g.		ISAKMP message. Certificate payloads SHOULD be included in an exchange
	Secure DNS [DNSSEC]) is not available to distribute certificates. The		whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is
	Certificate payload MUST be accepted at any point during an exchange.		not available to distribute certificates. The Certificate payload MUST be
			accepted at any point during an exchange. Figure 10 shows the format of
	Figure 10 shows the format of the Certificate Payload.		the Certificate Payload.
	NOTE: Certificate types and formats are not generally bound to a DOI - it		NOTE: Certificate types and formats are not generally bound to a DOI - it
	is expected that there will only be a few certificate types, and that most		is expected that there will only be a few certificate types, and that most
	DOIs will accept all of these types.		DOIs will accept all of these types.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 32, line 36 ¶		skipping to change at page 33, line 7 ¶
	o Next Payload (1 octet) - Identifier for the payload type of the next		o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the		payload in the message. If the current payload is the last in the
	message, then this field will be 0.		message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.		o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
	o Certificate Encoding (1 octet) - This field indicates the type of		o Certificate Encoding (1 octet) - This field indicates the type of
	certificate contained in the Certificate Data.		certificate or certificate-related information contained in the
			Certificate Data field.
	__________Certificate_Type____________Value__		_________Certificate_Type___________Value___
	NONE 0		NONE 0
	PKCS #7 wrapped X.509 certificates 1		PKCS #7 wrapped X.509 certificate 1
	PGP Certificates 2		PGP Certificate 2
	DNS Signed Keys 3		DNS Signed Key 3
	X.509 Certificates 4		X.509 Certificate - Signature 4
	Kerberos Tokens 5		X.509 Certificate - Key Exchange 5
	RESERVED 6- 255		Kerberos Tokens 6
			Certificate Revocation List (CRL) 7
			Authority Revocation List (ARL) 8
			RESERVED 9- 255
	o Certificate Data (variable length) - Actual encoding of certificate		o Certificate Data (variable length) - Actual encoding of certificate
	data. The type of certificate is indicated by the Certificate		data. The type of certificate is indicated by the Certificate
	Encoding field.		Encoding field.
	The payload type for the Certificate Payload is six (6).		The payload type for the Certificate Payload is six (6).
	3.10 Certificate Request Payload		3.10 Certificate Request Payload
	The Certificate Request Payload provides a means to request certificates		The Certificate Request Payload provides a means to request certificates
	via ISAKMP and can appear in any message. Certificate Request payloads		via ISAKMP and can appear in any message. Certificate Request payloads
	SHOULD be included in an exchange whenever an appropriate directory ser-		SHOULD be included in an exchange whenever an appropriate directory ser-
	vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi-		vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi-
	cates. The Certificate Request payloads MUST be accepted at any point		cates. The Certificate Request payloads MUST be accepted at any point
	during the exchange. The responder to the Certificate Request payload		during the exchange. The responder to the Certificate Request payload
	MUST send its immediate certificate, if certificates are supported, and		MUST send its immediate certificate, if certificates are supported, and
	SHOULD send as much of its certificate chain as possible. Figure 11 shows		SHOULD send as much of its certificate chain as possible. Figure 11 shows
	the format of the Certificate Request Payload.		the format of the Certificate Request Payload.
			The Certificate Payload fields are defined as follows:
			o Next Payload (1 octet) - Identifier for the payload type of the next
			payload in the message. If the current payload is the last in the
			message, then this field will be 0.
			o RESERVED (1 octet) - Unused, set to 0.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! # Cert. Types ! !		! # Cert. Types ! !
	+-+-+-+-+-+-+-+-+ !		+-+-+-+-+-+-+-+-+ !
	~ Certificate Types ~		~ Certificate Types ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! # Cert. Auths ! !		! # Cert. Auths ! !
	+-+-+-+-+-+-+-+-+ !		+-+-+-+-+-+-+-+-+ !
	~ Certificate Authorities ~		~ Certificate Authorities ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Certificate Request Payload Format		Figure 11: Certificate Request Payload Format
	The Certificate Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the
	message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
	o # Certificate Types (1 octet) - The number of Certificate Types		o # Certificate Types (1 octet) - The number of Certificate Types
	contained in the Certificate Type field.		contained in the Certificate Type field.
	o Certificate Types (variable length) - Contains a list of the types of		o Certificate Types (variable length) - Contains a list of the types of
	certificates requested, sorted in order of preference. Each		certificates requested, sorted in order of preference. Each
	individual certificate type is 1 octet.		individual certificate type is 1 octet.
	skipping to change at page 34, line 25 ¶		skipping to change at page 35, line 4 ¶
	Distinguished Name Attribute Type value.		Distinguished Name Attribute Type value.
	The payload type for the Certificate Request Payload is seven (7).		The payload type for the Certificate Request Payload is seven (7).
	3.11 Hash Payload		3.11 Hash Payload
	The Hash Payload contains data generated by the hash function (selected		The Hash Payload contains data generated by the hash function (selected
	during the SA establishment exchange), over some part of the message		during the SA establishment exchange), over some part of the message
	and/or ISAKMP state. This payload may be used to verify the integrity of		and/or ISAKMP state. This payload may be used to verify the integrity of
	the data in an ISAKMP message or for authentication of the negotiating en-		the data in an ISAKMP message or for authentication of the negotiating en-
	tities. Figure 12 shows the format of the Hash Payload.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Hash Data ~		~ Hash Data ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: Hash Payload Format		Figure 12: Hash Payload Format
			tities. Figure 12 shows the format of the Hash Payload.
	The Hash Payload fields are defined as follows:		The Hash Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next		o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the		payload in the message. If the current payload is the last in the
	message, then this field will be 0.		message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.		o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
	skipping to change at page 35, line 19 ¶		skipping to change at page 35, line 43 ¶
	3.12 Signature Payload		3.12 Signature Payload
	The Signature Payload contains data generated by the digital signature		The Signature Payload contains data generated by the digital signature
	function (selected during the SA establishment exchange), over some part		function (selected during the SA establishment exchange), over some part
	of the message and/or ISAKMP state. This payload is used to verify the		of the message and/or ISAKMP state. This payload is used to verify the
	integrity of the data in the ISAKMP message, and may be of use for non-		integrity of the data in the ISAKMP message, and may be of use for non-
	repudiation services. Figure 13 shows the format of the Signature Pay-		repudiation services. Figure 13 shows the format of the Signature Pay-
	load.		load.
			The Signature Payload fields are defined as follows:
			o Next Payload (1 octet) - Identifier for the payload type of the next
			payload in the message. If the current payload is the last in the
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Signature Data ~		~ Signature Data ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 13: Signature Payload Format		Figure 13: Signature Payload Format
	The Signature Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the
	message, then this field will be 0.		message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.		o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
	o Signature Data (variable length) - Data that results from applying		o Signature Data (variable length) - Data that results from applying
	the digital signature function to the ISAKMP message and/or state.		the digital signature function to the ISAKMP message and/or state.
	skipping to change at page 36, line 15 ¶		skipping to change at page 36, line 38 ¶
	3.13 Nonce Payload		3.13 Nonce Payload
	The Nonce Payload contains random data used to guarantee liveness dur-		The Nonce Payload contains random data used to guarantee liveness dur-
	ing an exchange and protect against replay attacks. Figure 14 shows the		ing an exchange and protect against replay attacks. Figure 14 shows the
	format of the Nonce Payload. If nonces are used by a particular key ex-		format of the Nonce Payload. If nonces are used by a particular key ex-
	change, the use of the Nonce payload would be dictated by the key ex-		change, the use of the Nonce payload would be dictated by the key ex-
	change. The nonces may be transmitted as part of the key exchange data,		change. The nonces may be transmitted as part of the key exchange data,
	or as a separate payload. However, this is defined by the key exchange,		or as a separate payload. However, this is defined by the key exchange,
	not by ISAKMP.		not by ISAKMP.
			The Nonce Payload fields are defined as follows:
			o Next Payload (1 octet) - Identifier for the payload type of the next
			payload in the message. If the current payload is the last in the
			message, then this field will be 0.
			o RESERVED (1 octet) - Unused, set to 0.
			o Payload Length (2 octets) - Length in octets of the current payload,
			including the generic payload header.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Nonce Data ~		~ Nonce Data ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 14: Nonce Payload Format		Figure 14: Nonce Payload Format
	The Nonce Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the
	message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.
	o Nonce Data (variable length) - Contains the random data generated by		o Nonce Data (variable length) - Contains the random data generated by
	the transmitting entity.		the transmitting entity.
	The payload type for the Nonce Payload is ten (10).		The payload type for the Nonce Payload is ten (10).
	3.14 Notification Payload		3.14 Notification Payload
	The Notification Payload contains both ISAKMP and DOI-specific data used		The Notification Payload contains both ISAKMP and DOI-specific data used
	to transmit informational data, such as error conditions, to an ISAKMP		to transmit informational data, such as error conditions, to an ISAKMP
	peer. It is possible to send multiple Notification payloads in a single		peer. It is possible to send multiple Notification payloads in a single
	skipping to change at page 37, line 17 ¶		skipping to change at page 37, line 41 ¶
	ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the		ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the
	SPI value is 0 because the cookie pair in the ISAKMP Header identifies the		SPI value is 0 because the cookie pair in the ISAKMP Header identifies the
	ISAKMP SA.		ISAKMP SA.
	Notification which occurs during, or is concerned with, a Phase 2 nego-		Notification which occurs during, or is concerned with, a Phase 2 nego-
	tiation is identified by the Initiator and Responder cookie pair in the		tiation is identified by the Initiator and Responder cookie pair in the
	ISAKMP Header and the Message ID and SPI associated with the current nego-		ISAKMP Header and the Message ID and SPI associated with the current nego-
	tiation. One example for this type of notification is to indicate why a		tiation. One example for this type of notification is to indicate why a
	proposal was rejected.		proposal was rejected.
			The Notification Payload fields are defined as follows:
			o Next Payload (1 octet) - Identifier for the payload type of the next
			payload in the message. If the current payload is the last in the
			message, then this field will be 0.
			o RESERVED (1 octet) - Unused, set to 0.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			! Domain of Interpretation (DOI) !
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Protocol-ID ! SPI Size ! Notify Message Type !		! Protocol-ID ! SPI Size ! Notify Message Type !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Security Parameter Index (SPI) ~		~ Security Parameter Index (SPI) ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Notification Data ~		~ Notification Data ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 15: Notification Payload Format		Figure 15: Notification Payload Format
	The Notification Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the
	message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
			o Domain of Interpretation (4 octets) - Identifies the DOI (as
			described in Section 2.1) under which this notification is taking
			place. For the Internet, the DOI is one (1). Other DOI's can be
			defined using the description in appendix B.
	o Protocol-Id (1 octet) - Specifies the protocol identifier for the		o Protocol-Id (1 octet) - Specifies the protocol identifier for the
	current notification. Examples might include ISAKMP, IPSEC ESP,		current notification. Examples might include ISAKMP, IPSEC ESP,
	IPSEC AH, OSPF, TLS, etc.		IPSEC AH, OSPF, TLS, etc.
	o SPI Size (1 octet) - Length in octets of the SPI as defined by the		o SPI Size (1 octet) - Length in octets of the SPI as defined by the
	Protocol-Id. In the case of ISAKMP, the Initiator and Responder		Protocol-Id. In the case of ISAKMP, the Initiator and Responder
	cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16		cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16
	octets for each SPI being deleted.		octets for each SPI being deleted.
	o Notify Message Type (2 octets) - Specifies the type of notification		o Notify Message Type (2 octets) - Specifies the type of notification
	skipping to change at page 38, line 23 ¶		skipping to change at page 39, line 10 ¶
	o Notification Data (variable length) - Informational or error data		o Notification Data (variable length) - Informational or error data
	transmitted in addition to the Notify Message Type. Values for this		transmitted in addition to the Notify Message Type. Values for this
	field are DOI-specific.		field are DOI-specific.
	The payload type for the Notification Payload is eleven (11).		The payload type for the Notification Payload is eleven (11).
	3.14.1 Notify Message Types		3.14.1 Notify Message Types
	Notification information can be error messages specifying why an SA could		Notification information can be error messages specifying why an SA could
	not be established. It can also be status data that a process managing an		not be established. It can also be status data that a process managing
	SA database wishes to communicate with a peer process. For example, a se-		an SA database wishes to communicate with a peer process. For example,
	cure front end or security gateway may use the Notify message to synchro-		a secure front end or security gateway may use the Notify message to syn-
	nize SA communication. The table below lists the Nofitication messages		chronize SA communication. The table below lists the Nofitication mes-
	and their corresponding values.		sages and their corresponding values. Values in the Private Use range are
			expected to be DOI-specific values.
	NOTIFY MESSAGES - ERROR TYPES		NOTIFY MESSAGES - ERROR TYPES
	__________Errors______________Value_____		__________Errors______________Value_____
	INVALID-PAYLOAD-TYPE 1		INVALID-PAYLOAD-TYPE 1
	DOI-NOT-SUPPORTED 2		DOI-NOT-SUPPORTED 2
	SITUATION-NOT-SUPPORTED 3		SITUATION-NOT-SUPPORTED 3
	INVALID-COOKIE 4		INVALID-COOKIE 4
	INVALID-MAJOR-VERSION 5		INVALID-MAJOR-VERSION 5
	INVALID-MINOR-VERSION 6		INVALID-MINOR-VERSION 6
	skipping to change at page 39, line 33 ¶		skipping to change at page 39, line 45 ¶
	PAYLOAD-MALFORMED 16		PAYLOAD-MALFORMED 16
	INVALID-KEY-INFORMATION 17		INVALID-KEY-INFORMATION 17
	INVALID-ID-INFORMATION 18		INVALID-ID-INFORMATION 18
	INVALID-CERT-ENCODING 19		INVALID-CERT-ENCODING 19
	INVALID-CERTIFICATE 20		INVALID-CERTIFICATE 20
	BAD-CERT-REQUEST-SYNTAX 21		BAD-CERT-REQUEST-SYNTAX 21
	INVALID-CERT-AUTHORITY 22		INVALID-CERT-AUTHORITY 22
	INVALID-HASH-INFORMATION 23		INVALID-HASH-INFORMATION 23
	AUTHENTICATION-FAILED 24		AUTHENTICATION-FAILED 24
	INVALID-SIGNATURE 25		INVALID-SIGNATURE 25
	RESERVED (Future Use) 26- 8192		ADDRESS-NOTIFICATION 26
	Private Use 8193 - 16384		RESERVED (Future Use) 27- 8192
			Private Use 8193 - 16383
	NOTIFY MESSAGES - STATUS TYPES		NOTIFY MESSAGES - STATUS TYPES
	________Status_____________Value______		________Status_____________Value______
	CONNECTED 16385		CONNECTED 16384
	RESERVED (Future Use) 16386- 24576		RESERVED (Future Use) 16385- 24576
	Private Use 24577 - 32767		Private Use 24577 - 32767
	3.15 Delete Payload		3.15 Delete Payload
	The Delete Payload contains a protocol-specific security association iden-		The Delete Payload contains a protocol-specific security association iden-
	tifier that the sender has removed from its security association database		tifier that the sender has removed from its security association database
	and is, therefore, no longer valid. Figure 16 shows the format of the		and is, therefore, no longer valid. Figure 16 shows the format of the
	Delete Payload. It is possible to send multiple SPIs in a Delete payload,		Delete Payload. It is possible to send multiple SPIs in a Delete payload,
	however, each SPI MUST be for the same protocol. Mixing of Protocol Iden-		however, each SPI MUST be for the same protocol. Mixing of Protocol Iden-
	tifiers MUST NOT be performed with the Delete payload.		tifiers MUST NOT be performed with the Delete payload.
	skipping to change at page 40, line 19 ¶		skipping to change at page 40, line 36 ¶
	SA, but an advisory from the initiator to the responder. If the responder		SA, but an advisory from the initiator to the responder. If the responder
	chooses to ignore the message, the next communication from the responder		chooses to ignore the message, the next communication from the responder
	to the initiator, using that security association, will fail. A responder		to the initiator, using that security association, will fail. A responder
	is not expected to acknowledge receipt of a Delete payload.		is not expected to acknowledge receipt of a Delete payload.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Next Payload ! RESERVED ! Payload Length !		! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			! Domain of Interpretation (DOI) !
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Protocol-Id ! SPI Size ! # of SPIs !		! Protocol-Id ! SPI Size ! # of SPIs !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		! !
	~ Security Parameter Index(es) (SPI) ~		~ Security Parameter Index(es) (SPI) ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 16: Delete Payload Format		Figure 16: Delete Payload Format
	The Delete Payload fields are defined as follows:		The Delete Payload fields are defined as follows:
	o Next Payload (1 octet) - Identifier for the payload type of the next		o Next Payload (1 octet) - Identifier for the payload type of the next
	payload in the message. If the current payload is the last in the		payload in the message. If the current payload is the last in the
	message, then this field will be 0.		message, then this field will be 0.
	o RESERVED (1 octet) - Unused, set to 0.		o RESERVED (1 octet) - Unused, set to 0.
	o Payload Length (2 octets) - Length in octets of the current payload,		o Payload Length (2 octets) - Length in octets of the current payload,
	including the generic payload header.		including the generic payload header.
			o Domain of Interpretation (4 octets) - Identifies the DOI (as
			described in Section 2.1) under which this deletion is taking place.
			For the Internet, the DOI is one (1). Other DOI's can be defined
			using the description in appendix B.
	o Protocol-Id (1 octet) - ISAKMP can establish security associations		o Protocol-Id (1 octet) - ISAKMP can establish security associations
	for various protocols, including ISAKMP and IPSEC. This field identi-		for various protocols, including ISAKMP and IPSEC. This field identi-
	fies which security association database to apply the delete request.		fies which security association database to apply the delete request.
	o SPI Size (1 octet) - Length in octets of the SPI as defined by the		o SPI Size (1 octet) - Length in octets of the SPI as defined by the
	Protocol-Id. In the case of ISAKMP, the Initiator and Responder		Protocol-Id. In the case of ISAKMP, the Initiator and Responder
	cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16		cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16
	octets for each SPI being deleted.		octets for each SPI being deleted.
	o # of SPIs (2 octets) - The number of SPIs contained in the Delete		o # of SPIs (2 octets) - The number of SPIs contained in the Delete
	skipping to change at page 41, line 14 ¶		skipping to change at page 41, line 40 ¶
	specific security association(s) to delete. Values for this field		specific security association(s) to delete. Values for this field
	are DOI and protocol specific. The length of this field is		are DOI and protocol specific. The length of this field is
	determined by the SPI Size and # of SPIs fields.		determined by the SPI Size and # of SPIs fields.
	The payload type for the Delete Payload is twelve (12).		The payload type for the Delete Payload is twelve (12).
	4 ISAKMP Exchanges		4 ISAKMP Exchanges
	ISAKMP supplies the basic syntax of a message exchange. The basic build-		ISAKMP supplies the basic syntax of a message exchange. The basic build-
	ing blocks for ISAKMP messages are the payload types described in section		ing blocks for ISAKMP messages are the payload types described in section
	3. This section describes the procedures for SA establishment, SA modifi-		3. This section describes the procedures for SA establishment and SA mod-
	cation, followed by a default set of exchanges that can be used for ini-		ification, followed by a default set of exchanges that MAY be used for
	tial interoperability.		initial interoperability.
	4.1 Security Association Establishment		4.1 Security Association Establishment
	The Security Association, Proposal, and Transform payloads are used to		The Security Association, Proposal, and Transform payloads are used to
	build ISAKMP messages for the negotiation and establishment of SAs. An		build ISAKMP messages for the negotiation and establishment of SAs. An
	SA establishment message consists of a single SA payload followed by at		SA establishment message consists of a single SA payload followed by at
	least one, and possibly many, Proposal and Transform payloads. The SA		least one, and possibly many, Proposal and Transform payloads. The SA
	Payload contains the DOI and Situation for the proposed SA. Each Proposal		Payload contains the DOI and Situation for the proposed SA. Each Proposal
	payload contains a Security Parameter Index (SPI) and ensures that the SPI		payload contains a Security Parameter Index (SPI) and ensures that the SPI
	is associated with the Protocol-Id in accordance with the Internet Secu-		is associated with the Protocol-Id in accordance with the Internet Secu-
	skipping to change at page 42, line 31 ¶		skipping to change at page 43, line 6 ¶
	receiving entity MUST select a single transform for each protocol in a		receiving entity MUST select a single transform for each protocol in a
	proposal or reject the entire proposal. The use of the Transform number		proposal or reject the entire proposal. The use of the Transform number
	in multiple Transform payload provides a second level OR operation, i.e.		in multiple Transform payload provides a second level OR operation, i.e.
	Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows three		Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows three
	possible transforms for ESP and a single transform for AH. Example 2 below		possible transforms for ESP and a single transform for AH. Example 2 below
	shows two transforms for AH AND two transforms for ESP OR two transform		shows two transforms for AH AND two transforms for ESP OR two transform
	for ESP alone. Note that the Next Payload field of the Transform payload		for ESP alone. Note that the Next Payload field of the Transform payload
	points to another Transform payload or 0. The Proposal payload delineates		points to another Transform payload or 0. The Proposal payload delineates
	the different proposals.		the different proposals.
			When responding to a Security Association payload, the responder MUST send
			a Security Association payload with the selected proposal, which may con-
			sist of multiple Proposal payloads and their associated Transform pay-
			loads. Each of the Proposal payloads MUST contain a single Transform
			payload associated with the Protocol. The responder SHOULD retain the
			Proposal # field in the Proposal payload and the Transform # field in
			each Transform payload of the selected Proposal. Retention of Proposal
			and Transform numbers should speed the initiator's protocol processing by
			negating the need to compare the respondor's selection with every offered
			option. These values enable the initiator to perform the comparison di-
			rectly and quickly. The initiator MUST verify that the Security Associa-
			tion payload received from the responder matches one of the proposals sent
			initially.
	4.1.1 Security Association Establishment Examples		4.1.1 Security Association Establishment Examples
	This example shows a Proposal for a combined protection suite with two		This example shows a Proposal for a combined protection suite with two
	different protocols. The first protocol is presented with two transforms		different protocols. The first protocol is presented with two transforms
	supported by the proposer. The second protocol is presented with a sin-		supported by the proposer. The second protocol is presented with a sin-
	gle transform. An example for this proposal might be: Protocol 1 is ESP		gle transform. An example for this proposal might be: Protocol 1 is ESP
	with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with		with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with
	Transform 1 as SHA. The responder MUST select from the two transforms pro-		Transform 1 as SHA. The responder MUST select from the two transforms pro-
	posed for ESP. The resulting protection suite will be either (1) 3DES AND		posed for ESP. The resulting protection suite will be either (1) 3DES AND
	SHA OR (2) DES AND SHA, depending on which ESP transform was selected by		SHA OR (2) DES AND SHA, depending on which ESP transform was selected by
	the responder.		the responder. Note this example is shown using the Base Exchange.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ ! NP = Proposal ! RESERVED ! Payload Length !		/ ! NP = Nonce ! RESERVED ! Payload Length !
	/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SA Pay ! Domain of Interpretation (DOI) !		SA Pay ! Domain of Interpretation (DOI) !
	\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ ! Situation !		\ ! Situation !
	>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ ! NP = Proposal ! RESERVED ! Payload Length !		/ ! NP = Proposal ! RESERVED ! Payload Length !
	/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Prop 1 ! Proposal # = 1! Protocol-Id ! # of Transforms !		Prop 1 ! Proposal # = 1! Protocol-Id ! # of Transforms !
	Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ ! SPI (8 octets) !		\ ! SPI (8 octets) !
	>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ ! NP = Transform! RESERVED ! Payload Length !		/ ! NP = Transform! RESERVED ! Payload Length !
	/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Tran 1 ! Transform # ! Transform ID ! RESERVED2 !		Tran 1 ! Transform # ! Transform ID ! RESERVED2 !
	\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 56, line 46 ¶		skipping to change at page 57, line 46 ¶
	actions are taken:		actions are taken:
	(a) The event, INVALID SITUATION, is logged in the appropriate system		(a) The event, INVALID SITUATION, is logged in the appropriate system
	audit file.		audit file.
	(b) An Informational Exchange with a Notification payload containing		(b) An Informational Exchange with a Notification payload containing
	the SITUATION-NOT-SUPPORTED message type MAY be sent to the		the SITUATION-NOT-SUPPORTED message type MAY be sent to the
	initiating entity. This action is dictated by a system security		initiating entity. This action is dictated by a system security
	policy.		policy.
	3. Process the remaining payloads as defined by the Next Payload field.		3. Process the remaining payloads (i.e. Proposal, Transform) of the
	If the Security Association Proposal (as described in sections 5.4.1		Security Association Payload. If the Security Association Proposal
	and 5.4.2) is not accepted, then the following actions are taken:		(as described in sections 5.4.1 and 5.4.2) is not accepted, then the
			following actions are taken:
	(a) The event, INVALID PROPOSAL, is logged in the appropriate system		(a) The event, INVALID PROPOSAL, is logged in the appropriate system
	audit file.		audit file.
	(b) An Informational Exchange with a Notification payload containing		(b) An Informational Exchange with a Notification payload containing
	the NO-PROPOSAL-CHOSEN message type MAY be sent to the initiating		the NO-PROPOSAL-CHOSEN message type MAY be sent to the initiating
	entity. This action is dictated by a system security policy.		entity. This action is dictated by a system security policy.
	5.4.1 Proposal Payload Processing		5.4.1 Proposal Payload Processing
	skipping to change at page 66, line 10 ¶		skipping to change at page 67, line 10 ¶
	1. There are no specific procedures for handling Nonce payloads. The		1. There are no specific procedures for handling Nonce payloads. The
	procedures are defined by the exchange types (and possibly the DOI		procedures are defined by the exchange types (and possibly the DOI
	and Key Exchange descriptions).		and Key Exchange descriptions).
	5.12 Notification Payload Processing		5.12 Notification Payload Processing
	When creating a Notification Payload, the transmitting entity MUST do the		When creating a Notification Payload, the transmitting entity MUST do the
	following:		following:
	1. Determine the Protocol-ID for this Notification.		1. Determine the DOI for this Notification.
	2. Determine the SPI size based on the Protocol-ID field. This field is		2. Determine the Protocol-ID for this Notification.
			3. Determine the SPI size based on the Protocol-ID field. This field is
	necessary because different security protocols have different SPI		necessary because different security protocols have different SPI
	sizes. For example, ISAKMP combines the Initiator and Responder		sizes. For example, ISAKMP combines the Initiator and Responder
	cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs.		cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs.
	3. Determine the Notify Message Type based on the error or status		4. Determine the Notify Message Type based on the error or status
	message desired.		message desired.
	4. Determine the SPI which is associated with this notification.		5. Determine the SPI which is associated with this notification.
	5. Determine if addition Notification Data is to be included. This is		6. Determine if addition Notification Data is to be included. This is
	additional information specified by the DOI.		additional information specified by the DOI.
	6. Construct a Notification payload.		7. Construct a Notification payload.
	Because the Informational Exchange with a Notification payload is a uni-		Because the Informational Exchange with a Notification payload is a uni-
	directional message a retransmission will not be performed. The local		directional message a retransmission will not be performed. The local
	security policy will dictate the procedures for continuing. However, we		security policy will dictate the procedures for continuing. However, we
	RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro-		RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro-
	priate system audit file.		priate system audit file.
	5.13 Delete Payload Processing		5.13 Delete Payload Processing
	During communications it is possible that hosts may be compromised or that		During communications it is possible that hosts may be compromised or that
	skipping to change at page 67, line 8 ¶		skipping to change at page 68, line 9 ¶
	the SA(s). Deletion of Security Associations MUST always be performed		the SA(s). Deletion of Security Associations MUST always be performed
	under the protection of an ISAKMP SA. The receiving entity SHOULD clean up		under the protection of an ISAKMP SA. The receiving entity SHOULD clean up
	its local SA database. However, upon receipt of a Delete message the SAs		its local SA database. However, upon receipt of a Delete message the SAs
	listed in the Security Parameter Index (SPI) field of the Delete payload		listed in the Security Parameter Index (SPI) field of the Delete payload
	cannot be used with the initiating entity. The SA Establishment procedure		cannot be used with the initiating entity. The SA Establishment procedure
	must be invoked to re-establish secure communications.		must be invoked to re-establish secure communications.
	When creating a Delete Payload, the transmitting entity MUST do the fol-		When creating a Delete Payload, the transmitting entity MUST do the fol-
	lowing:		lowing:
	1. Determine the Protocol-ID for this Notification.		1. Determine the DOI for this Deletion.
	2. Determine the SPI size based on the Protocol-ID field. This field is		2. Determine the Protocol-ID for this Deletion.
			3. Determine the SPI size based on the Protocol-ID field. This field is
	necessary because different security protocols have different SPI		necessary because different security protocols have different SPI
	sizes. For example, ISAKMP combines the Initiator and Responder		sizes. For example, ISAKMP combines the Initiator and Responder
	cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs.		cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs.
	3. Determine the # of SPIs to be deleted for this protocol.		4. Determine the # of SPIs to be deleted for this protocol.
	4. Determine the SPI(s) which is (are) associated with this deletion.		5. Determine the SPI(s) which is (are) associated with this deletion.
	5. Construct a Delete payload.		6. Construct a Delete payload.
	Because the Informational Exchange with a Delete payload is a unidirec-		Because the Informational Exchange with a Delete payload is a unidirec-
	tional message a retransmission will not be performed. The local security		tional message a retransmission will not be performed. The local security
	policy will dictate the procedures for continuing. However, we RECOMMEND		policy will dictate the procedures for continuing. However, we RECOMMEND
	that a DELETE PAYLOAD ERROR event be logged in the appropriate system au-		that a DELETE PAYLOAD ERROR event be logged in the appropriate system au-
	dit file.		dit file.
	6 Conclusions		6 Conclusions
	The Internet Security Association and Key Management Protocol (ISAKMP) is		The Internet Security Association and Key Management Protocol (ISAKMP) is
	skipping to change at page 70, line 6 ¶		skipping to change at page 71, line 6 ¶
	IP Security DOI.		IP Security DOI.
	_Protocol_Assigned_Value__		_Protocol_Assigned_Value__
	RESERVED 0		RESERVED 0
	ISAKMP 1		ISAKMP 1
	All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security		All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security
	protocols within that DOI will be numbered accordingly.		protocols within that DOI will be numbered accordingly.
	Security protocol values 2-1024 are reserved for IANA use. Values 1025-		Security protocol values 2-1024 are reserved for IANA use. Values 1025-
	15360 are reserved for future use. Values 15360-16384 are reserved for		15360 are reserved for future use. Values 15361-16383 are reserved for
	private use.		private use.
	B Defining a new Domain of Interpretation		B Defining a new Domain of Interpretation
	The Internet DOI may be sufficient to meet the security requirements of		The Internet DOI may be sufficient to meet the security requirements of
	a large portion of the internet community. However, some groups may have		a large portion of the internet community. However, some groups may have
	a need to customize some aspect of a DOI, perhaps to add a different set		a need to customize some aspect of a DOI, perhaps to add a different set
	of cryptographic algorithms, or perhaps because they want to make their		of cryptographic algorithms, or perhaps because they want to make their
	security-relevant decisions based on something other than a host id or		security-relevant decisions based on something other than a host id or
	user id. Also, a particular group may have a need for a new exchange		user id. Also, a particular group may have a need for a new exchange
End of changes. 68 change blocks.
	169 lines changed or deleted		232 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/