Hi,
On Mar 30, 2015, at 5:39 PM, Yoav Nir <ynir.i...@gmail.com> 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.
First, the third option is absolutely inappropriate.
The draft suggests using Chacha+Poly for both ESP and IKE and
in case of IKE there are no replay counter that is unique in the context of
IKE SA.
Message ID in IKE header _is_not_ unique - it can be repeated at least in
two cases:
RFC6311 and RFC7383. So, the IKE Message ID is allowed to repeat and these
repetitions would be fatal for security.
Among the first two options I prefer the AES-GCM-like approach -
taking the needed 32 bits from the keying material.
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.
I think UI issues are out of scope of this draft. The draft should make no
recommendations of what PRF
should be used (at least it should not make such recommendations with
RFC2119 keywords).
Regards,
Valery.
Thanks
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
