| |
|
| |
| | SNAC Router Flag in ICMPv6 Router Advertisement Messages |
| |
|
This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by infrastructure routers. This flag is used only by SNAC routers and is ignored by all other devices. |
| | A Framework for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-ietf-cats-framework-24.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Cheng Li, Zongpeng Du, Mohamed Boucadair, Luis Contreras, John Drake |
| | Working Group: |
Computing-Aware Traffic Steering (cats) |
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. |
| | Mobility-aware Transport Network Slicing for 5G |
| |
| | draft-ietf-dmm-tn-aware-mobility-25.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | Downgrade Prevention for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that prevents particular downgrade attacks on this protocol by having the peers confirm they have participated in the same conversation. This document updates RFC 7296. |
| | Post-Stack MPLS Network Action (MNA) Header Specification |
| |
| | draft-ietf-mpls-mna-ps-hdr-08.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Jie Dong, Jisu Bhattacharya |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document defines the Post-Stack MPLS Network Action (MNA) Header Specification for carrying Network Actions encodings and Ancillary Data after the MPLS label stack, based on the In-Stack MNA Specification defined in "MPLS Network Action (MNA) Sub-Stack Specification." MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user- defined operations. This document follows the framework specified in RFC 9789. |
| | YANG module file name convention |
| |
|
This document presents YANG module file name convention. The convention extends the current YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This documents updates RFCs 6020, 7950, and draft-ietf-netmod-rfc8407bis. |
| | SCION Control Plane |
| |
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The SCION Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths by combining path segments obtained through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | SCION Data Plane |
| |
|
This document describes the Data Plane of SCION (Scalability, Control, and Isolation On Next-generation networks), a path-aware, inter-domain network architecture. Unlike IP-based forwarding, SCION embeds inter-domain forwarding directives in the packet header, enabling endpoints to construct and select end-to-end paths from segments discovered by the Control Plane. The role of the Data Plane is to combine such segments into end-to-end paths, and to forward data according to the specified path. This document describes the SCION packet format, header structure, and extension headers. It also describes the cryptographic mechanisms used for path authorization, processing at routers including a life of a packet example. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists |
| |
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8603], the CNSA 1.0 guidance. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 which is compliant with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ TLS 1.3. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificate Management over CMS |
| |
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available here for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8756], the CNSA 1.0 guidance. |
| | A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators |
| |
|
This document codifies a consistent and reversible convention used in the threat intelligence and security communities for sharing potentially malicious indicators of compromise (IOCs), such as URLs, IP addresses, email addresses, and domain names. It describes a safe obfuscation format that reduces the risk of accidental execution or activation when IOCs are displayed or transmitted. The recommended form brackets the URI scheme name (for example, [http]) so that the string is not syntactically a valid URI per generic URI parsers; legacy scheme-substitution tokens are defined for de-obfuscation interoperability. These conventions aim to improve interoperability among tools and feeds that exchange threat intelligence data. |
| | Deployment and Use of the Domain Name System(DNS) in Deep Space |
| |
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. |
| | MANET Internetworking: Problem Statement and Gap Analysis |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. |
| | The Rewind Subscription Filter |
| |
|
This document proposes a Media Over Quic Transport (MOQT) extension that enables a new Subscription Filter, so that a subscriber can request that a finite number of past groups be delivered with SUBSCRIBE semantics (multiple streams, potentially incomplete) rather than FETCH semantics (single stream, complete, head-of-line- blocking). Service of this request is best-effort by the publisher, and it intended to accelerate joining a track in some use cases. |
| | TLS-Session-Bound Access Tokens for OAuth 2.0 |
| |
|
This document defines a mechanism for binding OAuth 2.0 access tokens to a specific mutual TLS (mTLS) connection. The binding is achieved through a proof token that incorporates the TLS Exporter value [RFC5705] derived from the current connection and an access token hash, signed by the client's private key corresponding to its mTLS certificate. This mechanism prevents stolen bearer tokens from being replayed on a different TLS connection. The proof is constructed once per (token, connection) pair and reused across all requests on that connection, delivering session binding with no per-request signing overhead and no additional key management beyond what mTLS already provides. The mechanism is applicable to TLS 1.2, TLS 1.3, and QUIC transports. While applicable to any OAuth 2.0 access token presented over mTLS, this specification is primarily motivated by the Token Exchange protocol [RFC8693], where multi-hop delegation chains in autonomous, agent-driven architectures create elevated replay risk. |
| | A Layman's Guide to a Subset of ASN.1,BER,and DER |
| |
|
This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The particular purpose of this note is to provide background material sufficient for understanding and implementing the RSA Data Security, Inc. Public Key Cryptography Standards (PKCS) family of standards. This document represents a republication of A Layman's Guide to a Subset of ASN.1, BER, and DER, originally authored and published by RSA Security USA LLC. This document is submitted with permission from, and on behalf of RSA Security USA LLC. By publishing this document, change control is transferred to the IETF and the Internet technical community in full conformance with the provisions of BCP 78 and BCP 79. |
| | Open Mesh Protocol (OMP): A Multi-Radio Proximity Mesh Networking Architecture and Problem Statement |
| |
|
This document describes the Open Mesh Protocol (OMP), a proposed open standard for device-native proximity mesh networking spanning multiple radio technologies simultaneously. Existing proximity wireless mesh standards -- including Wi-Fi Aware (NAN), Bluetooth Mesh, and Thread -- each operate over a single radio technology and serve specific application domains. No existing open standard provides a unified multi-radio mesh routing protocol spanning BLE, WiFi Direct, and LoRa with per-device cryptographic identity independent of any central registry or carrier relationship. This document describes the OMP architecture, specific technical implementations, and the gap in the current standards landscape that OMP addresses. It is submitted as an Informational Internet-Draft to establish a public prior art record and to invite community discussion on whether a new working group or individual submission track is appropriate for this work. |
| | AAuth Protocol |
| |
|
This document defines the AAuth authorization protocol, in which agents obtain proof-of-possession tokens from auth servers to access resources on behalf of users and organizations. It specifies three token types (agent, resource, and auth), a unified token endpoint with deferred response support, and cross-domain federation between auth servers. It builds on the AAuth Headers specification ([I-D.hardt-aauth-headers]), which defines the AAuth-Requirement response header and HTTP Message Signatures profile. |
| | HTTP AAuth Headers |
| |
|
This document defines two HTTP response headers — AAuth-Requirement and AAuth-Error — and profiles HTTP Message Signatures ([RFC9421]) for request authentication, with keying material conveyed via the Signature-Key header ([I-D.hardt-httpbis-signature-key]). A server uses AAuth-Requirement to require pseudonymous or verified agent identity, to request user interaction, or to signal that approval is pending. AAuth-Error conveys structured error information. Both headers use extensible registries for their values. |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS |
| |
|
This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. This protocol satisfies all of the criteria listed in draft-ietf-pim-zeroconf- mcast-addr-alloc-ps. |
| | Reference Interaction Models for Remote Attestation Procedures |
| |
|
This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. |
| | CCF Profile for COSE Receipts |
| |
|
This document defines a new verifiable data structure (VDS) type for COSE Receipts and inclusion proof specifically designed for append- only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. |
| | Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors |
| |
|
A Trust Anchor (TA) in the RPKI is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document proposes a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-mpls-01.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR-MPLS networks using the Simple Two- Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedures are used for SR-MPLS paths (including Segment Lists of SR-MPLS Policies, SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SR-MPLS paths. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-srv6-01.txt |
| | Date: |
02/04/2026 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement for SRv6 using the Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedures are used for links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths. |
| |
|
| |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by NIST. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | OAuth Profile for Open Public Clients |
| |
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | NETCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| | Adding an Uncacheable File Data Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients commonly perform client-side caching of file data in order to improve performance. On some systems, applications may influence client data caching behavior, but there is no standardized mechanism for a server or administrator to indicate that particular file data should not be cached by clients for reasons of performance or correctness. This document introduces a new file data caching attribute for NFSv4.2. Files marked with this attribute are intended to be accessed with client-side caching of file data suppressed, in order to support workloads that require predictable data visibility. This document extends NFSv4.2 (see RFC7862). |
| | The Network File System Access Control List Protocol |
| |
|
This Informational document describes the NFS_ACL protocol. NFS_ACL is a legacy member of the Network File System family of protocols that NFS clients use to view and update Access Control Lists stored on an NFS version 2 or version 3 server. |
| | Automated Certificate Management Environment (ACME) Extension for Public Key Challenges |
| |
|
The current ACME protocol [RFC8555] requires applicants to submit a PKCS#10 Certificate Signing Request (CSR) during the finalization phase. The construction, ASN.1 encoding, and transmission of the CSR impose additional implementation burdens on both the client (especially resource-constrained devices) and the server. Moreover, the CSR cannot prevent a public key from being replaced by an intermediary at the protocol level. This document introduces the "pk-01" challenge extension based on the ACME protocol. Its core mechanism is as follows: the applicant declares the public key to be authenticated during the "newOrder" phase and completes the Proof of Possession (PoP) by signing with the private key during the challenge phase. Since the public key is declared when the order is created and verified during the challenge phase, there is no need to submit a CSR during the finalization phase; the ACME server can issue the certificate directly based on the verified public key, thereby eliminating the CSR at the protocol level. The "pk-01" challenge supports two verification modes via the pop_mode field: |
| | Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and Requirements |
| |
|
This document describes use cases and requirements for VESPER (Verifiable STI Presentation and Evidence for RTU), an extension to the Secure Telephone Identity Revisited (STIR) framework. VESPER defines a delegate certificate profile that binds telephone number authority, entity identity, and originating provider authorization into a single verifiable trust artifact, grounded in Right-to-Use (RTU) validation and recorded in a public transparency log. The document identifies the trust gaps that motivate this work and describes requirements for verifiable origination authorization. |
| | Hybrid Post-Quantum Password Authenticated Key Exchange |
| |
| | draft-vos-cfrg-pqpake-01.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Jelle Vos, Stanislaw Jarecki, Christopher Wood |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the CPaceOQUAKE+ protocol, a hybrid asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is the result of a KEM-based transformation from the hybrid symmetric PAKE protocol called CPaceOQUAKE that is also described in this document. This document recommends configurations for CPaceOQUAKE+. |
| | VESPER Out-of-Band OOB |
| |
|
This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework in environments where SIP signaling is unavailable or unsuitable. By supporting an out-of-band (OOB) transport model, this approach enables entities to publish and retrieve signed PASSporT assertions independent of end-to-end delivery within SIP-based VoIP networks. These PASSporTs are signed with delegate certificates that were authorized for issuance by corresponding authority tokens, which represent the trust and validation of telephone number control and related claim information. Transparency features ensure that these authorizations are publicly auditable and cryptographically provable, supporting a higher standard of trust. This document also introduces support for Connected Identity to the STIR OOB model, enabling the called party to respond with a signed PASSporT asserting its identity, thereby binding the identities of both parties to the transaction and enhancing end-to-end accountability. The OOB mechanism serves as an alternative delivery path for PASSporTs in cases where end-to-end in-band SIP delivery is not possible, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. |
| | Quantum Datagram Control Protocol (QDCP) for IP Optical Environments |
| |
| | draft-zhu-qirg-qdcp-01.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Alan Zhu, Yichi Zhang, Robert Broberg, Liang Feng, Jonathan Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Quantum Datagram protocol a lightweight transport protocol designed to operate over UDP in IP optical environments. QDCP (formerly QFCP) enables the transmission of control- plane parameters required for transporting quantum information and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility and is prototyped for the transport of third-order nonlinear generated quantum information on IP optical infrastructure. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. |
| | Update to Recognize the IETF IPMC as the IETF Trust Successor |
| |
|
This document updates IETF documents that reference the IETF Trust to include the Trust's successor, the IETF Intellectual Property Management Corporation. Discussion of this draft is on the ipr-wg@ietf.org mailing list. |
| | Use Cases for Authentication of Web Bots |
| |
|
This draft outlines use cases for authentication for bot clients on the Web, to help inform discussions regarding the scope and intent of the WebBotAuth Working Group. |
| | Ogg Stem Files |
| |
|
This document defines a multi-track profile of the Ogg container format for storing for storing stems for use by DJ applications while remaining backwards compatible with existing media players. |
| | EDNS options for filtering information |
| |
|
This memo documents EDNS options, EDNS Extended DNS Errors INFO-CODE values, and methods that can be used to return information about filtered, blocked, or censored DNS responses. It complements the information provided in EDNS Extended DNS Error options [RFC8914]. |
| | Additional Security Algorithms For Use With TCP-AO |
| |
|
RFC5926 specifies cryptographic algorithms for TCP-AO. It explains how to use KDF_HMAC_SHA1 and KDF_AES_128_CMAC as KDFs. It also explains how to use HMAC-SHA-1-96 and AES-128-CMAC-96 as MAC algorithms. This document specifies several new KDFs and MAC algorithms for TCP- AO. The KDFs and MAC algorithms specified in this document use stronger cryptography. |
| | The Emerging Application of AI in IETF Specifications |
| |
|
Over recent years we have seen the emergence of Artificial Intelligence (AI) systems as tools that can contribute to the specification, implementation, and operation of Internet technologies. This document examines the potential for making increased use of Machine Learning (ML) in the scope of the IETF. |
| | Problem Statement for Human-Anchored Agent Identity,Delegation,and Provenance |
| |
|
Software agents now act on behalf of people across communication, automation, and decision-making contexts. These agents increasingly initiate actions, delegate tasks, and interact with other agents without a clear, durable, or verifiable connection to the human who authorized them. Existing identity systems authenticate software, but they do not provide a model for human anchoring, scoped delegation, or provenance across agent ecosystems. This document describes the problem space for human-anchored agent identity. It outlines the gaps in current identity mechanisms, the risks created by uncontrolled replication and impersonation, and the need for a consistent architectural model that preserves human authority, supports explicit delegation, and maintains verifiable provenance across contexts. This document does not define a protocol. It defines the problem that an architectural model must address in order to support safe, accountable, and interoperable agent ecosystems. |
| | Architecture for Human-Anchored Agent Identity,Delegation,and Provenance |
| |
|
Software agents increasingly act on behalf of people across communication, automation, and decision-making contexts. These agents initiate actions, delegate tasks, and interact with other agents without a consistent model for representing the human who authorized them, the scope of authority they possess, or the provenance of their actions across ecosystems. This document defines an architectural model for human-anchored agent identity. The model introduces a human identity root, explicit delegation semantics, and a provenance structure that enables ecosystems to determine whether an agent is legitimate, whether it is acting within its intended authority, and how its actions relate to a responsible human. This document does not define a protocol or wire format. It provides an architectural foundation that existing systems may bind to in order to support accountable, interoperable, and human-aligned agent ecosystems. |
| | Agentic Identity and Provenance over Avian Carriers (AIPAC) |
| |
|
This document specifies a method for establishing cryptographic identity and provenance attestation for agentic AI systems operating over Avian Carriers (AC). As large language models increasingly delegate sub-tasks to other models via pigeon, questions of authorship, intent, and hallucination propagation across feather- based transport layers demand urgent standardization. This document extends the delegation chain model and provenance structure of draft-beyer-agent-identity-architecture-00 to the specific constraints of feather-based transport layers, and extends RFC 1149, RFC 2549, and RFC 6214 to address agent identity. It is an April 1 publication. |
| | Domain-based Integrity Verification Enforcement (DIVE) Version 0.1 |
| |
|
Domain-based Integrity Verification Enforcement (DIVE) version 0.1 is an application-layer protocol that provides cryptographic integrity and authenticity verification of web resources by leveraging the Domain Name System Security Extensions (DNSSEC) as an independent verification channel. DIVE operates as an additional security layer above HTTP and HTTPS. Public keys and policy configuration are published as DNS TXT records protected by DNSSEC, while HTTP response headers carry per-resource cryptographic signatures. A client implementing DIVE verifies each covered resource against the corresponding DNS-published public key before accepting it. An attacker must therefore compromise both the DNS infrastructure and the origin server simultaneously in order to deliver a tampered resource to a DIVE-compliant client. This document defines the DNS record format, the HTTP header format, the client verification algorithm, the reporting mechanism, and the operational recommendations for the DIVE 0.1 protocol. |
| | Text Encoded Base 64 Numbers (Ten64) |
| |
|
Ten64 is a positional numeral system for representing numeric values with an alphabet of 64 characters (aka. radix/base 64). However, unlike most positional number systems, the characters are written in ascending (aka. big-endian, network-order) and NOT descending order. The main differences are the use of sextets (six bits) instead of octets (aka. bytes). Similar to hexadecimal, Ten64 can be used to create binary strings of arbitrary length. Ten64 can encode one or more Modern Western Numbers (aka. Arabic, Vedic), interpreting the characters respective composite big-endian binary as a one or more Modern Western Numbers. The motivation for Ten64 is to encode numbers in a compact and human- readable format similar to Base58. However, Ten64 is designed to be optimized for use with numbers commonly used in identifiers, such as DIDs, DOIDs, IANA OIDs, UUIDs, dates, time(stamp)s, points, and more. Unlike Base58, and more like hexadecimal Ten64 aligns the Modern Western Numerals with the respective big-ending binary (i.e.; 0 → 0, 1 → 1, 2 → 11, etc). Finally, Ten64 provides a disk-based number encoding system for huge numbers and number streams. |
| | vCon Extension for Morse Code Dialog Encoding |
| |
|
This document defines a vCon extension for representing Morse code conversations within the Virtualized Conversation (vCon) container format. Morse code remains an actively used communication medium among amateur radio operators, in historical preservation contexts, and in cultural works. The extension provides standardized encoding for Morse code dialog, including keying timing data, prosign representation, and the Farnsworth timing method. This document also addresses information-theoretic considerations of Morse code's variable-length encoding, its relationship to modern source coding theory, and the privacy implications of preserving historically significant Morse code conversations whose data subjects may be deceased. |
| | Monotonic Attestation Service (MAS) |
| |
|
This document defines the Monotonic Attestation Service (MAS), a protocol for issuing cryptographically attested, monotonically increasing sequence numbers within named namespaces. Each attestation includes a hash chain linking it to all prior entries in the namespace, providing verifiable proof of ordering and completeness. MAS is designed to complement RFC 3161 Trusted Timestamping: where RFC 3161 proves when an event occurred, MAS proves in what order and that the sequence is complete. |
| | UTF-8 Internet Protocol Addresses |
| |
|
This memo describes an alternate entry and display format for IPv6 addresses using UTF-8 instead of hextets. A mixed representation for traditional IPv6 address prefixes also is explored, along with means of transitioning between the two within an IPv6 address. Additionally, an address extension is proposed to accommodate the inevitable need for longer addresses. Finally, security implications of special UTF-8 glyphs are considered. |
| | Signed Email Authentication Layer (SEAL) |
| |
|
This document defines the Signed Email Authentication Layer (SEAL), a cryptographically signed identity envelope carried within a new message header field, SEAL-Envelope. SEAL provides a stable, forwarding-resilient identity assertion that is independent of the mutable RFC 5322 header block and message body. SEAL is designed to complement or replace DKIM and ARC by eliminating their dependency on mutable message components and by providing a canonical, tamper- evident identity layer that survives transit through intermediaries. |
| | Security Considerations for Intent-Based Requests in Agentic Systems |
| |
|
Intent-based requests enable users, applications, and agents to express goals and constraints without specifying step-by-step procedures. Such intents are commonly translated into executable directives and propagated across multiple entities (clients, agents, authorization components, orchestration functions, and execution endpoints). This multi-hop processing expands the attack surface for tampering, privilege escalation, constraint bypass, and intent drift. This document provides a solution-agnostic security analysis for intent-based requests across agentic systems. It introduces a reference model and scenarios to guide protocol and system design, and also presents threats and requirements. The document emphasizes constraint validation, invocation validation, multi-hop chain-of- custody, and policy-driven responses to drift, while remaining independent of any specific deployment domain. |
| | A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control |
| |
| | draft-ietf-opsawg-ucl-acl-15.txt |
| | Date: |
01/04/2026 |
| | Authors: |
Qiufang Ma, Qin WU, Mohamed Boucadair, Daniel King |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity. This YANG data model extends Access Control Lists (ACLs) with date and time parameters to support schedule-aware policy enforcement. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of packet header fields to enforce policy-based network access control. Moreover, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information |
| |
|
A Segment Routing (SR) Policy Candidate Path can contain multiple Segment Lists, allowing for load-balancing and protection across diverse paths. However, current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. This document defines PCEP extensions to encode multiple Segment Lists within an SR Policy Candidate Path, enabling multipath capabilities such as weighted or equal-cost load-balancing across Segment Lists. The extensions are designed to be generic and reusable for future path types beyond SR Policy, and are applicable to both stateless and stateful PCEP. |
| | Adapting Constrained Devices for Post-Quantum Cryptography |
| |
|
This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. |
| | QMux |
| |
|
This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. |