Hi Valery, I have some comments on https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-aux-00
AUX_EXCHANGE_SUPPORTED: This specification doesn't define any data this notification may contain, so the Notification Data is left empty. However, other specifications may override this. Implementations MUST ignore the non-empty Notification Data if they don't understand its purpose. If there are multiple future specifications which use AUX_EXCHANGE_SUPPORTED, is it expected that multiple AUX_EXCHANGE_SUPPORTED notifications would be sent in IKE_SA_INIT? I don’t know of any other notifications where there might be multiple copies sent in one exchange, not that this is a reason to avoid it, but it might be simpler to not introduce this possibility. Also, if the data is simple/only a few bytes there’s a chance of ambiguity as to whether the data is defined by one specification or another. I think it would be simpler if the notification data is just left empty (or left for IKE_AUX-specific data, see below). Other specifications will have to define how their own features are negotiated, so any related data could be sent in the notifications for those specifications and doesn’t need to be sent in IKE_AUX. Authentication: ICV_INIT_1, ICV_INIT_2, ICV_INIT_3, etc. represent the content of the Integrity Checksum Data field from the Encrypted payloads (or Encrypted Fragment payloads) from all the IKE_AUX messages sent by the initiator in an order of increasing MessageIDs (and increasing Fragment Numbers for the same Message ID). AEAD encryption transform IDs don’t use an Integrity Checksum Data field in their Encrypted payloads, so this method won’t work for authentication of IKE_AUX exchanges when AEAD is used. Additionally, Scott pointed out to me that Integrity Check Values aren’t designed to be secure against someone who knows the key (which would be the case for a Quantum-enabled attacker) and that for algorithms like GMAC the attacker would be able to find a collision. So then your statement later: THe forgery would become evident in the IKE_AUTH exchange (provided the attacker caanot break employed authentication mechanism) wouldn’t hold; an attacker could find a forgery with the same ICV and IKE_AUTH exchange would succeed. But regardless of that, AEAD is a good enough reason why ICVs shouldn’t be used here. Presumably you don’t want to include the whole data for the entire set of IKE_AUX exchanges in the signed octets because that would mean persisting the data for all IKE_AUX exchanges until IKE_AUTH is processed, requiring a lot of extra buffer state and increasing the attack surface for buffer exhausting? A second-preimage-resistant hash function is needed to use a digest of the IKE_AUX messages in the signed octets. This algorithm could possibly be negotiated in the AUX_EXCHANGE_SUPPORTED notification data. Thanks, Daniel
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
