Sec Area experts, https://datatracker.ietf.org/doc/draft-dmk-rtgwg-multisegment-sdwan/ describes the IPsec encrypted packets being steered through a Cloud GW without requiring the Cloud GW to decrypt the packets and re-encrypt the packets. The draft suggests the GENEVE header be included in the packets to indicate to the Cloud GW that the packets don't need decryption/encryption rather than just forwarding.
However, data authentication and integrity check are needed as the traffic traverse an untrusted network. The document suggests using HMAC for authentication and integrity checks. We are looking for feedback from security experts, especially on the analysis of using HMAC for integrity & authentication check. Thank you very much, Linda --------------------------- The advantages of using HMAC are: * Data Integrity: HMAC provides a strong mechanism for verifying the integrity of data. By hashing the message and using a secret key, it generates a fixed-size hash value that ensures the data has not been tampered with during transmission. * Authentication: HMAC also verifies the authenticity of the sender. Since HMAC requires a shared secret key between the sender and receiver, it confirms that the sender is who they claim to be. * Efficiency: HMAC is computationally efficient, making it suitable for real-time applications and resource-constrained devices. It uses simple bitwise operations and hash functions. * Resistance to Tampering: HMAC is designed to resist various forms of tampering, including replay attacks, message insertion, and message deletion. Any change in the message will result in a different HMAC value. * Flexibility: HMAC can be used with various hash functions, such as SHA-256 or SHA-512, depending on the desired level of security and application requirements. * Widely Supported: HMAC is a well-established and widely supported authentication mechanism, making it easy to integrate into different systems. Here are some common problems associated with using the HMAC and why their risks are acceptable in the scenario described in this draft. * Key Management: The security of HMAC depends heavily on the confidentiality and management of the shared secret key. If the key is compromised, the data packets from CPEs to Cloud GW can be dropped but not compromised because the user payloads are protected by IPsec SA encryption. * Lack of Non-Repudiation: HMAC provides data integrity and sender authentication but does not provide non-repudiation. Non-repudiation is the ability to prove that a message was sent by a specific sender, which HMAC alone cannot guarantee. This risk is same as two IPsec protected traffic between CPEs. * Limited to Symmetric Cryptography: HMAC relies on symmetric key cryptography, which means that both parties must share the same secret key. As the Cloud backbone interconnecting CPEs are paid services, there are established channels to distribute the symmetric key. * No Protection Against Eavesdropping: While HMAC ensures data integrity and sender authentication, it does not provide encryption. Eavesdropping does pose additional risks to payloads encrypted by IPsec SA. In summary, HMAC-based integrity and authentication offer strong security benefits in terms of data integrity and sender authentication. Even though it does not provide non-repudiation or protection against eavesdropping, the IPsec encrypted payload between CPEs won't be impacted.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
