The last remaining issue is related to the UPDATE message and the
rekeying procedure (Section 6.10.). Here, I added the following
paragraph for clarification purposes:
[RFC7402] specifies the rekeying of an existing HIP SA using the
UPDATE message. This rekeying procedure can also be used with HIP
DEX. However, where rekeying involves a new Diffie-Hellman key
exchange, HIP DEX peers MUST establish a new connection in order to
create a new Pair-wise Key SA due to the use of static ECDH key-pairs
with HIP DEX.
Does this fix your issue?
BR
René
On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu <[email protected]
<mailto:[email protected]>> 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]>
<mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/hipsec
<https://www.ietf.org/mailman/listinfo/hipsec>
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
