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/