draft-ietf-hip-base-10.orig		draft-ietf-hip-base-10.petri.txt
	5.2.12. HIP_SIGNATURE_2		5.2.12. HIP_SIGNATURE_2
	The parameter structure is the same as in Section 5.2.11. The fields		The parameter structure is the same as in Section 5.2.11. The fields
	are:		are:
	Type 61633		Type 61633
	Length length in octets, excluding Type, Length, and		Length length in octets, excluding Type, Length, and
	Padding		Padding
	SIG alg Signature algorithm		SIG alg signature algorithm
	Signature the signature is calculated over the HIP R1 packet,		Signature Within the R1 packet that contains the HIP_SIGNATURE_2
	excluding the HIP_SIGNATURE_2 parameter and any		parameter, the initiator's HIT, the checksum
	parameters that follow. Initiator's HIT, checksum
	field, and the Opaque and Random #I fields in the		field, and the Opaque and Random #I fields in the
	PUZZLE parameter MUST be set to zero while		PUZZLE parameter MUST be set to zero while
	computing the HIP_SIGNATURE_2 signature. Further,		computing the HIP_SIGNATURE_2 signature. Further,
	the HIP packet length in the HIP header MUST be		the HIP packet length in the HIP header MUST be
	calculated to the beginning of the HIP_SIGNATURE_2		adjusted as if the HIP_SIGNATURE_2 was not in the
	parameter when the signature is calculated.		packet during the signature calculation, i.e., the
			HIP packet length points to the beginning of
			the HIP_SIGNATURE_2 parameter during signing and
			verification.
	Zeroing the Initiator's HIT makes it possible to create R1 packets		Zeroing the Initiator's HIT makes it possible to create R1 packets
	beforehand to minimize the effects of possible DoS attacks. Zeroing		beforehand, to minimize the effects of possible DoS attacks. Zeroing
	the I and Opaque fields allows these fields to be populated		the Random #I and Opaque fields within the PUZZLE parameter allows
	dynamically on precomputed R1s.		these fields to be populated dynamically on precomputed R1s.
	Signature calculation and verification follows the process in		Signature calculation and verification follows the process in
	Section 6.4.2.		Section 6.4.2.
	5.2.15. ENCRYPTED		5.2.15. ENCRYPTED
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	skipping to change at page 51, line ?		skipping to change at page 51, line ?
	Type 641		Type 641
	Length length in octets, excluding Type, Length, and		Length length in octets, excluding Type, Length, and
	Padding		Padding
	Reserved zero when sent, ignored when received		Reserved zero when sent, ignored when received
	IV Initialization vector, if needed, otherwise		IV Initialization vector, if needed, otherwise
	nonexistent. The length of the IV is inferred from		nonexistent. The length of the IV is inferred from
	the HIP transform.		the HIP transform.
	Encrypted The data is encrypted using an encryption algorithm		Encrypted The data is encrypted using an encryption algorithm
	data as defined in HIP transform.		data as defined in HIP transform.
	Padding Any Padding, if necessary, to make the parameter a
	multiple of 8 bytes.
	The ENCRYPTED parameter encapsulates another parameter, the encrypted		The ENCRYPTED parameter encapsulates another parameter, the encrypted
	data, which is also in TLV format. Consequently, the first fields in		data, which holds one or more HIP parameters in block encrypted form.
	the encapsulated parameter(s) are Type and Length, allowing the
	contents to be easily parsed after decryption.
	Both the ENCRYPTED parameter and the encapsulated parameter(s) MUST		Consequently, the first fields in the encapsulated parameter(s) are
	be padded. The padding needed for the ENCRYPTED parameter is		Type and Length of the first such parameter, allowing the contents to
	referred as the "outer" padding. Correspondingly, the padding for		be easily parsed after decryption.
	the parameter(s) encapsulated within the ENCRYPTED parameter is
	referred as the "inner" padding.
	The inner padding follows exactly the rules of Section 5.2.1. The		The field labelled "Encrypted data" consists of the output of one or
	outer padding also follows the same rules but with an exception.		more HIP parameters concatenated together that have been passed
	Namely, some algorithms require that the data to be encrypted must be		through an encryption algorithm. Each of these inner parameters is
	a multiple of the cipher algorithm block size. In this case, the		padded according to the rules of Section 5.2.1 for padding individual
	outer padding MUST include extra padding, as specified by the		parameters. As a result, the concatenated parameters will be a block
	encryption algorithm. The size of the extra padding is selected so		of data that is 8-byte aligned.
	that the length of the ENCRYPTED is the minimum value that is both
	multiple of eight and the cipher block size. The encryption		Some encryption algorithms require that the data to be encrypted must
	algorithm may specify padding bytes other than zero; for example, AES		be a multiple of the cipher algorithm block size. In this case, the
	[FIPS01] uses the PKCS5 padding scheme [RFC2898] (see section 6.1.1)		above block of data MUST include additional padding, as specified by
	where the remaining n bytes to fill the block each have the value n.		the encryption algorithm. The size of the extra padding is selected
			so that the length of the unencrypted data block is a multiple of the
			cipher block size. The encryption algorithm may specify padding
			bytes other than zero; for example, AES [FIPS01] uses the PKCS5
			padding scheme (see section 6.1.1 of [RFC2898]) where the remaining n
			bytes to fill the block each have the value n. This yields an
			"unencrypted data" block that is transformed to an "encrypted data"
			block by the cipher suite. This extra padding added to the set of
			parameters to satisfy the cipher block alignment rules is not counted
			in HIP TLV length fields, and this extra padding should be removed by
			the cipher suite upon decryption.
	Note that the length of the cipher suite output may be smaller or		Note that the length of the cipher suite output may be smaller or
	larger than the length of the data to be encrypted, since the		larger than the length of the set of parameters to be encrypted,
	encryption process may compress the data or add additional padding to		since the encryption process may compress the data or add additional
	the data.		padding to the data.
			Once this encryption process is completed, the Encrypted data field
			is ready for inclusion in the Parameter. If necessary, additional
			Padding for 8-byte alignment is then added according to the rules of
			Section 5.2.1.
	8. Security Considerations		8. Security Considerations
	HIP is designed to provide secure authentication of hosts. HIP also		HIP is designed to provide secure authentication of hosts. HIP also
	attempts to limit the exposure of the host to various denial-of-		attempts to limit the exposure of the host to various denial-of-
	service and man-in-the-middle (MitM) attacks. In so doing, HIP		service and man-in-the-middle (MitM) attacks. In so doing, HIP
	itself is subject to its own DoS and MitM attacks that potentially		itself is subject to its own DoS and MitM attacks that potentially
	could be more damaging to a host's ability to conduct business as		could be more damaging to a host's ability to conduct business as
	usual.		usual.
	skipping to change at page 92, line 10		skipping to change at page 93, line 10
	such connection set up are for applications. There are certain		such connection set up are for applications. There are certain
	concerns with opportunistic mode, as discussed in Section 4.1.6.		concerns with opportunistic mode, as discussed in Section 4.1.6.
	NOTIFY messages are used only for informational purposes and they are		NOTIFY messages are used only for informational purposes and they are
	unacknowledged. A HIP implementation cannot rely solely on the		unacknowledged. A HIP implementation cannot rely solely on the
	information received in a NOTIFY message because the packet may have		information received in a NOTIFY message because the packet may have
	been replayed. It SHOULD NOT change any state information based		been replayed. It SHOULD NOT change any state information based
	purely on a received NOTIFY message.		purely on a received NOTIFY message.
	Since not all hosts will ever support HIP, ICMP 'Destination Protocol		Since not all hosts will ever support HIP, ICMP 'Destination Protocol
	Unreachable' are to be expected and present a DoS attack. Against an		Unreachable' messages are to be expected and present a DoS attack.
	Initiator, the attack would look like the Responder does not support		Against an Initiator, the attack would look like the Responder does
	HIP, but shortly after receiving the ICMP message, the Initiator		not support HIP, but shortly after receiving the ICMP message, the
	would receive a valid R1 HIP packet. Thus to protect from this		Initiator would receive a valid R1 HIP packet. Thus, to protect from
	attack, an Initiator should not react to an ICMP message until a		this attack, an Initiator should not react to an ICMP message until a
	reasonable delta time to get the real Responder's R1 HIP packet. A		reasonable delta time to get the real Responder's R1 HIP packet. A
	similar attack against the Responder is more involved. First an ICMP		similar attack against the Responder is more involved. Normally, if
	message is expected if the I1 was a DoS attack and the real owner of		an I1 message received by a Responder was a bogus one sent by an
	the spoofed IP address does not support HIP. The Responder SHOULD		attacker, the Responder may receive an ICMP message from the IP
	NOT act on this ICMP message to remove the minimal state from the R1		address the R1 message was sent to. However, a sophisticated
	HIP packet (if it has one), but wait for either a valid I2 HIP packet		attacker can try to take advantage of such a behavior and try to
	or the natural timeout of the R1 HIP packet. This is to allow for a		break up the HIP exchange by sending such an ICMP message to the
	sophisticated attacker that is trying to break up the HIP exchange.		Responder before the Initiator has a chance to send a valid I2
	Likewise, the Initiator should ignore any ICMP message while waiting		message. Hence, the Responder SHOULD NOT act on such an ICMP
	for an R2 HIP packet, deleting state only after a natural timeout.		message. Especially, it SHOULD NOT remove any minimal state created
			when it sent the R1 HIP packet (if it did create one), but wait for
			either a valid I2 HIP packet or the natural timeout (that is, if R1
			packets are tracked at all). Likewise, the Initiator should ignore
			any ICMP message while waiting for an R2 HIP packet, and should
			delete any pending state only after a natural timeout.
End of changes. 10 change blocks.
	38 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/