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!
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
