PQ-SecChannel Protocol Specification
draft-pq-secchannel-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 , Xuyang Ma , Ruiqi Yang | ||
| 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-secchannel-00
Network Working Group K. Fan
Internet-Draft R. Su
Intended status: Informational X. Ma
Expires: 14 February 2027 R. Yang
Xidian University
13 August 2026
PQ-SecChannel Protocol Specification
draft-pq-secchannel-00
Abstract
This document specifies the PQ-SecChannel cryptographic protocol,
which defines a secure interactive channel consisting of a Transport
Authentication Protocol and a Connection Protocol. The protocol is
designed to provide confidentiality, integrity, and mutual
authentication in the presence of quantum computing threats. PQ-
SecChannel incorporates standardized post-quantum cryptographic
algorithms, including lattice-based KEMs and signatures (e.g., Kyber
and Dilithium), Chinese post-quantum candidate algorithms (e.g.,
Aigis), and code-based KEMs (e.g., HQC), together with SM4-GCM for
AEAD (Authenticated Encryption with Associated Data) and SM3 for
hashing and key derivation. This specification is derived from the
Chinese national cryptography standard draft "PQ-SecChannel
Cryptographic Protocol Specification", adapted into IETF Internet-
Draft style for international review and potential interoperability
consideration. The protocol content also references the Secure Shell
architecture ([RFC4251], [RFC4252], [RFC4253], and [RFC4254]) and the
Chinese SSH cryptographic protocol specification [GMT0129].
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-SecChannel 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 . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Layers . . . . . . . . . . . . . . . . . . . . . 5
3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5
4. Transport Authentication Protocol . . . . . . . . . . . . . . 5
4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
4.2. Version Exchange . . . . . . . . . . . . . . . . . . . . 7
4.3. Algorithm Negotiation . . . . . . . . . . . . . . . . . . 7
4.4. Key Exchange and Authentication . . . . . . . . . . . . . 9
4.5. Message Packet Format . . . . . . . . . . . . . . . . . . 11
4.6. Data Encryption and Integrity . . . . . . . . . . . . . . 11
4.7. Compression . . . . . . . . . . . . . . . . . . . . . . . 12
4.8. Public Key and Certificate Format . . . . . . . . . . . . 12
4.9. Session Key Derivation . . . . . . . . . . . . . . . . . 12
4.10. Key Delivery and Re-Exchange . . . . . . . . . . . . . . 13
4.11. Service Request and Acceptance . . . . . . . . . . . . . 13
4.12. Disconnect . . . . . . . . . . . . . . . . . . . . . . . 14
5. Connection Protocol . . . . . . . . . . . . . . . . . . . . . 14
5.1. Channel Multiplexing . . . . . . . . . . . . . . . . . . 15
5.2. Channel Management . . . . . . . . . . . . . . . . . . . 15
5.3. Data Flow Control . . . . . . . . . . . . . . . . . . . . 16
6. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . 17
6.1. Asymmetric Algorithms . . . . . . . . . . . . . . . . . . 17
6.2. Symmetric Algorithms . . . . . . . . . . . . . . . . . . 17
6.3. Hash Function . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Key Types . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Quantum Resistance . . . . . . . . . . . . . . . . . . . 18
7.2. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 19
7.3. Authentication and Identity Binding . . . . . . . . . . . 19
7.4. Replay and MitM Protection . . . . . . . . . . . . . . . 19
Fan, et al. Expires 14 February 2027 [Page 2]
Internet-Draft PQ-SecChannel August 2026
7.5. Side-Channel Resistance . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. Registration of Protocol Identifier . . . . . . . . . . . 20
8.2. New Message Numbers . . . . . . . . . . . . . . . . . . . 20
8.3. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 21
8.4. No Further Actions . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
PQ-SecChannel is a protocol suite composed of a Transport
Authentication Protocol and a Connection Protocol. It aims to
provide quantum-resistant secure network services over unreliable or
untrusted networks. The protocol is applicable not only to
traditional TCP connections, but also to other reliable byte streams,
enabling secure applications such as sftp and scp.
This document specifies the PQ-SecChannel secure interactive
cryptographic protocol, including the encrypted Transport
Authentication Protocol, the Connection Protocol, and the methods for
using cryptographic algorithms within the protocol. It is applicable
to the development and testing of PQ-SecChannel server and client
products.
This document defines the two core components of PQ-SecChannel:
1.The Transport Authentication Protocol, which establishes a secure
communication channel, performs mutual authentication of the server
and client users, and provides confidentiality and integrity
protection.
2.The Connection Protocol, which multiplexes the encrypted channel
into multiple logical channels and provides services such as
interactive login sessions, remote command execution, and TCP/IP and
X11 forwarding.
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.
Fan, et al. Expires 14 February 2027 [Page 3]
Internet-Draft PQ-SecChannel August 2026
Additional terms and abbreviations used in this document :
* CR: Carriage Return.
* LF: Line Feed.
* SP: Space character.
* LZ77: A general-purpose data compression algorithm (Lempel-Ziv
77).
* UTF-8: 8-bit Unicode Transformation Format.
* KEM: Key Encapsulation Mechanism.
* IV: Initialization Vector.
* MAC: Message Authentication Code.
* PKI: Public Key Infrastructure.
* PQ-SecChannel: Post-Quantum Secure Channel (secure interactive
protocol).
* HASH: The negotiated cryptographic hash function (SM3 in this
specification).
All multi-byte integers are transmitted in network byte order (big-
endian). Algorithm identifiers used in this document MUST conform to
GB/T 33560 [GBT33560]. Terminology defined in GM/Z 4001 [GMZ4001]
applies to this document.
Basic data types used in this document are as follows:
* int8 / uint8 / byte: 1-byte signed / unsigned integer.
* uint32 / uint64: 4-byte / 8-byte unsigned integer.
* bool: Boolean value (1 = TRUE, 0 = FALSE).
* string: Arbitrary-length binary string, preceded by a uint32
length; length 0 denotes an empty string.
* mpint: Multiple-precision integer in two's complement form, stored
as a string.
* name-list: A string containing a comma-separated list of ASCII
names.
Fan, et al. Expires 14 February 2027 [Page 4]
Internet-Draft PQ-SecChannel August 2026
3. Protocol Overview
3.1. Protocol Layers
PQ-SecChannel operates as a two-layer protocol suite:
1. Transport Authentication Protocol: The foundation of PQ-
SecChannel. It establishes a secure communication channel and
authenticates both communicating parties, ensuring
confidentiality, integrity, and authenticity of data in transit.
It supports multiple post-quantum algorithms, including lattice-
based encryption (e.g., Kyber), lattice-based signatures (e.g.,
Dilithium), and Chinese post-quantum candidates (e.g., Aigis).
The protocol may run over TCP or other reliable data streams. It
uses PKI-based authentication and a strict algorithm negotiation
mechanism so that both parties select the strongest mutually
supported algorithms.
2. Connection Protocol: Runs above the Transport Authentication
Protocol. It multiplexes the encrypted channel into multiple
logical channels and provides network services such as
interactive shells and port forwarding. All data transfer and
service requests on this layer are protected by the keys and
algorithms established by the transport layer.
3.2. Threat Model
PQ-SecChannel is designed to resist:
* Eavesdropping (confidentiality)
* Message tampering (integrity)
* Man-in-the-middle attacks (mutual authentication)
* Quantum adversaries capable of breaking classical public-key
cryptography
It assumes a reliable underlying transport (e.g., TCP) and does not
provide comprehensive protection against denial-of-service attacks.
The protocol assumes that long-term private keys are protected and
that certificate validation is performed according to PKI practices.
4. Transport Authentication Protocol
Fan, et al. Expires 14 February 2027 [Page 5]
Internet-Draft PQ-SecChannel August 2026
4.1. Protocol Overview
The Transport Authentication Protocol runs over TCP/IP or another
reliable byte stream and may serve as the foundation for multiple
secure network services. It provides encryption, mutual
authentication between server and client, integrity protection via
AEAD, and optional compression. Key exchange methods, cipher
algorithms, and hash algorithms are all negotiated. Because SM4-GCM
(AEAD) is used, a separate MAC algorithm is not negotiated or
applied.
The server SHOULD configure an authentication timeout. If the client
fails to complete authentication within the configured time, the
connection SHOULD be closed. The RECOMMENDED timeout is 10 minutes,
and it MUST NOT exceed 30 minutes. The server SHOULD limit the
number of authentication attempts by a client within one session.
When a client fails authentication more than 20 consecutive times,
the server SHOULD disconnect.
The transport-layer connection is initiated by the client.
Communication uses predefined message numbers, including but not
limited to:
PQ-SecChannel_MSG_DISCONNECT
PQ-SecChannel_MSG_SERVICE_REQUEST
PQ-SecChannel_MSG_SERVICE_ACCEPT
PQ-SecChannel_MSG_KEXAUTH_INIT
PQ-SecChannel_MSG_NEWKEYS_AUTH_SUCCESS
PQ-SecChannel_MSG_KEX_AUTH_REQUEST
PQ-SecChannel_MSG_KEX_AUTH_REPLY
PQ-SecChannel_MSG_KEX_AUTH
A typical message flow is: version exchange; mutual PQ-
SecChannel_MSG_KEXAUTH_INIT; PQ-SecChannel_MSG_KEX_AUTH_REQUEST /
REPLY / AUTH; mutual PQ-SecChannel_MSG_NEWKEYS_AUTH_SUCCESS; then PQ-
SecChannel_MSG_SERVICE_REQUEST / ACCEPT.
Fan, et al. Expires 14 February 2027 [Page 6]
Internet-Draft PQ-SecChannel August 2026
4.2. Version Exchange
This document defines transport-layer protocol version 1.0. After
the network connection is established, both parties MUST send a
version identification string in the following format:
CPQ-SecChannel-<protoversion>-<softwareversion>[SP
<comments>]<CR><LF>
Example:
CPQ-SecChannel-1.0-MyPQ-SecChannel3.3 This is comment<CR><LF>
Where:
* CPQ-SecChannel is the short name used by this specification.
* <protoversion>: MUST be "1.0" for this specification.
* <softwareversion>: implementation-defined software name and
version; MUST NOT contain SP or hyphen ("-").
* <comments>: optional. If present, it MUST be separated from
<softwareversion> by SP.
* Character set: printable US-ASCII; maximum length 255 bytes
including <CR><LF>.
The server MAY send additional UTF-8 lines terminated by <CR><LF>
before its version string (e.g., to display an error before
disconnect). Clients MUST be able to process these lines and MAY
ignore them or display them to the user. Key exchange begins
immediately after the version identification strings are exchanged.
4.3. Algorithm Negotiation
After version exchange, both parties send a PQ-
SecChannel_MSG_KEXAUTH_INIT message containing lists of supported
algorithms. The first name in each list is the preferred algorithm.
Each party selects the first algorithm that also appears in the
peer's list.
The PQ-SecChannel_MSG_KEXAUTH_INIT payload format is:
Field Type
PQ-SecChannel_MSG_KEXAUTH_INIT byte
Fan, et al. Expires 14 February 2027 [Page 7]
Internet-Draft PQ-SecChannel August 2026
cookie byte[16]
kex_algorithms name-list
server_host_key_algorithms name-list
encryption_algorithms_client_to_server name-list
encryption_algorithms_server_to_client name-list
compression_algorithms_client_to_server name-list
compression_algorithms_server_to_client name-list
languages_client_to_server name-list
languages_server_to_client name-list
first_kex_packet_follows bool
reserved uint32
* cookie: 16-byte random value generated by the sender so that
neither party alone can fully determine the final keying material.
* kex_algorithms: Key encapsulation algorithms. Supported values
include "kyber" (and may include additional KEMs such as aigis-enc
and hqc as negotiated).
* server_host_key_algorithms: Host-key / signature algorithms used
for authentication (e.g., Dilithium).
* encryption_algorithms_*: Symmetric encryption algorithms (see
Cryptographic Algorithms). SM4-GCM is REQUIRED.
* compression_algorithms_*: Compression algorithms.
* languages_*: Language tags; SHOULD be empty unless language
negotiation is required.
* first_kex_packet_follows: TRUE if a guessed key-exchange packet
follows; otherwise FALSE.
* reserved: MUST be set to 0 and reserved for future use.
After PQ-SecChannel_MSG_KEXAUTH_INIT is exchanged, key agreement and
authentication proceed according to the negotiated algorithms and MAY
require additional packet exchanges.
Fan, et al. Expires 14 February 2027 [Page 8]
Internet-Draft PQ-SecChannel August 2026
4.4. Key Exchange and Authentication
Key agreement defines how session keys for encryption and
authentication are generated and how the server and client mutually
authenticate. After algorithm agreement, both parties compute
session keys and use them to protect subsequent packets.
1. Client sends:
PQ-SecChannel_MSG_KEX_AUTH_REQUEST || user_name || random_client
where random_client is an 8-byte random value.
2. Server responds:
PQ-SecChannel_MSG_KEX_AUTH_REPLY || challenge || server_sign_cert ||
server_enc_cert || random_server || sign
challenge is a server authentication parameter; server_sign_cert and
server_enc_cert are string-encoded server signature and encryption
certificates. sign is a signature under the server signature private
key over the following concatenation (in order):
user_name || random_client || random_server ||
public_key_algorithm_name || server_sign_cert || server_enc_cert
3. After verifying the server signature and certificates, the client
generates a 32-byte random shared secret K, encapsulates it under the
server encryption-certificate public key to obtain ciphertext ct, and
sends:
PQ-SecChannel_MSG_KEX_AUTH || response || public_key_algorithm ||
client_sign_cert || ct
where public_key_algorithm_name is "Dilithium", and response is a
signedData value produced with the client signature private key over:
user_name || public_key_algorithm_name || client_sign_cert || ct
Fan, et al. Expires 14 February 2027 [Page 9]
Internet-Draft PQ-SecChannel August 2026
4. The server verifies the client signature and certificate, then
decapsulates ct to recover K.
5. After successful authentication, both sides compute the session
hash:
H = HASH(random_client || random_server || certificate || K)
Key agreement produces a shared secret K and a session hash H. The
first exchange hash H of a connection is also used as the session_id.
Once established, session_id MUST NOT change until the connection is
closed.
Authentication Failure
If the server rejects authentication, it sends:
PQ-SecChannel_MSG_USERAUTH_FAILURE || partial_success(bool)
Based on supported authentication methods,
authentication_that_can_continue is "certificate". If the server
disconnects after failure, partial_success is FALSE; otherwise TRUE.
Whether to disconnect depends on server policy and client behavior
(e.g., repeated failures within the timeout).
Authentication Success
On success, the server sends:
PQ-SecChannel_MSG_USERAUTH_SUCCESS || prompt(string)
The client MAY send multiple authentication requests without waiting
for prior responses. The server MUST process each request completely
and, for failures, send PQ-SecChannel_MSG_USERAUTH_FAILURE before
continuing. After PQ-SecChannel_MSG_USERAUTH_SUCCESS, further
authentication requests MUST be ignored; other requests are passed to
upper-layer protocols, and the requested service SHOULD be started.
Authentication Banner
At any time from request until success, the server MAY send:
PQ-SecChannel_MSG_USERAUTH_BANNER || message(UTF-8 string)
The client SHOULD display message (which MAY contain multiple lines
separated by <CR><LF>) and MAY ignore it. Banner messages MAY be
used for errors or operational guidance.
Fan, et al. Expires 14 February 2027 [Page 10]
Internet-Draft PQ-SecChannel August 2026
4.5. Message Packet Format
After the version identification strings are exchanged, all
subsequent data uses the following packet format:
Field Type
packet_length uint32
padding_length byte
payload byte[n1]
padding byte[n2]
Where:
* packet_length: length in bytes of the packet, excluding
packet_length itself.
* padding_length: length of padding in bytes.
* n1 = packet_length - padding_length - 1; payload MAY be compressed
if compression was negotiated.
* n2 = padding_length. Padding MUST be random, at least 4 bytes and
at most 255 bytes, such that packet_length || padding_length ||
payload || padding is a multiple of the cipher block length. This
protocol uses SM4-GCM.
* Because SM4-GCM provides authenticated encryption, a separate mac
field is NOT used and MUST NOT be present in data packets.
Clients and servers MUST be able to process packets whose
uncompressed payload is 2^16 bytes or less.
4.6. Data Encryption and Integrity
When encryption is in effect, packet_length, padding_length, payload,
and padding MUST be encrypted with the negotiated algorithm and
session key.
Encryption algorithms:
* SM4-GCM: REQUIRED. SM4 block cipher in GCM mode (AEAD).
Integrity:
Fan, et al. Expires 14 February 2027 [Page 11]
Internet-Draft PQ-SecChannel August 2026
Integrity and authenticity of each packet are provided by the AEAD
tag of SM4-GCM. A separate MAC algorithm and mac field are not used
because SM4-GCM already provides integrity (cf. GB/T 15852.1
[GBT15852]).
The packet sequence number is a uint32 maintained independently by
each side (starting at 0, wrapping after the maximum uint32 value).
The sequence number is not transmitted in the packet and MUST be
authenticated as Additional Authenticated Data (AAD) in the AEAD
operation.
AEAD modes (SM4-GCM) MUST authenticate the packet sequence number as
associated data.
4.7. Compression
If compression is negotiated, the payload is compressed with the
negotiated algorithm before encryption. packet_length is computed
over the compressed payload. Server and client MAY use different
compression algorithms.
Supported algorithms:
* zlib: LZ77 compression (OPTIONAL)
* none: No compression (OPTIONAL)
4.8. Public Key and Certificate Format
* Public keys: Encoded per GB/T 43207 [GBT43207] and transmitted
using Base64.
* Certificates: Format per GM/T 0014 [GMT0014] and transmitted using
Base64. Certificate validation MUST follow PKI practices.
4.9. Session Key Derivation
Using shared secret K and session hash H, derive:
* Client-to-Server IV: HASH(K || H || "A" || session_id)
* Server-to-Client IV: HASH(K || H || "B" || session_id)
* Client-to-Server Enc Key: HASH(K || H || "C" || session_id)
* Server-to-Client Enc Key: HASH(K || H || "D" || session_id)
Fan, et al. Expires 14 February 2027 [Page 12]
Internet-Draft PQ-SecChannel August 2026
K is encoded as an mpint, the label ("A" through "D") is a single
byte, and session_id is the original first exchange hash H. Keys are
truncated to the required length for SM4-GCM. In this specification,
HASH is SM3. Separate MAC keys are not derived because SM4-GCM
provides integrity protection.
4.10. Key Delivery and Re-Exchange
Key agreement ends when both parties have sent PQ-
SecChannel_MSG_NEWKEYS_AUTH_SUCCESS. That message is protected with
the old keys and algorithms. All messages sent after it MUST use the
new keys and algorithms.
Except while a key exchange is already in progress, sending PQ-
SecChannel_MSG_KEXINIT begins re-keying. Upon receiving PQ-
SecChannel_MSG_KEXINIT, a party MUST respond with its own PQ-
SecChannel_MSG_KEXINIT. Re-keying uses the previous session keys and
algorithms until completion. Encryption and compression algorithms
do not change until re-keying finishes. Processing is the same as
the initial exchange except that session_id is preserved. Some or
all algorithms and the server certificate MAY change. All keys and
IVs are recomputed, and compression/encryption contexts are reset.
Re-keying SHOULD occur after 1 GB of data or 1 hour of connection
time, whichever comes first. It MUST occur before 100 GB or 24
hours, whichever comes first. Application data MAY continue after
PQ-SecChannel_MSG_NEWKEYS_AUTH_SUCCESS. Key exchange does not affect
protocols above the transport layer.
4.11. Service Request and Acceptance
After key agreement, the client MAY request a service identified by
name:
PQ-SecChannel_MSG_SERVICE_REQUEST || service_name
If the server rejects the request, it MAY send PQ-
SecChannel_MSG_DISCONNECT and close the connection. If the server
supports and permits the service, it MUST respond:
PQ-SecChannel_MSG_SERVICE_ACCEPT || service_name
The Connection Protocol service_name is "PQ-SecChannel". Other
services (e.g., "sftp", "scp") MAY be defined in extensions.
Fan, et al. Expires 14 February 2027 [Page 13]
Internet-Draft PQ-SecChannel August 2026
4.12. Disconnect
At any stage, either party MAY send a disconnect packet:
PQ-SecChannel_MSG_DISCONNECT || reason_code(uint32) ||
description(UTF-8)
Defined reason_code values:
* 1: Server refused connection
* 2: Protocol error
* 3: Key exchange failed
* 4: Reserved
* 5: MAC error
* 6: Compression / decompression error
* 7: Service not available
* 8: Protocol version not supported
* 9: Host key not present
* 10: Connection lost
* 11: Application-specific reason
* 12: Too many connections
* 13: User canceled authentication
* 14: Authentication method not supported
* 15: Illegal user name
After sending or receiving this message, the connection SHOULD be
closed.
5. Connection Protocol
Fan, et al. Expires 14 February 2027 [Page 14]
Internet-Draft PQ-SecChannel August 2026
5.1. Channel Multiplexing
The Connection Protocol runs over the authenticated transport layer.
It provides interactive login sessions, remote command execution,
TCP/IP forwarding, and X11 forwarding. The service_name is "PQ-
SecChannel".
Message numbers used by the Connection Protocol include:
PQ-SecChannel_MSG_GLOBAL_REQUEST
PQ-SecChannel_MSG_REQUEST_SUCCESS
PQ-SecChannel_MSG_REQUEST_FAILURE
PQ-SecChannel_MSG_CHANNEL_OPEN
PQ-SecChannel_MSG_CHANNEL_OPEN_CONFIRMATION
PQ-SecChannel_MSG_CHANNEL_OPEN_FAILURE
PQ-SecChannel_MSG_CHANNEL_WINDOW_ADJUST
PQ-SecChannel_MSG_CHANNEL_DATA
PQ-SecChannel_MSG_CHANNEL_EOF
PQ-SecChannel_MSG_CHANNEL_CLOSE
A connection channel represents a login session or forwarded
connection. Both server and client MAY open channels. Multiple
channels are multiplexed over one connection. Channels are
identified by channel numbers that MAY differ at each endpoint. When
opening a channel, the sender provides its local channel number;
subsequent packets carry the recipient's channel number.
5.2. Channel Management
* Open Channel:
PQ-SecChannel_MSG_CHANNEL_OPEN || channel_type(ASCII string) ||
sender_channel_id(uint32) || initial_window_size(uint32) ||
maximum_packet_size(uint32)
* Open Confirmation:
Fan, et al. Expires 14 February 2027 [Page 15]
Internet-Draft PQ-SecChannel August 2026
PQ-SecChannel_MSG_CHANNEL_OPEN_CONFIRMATION ||
recipient_channel_id(uint32) || sender_channel_id(uint32) ||
initial_window_size(uint32) || maximum_packet_size(uint32)
* Open Failure:
PQ-SecChannel_MSG_CHANNEL_OPEN_FAILURE ||
recipient_channel_id(uint32) || reason(uint32) ||
description(UTF-8) || language(tag)
reason values:
* PQ-SecChannel_OPEN_ADMINISTRATIVELY_PROHIBITED
* PQ-SecChannel_OPEN_CONNECT_FAILED
* PQ-SecChannel_OPEN_UNKNOWN_CHANNEL_TYPE
* PQ-SecChannel_OPEN_RESOURCE_SHORTAGE
5.3. Data Flow Control
The amount of data that may be sent is governed by a window. Parties
use window-adjust messages to increase the maximum transferable
amount. The window size MUST NOT exceed the range of uint32.
* Window Adjustment:
PQ-SecChannel_MSG_CHANNEL_WINDOW_ADJUST ||
recipient_channel_id(uint32) || size(uint32)
* Data Transmission:
PQ-SecChannel_MSG_CHANNEL_DATA ||
recipient_channel_id(uint32) || data(string)
* EOF:
PQ-SecChannel_MSG_CHANNEL_EOF || recipient_channel_id(uint32)
Sent when a party will send no more data on the channel. The
recipient NEED NOT reply, or MAY reply with the same message.
Fan, et al. Expires 14 February 2027 [Page 16]
Internet-Draft PQ-SecChannel August 2026
* Close:
PQ-SecChannel_MSG_CHANNEL_CLOSE || recipient_channel_id(uint32)
Either party MAY close a channel. The recipient NEED NOT reply.
Flow control uses a credit-based window. The initial window size is
implementation-defined.
6. Cryptographic Algorithms
6.1. Asymmetric Algorithms
PQ-SecChannel uses Kyber and Dilithium as primary asymmetric
algorithms for post-quantum identity authentication, key exchange,
and data signatures.
* Kyber: A lattice-based KEM used to exchange session keys securely.
A public/private key pair is generated; the public key
encapsulates shared secrets and the private key decapsulates them.
* Dilithium: A lattice-based digital signature algorithm used to
verify message integrity and sender identity.
Supplemental candidate algorithms:
* Aigis-enc / Aigis-sign: Chinese post-quantum candidates based on
(M)LWE and (M)SIS. Aigis-enc is an efficient KEM; Aigis-sign is a
compact signature scheme with smaller public keys, ciphertexts,
and signatures than Kyber/Dilithium in some parameter sets,
suitable for constrained environments.
* HQC (Hamming Quasi-Cyclic): A code-based KEM whose security relies
on decoding under Hamming weight. As a NIST alternate candidate,
HQC offers very small public keys and is suitable for bandwidth-
constrained scenarios, at the cost of larger ciphertexts and
somewhat lower performance.
6.2. Symmetric Algorithms
PQ-SecChannel uses SM4-GCM as the symmetric AEAD cipher for
protecting key-exchange and application data. Implementations MUST
use key lengths that provide adequate resistance against Grover's
algorithm (RECOMMENDED: 256-bit effective symmetric strength where
applicable).
* SM4-GCM: REQUIRED
Fan, et al. Expires 14 February 2027 [Page 17]
Internet-Draft PQ-SecChannel August 2026
6.3. Hash Function
* SM3: REQUIRED for hashing, integrity checks, and key derivation
(256-bit output).
6.4. Key Types
Server Keys
Server keys are asymmetric key pairs that MUST be quantum-resistant,
including a signature key pair and an encapsulation (encryption) key
pair.
* Signature key pair: Generated by the server cryptographic module,
RECOMMENDED to use Dilithium. The public key MAY be embedded in a
certificate issued by a CA for client verification of server
identity.
* Encapsulation key pair: Used for key exchange authentication and
data protection, using Kyber as the KEM. The encapsulation public
key is also embedded in a CA-issued certificate.
Client Keys
Client keys are asymmetric signature key pairs that MUST be quantum-
resistant. The signature key pair is generated by the client
cryptographic module, RECOMMENDED to use Dilithium. The client
public key MAY be embedded in a CA-issued certificate for server
verification of client identity.
Transport-Layer Session Keys
Transport-layer session keys are symmetric keys used to encrypt and
decrypt communication data, ensuring confidentiality and integrity in
transit. Session keys are jointly established by the server and
client as specified in Session Key Derivation.
7. Security Considerations
7.1. Quantum Resistance
The core security objective of PQ-SecChannel is to resist threats
from large-scale quantum computers, including Shor's algorithm
against classical public-key cryptosystems and Grover's algorithm
against symmetric search.
Fan, et al. Expires 14 February 2027 [Page 18]
Internet-Draft PQ-SecChannel August 2026
Asymmetric cryptography in this protocol relies on PQC problems
believed to be hard for both classical and quantum adversaries
(Module-LWE / Module-SIS for Kyber, Dilithium, and Aigis; coding
problems for HQC). Symmetric cryptography mandates 256-bit keys so
that Grover search remains at approximately 2^128 work. Quantum
resistance is knowledge-relative; long-term security depends on
ongoing cryptanalysis and the ability to update algorithms.
7.2. Forward Secrecy
PQ-SecChannel provides forward secrecy through ephemeral key
exchange. Each key exchange (initial and re-keying) derives session
key material from freshly generated values (including the 32-byte
secret K encapsulated under the server encryption public key). Even
if long-term identity private keys are later compromised, past
session keys cannot be recovered if ephemeral secrets were securely
discarded.
7.3. Authentication and Identity Binding
Server and client identities are bound to public keys via digital
certificates issued by trusted CAs or otherwise provisioned through
trusted channels. Implementations MUST perform full certificate
chain validation during key exchange, including signature validity,
validity period, key usage, and identity matching (Subject / SAN).
Implementations SHOULD support OCSP or CRL revocation checking; in
high-security environments, revocation checking MUST be enabled.
7.4. Replay and MitM Protection
* Cookie randomness in PQ-SecChannel_MSG_KEXAUTH_INIT prevents
trivial replay of prior handshake messages.
* Session keys depend on random_client, random_server, certificates,
and K, ensuring per-session freshness.
* Mutual signatures over algorithm- and identity-binding fields
prevent undetected MitM and downgrade attacks.
* Authentication timeouts and attempt limits mitigate online
guessing and stalled handshake abuse.
Fan, et al. Expires 14 February 2027 [Page 19]
Internet-Draft PQ-SecChannel August 2026
7.5. Side-Channel Resistance
Implementations MUST defend against side-channel attacks. Operations
that depend on secret data (KEM encapsulate/decapsulate and signature
generation/verification) MUST be constant-time. Implementers SHOULD
use well-audited cryptographic libraries with side-channel
countermeasures.
8. IANA Considerations
8.1. Registration of Protocol Identifier
IANA is requested to register "PQ-SecChannel" as a service name /
transport protocol identifier in the "Service Name and Transport
Protocol Port Number Registry", with default port TBD.
8.2. New Message Numbers
IANA is requested to allocate message numbers for the following
messages:
Message Name Value
PQ-SecChannel_MSG_DISCONNECT XX
PQ-SecChannel_MSG_SERVICE_REQUEST XX
PQ-SecChannel_MSG_SERVICE_ACCEPT XX
PQ-SecChannel_MSG_KEXAUTH_INIT XX
PQ-SecChannel_MSG_NEWKEYS_AUTH_SUCCESS XX
PQ-SecChannel_MSG_KEX_AUTH_REQUEST XX
PQ-SecChannel_MSG_KEX_AUTH_REPLY XX
PQ-SecChannel_MSG_KEX_AUTH XX
PQ-SecChannel_MSG_USERAUTH_FAILURE XX
PQ-SecChannel_MSG_USERAUTH_SUCCESS XX
PQ-SecChannel_MSG_USERAUTH_BANNER XX
PQ-SecChannel_MSG_CHANNEL_OPEN XX
PQ-SecChannel_MSG_CHANNEL_OPEN_CONFIRMATION XX
Fan, et al. Expires 14 February 2027 [Page 20]
Internet-Draft PQ-SecChannel August 2026
PQ-SecChannel_MSG_CHANNEL_OPEN_FAILURE XX
PQ-SecChannel_MSG_CHANNEL_WINDOW_ADJUST XX
PQ-SecChannel_MSG_CHANNEL_DATA XX
PQ-SecChannel_MSG_CHANNEL_EOF XX
PQ-SecChannel_MSG_CHANNEL_CLOSE XX
8.3. Algorithm Identifiers
IANA is requested to register the following algorithm names where
applicable:
kex_algorithms: kyber, aigis-enc, hqc
publickey_algorithms: dilithium, aigis-sign
encryption_algorithms: SM4-GCM
compression_algorithms: zlib, none
8.4. No Further Actions
No other IANA actions are required at this time.
9. References
9.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>.
[GMT0014] State Cryptography Administration (SCA), "Digital
Certificate Authentication System Cryptographic Protocol
Specification", GM/T 0014, 2012.
[GMT0128] State Cryptography Administration (SCA), "Datagram
Transport Layer Security Protocol Specification", GM/
T 0128, 2021.
Fan, et al. Expires 14 February 2027 [Page 21]
Internet-Draft PQ-SecChannel August 2026
[GMT0129] State Cryptography Administration (SCA), "SSH
Cryptographic Protocol Specification", GM/T 0129, 2021.
[GBT15852] Standardization Administration of China (SAC),
"Information technology - Security techniques - Message
authentication codes - Part 1: Mechanisms using a block
cipher", GB/T 15852.1.
[GBT33560] Standardization Administration of China (SAC),
"Information security technology - Cryptographic
application identifier specification", GB/T 33560.
[GBT43207] Standardization Administration of China (SAC),
"Information security technology - Information system
cryptographic application design guide", GB/T 43207.
[GMZ4001] State Cryptography Administration (SCA), "Cryptography
terminology", GM/Z 4001.
9.2. Informative References
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006,
<https://www.rfc-editor.org/rfc/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006,
<https://www.rfc-editor.org/rfc/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006,
<https://www.rfc-editor.org/rfc/rfc4253>.
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006,
<https://www.rfc-editor.org/rfc/rfc4254>.
Acknowledgments
The authors would like to thank the members of the IRTF Crypto Forum
Research Group (CFRG) and related IETF security working groups for
feedback. This document is based on the Chinese national
cryptography standard draft for PQ-SecChannel and acknowledges the
contributions of the Cryptography Industry Standardization Technical
Committee and the designers of the Aigis, Kyber, Dilithium, and HQC
algorithms.
Fan, et al. Expires 14 February 2027 [Page 22]
Internet-Draft PQ-SecChannel August 2026
Authors' Addresses
Kai Fan
Xidian University
Xi'an
Shaanxi,
China
Email: kfan@mail.xidian.edu.cn
Ruidan Su
Xidian University
Xi'an
Shaanxi,
China
Email: rdsu@xidian.edu.cn
Xuyang Ma
Xidian University
Xi'an
Shaanxi,
China
Email: 24151213690@stu.xidian.edu.cn
Ruiqi Yang
Xidian University
Xi'an
Shaanxi,
China
Email: yrq@stu.xidian.edu.cn
Fan, et al. Expires 14 February 2027 [Page 23]