Hi, There is two questions I would like guidance from the group about.
First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce is constructed from the 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm could be used in a multi-sender case such as GDOI, where the 32-bit zero can be replaced by a sender ID. Alternatively, we could generate a 32-bit salt value from the key material, but I don’t see a reason why we’d want that. Another thing we could do is what some people are advocating for TLS: Since a counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV that has the exact same value as the replay counter. We might as well save 8 bytes per packet and just feed the replay counter to the function. The argument against this is that some crypto modules may have the API set up in such a way that the IVs are generated within the module and could be something other than a counter (like an LFSR). The proposal will break such APIs. Second issue is about UI advice. Some implementations (yes, mine is included) allow the user to configure encryption algorithm, MAC algorithm, and D-H group. There is no setting for PRF since such UIs date back to IKEv1. The PRF is usually just taken from the setting for MAC algorithm. This works fine as long as all supported MAC algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC 5282 makes no mention of this issue. I’m wondering if we should recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256. Thanks Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
