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

From: Tom Henderson <[email-masked]>
Date: Wed, 08 Oct 2014 23:23:34 -0700

I've created a preview draft version 20 that makes the changes described 
in this post:

http://www.ietf.org/mail-archive/web/hipsec/current/msg03975.html

I also created a diff file between -19 and -20-pre and trimmed out the 
non-substantive parts.

I attached both of these files to this ticket, for review:
http://trac.tools.ietf.org/wg/hip/trac/ticket/51

If there is WG consensus to request to make these changes, then I'll ask 
for guidance on what to do next (publish a new draft, or handle another 
way).

- Tom

---

From: Rene Hummen <[email-masked]>
Date: Thu, 9 Oct 2014 16:55:17 +0000

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. 

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."

@@ -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.

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.

135	@@ -6019,13 +6075,17 @@
136	       HIT Suite ID reduces the cryptographic strength of the HIT.  HIT
137	       Suite IDs must be allocated carefully to avoid namespace
138	       exhaustion.  Moreover, deprecated IDs should be reused after an
139	-      appropriate time span.  If 16 Suite IDs prove insufficient and
140	-      more HIT Suite IDs are needed concurrently, more bits can be used
141	-      for the HIT Suite ID by using one HIT Suite ID (0) to indicate
142	-      that more bits should be used.  The HIT_SUITE_LIST parameter
143	-      already supports 8-bit HIT Suite IDs, should longer IDs be needed.
144	-      Possible extensions of the HIT Suite ID space to accommodate eight
145	-      bits and new HIT Suite IDs are defined through IETF Review.
146	+      appropriate time span.  If 15 Suite IDs (the zero value is
147	+      initially reserved) prove to be insufficient and more HIT Suite
148	+      IDs are needed concurrently, more bits can be used for the HIT
149	+      Suite ID by using one HIT Suite ID (0) to indicate that more bits
150	+      should be used.  The HIT_SUITE_LIST parameter already supports
151	+      8-bit HIT Suite IDs, should longer IDs be needed.  However, RFC
152	+      7343 [RFC7343] does not presently support such an extension, and
153	+      the rollover approach described in Appendix E is suggested to be
154	+      tried first.  Possible extensions of the HIT Suite ID space to
155	+      accommodate eight bits and new HIT Suite IDs are defined through
156	+      IETF Review.

This nicely captures the intended procedure.

BR
René

On 09 Oct 2014, at 08:23, Tom Henderson <[email-masked]> wrote:

> I've created a preview draft version 20 that makes the changes described in this post:
> 
> I also created a diff file between -19 and -20-pre and trimmed out the non-substantive parts.
> 
> If there is WG consensus to request to make these changes, then I'll ask for guidance on what to do next (publish a new draft, or handle another way).
> 
> - Tom
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Tom Henderson <[email-masked]>
Date: Thu, 09 Oct 2014 22:13:44 -0700

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.

> 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)
>

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

---

From: Rene Hummen <[email-masked]>
Date: Fri, 10 Oct 2014 08:52:04 +0000

> history of that particular design choice.

When using the four lower-order bits instead of the higher-order bits, we could simply define HIP Suite IDs > 16 to be reserved for future use. This would similarly facilitate the desired expansion, doesn’t it?

René