Xidian University

Xi'anShaanxiChina kfan@mail.xidian.edu.cn

Xidian University

Xi'anShaanxiChina rdsu@xidian.edu.cn

Xidian University

Xi'anShaanxiChina 24151213690@stu.xidian.edu.cn

Xidian University

Xi'anShaanxiChina yrq@stu.xidian.edu.cn

Internet PQ-SecChannel post-quantum cryptography 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 (, , , and ) and the Chinese SSH cryptographic protocol specification .

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.

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 when, and only when, they appear in all capitals. 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 . Terminology defined in GM/Z 4001 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.

Protocol Overview

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.

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.

Transport Authentication Protocol

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.

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.

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

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

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.

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.

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: 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 ). 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.

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)

Public Key and Certificate Format

• Public keys: Encoded per GB/T 43207 and transmitted using Base64.
• Certificates: Format per GM/T 0014 and transmitted using Base64. Certificate validation MUST follow PKI practices.

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)

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.

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.

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.

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.

Connection Protocol

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.

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:

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

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.

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

Cryptographic Algorithms

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.

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

Hash Function

• SM3: REQUIRED for hashing, integrity checks, and key derivation (256-bit output).

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.

Security Considerations

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

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.

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.

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.

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.

IANA Considerations

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.

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

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

No Further Actions No other IANA actions are required at this time.

References Normative References State Cryptography Administration (SCA) State Cryptography Administration (SCA) State Cryptography Administration (SCA) Standardization Administration of China (SAC) Standardization Administration of China (SAC) Standardization Administration of China (SAC) State Cryptography Administration (SCA) Informative References

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.