rfc9932v3.txt   rfc9932.txt 
Independent Submission S. Halén Independent Submission S. Halén
Request for Comments: 9932 The Swedish Internet Foundation Request for Comments: 9932 The Swedish Internet Foundation
Category: Informational J. Schlyter Category: Informational J. Schlyter
ISSN: 2070-1721 Kirei AB ISSN: 2070-1721 Kirei AB
February 2026 April 2026
Mutually Authenticating TLS in the Context of Federations Mutually Authenticating TLS in the Context of Federations
Abstract Abstract
This Informational Independent Submission to the RFC Series describes This Informational Independent Submission to the RFC Series describes
a means to use TLS 1.3 to perform machine-to-machine mutual a means to use TLS 1.3 to perform machine-to-machine mutual
authentication within federations. This memo is not a standard. It authentication within federations. This memo is not a standard. It
does not modify the TLS protocol in any way, nor does it require does not modify the TLS protocol in any way, nor does it require
changes to common TLS libraries. TLS is specified and standardized changes to common TLS libraries. TLS is specified and standardized
skipping to change at line 196 skipping to change at line 196
2. Diverse Design Patterns 2. Diverse Design Patterns
MATF is designed to be flexible and adaptable to the varying needs of MATF is designed to be flexible and adaptable to the varying needs of
different federations. Federations can differ significantly in terms different federations. Federations can differ significantly in terms
of size, scope, and security requirements, which makes it challenging of size, scope, and security requirements, which makes it challenging
to prescribe a one-size-fits-all trust framework and security to prescribe a one-size-fits-all trust framework and security
measures. measures.
For instance, in the European Union, Regulation (EU) No 910/2014 (the For instance, in the European Union, Regulation (EU) No 910/2014 (the
electronic identification, authentication, and trust services (eIDAS) electronic identification, authentication, and trust services (eIDAS)
Regulation [eIDAS]) establishes a regulatory framework for electronic Regulation) [eIDAS] establishes a regulatory framework for electronic
identification and trust services for electronic transactions in the identification and trust services for electronic transactions in the
internal market. The eIDAS Regulation provides a basis for cross- internal market. The eIDAS Regulation provides a basis for cross-
border recognition of notified electronic identification schemes and border recognition of notified electronic identification schemes and
for regulated trust services. for regulated trust services.
Similarly, national federations, such as those found in education or Similarly, national federations, such as those found in education or
healthcare sectors, often have their own specific trust frameworks healthcare sectors, often have their own specific trust frameworks
and security measures tailored to their unique needs. These and security measures tailored to their unique needs. These
federations may leverage existing national identification systems or federations may leverage existing national identification systems or
other trusted credentials to establish member identities and ensure other trusted credentials to establish member identities and ensure
skipping to change at line 235 skipping to change at line 235
design and functionality. This section outlines the key components design and functionality. This section outlines the key components
of this trust model and its implications for federation members and of this trust model and its implications for federation members and
the federation operator. the federation operator.
3.1. Role of the Federation Operator 3.1. Role of the Federation Operator
The federation operator plays a critical role in the MATF framework. The federation operator plays a critical role in the MATF framework.
This entity is responsible for: This entity is responsible for:
* Managing the central trust anchor, which is used to establish * Managing the central trust anchor, which is used to establish
trust across different domains within the federation trust across different domains within the federation.
* Vetting federation members to ensure they meet the required * Vetting federation members to ensure they meet the required
standards and policies. standards and policies.
* Maintaining and securing the federation metadata, which includes * Maintaining and securing the federation metadata, which includes
public key pins [RFC7469], issuer certificates, and other public key pins [RFC7469], issuer certificates, and other
essential information. essential information.
Additionally, the federation operator SHOULD develop their own threat Additionally, the federation operator SHOULD develop their own threat
models to proactively identify potential risks and threats. This models to proactively identify potential risks and threats. This
skipping to change at line 619 skipping to change at line 619
where the derived pin does not match any preloaded pin or where the where the derived pin does not match any preloaded pin or where the
peer identity cannot be resolved. This strict enforcement ensures peer identity cannot be resolved. This strict enforcement ensures
that only authorized and secure communication channels are that only authorized and secure communication channels are
established within the federation. established within the federation.
5.5. Certificate Rotation 5.5. Certificate Rotation
To replace a certificate, whether due to expiration or other reasons, To replace a certificate, whether due to expiration or other reasons,
the following procedure MUST be followed: the following procedure MUST be followed:
1. Submitting updated metadata. When a certificate is scheduled for 1. Submitting updated metadata: When a certificate is scheduled for
rotation, the federation member submits updated metadata that rotation, the federation member submits updated metadata that
adds the pin for the new public key alongside the already adds the pin for the new public key alongside the already
published pins. The federation operator republishes the signed published pins. The federation operator republishes the signed
federation metadata aggregate, making the new pin available to federation metadata aggregate, making the new pin available to
all federation members. all federation members.
2. Propagation period. Federation members MUST refresh their local 2. Propagation period: Federation members MUST refresh their local
metadata stores as specified in Section 4.2. The rotating member metadata stores as specified in Section 4.2. The rotating member
MUST allow sufficient time for peers to refresh and preload the MUST allow sufficient time for peers to refresh and preload the
new pin before switching to the new certificate. new pin before switching to the new certificate.
3. Switching to the new certificate. After the propagation period 3. Switching to the new certificate: After the propagation period
has elapsed, the rotating member updates its TLS stack to present has elapsed, the rotating member updates its TLS stack to present
the new certificate. This allows peers that have preloaded the the new certificate. This allows peers that have preloaded the
new pin to validate the rotated certificate. new pin to validate the rotated certificate.
4. Removing the old pin. Following a successful transition, the 4. Removing the old pin: Following a successful transition, the
rotating member MUST submit updated metadata excluding the old rotating member MUST submit updated metadata excluding the old
pin. The federation operator republishes the aggregate, ensuring pin. The federation operator republishes the aggregate, ensuring
that only current public keys remain trusted within the that only current public keys remain trusted within the
federation. federation.
5.6. Implementation Guidelines 5.6. Implementation Guidelines
The placement of pin validation depends on the deployment The placement of pin validation depends on the deployment
architecture. For clients, validation is typically performed by the architecture. For clients, validation is typically performed by the
component initiating the TLS connection. For servers using an component initiating the TLS connection. For servers using an
skipping to change at line 685 skipping to change at line 685
using a custom SSLContext and TrustManager. The choice of library is using a custom SSLContext and TrustManager. The choice of library is
left to the discretion of each implementation. left to the discretion of each implementation.
6. Federation Metadata 6. Federation Metadata
Federation metadata is published as a JSON Web Signature (JWS) Federation metadata is published as a JSON Web Signature (JWS)
[RFC7515]. The payload contains statements about entities of [RFC7515]. The payload contains statements about entities of
federation members. federation members.
Metadata is used for authentication and service discovery. A client Metadata is used for authentication and service discovery. A client
selects a server based on metadata claims, such as organization and selects a server based on metadata claims such as organization and
tags. To establish a connection, the client uses the base_uri, pins, tags. To establish a connection, the client uses the base_uri, pins,
and, if needed, issuers of the selected server. and, if needed, issuers of the selected server.
6.1. Federation Metadata Claims 6.1. Federation Metadata Claims
This section defines the set of claims that can be included in This section defines the set of claims that can be included in
metadata. metadata.
* iat (REQUIRED) * iat (REQUIRED)
skipping to change at line 787 skipping to change at line 787
properties: properties:
* entity_id (REQUIRED) * entity_id (REQUIRED)
A URI that uniquely identifies the entity. This identifier MUST A URI that uniquely identifies the entity. This identifier MUST
NOT collide with any other entity_id within the federation or NOT collide with any other entity_id within the federation or
within any other federation that the entity interacts with. within any other federation that the entity interacts with.
- Data Type: String - Data Type: String
- Syntax: A URI as defined in [RFC3986]. - Syntax: URI as defined in [RFC3986].
- Example: "https://example.com" - Example: "https://example.com"
* organization (OPTIONAL) * organization (OPTIONAL)
A name identifying the organization that the entity's metadata A name identifying the organization that the entity's metadata
represents. The federation operator MUST ensure that a mechanism represents. The federation operator MUST ensure that a mechanism
is in place to verify that the organization claim corresponds to is in place to verify that the organization claim corresponds to
the rightful owner of the information exchanged between nodes. the rightful owner of the information exchanged between nodes.
This is crucial for the trust model, ensuring certainty about the This is crucial for the trust model, ensuring certainty about the
skipping to change at line 985 skipping to change at line 985
The MATF metadata schema is defined in Appendix A. This schema The MATF metadata schema is defined in Appendix A. This schema
specifies the format for describing entities involved in MATF and specifies the format for describing entities involved in MATF and
their associated information. their associated information.
| Note: The schema in Appendix A is folded due to line length | Note: The schema in Appendix A is folded due to line length
| limitations as specified in [RFC8792]. | limitations as specified in [RFC8792].
6.3. Example Metadata 6.3. Example Metadata
The following is a non-normative example of a metadata statement. The following is a non-normative example of a metadata statement.
Line breaks in the example of the issuers claim are for readability Line breaks in the issuers claim example are for readability only.
only.
{ {
"iat": 1755514949, "iat": 1755514949,
"exp": 1756119888, "exp": 1756119888,
"iss": "https://federation.example.org", "iss": "https://federation.example.org",
"version": "1.0.0", "version": "1.0.0",
"cache_ttl": 3600, "cache_ttl": 3600,
"entities": [{ "entities": [{
"entity_id": "https://example.com", "entity_id": "https://example.com",
"organization": "Example Org", "organization": "Example Org",
skipping to change at line 1050 skipping to change at line 1049
6.4. Metadata Signing 6.4. Metadata Signing
Federation metadata is signed using JWS and published using JWS JSON Federation metadata is signed using JWS and published using JWS JSON
Serialization according to the general JWS JSON Serialization syntax Serialization according to the general JWS JSON Serialization syntax
defined in [RFC7515]. Federation metadata signatures are RECOMMENDED defined in [RFC7515]. Federation metadata signatures are RECOMMENDED
to be created using the algorithm ECDSA using P-256 and SHA-256 to be created using the algorithm ECDSA using P-256 and SHA-256
("ES256") as defined in [RFC7518]. However, to accommodate evolving ("ES256") as defined in [RFC7518]. However, to accommodate evolving
cryptographic standards, alternative algorithms MAY be used, provided cryptographic standards, alternative algorithms MAY be used, provided
they meet the security requirements of the federation. they meet the security requirements of the federation.
Federations may need to transition to post-quantum (PQ) cryptographic Federations may need to transition to post-quantum cryptographic
algorithms for federation metadata signatures and for endpoint algorithms for federation metadata signatures and for endpoint
certificate public key types. MATF can accommodate such transitions certificate public key types. MATF can accommodate such transitions
through key rollover and by updating published pins as new key types through key rollover and by updating published pins as new key types
are deployed. are deployed.
The following JWS Protected Header parameters are REQUIRED: The following JWS Protected Header parameters are REQUIRED:
* alg (Algorithm) * alg (Algorithm)
Identifies the algorithm used to generate the JWS signature Identifies the algorithm used to generate the JWS signature
skipping to change at line 1080 skipping to change at line 1079
The following is a non-normative example of a signature protected The following is a non-normative example of a signature protected
header. header.
{ {
"alg": "ES256", "alg": "ES256",
"kid": "c2fb760e-f4b6-4f7e-b17a-7115d2826d51" "kid": "c2fb760e-f4b6-4f7e-b17a-7115d2826d51"
} }
7. Example Usage Scenarios 7. Example Usage Scenarios
The examples in this section are non-normative and illustrate the The examples in this section are not normative and illustrate the
procedures described in Section 5.2 and Section 5.3. procedures described in Sections 5.2 and 5.3.
The following example describes a scenario within the federation The following example describes a scenario within the federation
"Skolfederation" where MATF is deployed. Both clients and servers "Skolfederation" where MATF is deployed. Both clients and servers
are registered members of the federation. In this scenario, clients are registered members of the federation. In this scenario, clients
manage cross-domain user accounts using SS 12000:2018, which is a manage cross-domain user accounts using SS 12000:2018, which is a
System for Cross-domain Identity Management (SCIM) extension. System for Cross-domain Identity Management (SCIM) extension.
+------------------------------------------------------+ +------------------------------------------------------+
| | | |
| Federation Metadata | | Federation Metadata |
skipping to change at line 1126 skipping to change at line 1125
C. If certificate chain validation is performed, the TLS client or C. If certificate chain validation is performed, the TLS client or
intermediary configures its trust store using the issuers listed intermediary configures its trust store using the issuers listed
in the federation metadata for the selected entity. in the federation metadata for the selected entity.
D. The client initiates a TLS connection to the selected base_uri D. The client initiates a TLS connection to the selected base_uri
and presents its client certificate. and presents its client certificate.
E. If an intermediary terminates the TLS session, it forwards E. If an intermediary terminates the TLS session, it forwards
identity material derived from the TLS session to the application identity material derived from the TLS session to the application
as described in Section 5.3 and Section 5.6. as described in Sections 5.3 and 5.6.
F. The application maps the derived pin to a matching metadata entry F. The application maps the derived pin to a matching metadata entry
and uses the associated entity_id for identification and and uses the associated entity_id for identification and
authorization. authorization.
7.1. Client Behavior 7.1. Client Behavior
A certificate is issued for the client. The client's certificate A certificate is issued for the client. The client's certificate
issuer and public key pins are published in the federation metadata. issuer and public key pins are published in the federation metadata.
skipping to change at line 1164 skipping to change at line 1163
application data is exchanged. application data is exchanged.
5. If validation succeeds, the client proceeds with application 5. If validation succeeds, the client proceeds with application
transactions. transactions.
7.2. Server Behavior 7.2. Server Behavior
To accept inbound connections from a client, the server uses To accept inbound connections from a client, the server uses
federation metadata to perform pin validation of the public key in federation metadata to perform pin validation of the public key in
the presented client certificate. The federation metadata publishes the presented client certificate. The federation metadata publishes
client public key pins and, for deployments that perform certificate client public key pins, and for deployments that perform certificate
chain validation, the allowed issuers. chain validation, the allowed issuers.
When the server receives a TLS connection attempt from a remote When the server receives a TLS connection attempt from a remote
client, the following steps are performed: client, the following steps are performed:
1. The server is configured to request or require a client 1. The server is configured to request or require a client
certificate. If certificate chain validation is performed, the certificate. If certificate chain validation is performed, the
trust store is populated using the issuers published in the trust store is populated using the issuers published in the
federation metadata. Otherwise, the server requests a client federation metadata. Otherwise, the server requests a client
certificate without issuer validation (for example, certificate without issuer validation (for example,
skipping to change at line 1402 skipping to change at line 1401
research and education identity federations worldwide", research and education identity federations worldwide",
<https://edugain.org>. <https://edugain.org>.
[EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala [EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala
användarkonton" [EGIL – manage your school's digital user användarkonton" [EGIL – manage your school's digital user
accounts efficiently], <https://sambruk.se/egil-dnp/>. accounts efficiently], <https://sambruk.se/egil-dnp/>.
[eIDAS] European Union, "Regulation (EU) No 910/2014 of the [eIDAS] European Union, "Regulation (EU) No 910/2014 of the
European Parliament and of the Council of 23 July 2014 on European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic identification and trust services for
electronic transactions in the internal market", Official electronic transactions in the internal market and
Journal of the European Union L 257/73, repealing Directive 1999/93/EC", Official Journal of the
ELI http://data.europa.eu/eli/reg/2014/910/oj, 23 July European Union L 257/73, 23 July 2014,
2014, <https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng>. <https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng>.
[Moa] Internetstiftelsens Federationer [The Swedish Internet [Moa] Internetstiftelsens Federationer [The Swedish Internet
Foundation], "Machine and Organization Authentication", 6 Foundation], "Machine and Organization Authentication", 6
October 2025, October 2025,
<https://wiki.federationer.internetstiftelsen.se/x/ <https://wiki.federationer.internetstiftelsen.se/x/
LYA5AQ>. LYA5AQ>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
 End of changes. 15 change blocks. 
20 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.48.