Arrgh. Please don’t reply-all to my previous message, because it was mistakenly directed to I-D announce…
> On Mar 30, 2015, at 5:39 PM, Yoav Nir <[email protected]> wrote: > > 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
