Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
Hi, ke, 2020-02-12 kello 17:20 +, Jeff Ahrenholz kirjoitti: > > 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. thanks for catching this! This occurred due to a html comment inside a figure (xml2rfc team is working on a fix). Here is the fixed document: https://tools.ietf.org/html/draft-ietf-hip-dex-13#section-6.3 > 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. apparently this has to be fixed manually in collaboration with the RFC editor. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
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 Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
On 2/12/20 11:48 AM, 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. The problem is the loss of text in sec 6.3, not sec 5.2.6. We found the problem is a bug in the submission tool. One way or another we will get the complete text in sec 6.3 in the next draft. minor nits: s/when key is smaller or equal to 128 bits/when the key is smaller or equal to 128 bits/ Fixed, thanks. 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. That is a submission tool bug. I will work with the developers on it. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
>> 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. > >In 6.3: > >IKM Input keying material >the Diffie-Hellman derived key, concatenated with the > random I_NONCE value for the Master Key SA >the Diffie-Hellman derived key, concatenated with the > random values of the ENCRYPTED_KEY parameters in > the same order as the HITs with sort(HIT-I | HIT-R) > for the Pair-wise Key SA Is this a new table row, or maybe something happened to the output? It looks good. In the dex-12 html/text versions I'm seeing the following text, which does not list IKM or info inputs for CKDF-Extract: The CKDF-Extract function is the following operation: CKDF-Extract(I, IKM, info) -> PRK Inputs: I Random #I, provided by the Responder, from the PUZZLE parameter The CKDF-Expand function is the following operation: Moskowitz, et al.Expires August 12, 2020 [Page 32] Internet-Draft HIP Diet EXchange (DEX) February 2020 CKDF-Expand(PRK, info, L) -> OKM Inputs: PRK a pseudorandom key of at least RHASH_len/8 octets (either the output from the extract step or the concatenation of the random values of the ENCRYPTED_KEY parameters in the same order as the HITs with sort(HIT-I | HIT-R) in case of no extract) info sort(HIT-I | HIT-R) | "CKDF-Expand" where "CKDF-Expand" is an octet string L length of output keying material in octets (<= 255*RHASH_len/8) ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
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. In 6.3: IKM Input keying material the Diffie-Hellman derived key, concatenated with the random I_NONCE value for the Master Key SA the Diffie-Hellman derived key, concatenated with the random values of the ENCRYPTED_KEY parameters in the same order as the HITs with sort(HIT-I | HIT-R) for the Pair-wise Key SA 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. I will look at this one again. Back later on it. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
> 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. -Jeff ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] Fwd: New Version Notification for draft-ietf-hip-dex-12.txt
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. Thank you Forwarded Message Subject:New Version Notification for draft-ietf-hip-dex-12.txt Date: Sun, 09 Feb 2020 23:11:55 -0800 From: internet-dra...@ietf.org To: Robert Moskowitz , Rene Hummen , Miika Komu A new version of I-D, draft-ietf-hip-dex-12.txt has been successfully submitted by Miika Komu and posted to the IETF repository. Name: draft-ietf-hip-dex Revision: 12 Title: HIP Diet EXchange (DEX) Document date: 2020-02-09 Group: hip Pages: 57 URL: https://www.ietf.org/internet-drafts/draft-ietf-hip-dex-12.txt Status: https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ Htmlized: https://tools.ietf.org/html/draft-ietf-hip-dex-12 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-hip-dex Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-dex-12 Abstract: This document specifies the Host Identity Protocol Diet EXchange (HIP DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The HIP DEX protocol design aims at reducing the overhead of the employed cryptographic primitives by omitting public-key signatures and hash functions. The HIP DEX protocol is primarily designed for computation or memory- constrained sensor/actuator devices. Like HIPv2, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. Unlike HIPv2, HIP DEX does not support Perfect Forward Secrecy (PFS), and MUST only be used on devices where PFS is prohibitively expensive. In addition, HIP DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.4 networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
