First thing first. IPsec doesn’t support non-repudiation.

The “New” IPsec (IPsec-v3)

The “New” IPsec (IPsec-v3) is primarily defined in three RFC documents as the proposed standard.

• RFC 4301, Security Architecture for the Internet Protocol (S, December 2005)
• RFC 4302, IP Authentication Header (S, December 2005)
• RFC 4303, IP Encapsulating Security Payload (ESP) (S, December 2005)

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.

Non-repudiation

• Non-repudiation is the “protection against an individual falsely denying having performed a particular action.” (NIST SP 800-53 R4) In a context of communication, the individual refers to either the sender or the recipient.
• Non-repudiation also refers to the “assurance that the sender of information is provided with proof of delivery and the recipient is provided with proof of the sender’s identity, so neither can later deny having processed the information.” (NIST SP 800-60 Vol. 1 R1)

According to FISMA, integrity comprises data integrity, the authenticity of data origin, and non-repudiation. It’s generally accepted that digital signature ensures non-repudiation, a security property of integrity.

Authenticity 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.

RFC 1826

The Authentication Header is a mechanism for providing strong integrity and authentication for IP datagrams. It might also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed. For example, use of an asymmetric digital signature algorithm, such as RSA, could provide non-repudiation.  (RFC 1826)

Cisco

Cisco developed its position based on RFC 1826 in this article:

The AH is a mechanism for providing strong integrity and authentication for IP datagrams. It can also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed. (Cisco)

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.”

RFC 2402

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just “authentication“), and to provide protection against replays.  (RFC 2402)

RFC 4302

“Authentication” in RFC 2402 is further revised to “Integrity” in RFC 4302:

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just “integrity“) and to provide protection against replays. (RFC 4302)

Key Exchange and Non-repudiation

Internet Key Exchange (IKE) is a crucial architectural component of IPsec. It is used for performing mutual authentication and establishing and maintaining security associations (SAs). There are two versions of IKE, Version 1 and Version 2. The new IKEv2 does not interoperate with IKEv1.

ISAKMP and IKEv1

ISAKMP can be treated as the basis of IKEv1, as Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for authentication and key exchange, while IKEv1 defines or standardizes the details.

IKEv1 describes “a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP.” (RFC 2409)

In RFC 2408, which defines ISAKMP, it states the Signature Payload of ISAKMP may be of use for non-repudiation services as follows:

The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non-repudiation services. (RFC 2408)

IKE V2

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)

ICV, MAC, and Digital Signature

IPsec protocols, mainly AH and ESP, employ integrity and confidentiality algorithms to deliver security services. The AH and ESP protocols ensure integrity but with different degrees of security.

Message Authentication Code (MAC)

Both AH and ESP rely on the field, Integrity Check Value (ICV), to verify data integrity and the authenticity of data origin. However, IPsec natively supports the computation of ICV through a hash-based or block-cipher message authentication code (MAC) instead of a digital signature. For example, RFC 4308 proposes HMAC-SHA1-96 and AES-XCBC-MAC-96.

Digital Signature

Technically, the ICV may be “digitally signed.” This implementation needs to compute the hash and encrypt it using the sender’s private key. It consumes too much computing resources and may impact performance adversely. Even though AH and ESP utilize the cryptographic suites negotiated through ISAKMP, digitally signed ICV can be rare and become proprietary implementation.

Digital Certificates

IPsec may use digital certificates for authentication, but it’s rare to see implementations use them for digital signature.

• RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) (S, January 2007)
• RFC 5998, An Extension for EAP-Only Authentication in IKEv2 (S, September 2010)

IPsec for Multicasting

Encapsulating Security Payload (ESP) [ESP] and Authentication Header (AH) [AH] headers can be used to protect both unicast traffic and group (e.g., IPv4 and IPv6 multicast) traffic. When unicast traffic is protected between a pair of entities, HMAC transforms (such as [HMAC-SHA]) are sufficient to prove data origin authentication. An HMAC is sufficient protection in that scenario because only the two entities involved in the communication have access to the key, and proof-of-possession of the key in the HMAC construct authenticates the sender. However, when ESP and AH authenticate group traffic, this property no longer holds because all group members share the single HMAC key. In the group case, the identity of the sender is not uniquely established, since any of the key holders has the ability to form the HMAC transform. Although the HMAC transform establishes a group-level security property, data origin authentication is not achieved.

Source: RFC 4359

The only applicable area of digital signature in IPsec is enforcing the authenticity of data origin for multicasting traffic. Multicasting occurred in a group of hosts that shared a secret key applied in the computation of ICV, i.g. HMAC.

In this situation, a digital signature can be applied and non-repudiation seems to be fulfilled. The following proposed standard by Cisco has details:

• RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, January 2006)

Non-repudiation at the “Application Level”

However, RFC 4359 officially doesn’t claim the achievement of non-repudiation. It reads as follows:

Non-repudiation is not claimed as a property of this transform. At times, the property of non-repudiation may be applied to digital signatures on application-level objects (e.g., electronic mail). However, this document describes a means of authenticating network-level objects (i.e., IP packets), which are ephemeral and not directly correlated to any application. Non-repudiation is not applicable to network-level objects (i.e., IP packets).

Source: RFC 4359

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 Authenticity and Non-repudiation, and Key Exchange and Non-repudiation