Network Working Group S. Sammartano Internet-Draft BubbleFish Technologies, Inc. Intended status: Informational 5 June 2026 Expires: 7 December 2026 N-PAMP: Native Post-Quantum Agent Messaging Protocol draft-bubblefish-npamp-00 Abstract The Native Post-Quantum Agent Messaging Protocol (N-PAMP) is a binary, multi-channel, wire-level protocol for authenticated communication between autonomous software agents. N-PAMP operates beneath application-layer agent protocols and provides a single fixed-size frame format, a registry of multiplexed channels, and three escalating security profiles (Standard, High, and Sovereign) built on standard post-quantum and classical cryptography. The protocol uses a hybrid key-encapsulation mechanism combining X25519 with ML-KEM, authenticated encryption with associated data, and a forward-secure key schedule. N-PAMP runs over QUIC as its primary transport and over TCP with TLS 1.3 as a fallback, negotiated via the Application-Layer Protocol Negotiation (ALPN) identifier "n-pamp/2". This document describes the wire format, channel architecture, profile negotiation, and cryptographic suites of N-PAMP, and reserves code-point ranges for extensions defined in companion specifications. 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 7 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Sammartano Expires 7 December 2026 [Page 1] Internet-Draft N-PAMP June 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Frame Structure . . . . . . . . . . . . . . . . . . . . . 6 4.2. Frame Header . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Frame Flags . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Extension TLVs . . . . . . . . . . . . . . . . . . . . . 8 4.5. Payload Encoding . . . . . . . . . . . . . . . . . . . . 8 4.6. Reserved Frame Types . . . . . . . . . . . . . . . . . . 9 4.7. CLOSE Frame . . . . . . . . . . . . . . . . . . . . . . . 10 5. Channel Architecture . . . . . . . . . . . . . . . . . . . . 10 5.1. Core Channel Registry . . . . . . . . . . . . . . . . . . 10 6. Profile Negotiation . . . . . . . . . . . . . . . . . . . . . 13 7. Cryptographic Suites . . . . . . . . . . . . . . . . . . . . 14 7.1. Key Encapsulation Mechanisms . . . . . . . . . . . . . . 14 7.2. Authenticated Encryption . . . . . . . . . . . . . . . . 15 7.3. Signatures . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. Key Derivation and Hashing . . . . . . . . . . . . . . . 16 7.5. Key Schedule and Nonces . . . . . . . . . . . . . . . . . 16 7.6. Random Number Generation . . . . . . . . . . . . . . . . 16 8. Extension Points . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Reserved Frame-Type Ranges . . . . . . . . . . . . . . . 16 8.2. Reserved TLV Tags . . . . . . . . . . . . . . . . . . . . 17 8.3. Reserved Channel-ID Range . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 18 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 18 9.3. Registries Maintained by This Specification . . . . . . . 19 9.4. TLV Type Registry . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10.1. Hybrid Key Establishment . . . . . . . . . . . . . . . . 21 10.2. Downgrade, Unknown-Key-Share, and Identity Substitution . . . . . . . . . . . . . . . . . . . . . . 21 10.3. Authenticated Encryption and Nonce Management . . . . . 21 10.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.5. Forward Secrecy and Key Update . . . . . . . . . . . . . 22 Sammartano Expires 7 December 2026 [Page 2] Internet-Draft N-PAMP June 2026 10.6. Connection Migration . . . . . . . . . . . . . . . . . . 22 10.7. Authenticated Close . . . . . . . . . . . . . . . . . . 22 10.8. Extension Points . . . . . . . . . . . . . . . . . . . . 22 10.9. Implementation Considerations . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 24 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Autonomous software agents increasingly communicate with one another over long-lived associations that carry control traffic, persistent state, capability delegation, identity attestation, and operational telemetry on a single connection. Existing transport-layer protocols such as TLS 1.3 [RFC8446] and QUIC [RFC9000], and application-layer agent protocols layered above them, do not by themselves provide a unified binary frame format with semantic channel multiplexing, profile-negotiated cryptographic strength, and mandatory authenticated encryption tailored to agent-to-agent traffic. N-PAMP addresses this gap. It defines a single fixed-size frame header, a set of multiplexed channels each carrying a distinct class of agent traffic, and three negotiated security profiles that hold the wire format constant while escalating the cryptographic primitives and operational requirements. All three profiles employ a hybrid key-encapsulation mechanism (KEM) combining the classical X25519 key agreement with a NIST-standardized module-lattice KEM (ML- KEM, [FIPS203]), so that the confidentiality of an association is preserved if either the classical or the post-quantum component remains unbroken. N-PAMP is deliberately scoped as a transport substrate. It does not define application-layer semantics for the data carried on its channels; those are the subject of companion specifications. This document specifies the wire format, the channel registry, profile negotiation, and the cryptographic suites, and it reserves code-point ranges so that companion extensions can be defined without colliding with the core protocol. 1.1. Goals The design goals of N-PAMP are: * Cryptographic agility within a stable wire format. The frame format does not change between profiles; the cryptographic primitives, modes, and operational requirements do. Sammartano Expires 7 December 2026 [Page 3] Internet-Draft N-PAMP June 2026 * Defense in depth through hybrid post-quantum and classical key establishment, authenticated encryption, and a forward-secure key schedule. * Channel multiplexing so that a single association can carry several classes of agent traffic with independent sequence spaces and per-channel keying. * Interoperability across profiles, so that an endpoint operating at a higher profile MAY interoperate with a lower-profile peer when local policy permits. 1.2. Non-Goals This document does NOT: * Replace TLS for ordinary web traffic. N-PAMP is purpose-built for autonomous-agent, multi-channel traffic over long-lived associations. * Define application-layer semantics for the data carried on its channels. * Define a general-purpose IP-layer tunneling or VPN protocol. 1.3. Terminology For the purposes of this document: Association: A long-lived, cryptographically authenticated session between two N-PAMP endpoints, identified by a stable Association ID. Channel: A semantic multiplexing lane within an association, identified by a 16-bit Channel ID, carrying one class of agent traffic with its own sequence space. Frame: The atomic unit of transmission, consisting of a fixed 36-octet header, optional extension TLVs, and an AEAD-protected payload. Profile: One of three negotiated levels of cryptographic strength and operational requirement (Standard, High, Sovereign). Sammartano Expires 7 December 2026 [Page 4] Internet-Draft N-PAMP June 2026 2. Conventions and Definitions 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. 3. Protocol Overview N-PAMP is a binary protocol. Every unit of communication is a frame consisting of a fixed 36-octet header (Section 4), zero or more extension TLVs, and a payload protected by an authenticated- encryption-with-associated-data (AEAD) construction [RFC5116]. Frames are carried on channels (Section 5), each of which has an independent per-direction sequence space. An N-PAMP association is established by a handshake that: 1. establishes a hybrid X25519 + ML-KEM shared secret; 2. negotiates a security profile, a KEM, a signature algorithm, and one or more AEAD suites; 3. authenticates both peers by signing a transcript that binds the negotiated parameters and both peer identities; and 4. derives a forward-secure key schedule from which per-channel, per-direction traffic keys are obtained. The negotiated profile, the KEM identifier, the signature identifier, the selected AEAD suite(s), and both peer identities are all bound into the handshake transcript and confirmed by a Finished message authentication code (MAC). A man-in-the-middle that alters any negotiated parameter or substitutes an identity invalidates the Finished MAC and aborts the handshake; this is the structural defense against downgrade, unknown-key-share, and identity-substitution attacks (see Section 10). N-PAMP uses QUIC [RFC9000] (secured with TLS 1.3, [RFC9001]) as its primary transport and TCP with TLS 1.3 [RFC8446] as a fallback. In both cases, the application protocol is negotiated using the ALPN extension [RFC7301] with the identifier "n-pamp/2" (Section 9). 4. Wire Format Sammartano Expires 7 December 2026 [Page 5] Internet-Draft N-PAMP June 2026 4.1. Frame Structure Every N-PAMP frame has the following structure: +--------+-------------+-------------------+-----------+ | Header | Extension | Payload | AEAD Tag | | 36 B | TLVs (var) | (var, encrypted) | (16 B) | +--------+-------------+-------------------+-----------+ Figure 1: N-PAMP frame structure The 36-octet header is fixed-size. Zero or more extension TLVs MAY accompany a frame. The payload is AEAD-sealed, and the associated data covers the 21-octet header prefix (octets 0-20, through the Payload Length field, the same octets protected by the header CRC32C) so that any modification to those header fields is detected on decryption. 4.2. Frame Header The fixed header is 36 octets, laid out as follows. Multi-octet integers are encoded in network byte order (big-endian) unless stated otherwise. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'N' | 'P' | 'A' | 'M' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Frame Type | Channel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Sequence Number (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC32C over octets 0-20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + Padding (11 octets, zero) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: 36-octet N-PAMP frame header The fields are: Sammartano Expires 7 December 2026 [Page 6] Internet-Draft N-PAMP June 2026 +========+========+==========+==================================+ | Offset | Size | Field | Description | +========+========+==========+==================================+ | 0-3 | 4 | Magic | ASCII "NPAM" (0x4E 0x50 0x41 | | | octets | | 0x4D). | +--------+--------+----------+----------------------------------+ | 4 | 4 bits | Ver | Protocol major version, the high | | | | | nibble of octet 4. The value | | | | | 0x2 designates the wire format | | | | | described in this document (wire | | | | | major version 2). | +--------+--------+----------+----------------------------------+ | 4 | 4 bits | Flags | The low nibble of octet 4 (see | | | | | Section 4.3). | +--------+--------+----------+----------------------------------+ | 5-6 | 2 | Frame | Frame type within the channel | | | octets | Type | (see Section 4.6). | +--------+--------+----------+----------------------------------+ | 7-8 | 2 | Channel | The semantic channel | | | octets | ID | (Section 5). | +--------+--------+----------+----------------------------------+ | 9-16 | 8 | Sequence | Per-(channel, direction) | | | octets | Number | monotonic sequence number, | | | | | starting at 0. | +--------+--------+----------+----------------------------------+ | 17-20 | 4 | Payload | Byte count of the payload | | | octets | Length | following the header. | +--------+--------+----------+----------------------------------+ | 21-24 | 4 | CRC32C | CRC32C (Castagnoli polynomial | | | octets | | 0x1EDC6F41) computed over header | | | | | octets 0-20. Receivers MUST | | | | | validate it before processing | | | | | any other header field. | +--------+--------+----------+----------------------------------+ | 25-35 | 11 | Reserved | MUST be zero; receivers MUST | | | octets | | reject frames whose reserved | | | | | octets are non-zero. | +--------+--------+----------+----------------------------------+ Table 1: Frame header fields All multi-octet integers are big-endian. The Ver field carries the wire major version; the value 0x02 corresponds to the ALPN identifier "n-pamp/2". Sammartano Expires 7 December 2026 [Page 7] Internet-Draft N-PAMP June 2026 4.3. Frame Flags The low nibble of header octet 4 carries four flag bits: +==========+======+=============================+ | Bit | Name | Meaning | +==========+======+=============================+ | 0 (0x01) | URG | Urgent-priority scheduling. | +----------+------+-----------------------------+ | 1 (0x02) | ENC | Payload is AEAD-encrypted. | +----------+------+-----------------------------+ | 2 (0x04) | COMP | Payload is compressed. | +----------+------+-----------------------------+ | 3 (0x08) | FRAG | Frame is a fragment of a | | | | larger logical message. | +----------+------+-----------------------------+ Table 2: Frame flags 4.4. Extension TLVs Zero or more Type-Length-Value (TLV) extensions MAY accompany a frame. Each TLV is encoded as: +---------+---------+-----------+ | Type | Length | Value | | 16 bits | 16 bits | Length B | +---------+---------+-----------+ Figure 3: Extension TLV encoding Type and Length are 16-bit unsigned integers in network byte order; Length is the byte count of Value (0 to 65535). A receiver that encounters an unknown TLV whose Type has the high bit (0x8000) clear MUST ignore that TLV. A receiver that encounters an unknown TLV whose Type has the high bit (0x8000) set MUST treat it as a forward- incompatible extension and reject the frame. The TLV type registry maintained by this specification is given in Section 9.4. 4.5. Payload Encoding The payload carries a frame-type-specific body. The body MAY be encoded in a binary serialization, in deterministic CBOR [RFC8949], or as raw octets. The selected encoding is signaled within the channel-local interpretation of the Frame Type field. Sammartano Expires 7 December 2026 [Page 8] Internet-Draft N-PAMP June 2026 4.6. Reserved Frame Types Each channel defines its own frame types in the 0x0000-0xFFFF space. The following frame types are reserved across all channels and have the same meaning on every channel: +========+================+============================+ | Type | Name | Description | +========+================+============================+ | 0x0000 | (reserved) | Reserved; MUST NOT be used | | | | as a frame type. | +--------+----------------+----------------------------+ | 0x0001 | PING | Liveness probe. | +--------+----------------+----------------------------+ | 0x0002 | PONG | Reply to PING. | +--------+----------------+----------------------------+ | 0x0003 | CLOSE | Authenticated close; AEAD- | | | | protected. | +--------+----------------+----------------------------+ | 0x0004 | CLOSE_ACK | Reply to CLOSE. | +--------+----------------+----------------------------+ | 0x0005 | ERROR | Error report; AEAD- | | | | protected. | +--------+----------------+----------------------------+ | 0x0006 | KEY_UPDATE | Initiate key update for | | | | this (channel, direction). | +--------+----------------+----------------------------+ | 0x0007 | KEY_UPDATE_ACK | Acknowledge key update. | +--------+----------------+----------------------------+ | 0x0008 | PATH_CHALLENGE | Path-migration challenge. | +--------+----------------+----------------------------+ | 0x0009 | PATH_RESPONSE | Path-migration response. | +--------+----------------+----------------------------+ | 0x000A | FLOW_UPDATE | Connection-level flow- | | | | control credit update. | +--------+----------------+----------------------------+ Table 3: Reserved frame types (all channels) Channel-specific frame types begin at 0x0100 within each channel's frame namespace. Frame-type code points at or above 0x0030 that are not reserved here, and in particular the ranges enumerated in Section 8, are reserved for extensions defined in companion specifications. Sammartano Expires 7 December 2026 [Page 9] Internet-Draft N-PAMP June 2026 4.7. CLOSE Frame A CLOSE frame is authenticated like any other frame. A receiver MUST verify the AEAD tag before honoring a close. An unauthenticated or forged CLOSE frame MUST be dropped and SHOULD be counted as a security event. 5. Channel Architecture N-PAMP multiplexes traffic over channels identified by a 16-bit Channel ID. Each channel carries one class of agent traffic and has an independent per-direction sequence space and independent traffic keys (Section 7). A peer that has not advertised a channel during the handshake MUST NOT receive frames on that channel; frames on an unadvertised channel MUST be dropped. 5.1. Core Channel Registry The following channels are defined and maintained by this specification: +======+===========+=====================+=========+===============+ |ID |Name | Purpose |Min | Direction | | | | |Profile | | +======+===========+=====================+=========+===============+ |0x0000|Control | Connection control, |Standard | Bidirectional | | | | handshake | | | | | | completion, | | | | | | capability epoch | | | +------+-----------+---------------------+---------+---------------+ |0x0001|Memory | Persistent-state |Standard | Multi-stream | | | | create/read/update/ | | | | | | delete and | | | | | | retrieval | | | +------+-----------+---------------------+---------+---------------+ |0x0002|Capability | Capability |Standard | Bidirectional | | | | issuance, | | | | | | delegation, | | | | | | revocation, lookup | | | +------+-----------+---------------------+---------+---------------+ |0x0003|Identity | Identity |Standard | Bidirectional | | | | resolution, | | | | | | attestation, | | | | | | presence | | | +------+-----------+---------------------+---------+---------------+ |0x0004|Governance | Policy proposals, |High | Bidirectional | | | | votes, quorum | | | | | | closure | | | Sammartano Expires 7 December 2026 [Page 10] Internet-Draft N-PAMP June 2026 +------+-----------+---------------------+---------+---------------+ |0x0005|Immune | Anomaly reports and |Standard | Bidirectional | | | | defensive gossip | | | +------+-----------+---------------------+---------+---------------+ |0x0006|Federation | Cross-instance |High | Multi-stream | | | | synchronization and | | | | | | gossip | | | +------+-----------+---------------------+---------+---------------+ |0x0007|Settlement | Agent-to-agent |Standard | Bidirectional | | | | settlement and | | | | | | receipts | | | +------+-----------+---------------------+---------+---------------+ |0x0008|Compliance | Attestation and |High | Bidirectional | | | | regulatory export | | | +------+-----------+---------------------+---------+---------------+ |0x0009|Sensory | Bulk telemetry and |High | Multi-stream | | | | low-priority | | | | | | observations | | | +------+-----------+---------------------+---------+---------------+ |0x000A|Telemetry | Operational metrics |Standard | Bidirectional | | | | and health | | | | | | reporting | | | +------+-----------+---------------------+---------+---------------+ |0x000B|Audit | Audit-epoch |Sovereign| Bidirectional | | | | commitments and | | | | | | transparency-log | | | | | | entries | | | +------+-----------+---------------------+---------+---------------+ |0x000C|Stream | Multiplexed full- |Standard | Multi-stream | | | | duplex streaming | | | | | | (tokens, audio, | | | | | | video, file | | | | | | transfer) | | | +------+-----------+---------------------+---------+---------------+ |0x000D|Bridge | Encapsulation of |Standard | Bidirectional | | | | external agent | | | | | | protocols within | | | | | | N-PAMP frames | | | +------+-----------+---------------------+---------+---------------+ |0x000E|Commerce | Multi-party agentic |Standard | Bidirectional | | | | commerce and | | | | | | payment mandates | | | +------+-----------+---------------------+---------+---------------+ |0x000F|Interaction| Agent-to-human |Standard | Bidirectional | | | | user-interface | | | | | | events | | | +------+-----------+---------------------+---------+---------------+ |0x0010|Discovery | Agent, tool, and |Standard | Bidirectional | Sammartano Expires 7 December 2026 [Page 11] Internet-Draft N-PAMP June 2026 | | | service discovery | | | | | | and capability | | | | | | advertisement | | | +------+-----------+---------------------+---------+---------------+ |0x0011|Workflow | Multi-agent |Standard | Bidirectional | | | | orchestration and | | | | | | task delegation | | | +------+-----------+---------------------+---------+---------------+ |0x0012|Knowledge | Retrieval queries |Standard | Multi-stream | | | | with ranked results | | | | | | and provenance | | | +------+-----------+---------------------+---------+---------------+ |0x0013|Spatial | Physical-world |High | Multi-stream | | | | state for robotics | | | | | | and IoT (high- | | | | | | frequency) | | | +------+-----------+---------------------+---------+---------------+ Table 4: Core channel registry The Min Profile column gives the lowest profile at which a channel may be enabled; a channel is available at that profile and at every higher profile (for example, a "High" channel is available at High and Sovereign). The Audit channel is enabled by default only at Sovereign; other profiles MAY enable it. The Control and Immune channels SHOULD be scheduled at higher priority than bulk channels (Memory, Sensory, Telemetry) during congestion. All N-PAMP channels are full-duplex: each peer maintains an independent send and receive sequence space and independent per- direction traffic keys, so both peers MAY transmit on a channel simultaneously. The Direction column classifies each channel as follows: +===============+====================================+ | Direction | Meaning | +===============+====================================+ | Bidirectional | Both peers send and receive frames | | | on a single stream. | +---------------+------------------------------------+ | Multi-stream | Bidirectional, and the channel MAY | | | open multiple concurrent transport | | | streams within its stream family. | +---------------+------------------------------------+ Table 5: Channel directionality Sammartano Expires 7 December 2026 [Page 12] Internet-Draft N-PAMP June 2026 The Stream channel (0x000C) provides general-purpose multiplexed full-duplex streaming, carrying concurrent bidirectional sub-streams (for example token, audio, video, and file-transfer streams), each with independent flow control. Channel IDs not listed in Section 5.1, and in particular the ranges enumerated in Section 8, are reserved for extensions defined in companion specifications. 6. Profile Negotiation N-PAMP defines three security profiles. The profiles share one wire format and differ in the cryptographic primitives and operational requirements they mandate. Each profile is an escalation of the previous one in cryptographic strength. +===========+======+========================================+ | Profile | Code | Summary | +===========+======+========================================+ | Standard | 0x01 | Baseline hybrid post-quantum security. | +-----------+------+----------------------------------------+ | High | 0x02 | Stronger KEM parameters and stronger | | | | hash; downgrade refusal to Standard. | +-----------+------+----------------------------------------+ | Sovereign | 0x03 | Highest standard-crypto strength; | | | | downgrade refusal below Sovereign. | +-----------+------+----------------------------------------+ Table 6: Security profiles Profile code points 0x00 and 0x04-0xFF are reserved by this specification. The profile is offered by the client and selected by the server during the handshake, and is carried in the handshake transcript. Because the profile is part of the transcript that the Finished MAC covers, an attacker who strips a profile from the offer or forces a lower selection invalidates the MAC and aborts the handshake. The profile invariants are: Sammartano Expires 7 December 2026 [Page 13] Internet-Draft N-PAMP June 2026 +===============+==============+=================+=================+ |Property |Standard | High | Sovereign | +===============+==============+=================+=================+ |Minimum KEM |X25519MLKEM768| X25519MLKEM1024 | X25519MLKEM1024 | +---------------+--------------+-----------------+-----------------+ |Allowed |Ed25519 | Ed25519, ML- | ML-DSA-87 | |signatures | | DSA-87 | | +---------------+--------------+-----------------+-----------------+ |KDF hash |SHA-256 | SHA-384 | SHA-384 | +---------------+--------------+-----------------+-----------------+ |Per-frame AEAD |Off | On | On | |diversification| | | | +---------------+--------------+-----------------+-----------------+ |Downgrade |Off | Refuses | Refuses below | |refusal | | Standard | Sovereign | +---------------+--------------+-----------------+-----------------+ |Mandatory key |Yes | Yes (tighter | Yes (tightest | |update | | bounds) | bounds) | +---------------+--------------+-----------------+-----------------+ Table 7: Profile invariants The server MUST select a profile from the client's offered set. The selected profile MUST be no lower than the server's configured minimum acceptable peer profile. A Sovereign server with a minimum acceptable peer profile of Sovereign completes a handshake only when the client offers Sovereign and Sovereign is selected. A High or Sovereign endpoint MAY interoperate with a lower-profile peer for read-only or capability-discovery operations when local policy permits, by accepting a lower selected profile; otherwise it refuses the downgrade as shown above. 7. Cryptographic Suites All cryptographic primitives used by N-PAMP are published standards. 7.1. Key Encapsulation Mechanisms +============+=================+=================+ | Code point | Name | Profiles | +============+=================+=================+ | 0x11ec | X25519MLKEM768 | Standard, High | +------------+-----------------+-----------------+ | 0x11ed | X25519MLKEM1024 | High, Sovereign | +------------+-----------------+-----------------+ Table 8: KEM code points Sammartano Expires 7 December 2026 [Page 14] Internet-Draft N-PAMP June 2026 Both are hybrid KEMs combining X25519 ECDH with ML-KEM [FIPS203] (ML- KEM-768 and ML-KEM-1024, respectively). The two shared secrets are concatenated as (X25519 shared secret || ML-KEM shared secret) and supplied as input keying material to HKDF-Extract [RFC5869]. The construction follows the established practice for hybrid key establishment [I-D.ietf-tls-hybrid-design]. The Sovereign profile MUST NOT accept X25519MLKEM768. 7.2. Authenticated Encryption +============+===================+=====+=======+=====+ | Code point | Name | Key | Nonce | Tag | +============+===================+=====+=======+=====+ | 0x0001 | AES-256-GCM | 32 | 12 | 16 | +------------+-------------------+-----+-------+-----+ | 0x0002 | ChaCha20-Poly1305 | 32 | 12 | 16 | +------------+-------------------+-----+-------+-----+ Table 9: AEAD code points AES-256-GCM is used as specified for AEAD ciphers in [RFC5116]; ChaCha20-Poly1305 is used as specified in [RFC8439]. Endpoints operating at the High and Sovereign profiles MUST support both AEAD suites because per-frame AEAD diversification at those profiles selects between them. Endpoints operating at the Standard profile MUST support at least one of the two. 7.3. Signatures +============+===========+=============================+===========+ | Code point | Name | Usage | Profiles | +============+===========+=============================+===========+ | 0x0807 | Ed25519 | Identity, capability tokens | All | +------------+-----------+-----------------------------+-----------+ | 0x0905 | ML-DSA-87 | Identity, audit epoch | High, | | | | | Sovereign | +------------+-----------+-----------------------------+-----------+ Table 10: Signature code points Ed25519 is used as specified in [RFC8032]. ML-DSA-87 is the module- lattice-based digital signature algorithm standardized in [FIPS204]. The Sovereign profile uses ML-DSA-87 for identity and audit signatures. Sammartano Expires 7 December 2026 [Page 15] Internet-Draft N-PAMP June 2026 7.4. Key Derivation and Hashing All key derivation uses HKDF [RFC5869]. The KDF hash is SHA-256 at the Standard profile and SHA-384 at the High and Sovereign profiles. The HKDF-Expand-Label construction follows TLS 1.3 [RFC8446], with a protocol-specific label prefix that provides domain separation from TLS 1.3, from QUIC, and from earlier N-PAMP versions. 7.5. Key Schedule and Nonces Traffic secrets are derived per (direction, epoch, AEAD suite, channel) tuple, so that no two distinct contexts share a key. Each traffic secret yields an AEAD key, an AEAD initialization vector, and a header-protection key by HKDF-Expand-Label. The per-frame nonce is the AEAD IV exclusive-ORed with the left-zero-padded sequence number, identical in form to the construction used in TLS 1.3 [RFC8446] and QUIC [RFC9001]. This namespace partitioning prevents cross- direction, cross-suite, and cross-channel nonce reuse, and supports forward secrecy: on key update, traffic secrets for the new epoch are derived afresh and the prior epoch's secrets are zeroized. 7.6. Random Number Generation All randomness that participates in security MUST come from a cryptographically secure random number generator. Implementations MUST NOT use a non-cryptographic source for any field that participates in security. 8. Extension Points N-PAMP reserves code-point ranges for extensions defined in companion specifications. The core protocol in this document neither defines nor requires any extension; it only reserves the ranges below so that extensions can be specified without colliding with the core wire format. The algorithms and semantics that occupy these ranges are out of scope for this document and are defined in companion specifications. 8.1. Reserved Frame-Type Ranges The following per-channel frame-type code points are reserved for extensions defined in companion specifications: Sammartano Expires 7 December 2026 [Page 16] Internet-Draft N-PAMP June 2026 +=================+=============================+ | Range | Reserved for | +=================+=============================+ | 0x0035 - 0x0036 | Memory-channel eviction and | | | revive extension frames | +-----------------+-----------------------------+ | 0x0060 - 0x0063 | Capability-channel token | | | extension frames | +-----------------+-----------------------------+ | 0x0080 - 0x0080 | Control-channel flow- | | | extension frames | +-----------------+-----------------------------+ | 0x0090 - 0x0090 | Audit-channel per-frame | | | integrity-extension frames | +-----------------+-----------------------------+ | 0x00A0 - 0x00A3 | Settlement/Audit batch- | | | commitment extension frames | +-----------------+-----------------------------+ | 0x00B0 - 0x00B4 | Governance-channel quorum | | | extension frames | +-----------------+-----------------------------+ | 0x00C0 - 0x00C4 | Immune-channel propagation | | | extension frames | +-----------------+-----------------------------+ Table 11: Reserved frame-type ranges (companion specifications) 8.2. Reserved TLV Tags The TLV types 0x0010, 0x0013, and 0x0014 are reserved for extension TLVs defined in companion specifications. TLV types in the range 0x8000-0xFFFF remain reserved as forward-incompatible extension points per Section 4. 8.3. Reserved Channel-ID Range Channel IDs in the range 0x0014-0xFFFF are reserved. Channels 0x0014-0x001F are reserved for future core additions by this specification; 0x0020-0xEFFF are reserved for extension channels defined in companion specifications; 0xF000-0xFFFE are GREASE values that receivers MUST ignore; and 0xFFFF MUST NOT appear on the wire. The specific extension assignments are out of scope for this document. No algorithms, parameters, or semantics for any reserved range are defined in this document. Sammartano Expires 7 December 2026 [Page 17] Internet-Draft N-PAMP June 2026 9. IANA Considerations 9.1. ALPN Protocol Identifier This document requests that IANA register the following value in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]: +=================+=============================+===========+ | Protocol | Identification Sequence | Reference | +=================+=============================+===========+ | N-PAMP, wire | 0x6E 0x2D 0x70 0x61 0x6D | (this | | major version 2 | 0x70 0x2F 0x32 ("n-pamp/2") | document) | +-----------------+-----------------------------+-----------+ Table 12: Requested ALPN registration The identification sequence is the 8-octet UTF-8 string "n-pamp/2". The trailing digit "2" equals the N-PAMP wire major version (the value 0x02 carried in the Ver field of the frame header, Section 4). The registration policy for the ALPN registry is Expert Review [RFC8126]. The earlier identifier "n-pamp/1" is deprecated. Implementations SHOULD NOT negotiate "n-pamp/1" for new associations. Future wire major versions will use distinct ALPN identifiers (for example, "n-pamp/3"). 9.2. URI Scheme Registration This document requests provisional registration of the "npamp" URI scheme in the "Uniform Resource Identifier (URI) Schemes" registry, following the template and the provisional-registration procedure (First Come First Served) of [RFC7595]. *Scheme name:* npamp *Status:* Provisional *Applications/protocols that use this scheme:* The protocol defined in this document (N-PAMP). An "npamp" URI names an N-PAMP endpoint and an optional resource path within that endpoint. *URI scheme syntax:* The "npamp" scheme uses the generic URI syntax of [RFC3986]: npamp-URI = "npamp://" authority path-abempty [ "?" query ] Sammartano Expires 7 December 2026 [Page 18] Internet-Draft N-PAMP June 2026 where "authority", "path-abempty", and "query" are as defined in [RFC3986]. The "authority" component identifies the N-PAMP endpoint (host and optional port). N-PAMP does not reserve a fixed default port; the underlying transport is negotiated as described in Section 3. *Encoding considerations:* "npamp" URIs are processed as defined in [RFC3986]; non-ASCII characters in the path or query components are percent-encoded UTF-8 octets. *Interoperability considerations:* None beyond those of [RFC3986]. The scheme carries no protocol semantics of its own; all behavior is defined by N-PAMP. *Security considerations:* See Section 10. An "npamp" URI is only an identifier. Connecting to an "npamp" endpoint invokes the N-PAMP handshake and its authentication, confidentiality, and downgrade protections; dereferencing an "npamp" URI MUST NOT bypass the security profile negotiated by N-PAMP. *Contact:* Shawn Sammartano, BubbleFish Technologies, Inc. *Change controller:* Shawn Sammartano, BubbleFish Technologies, Inc. *Reference:* This document. 9.3. Registries Maintained by This Specification The N-PAMP channel registry (Section 5.1), the frame-type registry (Section 4.6), and the TLV type registry (Section 9.4) are defined and maintained within this specification. Because this document is published through the Independent Submission stream, it does not request the creation of new IANA-hosted registries for these code points; the registries are normative within this document and are extended by companion specifications and by future revisions of this document, not by IANA registration actions. 9.4. TLV Type Registry The following TLV tags are defined by this specification. Tags marked "reserved" are described in Section 8. +===============+=================+========+======================+ | Tag | Name | Length | Description | +===============+=================+========+======================+ | 0x01 | ProfileOffer | 4 | Profiles offered by | | | | | the client | | | | | (handshake only). | Sammartano Expires 7 December 2026 [Page 19] Internet-Draft N-PAMP June 2026 +---------------+-----------------+--------+----------------------+ | 0x02 | ProfileSelect | 1 | Profile selected by | | | | | the server | | | | | (handshake only). | +---------------+-----------------+--------+----------------------+ | 0x03 | KEMOffer | var | KEMs offered by the | | | | | client. | +---------------+-----------------+--------+----------------------+ | 0x04 | KEMSelect | 2 | KEM selected by the | | | | | server. | +---------------+-----------------+--------+----------------------+ | 0x05 | SigOffer | var | Signature algorithms | | | | | offered. | +---------------+-----------------+--------+----------------------+ | 0x06 | SigSelect | 2 | Signature algorithm | | | | | selected. | +---------------+-----------------+--------+----------------------+ | 0x07 | KEMShare | var | Public KEM share. | +---------------+-----------------+--------+----------------------+ | 0x08 | KEMCiphertext | var | KEM encapsulation | | | | | ciphertext. | +---------------+-----------------+--------+----------------------+ | 0x10 | (reserved) | var | Reserved for a | | | | | companion | | | | | specification. | +---------------+-----------------+--------+----------------------+ | 0x12 | AnomalyCharge | 32 | Per-frame integrity | | | | | charge. | +---------------+-----------------+--------+----------------------+ | 0x13 | (reserved) | var | Reserved for a | | | | | companion | | | | | specification. | +---------------+-----------------+--------+----------------------+ | 0x14 | (reserved) | 32 | Reserved for a | | | | | companion | | | | | specification | | | | | (handshake only). | +---------------+-----------------+--------+----------------------+ | 0x15 | PathChallenge | 32 | Path-migration | | | | | challenge nonce. | +---------------+-----------------+--------+----------------------+ | 0x16 | PathResponse | 64 | Path-migration | | | | | response. | +---------------+-----------------+--------+----------------------+ | 0x17 | KeyUpdateMarker | 8 | Key-update epoch | | | | | marker. | +---------------+-----------------+--------+----------------------+ | 0x18 | ProtectionMode | 1 | Protection-mode | Sammartano Expires 7 December 2026 [Page 20] Internet-Draft N-PAMP June 2026 | | | | selector. | +---------------+-----------------+--------+----------------------+ | 0x8000-0xFFFF | (reserved) | -- | Forward-incompatible | | | | | extension points | | | | | (Type high bit set). | +---------------+-----------------+--------+----------------------+ Table 13: TLV type registry 10. Security Considerations This section follows the spirit of [RFC3552]. N-PAMP inherits the security properties of its underlying transports, TLS 1.3 [RFC8446] and QUIC [RFC9001], and adds the considerations below. 10.1. Hybrid Key Establishment Every profile uses a hybrid KEM that concatenates an X25519 shared secret with an ML-KEM shared secret [FIPS203] before key derivation. The confidentiality of an association is preserved as long as at least one of the two components remains unbroken; an adversary must defeat both the classical and the post-quantum component to recover traffic keys. N-PAMP makes no claim of unconditional or "quantum- proof" security; it provides post-quantum hybrid security against the adversaries addressed by its component primitives. 10.2. Downgrade, Unknown-Key-Share, and Identity Substitution The negotiated profile, KEM, signature algorithm, AEAD suite(s), and both peer identities are bound into the handshake transcript and confirmed by the Finished MAC (Section 3, Section 6). Altering any negotiated parameter, stripping a profile from the offer, or substituting a peer identity invalidates the Finished MAC and aborts the handshake. The High and Sovereign profiles additionally refuse to complete at a profile below their configured minimum. 10.3. Authenticated Encryption and Nonce Management All payloads are protected by AEAD [RFC5116]. Traffic keys are partitioned per (direction, epoch, suite, channel), which structurally prevents nonce reuse across directions, AEAD suites, and channels. AEAD tag verification MUST be performed before any payload is processed, and equality comparisons of authentication values MUST be constant-time to avoid timing side channels. Sammartano Expires 7 December 2026 [Page 21] Internet-Draft N-PAMP June 2026 10.4. Replay Each (channel, direction) pair maintains a sliding replay window over sequence numbers. Frames outside the window or already recorded within it MUST be rejected. Where 0-RTT data is permitted, it MUST be limited to idempotent operations and protected against replay by an anti-replay mechanism scoped to the current epoch; the Sovereign profile disables 0-RTT entirely. 10.5. Forward Secrecy and Key Update Endpoints MUST perform key updates within profile-specific bounds on elapsed time, frames sent, and bytes protected, with the tightest bounds at the Sovereign profile. On key update, the prior epoch's traffic secrets MUST be zeroized so that compromise of the current epoch does not expose previously protected traffic. Rotation of the master secret requires a fresh handshake. 10.6. Connection Migration When carried over QUIC, an endpoint MUST validate a peer's new path with a challenge-response exchange (PATH_CHALLENGE / PATH_RESPONSE) before accepting an address change, to prevent off-path migration spoofing. 10.7. Authenticated Close CLOSE frames are AEAD-protected and MUST be verified before being honored, so that an off-path attacker cannot tear down an association with a forged CLOSE. 10.8. Extension Points The reserved code-point ranges in Section 8 carry no algorithms or semantics in this document. Any security properties of extensions occupying those ranges are the responsibility of the companion specifications that define them and are out of scope here. 10.9. Implementation Considerations Where the wire format requires deterministic encoding (for example, deterministic CBOR [RFC8949] or canonical integer encodings), implementations MUST produce byte-identical output for identical inputs, because non-deterministic encodings can invalidate transcript and integrity computations across peers. 11. References Sammartano Expires 7 December 2026 [Page 22] Internet-Draft N-PAMP June 2026 11.1. Normative References [FIPS203] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, 2024. [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS 204, 2024. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Sammartano Expires 7 December 2026 [Page 23] Internet-Draft N-PAMP June 2026 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . 11.2. Informative References [I-D.ietf-tls-hybrid-design] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-16, 7 September 2025, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Acknowledgments The author thanks the reviewers of earlier N-PAMP drafts for their feedback. Author's Address Sammartano Expires 7 December 2026 [Page 24] Internet-Draft N-PAMP June 2026 Shawn Sammartano BubbleFish Technologies, Inc. Email: npamp-editor@bubblefish.sh Sammartano Expires 7 December 2026 [Page 25]