5. Authentication
Questa sezione conserva il testo RFC per MATF, inclusi federation trust model, metadata repository, public key pinning, JSON/JWS metadata, usage scenarios, deployments, security considerations e JSON Schema.
5. Authentication
All communication established within the federation uses TLS 1.3
[RFC8446] with mutual authentication. This mechanism ensures the
authenticity of both communicating parties, establishing a robust
foundation for secure data exchange.
5.1. Public Key Pinning
MATF implements public key pinning based on [RFC7469]. Public key
pinning associates one or more public key pins with each federation
endpoint. These pins are published in the federation metadata.
During a connection, clients and servers extract the public key from
the presented certificate and verify that it matches the
preconfigured public key pins retrieved from the federation metadata.
5.1.1. Benefits of Public Key Pinning
The decision to utilize public key pinning in the MATF framework was
driven by several critical factors aimed at enhancing security and
ensuring trust.
5.1.1.1. Interfederation Trust
In interfederation environments, where multiple federations need to
trust each other, public key pinning remains effective. Members can
validate entities in other federations using pins published through
shared metadata, ensuring trust across boundaries. Unlike private
certificate chains, which can become complex and difficult to manage
across multiple federations, public key pinning provides a
straightforward mechanism for establishing trust. MATF
interfederation addresses this challenge by aggregating metadata from
all participating federations into a unified metadata repository.
This shared metadata enables secure communication between entities in
different federations, ensuring consistent key validation and robust
cross-federation trust and security.
5.1.1.2. Fortifying Security Against Threats
Public key pinning provides a robust defense mechanism by directly
binding a peer to a specific public key. This ensures that only the
designated key is trusted, preventing attackers from exploiting
fraudulent certificates. By eliminating reliance on external trust
intermediaries, this approach significantly enhances resilience
against potential threats.
5.1.1.3. Use of Self-Signed Certificates
The use of self-signed certificates within the federation leverages
public key pinning to establish trust. By bypassing external
Certificate Authorities (CAs), servers and clients rely on the
federation's mechanisms to validate trust. Public key pinning
ensures that only the specific self-signed public keys, identified by
key pins in the metadata, are trusted.
5.1.1.4. Revocation
In deployments that rely on certificate chains and certificate
revocation mechanisms, revocation can be complex and slow. This
complexity arises because a certificate that can no longer be
trusted, and potentially other certificates within the chain, may
need to be revoked and reissued. Public key pinning mitigates this
complexity by allowing clients to base trust decisions on pinned
public keys rather than on certificate chains.
If a public key can no longer be trusted within a MATF federation,
the associated pin is removed. Updated metadata is published. The
updated metadata includes a new pin corresponding to the public key
in the replacement certificate. This approach reduces reliance on
certificate revocation mechanisms and shifts the trust relationship
to the specific, updated public key identified by its pin.
5.2. Pin Discovery and Preloading
Peers in the federation obtain public key pins from the federation
metadata. These pins serve as preconfigured trust parameters used
for validation, as specified in Section 5.3.
The federation MUST define discovery rules. These rules describe how
peers use federation metadata claims such as organization and tags to
identify relevant endpoints and their pins.
Before initiating or accepting a connection, a peer MUST preload the
pins for the selected or authorized endpoints from its local metadata
store. Maintenance of the local metadata store, including refresh
behavior and expiry handling, is specified in Section 4.2.
To support peer identification, the preloaded state MUST enable
mapping from a derived pin to the corresponding entity_id. This may
be achieved by maintaining a local index that maps each preloaded pin
value to its associated entity_id.
A server MAY preload only the pins for clients that satisfy the
server's connection policy (for example, based on organization or
tags). Pin validation enforces the resulting policy as specified in
Section 5.3.
5.3. Verification of Received Certificates
Upon connection establishment, both endpoints MUST verify that the
public key in the presented peer certificate matches a pin published
in the federation metadata. This validation MAY be performed by the
TLS stack or by application logic.
In architectures where an intermediary terminates the TLS session,
pin validation MUST be performed by either the intermediary or the
application. If the application performs pin validation, the
intermediary MUST forward the peer certificate or a derived pin to
the application. The application MUST be able to determine the peer
entity_id from the forwarded information and the federation metadata.
This resolution relies on the client pin digest uniqueness property
specified in Section 6.1.1.1.
If the intermediary performs pin validation, it MUST propagate the
peer certificate, the derived pin, or the entity_id to the
application to enable authorization.
The channel between the intermediary and the application MUST be
integrity protected and MUST provide endpoint authentication.
Any conveyed certificate, pin, or identity used for this purpose MUST
be derived directly from the TLS session. Implementations MUST NOT
accept these values from peer-supplied application data.
If the implementation permits disabling default CA-based certificate
chain validation, it SHOULD do so while still enforcing pin
validation. If chain validation is required, the trust anchors used
for certificate chain validation MUST be selected from the issuers
listed in the federation metadata.
If no matching pin is found for a peer, the connection MUST be
handled according to Section 5.4.
5.4. Failure to Validate
A received certificate that fails validation MUST result in the
immediate termination of the connection. This includes scenarios
where the derived pin does not match any preloaded pin or where the
peer identity cannot be resolved. This strict enforcement ensures
that only authorized and secure communication channels are
established within the federation.
5.5. Certificate Rotation
To replace a certificate, whether due to expiration or other reasons,
the following procedure MUST be followed:
1. Submitting updated metadata: When a certificate is scheduled for
rotation, the federation member submits updated metadata that
adds the pin for the new public key alongside the already
published pins. The federation operator republishes the signed
federation metadata aggregate, making the new pin available to
all federation members.
2. Propagation period: Federation members MUST refresh their local
metadata stores as specified in Section 4.2. The rotating member
MUST allow sufficient time for peers to refresh and preload the
new pin before switching to the new certificate.
3. Switching to the new certificate: After the propagation period
has elapsed, the rotating member updates its TLS stack to present
the new certificate. This allows peers that have preloaded the
new pin to validate the rotated certificate.
4. Removing the old pin: Following a successful transition, the
rotating member MUST submit updated metadata excluding the old
pin. The federation operator republishes the aggregate, ensuring
that only current public keys remain trusted within the
federation.
5.6. Implementation Guidelines
The placement of pin validation depends on the deployment
architecture. For clients, validation is typically performed by the
component initiating the TLS connection. For servers using an
intermediary, the communication channel between the intermediary and
the application MUST be integrity protected to prevent tampering with
forwarded peer identity material.
When an intermediary propagates peer identity material (for example,
the peer certificate, a derived pin, or the entity_id) using HTTP
header fields, those header fields are the mechanism used to fulfill
the requirements specified in Section 5.3. For each header field
name used for this purpose, the intermediary MUST remove any instance
of that header field received from the peer and then set the header
field value itself. This ensures that the application only processes
identity material derived directly from the TLS session, enabling the
application to match the peer to the federation metadata and apply
authorization policy based on federation metadata claims. Header
fields that are not used to convey identity material are unaffected
by this requirement. The communication channel between the
intermediary and the application MUST provide integrity protection
and endpoint authentication to prevent tampering with forwarded peer
identity material.
Implementations SHOULD, when possible, rely on libraries with built-
in support for pinning. libcurl, for example, supports pinning via
the CURLOPT_PINNEDPUBLICKEY option. In Python, the cryptography
library can extract public keys, and application code can compare the
derived pin to a configured value. Go provides crypto/tls and
crypto/x509 for certificate inspection and public key extraction. In
Java, java.security.cert.X509Certificate enables public key
extraction, while java.net.http.HttpClient allows pinning enforcement
using a custom SSLContext and TrustManager. The choice of library is
left to the discretion of each implementation.