Why IPsec doesn’t support non-repudiation?

Posted on by

Top Level IPsec Processing Model_V2

This post is a digest of “IPsec and Non-repudiation.”

Why IPsec doesn’t support non-repudiation? The following is a quick answer:

  1. Only a few obsoleted IPsec-related RFCs used the term, “non-repudiation.”
  2. The latest IPsec-related RFCs avoid using the term, “non-repudiation.”
  3. Non-repudiation applies to the application level. (RFC 4359)

The “New” IPsec (IPsec-v3)

RFC 4301 reads as follows:

The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality.

Connectionless integrity and data origin authentication are collectively called “integrity.” As a result, we can further summarize services provided by IPsec:

  • Access control
  • Integrity (data integrity and authenticity)
  • Confidentiality
  • Anti-replay

RFC 4301 doesn’t mention non-repudiation explicitly, implicitly, or even literally throughout the document.

Authenticaticity and Non-repudiation

Authenticity is “the property of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or message originator.” (NIST SP 800-53 Rev. 4)

Mutual authentication through the implementation of certificates or the Public Key Infrastructure (PKI) is commonly confused with non-repudiation. Even the first release of the AH standard (RFC 1826) holds this position.

However, RFC 1826 has been obsoleted by RFC 2402 and RFC 4302. Both of them explicitly remove the term “non-repudiation” and replace it with “data origin authentication for IP datagrams.”

Key Exchange and Non-repudiation

However, IKEv1 has been obsoleted by IKEv2 as defined in RFC 4306 and RFC 5996. The latest version of IKEv2 is RFC 5996, which mentions nothing about “non-repudiation” but “mutual authentication” and states:

IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) or Authentication Header (AH) and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry. (RFC 5996)

Conclusion

As the word choice shifts from non-repudiation to authentication and integrity in RFCs, we can see IETF is serious about the definition of “non-repudiation.” It avoids using the term “non-repudiation” in IPsec-related RFCs and denies its applicability to network packets.
In summary,
  • Only a few obsoleted IPsec-related RFCs used the term, “non-repudiation.”
  • The latest IPsec-related RFCs avoid using the term, “non-repudiation.”
  • Non-repudiation applies to the application level. (RFC 4359)

Based on the study above, we can conclude IPsec doesn’t support non-repudiation.

Revisions

  • 2020/07/27, Initial post
  • 2020/07/29, Add Authenticaticity and Non-repudiation, and Key Exchange and Non-repudiation
https://wentzwu.com/2020/07/27/ipsec-and-non-repudiation/

Leave a Reply