I'll try to wrap up the inputs and post a revision over the weekend, if no further comments. Please see inline below.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Henderson, Thomas R > Sent: Sunday, September 08, 2013 9:50 PM > To: HIP > Cc: '[email protected]' > Subject: [Hipsec] additional comments on latest RFC5201-bis draft > > Last week I published a new version of RFC5201-bis: > http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13 > > This was mainly to address ID-nits and prepare the draft for the next > stage of the review process. However, I also received a number of > comments from Anders Brandt (cc'ed) on the version-12 draft. The > purely editorial ones were included in version-13, but I decided to > post a few for review on the list. > > In the interest of expediency, I'd like to suggest that we aim for > resolving all of these within the next two weeks. > > 1) Section 4.1, the statement is made: > > "As a result, it is believed that the HIP opportunistic mode is at > least as secure as current IP." > > Anders questioned what this statement means. Further clarifications > are needed here. I propose to address this with the union of Miika and Robert's comments: As a result, opportunistic mode in HIP offers a "better than nothing" security model. Initially, a base exchange authenticated in the opportunistic mode involves a leap of faith subject to man-in-the-middle attacks, but subsequent datagrams related to the same HIP association cannot be compromised by a new man-in-the-middle attack, and further, if the man-in-the-middle moves away from the path of the active association, the attack would be exposed after the fact. Thus, it can be stated that opportunistic mode in HIP is at least as secure as unprotected IP-based communications. > > 2) Section 5.1 > > "Since all HIP headers MUST contain the sender's and receiver's HIT > fields, the minimum value for this field is 4, and conversely, the > maximum length of the HIP parameters filed is (255*8-32 = 2008 bytes." > > Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs > clarification or reference to the discussion on HIP fragmentation in > Section 5.1.3. I propose to add a reference here to the later section on fragmentation requirements. > > 3) Section 5.3.2 > > "If the Responder uses the same DH keypair for multiple handshakes. It > must take care to avoid small subgroup attacks [RFC2785]." These > sentences are marked by Anders, perhaps for grammatical reasons (they > should at least be combined). I will just repair the grammatical error (make into one sentence), since no other comments were received. > > 4) Section 6.7.1, R1 Management > > Anders asks whether it is allowed to make an initiator-only device, if > there is a MUST in this section to be able to produce R1s. I do not > believe that the current protocol allows one to make an initiator-only > device; perhaps this could be clarified. > My view is in line with Robert's on this, so I propose: Old text: All compliant implementations MUST be able to produce R1 packets. New text: All compliant implementations MUST be able to produce R1 packets; even if a device is configured by policy to only initiate associations, it must be able to process I1s in case of recovery from loss of state or key exhaustion. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
