Hi,
I just uploaded draft version 04, where I addressed Miika's comments
as discussed in the previous emails.
From my point of view, this document is ready to proceed.
BR
René
2016-10-21 9:13 GMT+02:00 Gonzalo Camarillo
<[email protected] <mailto:[email protected]>>:
Hi Rene,
do you intend to release a new version of the draft with this
addition?
What is the current status of the draft otherwise?
Thanks,
Gonzalo
On 26/09/2016 4:46 PM, Miika Komu wrote:
> Hi René,
>
> On 09/11/2016 11:06 PM, René Hummen wrote:
>> Hello Miika,
>>
>> going through your email again, I saw a total of four suggestions.
>>
>> Three of them refer to imprecisions in the text of RFC 7401
(which I
>> copy/pasted for HIP DEX). There, I understood that consistency
with RFC
>> 7401 has a higher priority than only fixing your comments for
HIP DEX,
>> but keeping the text as is for RFC 7401. This means, I will not
modify
>> the text in the HIP DEX draft. Is this also your intention?
>
> yes, 7401 takes precedence over my comments.
>
>> 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?
>
> Yes. I assume you mean a new HIP association with connection.
>
>> BR
>> René
>>
>>
>>
>> On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu
<[email protected] <mailto:[email protected]>
>> <mailto:[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]>>
>> <mailto:[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]>
<mailto:[email protected] <mailto:[email protected]>>
>> https://www.ietf.org/mailman/listinfo/hipsec
<https://www.ietf.org/mailman/listinfo/hipsec>
>> <https://www.ietf.org/mailman/listinfo/hipsec
<https://www.ietf.org/mailman/listinfo/hipsec>>
>>
>>
>
_______________________________________________
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
