On 2/12/20 12:20 PM, Jeff Ahrenholz wrote:
I believe this version answers all the IESG issues.
Please review, there are some important additions.
EKR had a number of security concerns. Some I feel don't apply to HIP, like
use an AEAD for HIP packet security.
But there are a number of added sections, particularly in Security
Considerations that are worth the group's review that I have things stated
properly.
Also there is a new parameter, I_NONCE to add Initiator randomness into the
Master Key generation. There is some cleanup in the KEYMAT section to reflect
this.
So please take a read through.
I took a look at the new I_NONCE parameter...
Regarding this statement (Section 5.2.6):
"The I_NONCE parameter encapsulates a random value that is later used in the Master
key creation process (see Section 6.3)."
Looking at Section 6.3 HIP DEX KEYMAT Generation, it discusses using
Diffie-Hellman derived key Kij, but I don't see anything about using I_NONCE.
There is a random #I provided by the Responder from the PUZZLE parameter, but
nothing about a random I_NONCE supplied by the Initiator.
minor nits:
s/when key is smaller or equal to 128 bits/when the key is smaller or equal to
128 bits/
In Section 4.1.1 HIP Puzzle Mechanism, the links (HTML version) to RFC 7401
sections 4.1.1 and 4.1.2 do not link to RFC 7401 but to the dex draft.
This is the fault of the tool that takes the ID txt to generate the
html. Currently, this is NOT done from the xml, so changing the xml
will not help. Once approved for RFC, the RFC editor will make sure all
html is right. So we just have to live with this for now. The problem
is not ours and there are no reasonable changes we can make to the text
to get the html right for the draft.
Humph.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
