| |
|
| |
| | Privacy Pass with Token Binding Extension |
| |
|
This document provides a token binding extension for the Privacy Pass protocol. This extension allows a Client to cryptographically bind a Privacy Pass token to its own generated one-time public key during the issuance flow, without exposing the public key to the Issuer. Later, when spending the token during the redemption flow, the Client must use the corresponding private key to generate a binding proof that the Origin needs to additionally verify except the token itself, where the proof generation can optionally support channel binding. This proof constrains the legitimate presenter of the token to be only the Client who holds the private key and further constrains the legitimate usage of the token to be only the Client's specific channel when channel binding is used in the proof generation, and thus can prevent token export and replay attacks. In addition, the token binding extension does not introduce additional cryptographic primitives, and only uses the primitives currently utilized in the issuance protocol to generate the one-time public-private keypair as well as generate and verify the binding proof. |
| | Private Network-to-Network Interface (PNNI) Signaling in Asynchronous Transfer Mode (ATM) Networks |
| |
|
This document describes the Private Network-to-Network Interface (PNNI) signaling procedures used in Asynchronous Transfer Mode (ATM) networks. PNNI is a hierarchical link-state routing protocol that enables topology discovery, dynamic routing, and call establishment across ATM networks. This document outlines the signaling model, hierarchical routing structures, call setup procedures, and interoperability considerations for both modern and legacy ATM network implementations. |
| |
|
| |
| | Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS) |
| |
|
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024, as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535, identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet’s operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Building on RFC 3535, this document provides the report of the follow-up IAB workshop on Network Management. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
| | Current Process for Handling RFC Errata Reports |
| |
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. |
| | Commercial National Security Algorithm Suite Certificate and Certificate Revocation List Profile |
| |
|
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. |
| | Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3 |
| |
|
This document defines a base profile of TLS 1.3 for use 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 Profile for SSH |
| |
|
This document defines a base profile of SSH for use 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 SSH. It is also appropriate for all other U.S. 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 Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
This document defines a base profile of S/MIME for use 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 S/MIME. 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 Profile of 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. |
| | TLS Key Share Prediction |
| |
|
This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips. |
| |
|
| |
| | Application of the Alternate Marking Method to the Segment Routing Header |
| |
| | draft-fz-spring-srv6-alt-mark-17.txt |
| | Date: |
27/08/2025 |
| | Authors: |
Giuseppe Fioccola, Tianran Zhou, Gyan Mishra, xuewei wang, Geng Zhang, Mauro Cociglio |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an alternative experimental approach for the application of the Alternate-Marking Method to SRv6. It uses an experimental TLV in the Segment Routing Header, and thus participation in this experiment should be between coordinating parties in a controlled domain. This approach has potential scaling and simplification benefits over the technique described in RFC 9343 and the scope of the experiment is to determine whether those are significant and attractive to the community. This protocol extension has been developed outside the IETF as an alternative to the IETF's standards track specification RFC 9343 and it does not have IETF consensus. It is published here to guide experimental implementation, ensure interoperability among implementations to better determine the value of this approach. Researchers are invited to submit their evaluations of this work to the RFC Editor for consideration as independent submissions or to the IETF SPRING working group as Internet-Drafts. |
| | Mutually Authenticating TLS in the context of Federations |
| |
| | draft-halen-fedae-03.txt |
| | Date: |
27/08/2025 |
| | Authors: |
Stefan Halen, Jakob Schlyter |
| | Working Group: |
Individual Submissions (none) |
|
This informational independent submission to the RFC series describes a means to use TLS 1.3 to perform machine-to-machine mutual authentication within federations. This memo is not a standard. It does not modify the TLS protocol in any way, nor does it require changes to common TLS libraries. TLS is specified and standardized by the IETF's TLS working group. The framework enables interoperable trust management for federated machine-to-machine communication. It introduces a centrally managed trust anchor and a controlled metadata publication process, ensuring that only authorized members are identifiable within the federation. These mechanisms support unambiguous entity identification and reduce the risk of impersonation, promoting secure and policy-aligned interaction across organizational boundaries. |
| | Reverse Change-of-Authorization (CoA) in RADIUS/(D)TLS |
| |
|
This document defines a "reverse Change-of-Authorization (CoA)" path for RADIUS packets. A TLS connection is normally used to forward request packets from a client to a server and to send responses from the server to the client. This specification allows a server to send CoA request packets to the client in "reverse" down that connection, and for the client to send responses to the server. Without this capability, it is in general impossible for a server to send CoA packets to a Network Access Server (NAS) that is located behind a firewall or NAT. This reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. This document updates RFC8559. |
| |
|
| |
| | Prioritizing known-local IPv6 ULAs through address selection policy |
| |
|
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It introduces a requirement to implement Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. |
| | ALPN ID Specification for CoAP over DTLS |
| |
| | draft-ietf-core-coap-dtls-alpn-05.txt |
| | Date: |
11/08/2025 |
| | Authors: |
Martine Lenders, Christian Amsuess, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Constrained RESTful Environments (core) |
|
This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services. |