On 10/09/2014 09:55 AM, Rene Hummen wrote:
Hi Tom,
I am not sure if we there was an answer to this question before. Why
don’t we simply use the four lower-order bits in the HIT_SUITE_LIST
ID field to convey the HIT Suites ID? That would definitely make the
mapping between HIT Suites IDs and OGA IDs much clearer as the 4-bit
and the 8-bit values would be the same. Moreover, I thought we would
skip the part about using larger HIT suite IDs _in the main protocol
specification_. I like your added text in the IANA consideration
though.
I agree with your comment that alignment with lower-order bits in the
8-bit fields would be clearer. However, I suppose it was done the way
it currently reads to facilitate the expansion; I don't remember the
history of that particular design choice.
I also would be fine to delete the text on larger HIT suite IDs in the
parameter definition, leaving it for the appendix and IANA
considerations section.
My proposed changes are inline based on your provided diff:
31 @@ -3099,8 +3099,11 @@ 32 host. Each HIT
Suite ID is one octet long. The four 33
higher-order bits of the ID field correspond to the 34
HIT Suite ID in the ORCHID OGA field. The four 35 -
lower-order bits are reserved and set to 0 and 36 -
ignored by the receiver. 37 + lower-order bits are
reserved and set to 0 by 38 + the sender. The
reception of an ID with the 39 + four lower-order
bits not set to 0 should be 40 + considered as an
error that MAY result in a 41 + NOTIFICATION of
type UNSUPPORTED_HIT_SUITE.
I think the “should” should be a “SHOULD”. Combined, with my above
suggestion, we could rephrase your revised text as follows: “The
reception of a HIT Suite ID with one of the four higher-order bits
set to 1 SHOULD be considered as an error. This error MAY trigger a
NOTIFICATION message of type UNSUPPORTED_HIT_SUITE."
OK with this, if the other change is indeed made.
@@ -3115,13 +3118,55 @@ 46 the ID field. Future documents may
define the use of the four lower- 47 order bits in the ID field.
The above paragraph about extending the HIT Suite ID space from 4 to
8 bit could be removed from the main protocol specification. I don’t
think there is anything weird about an 8-byte HIT Suite ID field
alignment in the HIT_SUITE_LIST parameter (if we change the HIT Suite
ID spec from, e.g., 0x10 to 0x01).
49 - The following HIT Suites ID are defined: 50 + The following
HIT Suites ID are defined, and the relationship between 51 + the
four-bit ID value used in the OGA ID field, and the eight-bit 52 +
encoding within the HIT_SUITE_LIST ID field, is clarified: 53 + 54 +
HIT Suite Four-bit ID Eight-bit encoding 55 +
RESERVED 0 0x00 56 + RSA,DSA/SHA-256
1 0x10 (REQUIRED) 57 + ECDSA/SHA-384
2 0x20 (RECOMMENDED) 58 +
ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)
This could remain as in -19 because 4-bit and 8-bit values would not
differ.
Agreed, if that change is made.
100 + The hash of the responder as defined in the HIT Suite
determines the 101 + HMAC to be used for the HMAC parameter. The
HMACs currently defined 102 + here are HMAC-SHA-256 [RFC4868],
HMAC-SHA-384 [RFC4868], and HMAC- 103 + SHA-1 [RFC2404].
This appears to be a small editorial mistake: “HMAC parameter” ->
“HIP_MAC and HIP_MAC_2 parameters”. To be precise, the hash function
specifies the RHASH, which in turn determines the hash function to be
used for HMAC. RHASH is also used as the key derivation function.
I can fix this in the next iteration; the above was copied from Appendix
E of -19. Thanks for the catch.
- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
