Network Working Group K. Fan Internet-Draft R. Su Intended status: Informational Y. Wang Expires: 14 February 2027 J. Cheng Xidian University 13 August 2026 PQ-SecTunnel Protocol Specification draft-pq-sectunnel-00 Abstract This document specifies the PQ-SecTunnel protocol, a UDP-based quantum-resistant IP tunnel derived from the WireGuard architecture. Session keys are established by a three-message Noise_IKpsk1kem handshake that replaces Diffie-Hellman with dual Key Encapsulation Mechanism (KEM) operations (static and ephemeral). Authentication is implicit: peers prove possession of long-term KEM private keys through interlocking encapsulations rather than signing the transcript. The protocol is organized as a multi-suite framework. Implementations MAY select ML-KEM-512 or ML-KEM-768 independently for the static and ephemeral KEM roles. This document RECOMMENDS the profile static=ML-KEM-512, ephemeral=ML-KEM-768, AEAD=SM4-GCM, Hash=SM3 (denoted mlkem512-mlkem768-sm4gcm-sm3). Other ML-KEM combinations with the same AEAD/Hash, and additional KEM families such as Aigis-enc (integration ongoing), are optional profiles. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 February 2027. Fan, et al. Expires 14 February 2027 [Page 1] Internet-Draft PQ-SecTunnel August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Cryptographic Suites . . . . . . . . . . . . . . . . . . 6 4. Key Agreement Protocol . . . . . . . . . . . . . . . . . . . 6 4.1. Handshake Overview . . . . . . . . . . . . . . . . . . . 6 4.2. Pre-Configuration . . . . . . . . . . . . . . . . . . . . 7 4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Handshake Initiation . . . . . . . . . . . . . . . . 7 4.3.2. Handshake Response . . . . . . . . . . . . . . . . . 8 4.3.3. Key Confirmation . . . . . . . . . . . . . . . . . . 9 4.3.4. Cookie Reply . . . . . . . . . . . . . . . . . . . . 9 4.4. Handshake State Machine . . . . . . . . . . . . . . . . . 10 4.4.1. Handshake Initiation (Initiator) . . . . . . . . . . 10 4.4.2. Handshake Response (Responder) . . . . . . . . . . . 11 4.4.3. Key Confirmation (Initiator) . . . . . . . . . . . . 11 4.4.4. Key Confirmation (Responder) . . . . . . . . . . . . 12 4.5. Key Derivation and Chaining . . . . . . . . . . . . . . . 12 4.6. MAC1/MAC2 and Cookie Messages . . . . . . . . . . . . . . 13 4.7. Implicit Authentication Model . . . . . . . . . . . . . . 14 5. Data Transport Protocol . . . . . . . . . . . . . . . . . . . 14 5.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Packet Encryption . . . . . . . . . . . . . . . . . . . . 14 5.3. Packet Decryption . . . . . . . . . . . . . . . . . . . . 15 6. Application-Layer Fragmentation . . . . . . . . . . . . . . . 15 7. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . 16 7.1. Asymmetric Algorithms . . . . . . . . . . . . . . . . . . 16 7.2. Symmetric Algorithms . . . . . . . . . . . . . . . . . . 16 7.3. Hash, KDF, and DoS MAC . . . . . . . . . . . . . . . . . 17 Fan, et al. Expires 14 February 2027 [Page 2] Internet-Draft PQ-SecTunnel August 2026 8. Certificate Management . . . . . . . . . . . . . . . . . . . 17 8.1. Certificate Format . . . . . . . . . . . . . . . . . . . 17 8.2. Public Key Information . . . . . . . . . . . . . . . . . 17 8.3. OID Mapping . . . . . . . . . . . . . . . . . . . . . . . 17 8.4. Certificate Validation . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9.1. Quantum Resistance . . . . . . . . . . . . . . . . . . . 17 9.2. Authentication and Key Pre-Distribution . . . . . . . . . 18 9.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 18 9.4. Replay and MitM Protection . . . . . . . . . . . . . . . 18 9.5. Denial-of-Service Considerations . . . . . . . . . . . . 18 9.6. Static KEM Hash(ct) Mixing . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10.1. Service Name and Transport Protocol Port Number Registry . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. PQ-SecTunnel Message Types Registry . . . . . . . . . . 19 10.3. OID Registrations . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. OID Definitions . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Traditional IP-layer security protocols such as IPsec commonly rely on classical public-key primitives (RSA, ECDH) for key exchange and authentication. Advances in large-scale quantum computing threaten those constructions. PQ-SecTunnel provides a quantum-resistant tunnel for IP traffic over UDP. The protocol has two phases: 1. Key Agreement Protocol: A 3-message handshake that performs mutual implicit authentication and establishes shared symmetric session keys. This handshake is based on post-quantum Key Encapsulation Mechanisms (KEMs). 2. Data Transport Protocol: The use of the derived session keys with an AEAD cipher to encrypt, authenticate, and transport the encapsulated IP packets over UDP. PQ-SecTunnel is specified as a suite framework. Algorithm identifiers are fixed at build or deployment time for a given peer pair; there is no in-band suite negotiation in the current design. Peers MUST use identical suite parameters. Fan, et al. Expires 14 February 2027 [Page 3] Internet-Draft PQ-SecTunnel August 2026 This revision aligns the handshake description with the project handshake specification (Noise_IKpsk1kem chaining), documents little- endian field encoding as implemented, defines Cookie reply messages and application-layer fragmentation for oversized handshake datagrams, and adopts SM4-GCM / SM3 for the recommended Chinese national cryptography profile. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Additional terms used in this document: * AEAD: Authenticated Encryption with Associated Data. * Initiator: The party that sends Handshake Initiation. * Responder: The peer that receives Handshake Initiation and sends Handshake Response. * Static KEM: Long-term KEM used for ct_1 and ct_3. * Ephemeral KEM: Per-handshake KEM used for E_i key generation and ct_2. * KDF: HKDF-style extract-and-expand keyed by the chaining key (Section 4.5). * shk: Shared secret produced by a KEM encapsulation/decapsulation. * sid_i / sid_r: 32-bit sender indices allocated from the peer index table. * TK_i / TK_r: Unidirectional transport keys (Initiator-to-Responder / Responder-to-Initiator). * MAC: Keyed BLAKE2s [RFC7693] used for mac1/mac2 DoS cookies (independent of the suite Hash). Fan, et al. Expires 14 February 2027 [Page 4] Internet-Draft PQ-SecTunnel August 2026 Unless otherwise stated, multi-byte integer fields in PQ-SecTunnel messages are encoded in little-endian byte order (WireGuard- compatible). This includes the message type word, sender/receiver indices, data-packet counters, and fragment header integer fields. Cryptographic octet strings (public keys, ciphertexts, MACs, AEAD outputs) are opaque sequences in the order produced by the primitive. 3. Protocol Overview 3.1. Architecture Logical components: * Certificate / key provisioning: loads long-term KEM public keys (raw configuration or X.509). * Key agreement: three-message Noise_IKpsk1kem handshake. * Data plane: AEAD encapsulation of inner IP packets over UDP. * Virtual network interface: injects/captures plaintext IP for the host stack. * Optional application-layer fragmentation: splits oversized handshake UDP payloads. 3.2. Packet Flow 1. An application emits an inner IP packet. 2. Routing directs the packet to the PQ-SecTunnel virtual interface. 3. The data plane looks up the peer session, assigns a counter, and AEAD-encrypts the inner packet. 4. The outer packet is UDP to the peer endpoint. 5. On receipt, the peer decrypts, anti-replay checks the counter, and injects the inner IP packet. 3.3. Threat Model The PQ-SecTunnel protocol is designed to resist the following: * Confidentiality and integrity of tunnelled IP traffic against classical and quantum eavesdroppers (within the limits of the chosen suite). Fan, et al. Expires 14 February 2027 [Page 5] Internet-Draft PQ-SecTunnel August 2026 * MitM resistance given authentic pre-distributed long-term KEM public keys. * Forward secrecy for past sessions after ephemeral private key destruction. * DoS mitigation via mac1/mac2 and Cookie replies before expensive KEM operations. The protocol does not provide transport reliability. Handshake messages that exceed the path MTU MUST use application-layer fragmentation (Section 6) or otherwise ensure delivery; relying solely on IP fragmentation is NOT RECOMMENDED. 3.4. Cryptographic Suites A suite is the 4-tuple (Static_KEM, Ephemeral_KEM, AEAD, Hash). Static_KEM and Ephemeral_KEM MAY differ. For ML-KEM, any combination of ML-KEM-512 and ML-KEM-768 in the two roles is permitted. RECOMMENDED profile for this document: mlkem512-mlkem768-sm4gcm-sm3 (Static=ML-KEM-512, Ephemeral=ML-KEM-768, AEAD=SM4-GCM, Hash=SM3). Other ML-KEM combinations with SM4-GCM/SM3 (for example mlkem512-mlkem512-sm4gcm-sm3 or mlkem768-mlkem768-sm4gcm-sm3) are OPTIONAL (MAY). Aigis-enc parameter sets are envisioned as additional optional KEM choices in the same handshake framework. Normative sizes, OIDs, and interoperability requirements for Aigis-enc are left for a future revision; current implementations MAY experiment but MUST NOT claim conformance to an Aigis profile until specified. 4. Key Agreement Protocol 4.1. Handshake Overview Messages: Handshake Initiation (Initiator), Handshake Response (Responder), Key Confirmation (Initiator). Optional Cookie Reply (Responder) may be sent under load. After Key Confirmation verification, both sides derive TK_i and TK_r. mac1/mac2 are computed over the wire encoding of each handshake message and are verified on receipt before KEM/AEAD processing. They do not enter the C/H chaining state. Fan, et al. Expires 14 February 2027 [Page 6] Internet-Draft PQ-SecTunnel August 2026 4.2. Pre-Configuration Before the handshake can be initiated, several prerequisites MUST be met: 1.Long-term Static KEM key pairs: Initiator (S_i^pub, S_i^priv), Responder (S_r^pub, S_r^(priv).) 2.Each peer MUST possess an authentic copy of the peer's long-term public key before handshake (out-of-band; certificates MAY be used, Section 8). 3. Both peers MUST use the same suite parameters. 4.3. Message Formats All handshake and data messages begin with a 32-bit little-endian type field whose low 8 bits carry the message type and whose upper 24 bits MUST be zero (WireGuard-compatible packing). Message types (see also Section 10): +======+======================+ +======+======================+ | Type | Name | +------+----------------------+ | 1 | Handshake Initiation | +------+----------------------+ | 2 | Handshake Response | +------+----------------------+ | 3 | Key Confirmation | +------+----------------------+ | 4 | Cookie Reply | +------+----------------------+ | 5 | Transport Data | +------+----------------------+ Table 1 4.3.1. Handshake Initiation This message is sent by the Initiator to begin the handshake. message HandshakeInitiation { u8 type; u8 reserved_zero[3]; Fan, et al. Expires 14 February 2027 [Page 7] Internet-Draft PQ-SecTunnel August 2026 u32 sid_i; u8 E_i_pub[Ne]; u8 ct_1[Ns_ct]; u8 static[HashLen+Tag]; u8 time[12+Tag]; u8 mac1[16]; u8 mac2[16]; } Ne / Ns_ct depend on Ephemeral_KEM / Static_KEM. For the recommended profile: Ne = 1184 (ML-KEM-768 public key), Ns_ct = 768 (ML-KEM-512 ciphertext). HashLen = 32 (SM3). Tag = 16 (SM4-GCM). 4.3.2. Handshake Response This message is sent by the Responder after validating the Handshake Initiation message. message HandshakeResponse { u8 type; u8 reserved_zero[3]; u32 sid_r; u32 sid_i; u8 ct_2[Ne_ct]; u8 ct_3[Ns_ct]; u8 empty[Tag]; u8 mac1[16]; u8 mac2[16]; } For the recommended profile: Ne_ct = 1088 (ML-KEM-768 ciphertext). Fan, et al. Expires 14 February 2027 [Page 8] Internet-Draft PQ-SecTunnel August 2026 4.3.3. Key Confirmation This message is sent by the Initiator after validating the Handshake Response message. message KeyConfirmation { u8 type; u8 reserved_zero[3]; u32 sid_i; u32 sid_r; u8 conf[Tag]; u8 mac1[16]; u8 mac2[16]; } 4.3.4. Cookie Reply message CookieReply { u8 type; u8 reserved_zero[3]; u32 receiver_index; u8 nonce[24]; u8 encrypted_cookie[16+16]; } Cookie Reply encrypts a 16-octet cookie under XChaCha20-Poly1305. The AEAD key is derived as BLAKE2s("cookie--" || S_r^pub) with output length as required by XChaCha20-Poly1305 (32 octets). Associated data is the mac1 field of the message that triggered the reply. This construction is independent of the suite AEAD (SM4-GCM) and matches the WireGuard cookie design retained by PQ-SecTunnel. Fan, et al. Expires 14 February 2027 [Page 9] Internet-Draft PQ-SecTunnel August 2026 4.4. Handshake State Machine Notation follows the project handshake specification. Hash is the suite hash (SM3). KDF is HKDF-HMAC-Hash (Section 4.5). AEAD.Enc(key, nonce, plaintext, AAD) uses nonce = 12 zero octets for all handshake AEAD operations; AAD is the current transcript hash H before encryption; after encryption, H is updated as H := Hash(H || ciphertext_with_tag). KEM.Enc(pk) denotes standard encapsulation producing (ct, shk). KEM.Dec(sk, ct) produces shk. For static-KEM ciphertexts ct_1 and ct_3, after obtaining shk the implementation MUST replace the value mixed into the chain with Hash(ct) (same length as the KEM shared- secret buffer used by mix_kem_ss). For ephemeral ct_2, the raw shk_2 MUST be mixed (not Hash(ct_2)). 4.4.1. Handshake Initiation (Initiator) 1. sid_i <- allocate sender_index 2. C_0 = Hash(label_1) 3. H_0 = Hash(C_0 || label_2) 4. H_1 = Hash(H_0 || S_r^pub); C_1 = KDF(C_0, S_r^(pub)) 5. (E_i^priv, E_i^pub) = EphemeralKEM.Gen() 6. H_2 = Hash(H_1 || E_i^pub); C_2 = KDF(C_1, E_i^(pub)) 7. (ct_1, shk_1) = StaticKEM.Enc(S_r^(pub)) 8. H_3 = Hash(H_2 || ct_1) 9. ss = Hash(ct_1); (C_3, K_1) = KDF(C_2, ss) 10. static = AEAD.Enc(K_1, 0, Hash(S_i^pub), H_3) 11. H_4 = Hash(H_3 || static) 12. C_4 = KDF(C_3, S_i^(pub)) (C_5, Htmp, K_2) = KDF(C_4, H_4 || PSK); H_5 = Hash(H_4 || Htmp) 13. time = AEAD.Enc(K_2, 0, t_now, H_5) 14. H_6 = Hash(H_5 || time) Fan, et al. Expires 14 February 2027 [Page 10] Internet-Draft PQ-SecTunnel August 2026 15. mac1 / mac2 as in Section 4.6 16. Send HandshakeInitiation label_1 is the protocol name string for the suite (RECOMMENDED example: "Noise_IKpsk1kem_SM4GCM_SM3_EphemMLKEM768"). label_2 is the identifier string (example: "PQWireGuard v2 zx2c4 Jason@zx2c4.com"). Both include the terminating NUL octet when hashed, matching the reference implementation. 4.4.2. Handshake Response (Responder) 1. Verify mac1/mac2; on failure silently drop 2. Recompute C_0..H_6 through decryption of static and time as Initiation inverse 3. sid_r <- allocate sender_index 4. (ct_2, shk_2) = EphemeralKEM.Enc(E_i^(pub)) 5. H_7 = Hash(H_6 || ct_2); C_6 = KDF(C_5, ct_2) 6. C_7 = KDF(C_6, shk_2) 7. (ct_3, shk_3) = StaticKEM.Enc(S_i^(pub)) 8. H_8 = Hash(H_7 || ct_3) 9. ss = Hash(ct_3); C_8 = KDF(C_7, ss) 10. (C_9, Htmp, K_3) = KDF(C_8, H_8 || PSK); H_9 = Hash(H_8 || Htmp) 11. empty = AEAD.Enc(K_3, 0, empty, H_9) 12. H_10 = Hash(H_9 || empty) 13. (C_10, K_4) = KDF(C_9, empty) 14. mac1/mac2; send HandshakeResponse 4.4.3. Key Confirmation (Initiator) 1. Verify mac1/mac2; on failure abort 2. shk_2 = EphemeralKEM.Dec(E_i^priv, ct_2); destroy E_i^priv 3. H_7 = Hash(H_6 || ct_2); C_6 = KDF(C_5, ct_2) Fan, et al. Expires 14 February 2027 [Page 11] Internet-Draft PQ-SecTunnel August 2026 4. C_7 = KDF(C_6, shk_2) 5. shk_3 = StaticKEM.Dec(S_i^priv, ct_3) 6. H_8 = Hash(H_7 || ct_3) 7. ss = Hash(ct_3); C_8 = KDF(C_7, ss) 8. (C_9, Htmp, K_3) = KDF(C_8, H_8 || PSK); H_9 = Hash(H_8 || Htmp) 9. AEAD.Dec(K_3, 0, empty, H_9); require empty plaintext 10. H_10 = Hash(H_9 || empty) 11. (C_10, K_4) = KDF(C_9, empty) 12. conf = AEAD.Enc(K_4, 0, empty, H_10) 13. mac1/mac2; send KeyConfirmation 14. (TK_i, TK_r) = KDF(C_10, empty_input) 4.4.4. Key Confirmation (Responder) 1. Verify mac1/mac2; on failure abort 2. AEAD.Dec(K_4, 0, conf, H_10); require empty plaintext 3. (TK_i, TK_r) = KDF(C_10, empty_input) 4.5. Key Derivation and Chaining KDF is Hugo Krawczyk's HKDF using HMAC with the suite Hash (HMAC-SM3 for the recommended profile) [RFC5869]. Let CK be the chaining key. KDF(CK, input) producing n outputs means: PRK = HMAC(CK, input); then Expand with counters 0x01, 0x02, ... as in Noise/WireGuard. When this document writes (C', K) = KDF(C, ss), the first output updates the chaining key and the second is an AEAD key of AEAD-key length. mix_psk(C, H, PSK) computes KDF outputs (C', Htmp, K) from input (H || PSK), then sets H' = Hash(H || Htmp). The AEAD key K is used for the subsequent encrypted field (time or empty). Table 1: Informative chaining summary (Initiation through transport keys) Fan, et al. Expires 14 February 2027 [Page 12] Internet-Draft PQ-SecTunnel August 2026 +======+==============================+=============================+ +======+==============================+=============================+ | Step | Hash update | Chain-key update | +------+------------------------------+-----------------------------+ | 0 | H_0 = Hash(C_0 || label_2) | C_0 = Hash(label_1) | +------+------------------------------+-----------------------------+ | 1 | H_1 = Hash(H_0 || | C_1 = KDF(C_0, S_r^(pub)) | | | S_r^(pub)) | | +------+------------------------------+-----------------------------+ | 2 | H_2 = Hash(H_1 || | C_2 = KDF(C_1, E_i^(pub)) | | | E_i^(pub)) | | +------+------------------------------+-----------------------------+ | 3 | H_3 = Hash(H_2 || ct_1) | (C_3,K_1)=KDF(C_2, | | | | Hash(ct_1)) | +------+------------------------------+-----------------------------+ | 4 | H_4 = Hash(H_3 || static) | C_4 = KDF(C_3, S_i^pub); | | | | then mix_psk -> C_5,H_5,K_2 | +------+------------------------------+-----------------------------+ | 5 | H_6 = Hash(H_5 || time) | (after time AEAD) | +------+------------------------------+-----------------------------+ | 6 | H_7 = Hash(H_6 || ct_2) | C_6 = KDF(C_5, ct_2); C_7 = | | | | KDF(C_6, shk_2) | +------+------------------------------+-----------------------------+ | 7 | H_8 = Hash(H_7 || ct_3) | C_8 = KDF(C_7, Hash(ct_3)); | | | | mix_psk -> C_9,H_9,K_3 | +------+------------------------------+-----------------------------+ | 8 | H_10 = Hash(H_9 || empty) | (C_10,K_4)=KDF(C_9, empty) | +------+------------------------------+-----------------------------+ | 9 | (transport) | (TK_i,TK_r)=KDF(C_10, "") | +------+------------------------------+-----------------------------+ Table 2 4.6. MAC1/MAC2 and Cookie Messages Let MsgPrefix be the message bytes excluding mac1 and mac2. Keys: mac1_key = BLAKE2s("mac1----" || S_r^(pub)) mac1 = BLAKE2s(key=mac1_key, data=MsgPrefix)[0:16] if Cookie available: mac2 = BLAKE2s(key=Cookie, data=MsgPrefix||mac1)[0:16] else: mac2 = 16 zero octets Fan, et al. Expires 14 February 2027 [Page 13] Internet-Draft PQ-SecTunnel August 2026 Under load, a Responder MAY ignore KEM processing and send Cookie Reply (Section 4.3.4). The Initiator decrypts the cookie and includes mac2 on retry. Receivers MUST verify mac1 (and mac2 when required) before expensive KEM work. 4.7. Implicit Authentication Model The Initiator proves knowledge bound to S_i by producing static = AEAD(Hash(S_i^pub)) under a key derived from ct_1 encapsulated to S_r. The Responder proves possession of S_r^priv by decapsulating ct_1 and later producing ct_3 to S_i^pub. Successful completion binds both long-term identities into TK_i/TK_r without transcript signatures. 5. Data Transport Protocol 5.1. Packet Format message TransportData { u8 type; u8 reserved_zero[3]; u32 key_idx; u64 counter; u8 ciphertext[]; } On the wire the UDP payload is exactly this structure. The outer UDP/IP headers are ordinary Internet headers toward the peer endpoint. 5.2. Packet Encryption When the virtual network interface captures a plaintext IP packet (Inner IP Packet) for transmission: 1. Select the sending key (TK_i on Initiator, TK_r on Responder) and remote key_idx. 2. Let counter be the next 64-bit sending counter (MUST NOT reuse under the same key). Fan, et al. Expires 14 February 2027 [Page 14] Internet-Draft PQ-SecTunnel August 2026 3. For SM4-GCM: form a 12-octet IV as four zero octets followed by the eight little-endian octets of counter (IV bytes 4..11). 4. Encrypt with AEAD key = transport key, nonce/IV as above, plaintext = inner IP packet, AAD length = 0 (empty AAD). 5. Emit TransportData with ciphertext||tag. 5.3. Packet Decryption 1. Parse type/key_idx/counter; look up receiving key. 2. Anti-replay: maintain a sliding window; silently drop duplicates or out-of-window counters. 3. AEAD-decrypt with empty AAD; on failure silently drop. 4. Inject recovered inner IP packet into the local stack. 6. Application-Layer Fragmentation When a handshake message (after mac1/mac2 are attached) exceeds the maximum fragment payload size, implementations MUST fragment at the application layer rather than relying on IP fragmentation. Fragment header (8 octets, little-endian where noted): struct PqcFragHdr { u16 magic; u16 msg_id; u8 frag_index; u8 frag_total; u16 frag_len; }; The magic field MUST be 0x5051 (ASCII "PQ"), encoded little-endian. msg_id is a random reassembly identifier. frag_index is zero-based; frag_total is the number of fragments; frag_len is the number of payload octets in this fragment. Fan, et al. Expires 14 February 2027 [Page 15] Internet-Draft PQ-SecTunnel August 2026 Maximum fragment payload size is 1400 octets. The receiver reassembles fragments sharing (endpoint, msg_id) and passes the completed handshake buffer to the normal handshake parser (without the fragment header). Control encoding: frag_total = 0xFF and frag_index = 0xFF denotes a fragment ACK used by the sender for retransmission. Implementations SHOULD retransmit unacknowledged fragments with bounded retries. Fragmentation MUST be applied after mac1/mac2 computation so that MACs cover the original handshake message. Receivers MUST accept fragmented handshake messages for suites whose initiation or response exceeds typical path MTU (including the recommended mlkem512-mlkem768-sm4gcm-sm3 profile). 7. Cryptographic Algorithms 7.1. Asymmetric Algorithms Implementations of this specification's ML-KEM profiles MUST implement ML-KEM as specified in [FIPS203]. Support for both ML- KEM-512 and ML-KEM-768 as Static_KEM and as Ephemeral_KEM is RECOMMENDED so that operators MAY choose any pairing. The profile mlkem512-mlkem768-sm4gcm-sm3 is RECOMMENDED. Digital signatures for out-of-band X.509 certificates: implementations that use the certificate path MUST support a quantum- resistant signature algorithm such as ML-DSA [FIPS204]. Tunnel handshake authentication itself does not use signatures. Aigis-enc MAY appear in experimental builds as Static_KEM and/or Ephemeral_KEM using the same message layout and chaining rules; interoperable Aigis profiles are not yet normatively defined here. 7.2. Symmetric Algorithms For the recommended profile, AEAD MUST be SM4-GCM with 128-bit keys, 128-bit authentication tags, and 96-bit nonces, following the GCM construction as used with SM4 in national standards practice (see [GBT32907] for SM4; GCM as referenced by related TLCP guidance [GB38636]). Handshake AEAD nonce is 12 zero octets. Transport AEAD nonce/IV construction is defined in Section 5.2. Handshake AAD is the current transcript hash; transport AAD is empty. Fan, et al. Expires 14 February 2027 [Page 16] Internet-Draft PQ-SecTunnel August 2026 7.3. Hash, KDF, and DoS MAC Suite Hash for the recommended profile MUST be SM3 [GBT32905]. KDF is HKDF with HMAC-SM3 [RFC5869]. mac1/mac2 and cookie key derivation use keyed BLAKE2s [RFC7693] as in Section 4.6, even when the suite Hash is SM3. This separation follows the WireGuard DoS design retained by PQ-SecTunnel and is independent of the C/H hash chain. 8. Certificate Management 8.1. Certificate Format When certificates are used to distribute long-term KEM public keys, they MUST be X.509 v3 certificates. 8.2. Public Key Information The SubjectPublicKeyInfo field MUST carry the long-term PQC KEM public key. The AlgorithmIdentifier OID MUST identify the KEM algorithm (Appendix A). 8.3. OID Mapping Implementations MUST map SubjectPublicKeyInfo OIDs to the corresponding KEM implementation. Informative OID values under the Chinese national arc appear in Appendix A. 8.4. Certificate Validation Certificates MUST be distributed and validated out-of-band before handshake when the certificate path is used. Implementations MUST validate the signature chain against a configured trust anchor, check validity periods, and ensure the peer identity matches local policy. Raw public-key configuration without certificates remains permitted. 9. Security Considerations 9.1. Quantum Resistance Asymmetric handshake secrets are established with ML-KEM [FIPS203]. Symmetric security for the recommended profile uses SM4-128 and SM3-256. Operators needing higher classical margins MAY select ML- KEM-768 for both roles. Fan, et al. Expires 14 February 2027 [Page 17] Internet-Draft PQ-SecTunnel August 2026 9.2. Authentication and Key Pre-Distribution Implicit authentication requires authentic pre-distribution of long- term KEM public keys. Compromise or substitution of the preloaded peer public key enables MitM. 9.3. Forward Secrecy Session keys depend on shk_2 bound to the ephemeral private key E_i^priv, which MUST be destroyed after processing Handshake Response. Compromise of both long-term static private keys after the fact does not recover past TK_i/TK_r if E_i^priv was erased and the ephemeral KEM remains unbroken. 9.4. Replay and MitM Protection Handshake: the encrypted timestamp and transcript hash chain bind messages. Transport: the 64-bit counter with sliding-window anti- replay MUST be enforced. 9.5. Denial-of-Service Considerations mac1 provides a cheap filter keyed by the Responder public key. Under load, Cookie Reply enables mac2 checks before KEM decapsulation. 9.6. Static KEM Hash(ct) Mixing Mixing Hash(ct_1)/Hash(ct_3) instead of the raw static KEM shared secret is the current protocol rule and must be implemented for interoperability. It differs from the raw-shk rule used for ct_2. Changing this rule would be a breaking revision. 10. IANA Considerations 10.1. Service Name and Transport Protocol Port Number Registry IANA is requested to register PQ-SecTunnel in the "Service Name and Transport Protocol Port Number Registry". * Service Name: pq-sectunnel * Transport Protocol: UDP * Port Number: TBD Fan, et al. Expires 14 February 2027 [Page 18] Internet-Draft PQ-SecTunnel August 2026 10.2. PQ-SecTunnel Message Types Registry IANA is requested to create a registry "PQ-SecTunnel Message Types" with Specification Required registration policy. Initial values: +=======+======================+===============+ +=======+======================+===============+ | Value | Description | Reference | +-------+----------------------+---------------+ | 0 | Invalid / reserved | this document | +-------+----------------------+---------------+ | 1 | Handshake Initiation | this document | +-------+----------------------+---------------+ | 2 | Handshake Response | this document | +-------+----------------------+---------------+ | 3 | Key Confirmation | this document | +-------+----------------------+---------------+ | 4 | Cookie Reply | this document | +-------+----------------------+---------------+ | 5 | Transport Data | this document | +-------+----------------------+---------------+ Table 3 10.3. OID Registrations OIDs under 1.2.156 used in Appendix A are outside IANA; no IANA action is requested. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . Fan, et al. Expires 14 February 2027 [Page 19] Internet-Draft PQ-SecTunnel August 2026 [RFC7693] Saarinen, M.-J., Ed. and J.-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, November 2015, . [FIPS203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024. [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", FIPS 204, August 2024. [GBT32905] Standardization Administration of China (SAC), "Information security technology - SM3 cryptographic hash algorithm", GB/T 32905, 2016. [GBT32907] Standardization Administration of China (SAC), "Information security technology - SM4 block cipher algorithm", GB/T 32907, 2016. [GB38636] Standardization Administration of China (SAC), "Information security technology - Transport Layer Cryptography Protocol (TLCP)", GB/T 38636, 2020. 11.2. Informative References [WIREGUARD] Donenfeld, J.A., "WireGuard: Next Generation Kernel Network Tunnel", NDSS 2017, 2017. Appendix A. OID Definitions Informative Object Identifiers under the Chinese national registration arc, as used by related certificate tooling. Only OIDs required by a deployment need be recognized. Table 2: PQC and GM/T OID Definitions +=======================+============================+==============+ +=======================+============================+==============+ | Object Identifier | Object Identifier | 备注 | | (OID) | Definition | | +-----------------------+----------------------------+--------------+ | General Object | | | | Identifiers | | | +-----------------------+----------------------------+--------------+ | 1.2 | International | | Fan, et al. Expires 14 February 2027 [Page 20] Internet-Draft PQ-SecTunnel August 2026 | | Organization for | | | | Standardization (ISO) | | | | Member Identifier | | +-----------------------+----------------------------+--------------+ | 1.2.156 | China | | +-----------------------+----------------------------+--------------+ | 1.2.156.197 | State Cryptography | | | | Administration (SCA) | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197 | Cryptography Industry | | | | Standardization | | | | Technical Committee | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1 | Cryptographic | | | | Algorithms | | +-----------------------+----------------------------+--------------+ | Block Cipher | | | | Algorithm Object | | | | Identifiers | | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.100 | Block Cipher Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.102 | SM1 Block Cipher | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.103 | SSF33 Block Cipher | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.104 | SM4 Block Cipher | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | Stream Cipher | | | | Algorithm Object | | | | Identifiers | | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.200 | Stream Cipher | | | | Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.201 | Zuchongzhi Stream | | | | Cipher Algorithm | | +-----------------------+----------------------------+--------------+ | Public Key | | | | Cryptographic | | | | Algorithm Object | | | | Identifiers | | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.300 | Public Key | | | | Cryptographic | | Fan, et al. Expires 14 February 2027 [Page 21] Internet-Draft PQ-SecTunnel August 2026 | | Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.301 | SM2 Elliptic Curve | | | | Public Key | | | | Cryptographic Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.301.1 | SM2-1 Digital Signature | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.301.2 | SM2-2 Key Exchange | | | | Protocol | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.301.3 | SM2-3 Public Key | | | | Encryption Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.302 | SM9 Identity-Based | | | | Cryptographic Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.302.1 | SM9-1 Digital Signature | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.302.2 | SM9-2 Key Exchange | | | | Protocol | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.302.3 | SM9-3 Key Encapsulation | | | | Mechanism and Public | | | | Key Encryption | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.303 | Post-Quantum Key | Post-Quantum | | | Encapsulation | | | | Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.303.1 | ML-KEM-512 Key | Post-Quantum | | | Encapsulation Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.303.2 | ML-KEM-768 Key | Post-Quantum | | | Encapsulation Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.303.3 | ML-KEM-1024 Key | Post-Quantum | | | Encapsulation Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.304 | Post-Quantum Digital | Post-Quantum | | | Signature Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.304.1 | ML-DSA-44 Digital | Post-Quantum | | | Signature Algorithm | | +-----------------------+----------------------------+--------------+ Fan, et al. Expires 14 February 2027 [Page 22] Internet-Draft PQ-SecTunnel August 2026 | 1.2.156.10197.1.304.2 | ML-DSA-65 Digital | Post-Quantum | | | Signature Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.304.3 | ML-DSA-87 Digital | Post-Quantum | | | Signature Algorithm | | +-----------------------+----------------------------+--------------+ | Hash Algorithm Object | | | | Identifiers | | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.400 | Hash Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.401 | SM3 Cryptographic Hash | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.401.1 | SM3 Cryptographic Hash | | | | Algorithm (No Key Used) | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.401.2 | SM3 Cryptographic Hash | | | | Algorithm (Key Used) | | +-----------------------+----------------------------+--------------+ | Combined Operation | | | | Algorithm Object | | | | Identifiers | | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.500 | Combined Operation | | | | Mechanisms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.501 | Signature Based on SM2 | | | | Algorithm and SM3 | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.504 | Signature Based on RSA | | | | Algorithm and SM3 | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.505 | Signature Based on ML- | Post-Quantum | | | DSA Algorithm and SM3 | | | | Algorithm | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.505.1 | ML-DSA-44-with-SM3 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.505.2 | ML-DSA-65-with-SM3 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.505.3 | ML-DSA-87-with-SM3 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.506 | Signature Based on SM2, | Post-Quantum | | | ML-DSA Algorithms and | | | | SM3 Algorithm | | Fan, et al. Expires 14 February 2027 [Page 23] Internet-Draft PQ-SecTunnel August 2026 +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.506.1 | ML-DSA-44-SM2-with-SM3 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.506.2 | ML-DSA-65-SM2-with-SM3 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.506.3 | ML-DSA-87-SM2-with-SM3 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.507 | Based on SM2 and ML-KEM | Post-Quantum | | | Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.507.1 | ML-KEM-512-SM2 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.507.2 | ML-KEM-768-SM2 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.507.3 | ML-KEM-1024-SM2 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.508 | Based on SM2 and ML-DSA | Post-Quantum | | | Algorithms | | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.508.1 | ML-DSA-44-SM2 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.508.2 | ML-DSA-65-SM2 | Post-Quantum | +-----------------------+----------------------------+--------------+ | 1.2.156.10197.1.508.3 | ML-DSA-87-SM2 | Post-Quantum | +-----------------------+----------------------------+--------------+ Table 4 Acknowledgments The authors thank contributors to the PQ-SecTunnel implementation and reviewers of earlier drafts. The handshake design builds on the Noise protocol framework and the WireGuard construction [WIREGUARD]. Aigis-enc (and related lattice KEMs developed in the Chinese research community) are acknowledged as candidate additional KEM modules for the same tunnel framework; detailed Aigis profiles are deferred until implementation and interoperability work is complete. The designers of Kyber/ML-KEM and Dilithium/ML-DSA are likewise acknowledged. Authors' Addresses Kai Fan Xidian University Xi'an Shaanxi, China Email: kfan@mail.xidian.edu.cn Fan, et al. Expires 14 February 2027 [Page 24] Internet-Draft PQ-SecTunnel August 2026 Ruidan Su Xidian University Xi'an Shaanxi, China Email: rdsu@xidian.edu.cn Yi Wang Xidian University Xi'an Shaanxi, China Email: 23151214152@stu.xidian.edu.cn Jiaqing Cheng Xidian University Xi'an Shaanxi, China Email: jiaqing.ch@stu.xidian.edu.cn Fan, et al. Expires 14 February 2027 [Page 25]