> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer <[email protected]> wrote: > > I am still a bit confused about Sec. 3 (use in IKEv2): > > - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the > IV is included explicitly, and where exactly it should go?
It says that the IV is 64-bit, same as in section 2, and RFC 7296 section 3.14 says that the IV is explicit. Although in honesty, it also says that the size of the IV is equal to block length, which would make it 512 bits here? Anyway, RFC 7296 does say that this is true only for CBC. > - In the bullet that describes the IV, I would add text that the IKE Message > ID is not an option, and why. The whole idea of using sequence number as IV is now gone from the draft. If we want to add some path-not-taken text, it should probably go in the Security Considerations or maybe another appendix. I don’t really think it is relevant. > - How do we make sure that the key/IV combination is unique between Initiator > and Responder? PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and responder respectively. Each is 36 octets (288 bits). While we don’t explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used by both. > Thanks, > Yaron > > On 04/27/2015 01:44 AM, Paul Hoffman wrote: >> Greetings again. This begins the two-week WG Last Call on >> draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would >> love to hear from people in either of two groups: >> >> - Those who have already reviewed an earlier version of this draft. Please >> re-read the draft now, and let us know if it is perfect, or if there >> anything else you want added or changed. This includes Yaron, PaulW, Tero, >> ScottF, and Valery. >> >> - Those who have *not* yet reviewed this draft, but want to help the IETF >> create good standards in this area. If you are an IPsec implementer, or know >> one at your organization, reviewing this draft and sending any comments to >> the list (even just "seems fine" or "I liked it except this one thing") is >> useful to all of us. >> >> It seems very likely that this new algorithm combination will appear in >> IKEv2 and ESP soon, and having folks give a bit more review will help >> prevent whoopsies in the future. >> >> --Paul Hoffman >> > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
