Hi Rene, please, note Miika's email below, which includes a couple of suggestions about the draft.
Cheers, Gonzalo On 07/06/2016 4:11 PM, Miika Komu wrote: > Hi, > > On 06/03/2016 02:20 PM, René Hummen wrote: >> This is part 3 of 3. > > I am fine with your fixes. Some comments below. > >> On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu <[email protected] >> <mailto:[email protected]>> wrote: >> [...] >> > 6.2.1. CMAC Calculation >> > >> > [...] >> > >> > >> > 5. Set Checksum and Header Length fields in the HIP header to >> > original values. Note that the Checksum and Length fields >> > contain incorrect values after this step. >> >> I guess also the values following HIP_MAC should be restored since >> they were wiped in the step 2. >> >> >> I also found this description a bit imprecise, but it is taken from >> RFC7401. Step 2 already hints at the fact that parameters following >> HIP_MAC may still be of interest: >> "Remove the HIP_MAC parameter, as well as all other parameters >> that follow it with greater Type value, saving the contents if >> they will be needed later." >> >> The question is whether we want to fix the description for HIP DEX or to >> keep things as they are for consistency reasons. In the former case, I >> would prefer to completely rewrite the verification procedure to work on >> the received packet without removing any parameters. However, we should >> then probably also post an errata to RFC7401. If there are no stong >> opinions about that, I would go for the latter option. > > Latter option works for me too. > >> > The CKDF-Extract function is the following operation: >> > >> > CKDF-Extract(I, IKM, info) -> PRK >> >> What does the arrow operator signify? I thought that it produces PRK, >> but PRK is actually defined below. >> >> >> The arrow is part of a basic mathematical function definition. So yes, >> PRK is the output (domain), but we still need to give it a proper name. >> I changed the artwork to clearly point out the inputs and outputs. > > Thanks, it is now better. > >> Please check this section again in the updated version and get back to >> me if the above changes do not sufficiently help your understanding. > > It is good now, thanks! > >> > L length of output keying material in octets >> > (<= 255*RHASH_len/8) >> > | denotes the concatenation >> > >> > The output keying material OKM is calculated as follows: >> > >> > N = ceil(L/RHASH_len/8) >> > T = T(1) | T(2) | T(3) | ... | T(N) >> > OKM = first L octets of T >> > >> > where >> > >> > T(0) = empty string (zero length) >> > T(1) = CMAC(PRK, T(0) | info | 0x01) >> > T(2) = CMAC(PRK, T(1) | info | 0x02) >> > T(3) = CMAC(PRK, T(2) | info | 0x03) >> > ... >> >> The Expand was a bit more clear, but still didn't understand how to >> get to the >> Expanded key material due the arrow notation. >> >> >> Ok, let's clarify this as several comments are related to the arrow >> notation. For the function definition we use the mathematical arrow >> notation (same as RFC 5869) and for the actual opertation we use the >> equals sign (same as RFC 5869). In the end, they denote the same thing: >> "assign X to Y". > > Ok, this is what I guessed too. > >> > (where the constant concatenated to the end of each T(n) is a >> > single octet.) >> >> Is there a max value? >> >> >> I am not sure what you mean here. If you refer to the N in T(N) then it >> is defined above as N = ceil(L/RHASH_len/8). > > Yes, I asked about the maximum value for N (which depends on L), but > never mind. > >> > 8. The R1 packet may have the A-bit set - in this case, the >> system >> > MAY choose to refuse it by dropping the R1 packet and returning >> > to state UNASSOCIATED. The system SHOULD consider dropping the >> > R1 packet only if it used a NULL HIT in the I1 packet. >> >> I didn't understand the logic in the last sentence. >> >> >> Someone must have had a reason for this recommendation, but that someone >> wasn't me. This is text from RFC7401. Any suggestions how to proceed? > > Fix similarly as the other RFC7401 issue in the beginning of this email. > >> > 6.7. Processing Incoming I2 Packets >> > >> > [...] >> > >> > 5. If the system's state machine is in the I2-SENT state, the >> > system MUST make a comparison between its local and sender's >> > HITs (similarly as in Section 6.3). If the local HIT is smaller >> > than the sender's HIT, it should drop the I2 packet, use the >> > peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce >> > #I from the R1 packet received earlier, and get the local >> > Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J >> > from the I2 packet sent to the peer earlier. Otherwise, the >> > system should process the received I2 packet and drop any >> > previously derived Diffie-Hellman keying material Kij and >> > ENCRYPTED_KEY keying material it might have generated upon >> > sending the I2 packet previously. The peer Diffie-Hellman key, >> > ENCRYPTED_KEY, and the nonce #J are taken from the just arrived >> > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying >> > material, and the nonce #I are the ones that were sent earlier >> > in the R1 packet. >> >> Please replace "sender" with "peer" (or remote host) in this section >> for more symmetric terminology. >> >> get -> obtain >> >> >> I can make these changes if you insist, but I was going for a minimal >> diff to RFC 7401. > > Not insisting. > >> >> > 11. The implementation SHOULD also verify that the Initiator's >> HIT >> > in the I2 packet corresponds to the Host Identity sent in the I2 >> > packet. (Note: some middleboxes may not be able to make this >> > verification.) >> >> Why SHOULD? Why not MUST? I think we're talking about end-hosts here >> anyway. >> >> >> It is defined this way in RFC 7401. Do you really want to change the >> packet processing behavior for HIP DEX only? > > Fix similarly as the first RFC7401 issue in this email. > >> > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets >> >> > UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in >> HIP DEX >> > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of >> [RFC7401]). >> > The only difference is the that the HIP_SIGNATURE is never present >> > and, therefore, is not required to be processed by the receiving >> > party. >> >> How does rekeying work with the extract and expand functions? >> >> >> Rekeying is not defined in this document, same as for RFC 7401. That >> being said, the rekeying procedure with reuse of the KEYMAT from RFC >> 7402 directly translates to HIP DEX. For new KEYMAT, the peers need to >> establish a new connection due to the use of static DH keys. > > Maybe this should be explicitly stated in the draft. > >> >> >> > 7. HIP Policies >> >> > There are a number of variables that will influence the HIP >> exchanges >> > that each host must support. All HIP DEX implementations SHOULD >> > provide for an ACL of Initiator's HI to Responder's HI. This ACL >> > SHOULD also include preferred transform and local lifetimes. >> > Wildcards SHOULD also be supported for this ACL. >> >> Why ACLs are mandatory? >> >> >> It is not a MUST and considering that HIP DEX is primarly targeted at >> things, there is the need to do basic device authorizations (based on >> their identities) without a human in the loop. Of course you are also >> allowed to use more suffisticated authorization mechanisms. > > Ok. > >> ACL -> ACL consisting of >> >> >> Changed to the following text that is closer to RFC 7401: >> " All HIP DEX implementations SHOULD provide for an Access Control List >> (ACL), representing for which hosts they accept HIP diet exchanges, >> and the preferred transport format and local lifetimes. Wildcarding >> SHOULD be supported for such ACLs." >> >> > 8. Security Considerations >> >> > o The HIP DEX HIT generation may present new attack >> opportunities. >> >> They cannot be used in ACLs. Maybe this could be mentioned. Can this >> be mitigated by always using full HIs? >> >> >> I changed the bullet-point as follows: >> "The HIP DEX HIT generation may present new attack opportunities. >> Hence, HIP DEX HITs should not be use as the only means to >> identify a peer in an ACL. Instead, the use of the peer's HI is >> recommended." > > Ok. > >> Note that I added a new Section 8 "Interoperability between HIP DEX and >> HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibility. > > Thanks! > > > > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
