Clearly we need to mention that the IV is included, despite the text of
RFC 7296.
You are right about SK_ei/er. The second bullet in Sec. 3 should not
mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er.
Thanks,
Yaron
On 04/27/2015 11:38 AM, Yoav Nir wrote:
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
