< draft-ietf-ipsec-ipsec-doi-01.txt		draft-ietf-ipsec-ipsec-doi-02.txt >
	Network Working Group Derrell Piper		Network Working Group Derrell Piper
	INTERNET-DRAFT cisco Systems		INTERNET-DRAFT cisco Systems
	draft-ietf-ipsec-ipsec-doi-01.txt November 15, 1996		draft-ietf-ipsec-ipsec-doi-02.txt February 28, 1997
	The Internet IP Security Domain of Interpretation for ISAKMP		The Internet IP Security Domain of Interpretation for ISAKMP
	<draft-ietf-ipsec-ipsec-doi-01.txt>		<draft-ietf-ipsec-ipsec-doi-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and working groups. Note that other groups may also distribute		and working groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet Drafts.
	Internet Drafts are draft documents valid for a maximum of six months		Internet Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inapproporiate to use Internet Drafts as reference		time. It is inappropriate to use Internet Drafts as reference
	material or to cite them other than as ``work in progress.''		material or to cite them other than as ``work in progress.''
	To learn the current status of any Internet Draft, please check the		To learn the current status of any Internet Draft, please check the
	``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow		``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au (Australia), ds.internic.net (US East Coast), or		munnari.oz.au (Australia), ds.internic.net (US East Coast), or
	ftp.isi.edu (US West Coast).		ftp.isi.edu (US West Coast).
	Distribution of this memo is unlimited. This draft will expire six		Distribution of this memo is unlimited. This draft will expire six
	months from date of issue.		months from date of issue.
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	The SIT_IDENTITY_ONLY type specifies that the security association		The SIT_IDENTITY_ONLY type specifies that the security association
	will be identified by source identity information present in an		will be identified by source identity information present in an
	associated Identification Payload. See Section 4.6.2 for a complete		associated Identification Payload. See Section 4.6.2 for a complete
	description of the various Identification types. All IPSEC DOI		description of the various Identification types. All IPSEC DOI
	implementations MUST support SIT_IDENTITY_ONLY by including an		implementations MUST support SIT_IDENTITY_ONLY by including an
	Identification Payload in at least one of the phase I Oakley		Identification Payload in at least one of the phase I Oakley
	exchanges ([IO], Section 5) and MUST abort any association setup that		exchanges ([IO], Section 5) and MUST abort any association setup that
	does not include an Identification Payload.		does not include an Identification Payload.
			If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the
			situation consists only of the 4 octet situation bitmap and does not
			include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
			or any subsequent label information. Conversely, if the initiator
			supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain
			Identifier MUST be included in the situation payload.
	4.2.2 SIT_SECRECY		4.2.2 SIT_SECRECY
	The SIT_SECRECY type specifies that the security association is being		The SIT_SECRECY type specifies that the security association is being
	negotiated in an environment that requires labeled secrecy. If		negotiated in an environment that requires labeled secrecy. If
	SIT_SECRECY is present in the Situation bitmap, the Situation field		SIT_SECRECY is present in the Situation bitmap, the Situation field
	will be followed by variable-length data that includes a sensitivity		will be followed by variable-length data that includes a sensitivity
	level and compartment bitmask. See Section 4.6.1 for a complete		level and compartment bitmask. See Section 4.6.1 for a complete
	description of the Security Association Payload format.		description of the Security Association Payload format.
	If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be		If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 45 ¶
	Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC		Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
	DOI.		DOI.
	Protocol ID Value		Protocol ID Value
	----------- -----		----------- -----
	RESERVED 0		RESERVED 0
	PROTO_ISAKMP 1		PROTO_ISAKMP 1
	PROTO_IPSEC_AH 2		PROTO_IPSEC_AH 2
	PROTO_IPSEC_ESP 3		PROTO_IPSEC_ESP 3
	The values 4-15360 are reserved to IANA. Values 15361-16384 are		The size of this field is one octet. The values 4-248 are reserved
	reserved for private use.		to IANA. Values 249-255 are reserved for private use.
	4.4.1.1 PROTO_ISAKMP		4.4.1.1 PROTO_ISAKMP
	The PROTO_ISAKMP type specifies message protection required during		The PROTO_ISAKMP type specifies message protection required during
	Phase I of the ISAKMP protocol. The specific protection mechanism		Phase I of the ISAKMP protocol. The specific protection mechanism
	used for the IPSEC DOI is described in [IO]. All implementations		used for the IPSEC DOI is described in [IO]. All implementations
	within the IPSEC DOI MUST support PROTO_ISAKMP.		within the IPSEC DOI MUST support PROTO_ISAKMP.
	NB: ISAKMP reserves the value one (1) across all DOI definitions.		NB: ISAKMP reserves the value one (1) across all DOI definitions.
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 10 ¶
	4.4.1.1 PROTO_ISAKMP		4.4.1.1 PROTO_ISAKMP
	The PROTO_ISAKMP type specifies message protection required during		The PROTO_ISAKMP type specifies message protection required during
	Phase I of the ISAKMP protocol. The specific protection mechanism		Phase I of the ISAKMP protocol. The specific protection mechanism
	used for the IPSEC DOI is described in [IO]. All implementations		used for the IPSEC DOI is described in [IO]. All implementations
	within the IPSEC DOI MUST support PROTO_ISAKMP.		within the IPSEC DOI MUST support PROTO_ISAKMP.
	NB: ISAKMP reserves the value one (1) across all DOI definitions.		NB: ISAKMP reserves the value one (1) across all DOI definitions.
	4.4.1.2 PROTO_IPSEC_AH		4.4.1.2 PROTO_IPSEC_AH
	The PROTO_IPSEC_AH type specifies IP packet data origin		The PROTO_IPSEC_AH type specifies IP packet data origin
	authentication. Confidentiality MUST NOT be provided by any		authentication. The default AH transform includes data origin
			authentication and replay prevention. For export control
			considerations, confidentiality MUST NOT be provided by any
	PROTO_IPSEC_AH transform.		PROTO_IPSEC_AH transform.
	4.4.1.3 PROTO_IPSEC_ESP		4.4.1.3 PROTO_IPSEC_ESP
	The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Data		The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Data
	origin authentication, if required, must be provided as part of the		origin authentication, if required, must be provided as part of the
	ESP transform. The default ESP transform includes data origin		ESP transform. The default ESP transform includes data origin
	authentication and replay prevention.		authentication, confidentiality, and replay prevention.
	4.4.2 IPSEC ISAKMP Transform Values		4.4.2 IPSEC ISAKMP Transform Values
	As part of an ISAKMP Phase I negotiation, the initiator's choice of		As part of an ISAKMP Phase I negotiation, the initiator's choice of
	Key Exchange offerings is made using some host system policy		Key Exchange offerings is made using some host system policy
	description. The actual selection of Key Exchange mechanism is made		description. The actual selection of Key Exchange mechanism is made
	using the standard ISAKMP Proposal Payload. The following table		using the standard ISAKMP Proposal Payload. The following table
	lists the defined ISAKMP Phase I Transform Identifiers for the		lists the defined ISAKMP Phase I Transform Identifiers for the
	Proposal Payload for the IPSEC DOI.		Proposal Payload for the IPSEC DOI.
	Transform Value		Transform Value
	--------- -----		--------- -----
	RESERVED 0		RESERVED 0
	KEY_OAKLEY 1		KEY_OAKLEY 1
	KEY_MANUAL 2		KEY_MANUAL 2
	KEY_KDC 3		KEY_KDC 3
	The values 4-15360 are reserved to IANA. Values 15361-16384 are		The size of this field is one octet. The values 4-248 are reserved
	reserved for private use.		to IANA. Values 249-255 are reserved for private use.
	4.4.2.1 KEY_OAKLEY		4.4.2.1 KEY_OAKLEY
	The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman		The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
	key exchange as defined in the [IO] document. All implementations		key exchange as defined in the [IO] document. All implementations
	within the IPSEC DOI MUST support KEY_OAKLEY.		within the IPSEC DOI MUST support KEY_OAKLEY.
	4.4.2.2 KEY_MANUAL		4.4.2.2 KEY_MANUAL
	The KEY_MANUAL type specifies that a shared secret key mechanism is		The KEY_MANUAL type specifies that a shared secret key mechanism is
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 22 ¶
	Kerberos-like ticket protocol. Specific details of a KDC-based key		Kerberos-like ticket protocol. Specific details of a KDC-based key
	establishment protocol will be described in a future document.		establishment protocol will be described in a future document.
	4.4.3 IPSEC AH Transform Values		4.4.3 IPSEC AH Transform Values
	The Authentication Header Protocol (AH) defines one mandatory and		The Authentication Header Protocol (AH) defines one mandatory and
	several optional transforms used to provide data origin		several optional transforms used to provide data origin
	authentication. The following table lists the defined AH Transform		authentication. The following table lists the defined AH Transform
	Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.		Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
	Transform Value		Transform ID Value
	--------- -----		------------ -----
	RESERVED 0		RESERVED 0
	AH_1828 1		AH_MD5_KPDK 1
	AH_HMAC_MD5_REPLAY 2		AH_MD5 2
	AH_MHAC_SHA_REPLAY 3		AH_SHA 3
	The values 4-15360 are reserved to IANA. Values 15361-16384 are		The size of this field is one octet. The values 4-248 are reserved
	reserved for private use.		to IANA. Values 249-255 are reserved for private use.
	4.4.3.1 AH_1828		4.4.3.1 AH_MD5_KPDK
	The AH_1828 type specifies the transform described in RFC-1828. This		The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key)
	mode should be used only for compatibility with existing RFC-1828		described in RFC-1826 and RFC-1828. This mode MAY be used for
	implementations.		compatibility with existing implementations. Implementations are not
			required to support this mode.
	4.4.3.2 AH_MD5_REPLAY		4.4.3.2 AH_MD5
	The AH_MD5_REPLAY type specifies the transform described in		The AH_MD5 type specifies a generic AH transform using MD5. The
	[HMACMD5]. This transform MUST be supported by all implementations		actual protection suite is determined in concert with an associated
	and is the preferred AH transform for the IPSEC DOI.		SA attribute list. A generic MD5 transform is currently undefined.
	4.4.3.3 AH_SHA_REPLAY		All implementations within the IPSEC DOI MUST support AH_MD5 along
			with the HMAC and REPLAY attributes. This suite is defined as the
			HMAC-MD5 transform described in RFC-2085.
	The AH_SHA_REPLAY type specifies the transform described in		4.4.3.3 AH_SHA
	[HMACSHA]. While not required, it is strongly recommended that all
	implementations include the AH_SHA_REPLAY transform in addition to		The AH_SHA type specifies a generic AH transform using SHA-1. The
	AH_MD5_REPLAY.		actual protection suite is determined in concert with an associated
			SA attribute list. A generic SHA transform is currently undefined.
			All implementations within the IPSEC DOI are strongly encouraged to
			support AH_SHA along with the HMAC and REPLAY attributes. This suite
			is defined as the HMAC-SHA transform described in [HMACSHA].
	4.4.4 IPSEC ESP Transform Identifiers		4.4.4 IPSEC ESP Transform Identifiers
	The Encapsulating Security Protocol (ESP) defines one mandatory and		The Encapsulating Security Protocol (ESP) defines one mandatory and
	several optional transforms used to provide data confidentiality.		several optional transforms used to provide data confidentiality.
	The following table lists the defined ESP Transform Identifiers for		The following table lists the defined ESP Transform Identifiers for
	the ISAKMP Proposal Payload for the IPSEC DOI.		the ISAKMP Proposal Payload for the IPSEC DOI.
	Transform ID Value		Transform ID Value
	------------ -----		------------ -----
	RESERVED 0		RESERVED 0
	ESP_1829_TRANSPORT 1		ESP_DES_CBC 1
	ESP_1829_TUNNEL 2		ESP_DES 2
	ESP_DES_CBC_HMAC_REPLAY 3		ESP_3DES 3
			ESP_RC5 4
	The values 4-15360 are reserved to IANA. Values 15361-16384 are		The size of this field is one octet. The values 5-248 are reserved
	reserved for private use.		to IANA. Values 249-255 are reserved for private use.
	4.4.4.1 ESP_1829_TRANSPORT		4.4.4.1 ESP_DES_CBC
	The ESP_1829_TRANSPORT type specifies the ESP transform described in		The ESP_DES_CBC type specifies the DES-CBC transform defined in RFC-
	RFC-1829, operating in Transport Mode. This mode should be used only		1827 and RFC-1829. This mode MAY be used for compatibility with
	for compatibility with existing RFC-1829 implementations.		existing implementations. Implementations are not required to
			support this mode.
	4.4.4.2 ESP_1829_TUNNEL		4.4.4.2 ESP_DES
	The ESP_1829_TUNNEL type specifies the ESP transform described in		The ESP_DES type specifies a generic DES transform using DES-CBC.
	RFC-1829, operating in Tunnel Mode. This mode should be used only		The actual protection suite is determined in concert with an
	for compatibility with existing RFC-1829 implementation.		associated SA attribute list. A generic transform is currently
			undefined.
	4.4.4.3 ESP_DES_CBC_HMAC_REPLAY		All implementations within the IPSEC DOI MUST support ESP_DES along
			with the HMAC and REPLAY attributes. This suite is defined as the
			[Hughes] transform.
	The ESP_DES_CBC_HMAC_REPLAY type specifies the transform described in		4.4.4.3 ESP_3DES
	[Hughes]. This transform MUST be supported by all implementations
	and is the preferred ESP transform for the IPSEC DOI.
	4.5 IPSEC Security Association Atttributes		The ESP_3DES type specifies a generic triple-DES transform. The
			actual protection suite is determined in concert with an associated
			SA attribute list. The generic transform is currently undefined.
			All implementations within the IPSEC are strongly encouraged to
			support ESP_3DES along with the HMAC and REPLAY attributes. This
			suite is defined as the [Naganand] transform.
			4.4.4.4 ESP_RC5
			The ESP_RC5 type specifies the RC5 transform defined in [RC5].
			4.5 IPSEC Security Association Attributes
	The following SA attribute definitions are used in phase II of an		The following SA attribute definitions are used in phase II of an
	ISAKMP/Oakley negotation. Attribute types can be either Basic (B) or		ISAKMP/Oakley negotiation. Attribute types can be either Basic (B)
	Variable-Length (V). Encoding of these attributes is defined in the		or Variable-Length (V). Encoding of these attributes is defined in
	base ISAKMP specification.		the base ISAKMP specification.
	Attribute Classes		Attribute Classes
	class value type		class value type
	-------------------------------------------------		-------------------------------------------------
	Auth Key Life Type 1 B		Auth Key Life Type 1 B
	Auth Key Life Duration 2 B/V		Auth Key Life Duration 2 B/V
	Enc Key Life Type 3 B		Enc Key Life Type 3 B
	Enc Key Life Duration 4 B/V		Enc Key Life Duration 4 B/V
	SA Life Type 5 B		SA Life Type 5 B
	SA Life Duration 6 B/V		SA Life Duration 6 B/V
	Replay Protection 7 B		Replay Protection 7 B
			Group Description 8 B
			CA Distinguished Name 9 B
			Encapsulation Mode 10 B
			HMAC Algorithm 11 B
	Class Values		Class Values
	Auth Key Life Type		Auth Key Life Type
			Auth Key Duration
			Specifies the time-to-live for the authentication key(s)
			used in the corresponding AH HMAC transform.
	Enc Key Life Type		Enc Key Life Type
			Enc Key Duration
			Specifies the time-to-live for the encryption key(s)
			using in the corresponding ESP transform.
	SA Life Type		SA Life Type
			SA Duration
			Specifies the time-to-live for the overall security
			association. When the SA expires, all keys negotiated
			under the association (AH or ESP) must be renegotiated
			regardless of the time-to-live remaining for the keys.
			RESERVED 0
	seconds 1		seconds 1
	kilobytes 2		kilobytes 2
	Values 3-65000 are reserved to IANA. Values 65001-65535		Values 3-61439 are reserved to IANA. Values 61440-65535
	are for experimental use. For a given "Life Type," the		are for experimental use. For a given "Life Type," the
	value of the "Life Duration" attribute defines the actual		value of the "Life Duration" attribute defines the actual
	length of the component lifetime -- either a number of		length of the component lifetime -- either a number of
	seconds, or a number of Kbytes that can be protected.		seconds, or a number of Kbytes that can be protected.
			If unspecified, the default value shall be assumed to be
			28800 seconds (8 hours) for Auth, Enc, and SA lifetime.
	Replay Protection		Replay Protection
	not required 0		RESERVED 0
	required 1		required 1
			disallowed 2
	Values 2-65000 are reserved to IANA. Values 65001-65535		Values 3-61439 are reserved to IANA. Values 61440-65535
	are for experimental use.		are for private use among mutually consenting parties.
			There is no default value for Replay Protection, as it
			must be specified to correctly identify the applicable
			transform.
			Group Description
			RESERVED 0
			default group 1
			Values 2-61439 are reserved to IANA. Values 61440-65535
			are for private use among mutually consenting parties.
			If unspecified, the default value shall be assumed to be
			the default Oakley group ([IO], Section 5.5.1).
			CA Distinguished Name
			RESERVED 0
			DNS Security 1
			Values 2-61439 are reserved to IANA. Values 61440-65535
			are for private use among mutually consenting parties.
			If unspecified, the default value shall be assumed to be
			DNS Security (Section 4.8).
			Encapsulation Mode
			RESERVED 0
			Tunnel 1
			Transport 2
			Values 3-61439 are reserved to IANA. Values 61440-65535
			are for private use among mutually consenting parties.
			If unspecified, the default value shall be assumed to be
			unspecified (host-dependent).
			HMAC Algorithm
			RESERVED 0
			MD5 1
			SHA-1 2
			Values 3-61439 are reserved to IANA. Values 61440-65535
			are for private use among mutually consenting parties.
			There is no default value for HMAC Algorithm, as it
			must be specified to correctly identify the applicable
			transform.
			4.5.1 Required Attribute Support
			To ensure basic interoperability, all implementations MUST support
			all of the following attributes:
			Auth Key Life Type
			Auth Key Duration
			Enc Key Life Type
			Enc Key Duration
			SA Life Type
			SA Duration
			Replay Protection
			HMAC Algorithm (MD5 required, SHA-1 optional)
			4.5.2 Attribute List Parsing Requirement
			To allow for flexible semantics, the IPSEC DOI requires that a
			conforming ISAKMP implementation MUST correctly parse an attribute
			list that contains multiple instances of the same attribute class, so
			long as the different attribute entries do not conflict with one
			another.
			To see why this is important, the following example shows the binary
			encoding of a four entry attribute list that specifies an Encryption
			Key Lifetime of either 100MB or 24 hours. (See Section 3.3 of
			[ISAKMP] for a complete description of the attribute encoding
			format.)
			Attribute #1:
			0x80030001 (AF = 1, type = Enc Key Life Type, value = seconds)
			Attribute #2:
			0x00040004 (AF = 0, type = Enc Key Duration, length = 4 bytes)
			0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)
			Attribute #3:
			0x80030002 (AF = 1, type = Enc Key Life Type, value = KB)
			Attribute #4:
			0x00040004 (AF = 0, type = Enc Key Duration, length = 4 bytes)
			0x000186A0 (value = 0x186A0 = 100000KB = 100MB)
			If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
			Notification Payload SHOULD be returned and the security association
			setup MUST be aborted.
	4.6 IPSEC Payload Content		4.6 IPSEC Payload Content
	The following sections describe those ISAKMP payloads whose data		The following sections describe those ISAKMP payloads whose data
	representations are dependent on the applicable DOI.		representations are dependent on the applicable DOI.
	4.6.1 Security Association Payload		4.6.1 Security Association Payload
	The following diagram illustrates the content of the Security		The following diagram illustrates the content of the Security
	Association Payload for the IPSEC DOI. See Section 4.2 for a		Association Payload for the IPSEC DOI. See Section 4.2 for a
	description of the Situation bitmap.		description of the Situation bitmap.
	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 (IPSEC) |		! Domain of Interpretation (IPSEC) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! RESERVED ! Situation (bitmap) !		! Situation (bitmap) !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Labeled Domain Identifier !		! Labeled Domain Identifier !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Secrecy Length (in octets) ! RESERVED !		! Secrecy Length (in octets) ! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Secrecy Level ~		~ Secrecy Level ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Secrecy Cat. Length (in bits) ! RESERVED !		! Secrecy Cat. Length (in bits) ! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Secrecy Category Bitmap ~		~ Secrecy Category Bitmap ~
	skipping to change at page 11, line 24 ¶		skipping to change at page 14, line 30 ¶
	o Next Payload (2 octets) - Identifier for the payload type of		o Next Payload (2 octets) - Identifier for the payload type of
	the next payload in the message. If the current payload is		the next payload in the message. If the current payload is
	the last in the message, this field will be zero (0).		the last in the message, this field will be zero (0).
	o RESERVED (1 octet) - Unused, must be zero (0).		o RESERVED (1 octet) - Unused, must be zero (0).
	o Payload Length (2 octets) - Length, in octets, of the current		o Payload Length (2 octets) - Length, in octets, of the current
	payload, including the generic header.		payload, including the generic header.
	o Domain of Intepretation (4 octets) - Specifies the IPSEC DOI,		o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
	which has been assigned the value one (1).		which has been assigned the value one (1).
	o Situation (2 octets) - Bitmask used to interpret the		o Situation (4 octets) - Bitmask used to interpret the
	remainder of the Security Association Payload. See Section		remainder of the Security Association Payload. See Section
	4.2 for a complete list of values.		4.2 for a complete list of values.
	o RESERVED (2 octets) - Unused, must be zero (0).
	o Labeled Domain Identifier (4 octets) - IANA Assigned Number		o Labeled Domain Identifier (4 octets) - IANA Assigned Number
	used to interpret the Secrecy and Integrity information.		used to interpret the Secrecy and Integrity information.
	o Secrecy Length (2 octets) - Specifies the length, in octets,		o Secrecy Length (2 octets) - Specifies the length, in octets,
	of the secrecy level identifier.		of the secrecy level identifier.
	o Secrecy Category Length (2 octets) - Specifies the length, in		o Secrecy Category Length (2 octets) - Specifies the length, in
	bits, of the secrecy category (compartment) bitmap.		bits, of the secrecy category (compartment) bitmap.
	o Secrecy Category Bitmap (variable length) - A bitmap used to		o Secrecy Category Bitmap (variable length) - A bitmap used to
	skipping to change at page 12, line 9 ¶		skipping to change at page 15, line 12 ¶
	o Integrity Length (2 octets) - Specifies the length, in		o Integrity Length (2 octets) - Specifies the length, in
	octets, of the integrity level identifier.		octets, of the integrity level identifier.
	o Integrity Category Length (2 octets) - Specifies the length,		o Integrity Category Length (2 octets) - Specifies the length,
	in bits, of the integrity category (compartment) bitmap.		in bits, of the integrity category (compartment) bitmap.
	o Integrity Category Bitmap (variable length) - A bitmap used		o Integrity Category Bitmap (variable length) - A bitmap used
	to designate integrity categories (compartments) that are		to designate integrity categories (compartments) that are
	required.		required.
	4.6.2 Identification Payload Content		4.6.1.1 Labeled Domain Identifier Values
	The Identification Payload is used to identify the initiator of		The following table lists the assigned values for the Labeled Domain
	the Security Association. The identity of the initiator SHOULD be		Identifier field contained in the Situation field of the Security
	used by the responder to determine the correct host system		Association Payload.
	security policy requirement for the association. For example, a
	host might choose to require data origin authentication without
	confidentiality (AH) from a certain set of IP addresses and full
	authentication with confidentiality (Hughes) from another range of
	IP addresses. The Identification Payload provides information
	that can be used by the responder to make this decision.
	The following diagram illustrates the content of the		Domain Value
	Identification Payload.		------- -----
			RESERVED 0
	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		The values 1-0x7fffffff are reserved to IANA. Values 0x8000000-
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		0xffffffff are reserved for private use.
	! Next Payload ! RESERVED ! Payload Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! ID Type ! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Identification Data ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Identification Payload Format		4.6.2 Identification Payload Content
	The Identification Payload field is defined as follows:		The Identification Payload is used to identify the initiator of the
			Security Association. The identity of the initiator SHOULD be used
			by the responder to determine the correct host system security policy
			requirement for the association. For example, a host might choose to
			require data origin authentication without confidentiality (AH) from
			a certain set of IP addresses and full authentication with
			confidentiality (Hughes) from another range of IP addresses. The
			Identification Payload provides information that can be used by the
			responder to make this decision.
	o Next Payload (2 octets) - Identifier for the payload type of		The following diagram illustrates the content of the Identification
	the next payload in the message. If the current payload is		Payload.
	the last in the message, this field will be zero (0).
	o RESERVED (1 octet) - Unused, must be zero (0).		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 !
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			! ID Type ! Protocol ID ! Port !
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Identification Data ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Payload Length (2 octets) - Length, in octets, of the		Figure 2: Identification Payload Format
	identification data, including the generic header.
	o Identification Type (1 octet) - Value describing the		The Identification Payload field is defined as follows:
	identity information found in the Identification Data field.
	o RESERVED (3 octets) - Unused, must be zero (0).		o Next Payload (2 octets) - Identifier for the payload type of
			the next payload in the message. If the current payload is
			the last in the message, this field will be zero (0).
			o RESERVED (1 octet) - Unused, must be zero (0).
			o Payload Length (2 octets) - Length, in octets, of the
			identification data, including the generic header.
			o Identification Type (1 octet) - Value describing the
			identity information found in the Identification Data field.
			o Protocol ID (1 octet) - Value specifying an associated
			IP protocol ID (e.g. UDP/TCP). A value of zero means that the
			Protocol ID field should be ignored.
			o Port (2 octets) - Value specifying an associated port.
			A value of zero means that the Port field should be ignored.
			o RESERVED (1 octet) - Unused, must be zero (0).
			4.6.2.1 Identification Type Values
	4.6.2.1 Identifiction Type Values
	The following table lists the assigned values for the Identification		The following table lists the assigned values for the Identification
	Type field found in the Identification Payload.		Type field found in the Identification Payload.
	ID Type Value		ID Type Value
	------- -----		------- -----
	RESERVED 0		RESERVED 0
	ID_IPV4_ADDR 1		ID_IPV4_ADDR 1
	ID_FQDN 2		ID_FQDN 2
	ID_FQUN 3		ID_USER_FQDN 3
	ID_IPV4_ADDR_RANGE 4		ID_IPV4_ADDR_SUBNET 4
	ID_IPV6_ADDR 5		ID_IPV6_ADDR 5
	ID_IPV6_ADDR_RANGE 6		ID_IPV6_ADDR_SUBNET 6
			ID_IPV4_ADDR_RANGE 7
			ID_IPV6_ADDR_RANGE 8
	The values 6-500 are reserved to IANA. Values 501-512 are reserved		The size of this field is one octet. The values 9-248 are reserved
	for private use.		to IANA. Values 249-255 are reserved for private use.
	4.6.2.2 ID_IPV4_ADDR		4.6.2.2 ID_IPV4_ADDR
	The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.		The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
	4.6.2.3 ID_FQDN		4.6.2.3 ID_FQDN
	The ID_FQDN type specifies a fully-qualified domain name string. An		The ID_FQDN type specifies a fully-qualified domain name string. An
	example of a ID_FQDN is, "foo.bar.com".		example of a ID_FQDN is, "foo.bar.com".
	4.6.2.4 ID_FQUN		4.6.2.4 ID_USER_FQDN
	The ID_FQUN type specifies a fully-qualified username string, An		The ID_USER_FQDN type specifies a fully-qualified username string, An
	example of a ID_FQUN is, "piper@foo.bar.com".		example of a ID_USER_FQDN is, "piper@foo.bar.com".
	4.6.2.5 ID_IPV4_ADDR_RANGE		4.6.2.5 ID_IPV4_ADDR_SUBNET
	The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,		The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
	represented by two four (4) octet values. The first value is an IPv4		represented by two four (4) octet values. The first value is an IPv4
	address. The second is an IPv4 network mask. Note that ones (1s) in		address. The second is an IPv4 network mask. Note that ones (1s) in
	the network mask indicate that the corresponding bit in the address		the network mask indicate that the corresponding bit in the address
	is fixed, while zeros (0s) indicate a "wildcard" bit.		is fixed, while zeros (0s) indicate a "wildcard" bit.
	4.6.2.6 ID_IPV6_ADDR		4.6.2.6 ID_IPV6_ADDR
	The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6		The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
	address.		address.
	4.6.2.7 ID_IPV6_ADDR_RANGE		4.6.2.7 ID_IPV6_ADDR_SUBNET
	The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,		The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
	represented by two sixteen (16) octet values. The first value is an		represented by two sixteen (16) octet values. The first value is an
	IPv6 address. The second is an IPv6 network mask. Note that ones		IPv6 address. The second is an IPv6 network mask. Note that ones
	(1s) in the network mask indicate that the corresponding bit in the		(1s) in the network mask indicate that the corresponding bit in the
	address is fixed, while zeros (0s) indicate a "wildcard" bit.		address is fixed, while zeros (0s) indicate a "wildcard" bit.
			4.6.2.8 ID_IPV4_ADDR_RANGE
			The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
			represented by two four (4) octet values. The first value is the
			beginning IPv4 address (inclusive) and the second value is the ending
			IPv4 address (inclusive). All addresses falling between the two
			specified addresses are considered to be within the list.
			4.6.2.9 ID_IPV6_ADDR_RANGE
			The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
			represented by two sixteen (16) octet values. The first value is the
			beginning IPv6 address (inclusive) and the second value is the ending
			IPv6 address (inclusive). All addresses falling between the two
			specified addresses are considered to be within the list.
	4.7 IPSEC Security Parameter Index (SPI) Encoding		4.7 IPSEC Security Parameter Index (SPI) Encoding
	ISAKMP defines the SPI field as eight octets in length, however the		ISAKMP defines the SPI field as eight octets in length, however the
	IPSEC transforms use only four octets.		IPSEC transforms use only four octets.
	All implementation MUST use the following mapping for the ISAKMP SPI		All implementation MUST use the following mapping for the ISAKMP SPI
	field in the IPSEC DOI.		field in the IPSEC DOI.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! SPI !		! SPI !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! RESERVED !		! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: ISAKMP SPI Encoding		Figure 3: ISAKMP SPI Encoding
	The ISAKMP SPI field is defined as follows:		The ISAKMP SPI field is defined as follows:
	o SPI - Security Paramater Index (4 octets) - contains the		o SPI - Security Parameter Index (4 octets) - contains the
	SPI value which identifies the security association.		SPI value which identifies the security association.
	o RESERVED (4 octets) - Unused, must be zero (0).		o RESERVED (4 octets) - Unused, must be zero (0).
	4.8 IPSEC Key Exchange Requirements		4.8 IPSEC Certificate Authorities
	The IPSEC DOI introduces no additional Key Exhange types.		The ISAKMP Certificate Request Payload allows either side of an
			ISAKMP negotiation to request its peer to provide a certificate chain
			needed to authenticate itself. The Certificate Request Payload
			includes a list of acceptable Certificate Types and Certificate
			Authorities. Appropriate certificate chains are then returned in a
			Certificate Payload response.
	5. Security Considerations		The IPSEC DOI defines the following Certificate Authorities for the
			processing of Certificate Request Payloads. See Section 4.5 for
			details on the specific data attribute type values for these CAs.
			Certificate Authority
			---------------------
			DNS Security
			4.8.1 DNS Security
			This CA type represents the combination of KEY and SIG records, as
			defined in RFC-2065, that can be used for authentication. The
			particular encoding required to formulate the Certificate Payload
			(response) is TBD.
			4.9 IPSEC Key Exchange Requirements
			The IPSEC DOI introduces no additional Key Exchange types.
			5. Security Considerations
	This entire draft pertains to a hybrid protocol, combining Oakley		This entire draft pertains to a hybrid protocol, combining Oakley
	([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive keying		([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive keying
	material for security associations in a secure and authenticated		material for security associations in a secure and authenticated
	manner. Specific discussion of the various security protocols and		manner. Specific discussion of the various security protocols and
	transforms identified in this document can be found in the associated		transforms identified in this document can be found in the associated
	base documents.		base documents.
	Acknowledgements		Acknowledgements
	This document is derived, in part, from previous works by Douglas		This document is derived, in part, from previous works by Douglas
	Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,		Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
	and Dave Carrel.		and Dave Carrel.
	References		References
	[HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with		[RFC-1825] Atkinson, R., "Security Architecture for the Internet
	Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-03.txt.		Protocol," RFC-1825, August 1995.
			[RFC-1826] Atkinson, R., "IP Authentication Header," RFC-1826, August
			1995.
			[RFC-1827] Atkinson, R., "IP Encapsulating Security Payload (ESP),"
			RFC-1827, August 1995.
			[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed
			MD5," RFC-1828, August 1995.
			[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC
			Transform," RFC-1829, August 1995.
			[RFC-2065] Eastlake 3rd, D., Kaufman, C., "Domain Name System
			Security Extensions," RFC-2065, January 1997.
			[RFC-2085] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with
			Replay Prevention," RFC-2085, February 1997.
	[HMACSHA] Chang, S., Glenn, R., "HMAC-SHA IP Authentication with		[HMACSHA] Chang, S., Glenn, R., "HMAC-SHA IP Authentication with
	Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt.		Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt.
	[Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay		[Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay
	Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt.		Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt.
	[IO] Carrel, D., Harkins, D., "The Resolution of ISAKMP with Oakley,"		[IO] Carrel, D., Harkins, D., "The Resolution of ISAKMP with Oakley,"
	draft-ietf-ipsec-isakmp-oakley-02.txt.		draft-ietf-ipsec-isakmp-oakley-03.txt.
	[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,		[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
	"Internet Security Association and Key Management Protocol (ISAKMP),"		"Internet Security Association and Key Management Protocol (ISAKMP),"
	draft-ietf-ipsec-isakmp-06.{ps,txt}.		draft-ietf-ipsec-isakmp-07.{ps,txt}.
			[Naganand] Daraswamy, N., "Combined 3DES-CBC, HMAC and Replay
			Detection Security Transform," draft-ietf-ipsec-esp-3des-md5-00.txt.
	[OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"		[OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
	draft-ietf-ipsec-oakley-01.txt.		draft-ietf-ipsec-oakley-01.txt.
	[PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key		[PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key
	Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in		Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in
	progress.		progress.
			[RC5] Howard, B., Baldwin, R., "The ESP RC5-CBC Transform," draft-
			baldwin-esp-rc5-00.txt.
	Author's Address:		Author's Address:
	Derrell Piper <piper@cisco.com>		Derrell Piper <piper@cisco.com>
	cisco Systems		cisco Systems
	101 Cooper St.		101 Cooper St.
	Santa Cruz, California, 95060		Santa Cruz, California, 95060
	United States of America		United States of America
	+1 408 457-5384		+1 408 457-5384
End of changes. 71 change blocks.
	115 lines changed or deleted		350 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/