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

[Rene Hummen <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> 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: [phone]
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/