Re: [Hipsec] Antwort: Re: clarification on HIT Suite IDs

[Tom Henderson <[e-mail]>]

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