PQ-SecTunnel Protocol Specification
draft-pq-sectunnel-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Kai Fan , Ruidan Su , Yi Wang , Jiaqing Cheng | ||
| Last updated | 2026-08-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pq-sectunnel-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
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,
<https://www.rfc-editor.org/rfc/rfc7693>.
[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]