| Internet-Draft | RPKI Attested OIDC | June 2025 |
| Misell | Expires 1 January 2026 | [Page] |
The Peering API currently under discussion in the GROW Working Group does not provide a standardised mechanism to authenticate parties engaged in the Peering API. This document specifies a method to attest as to the identities of parties in an OpenID Connect (OIDC) exchange, binding the authentication flow to agents of ASNs.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.molgen.mpg.de/q/rpki-peering-api-discovery.¶
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 1 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
An API allowing programmatic configuration of BGP peering sessions is defined in [I-D.ramseyer-grow-peering-api]. The API defined in that document does not provide a standardised mechanism to authenticate parties engaged in the Peering API. To this end, this documents defines extensions to OpenID Connect to allow verifying an AS's Identity Provider (IdP), its Relying Parties (RP), and agents thereof.¶
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 [BCP14] when, and only when, they appear in all capitals, as shown here.¶
The Peering API currently under discussion at the Global Routing Operations Working Group [I-D.ramseyer-grow-peering-api]is in need of a way to authenticate parties involved in such API exchanges. The draft, as it is currently conceived, relies on the OAuth service provided by PeeringDB to authenticate Autonomous Systems and their agents. It is undesirable, in the scope of an IETF document to rely on such external parties as a core part of the specification. We therefore set out to define an alternative OAuth federation mechanism based on the RPKI[RFC6480], one that is not tied to one entity, and is usable by anyone within the Internet ecosystem.¶
The reasons for adapting OAuth and not defining a new authentication mechanism are twofold; firstly, OAuth is a familiar protocol for authentication in application development, and many libraries exist that support it, secondly, and perhaps more crucially, is the large extant deployment of corporate IdPs using OAuth. From discussions from the proponents of the Peering API, the need to identify not only the Autonomous System from which the request originates, but in addition which agent of the AS has made the request. That is, it would be beneficial be able to say not only that AS64496 submitted a peering request, but that John of AS64496 did so.¶
Given the prevalence of corporate IdPs, specifically those that support OAuth, it seems fitting to extend this to also provide authentication to a peering API. OAuth already provides the dynamic client registration, and token introspection, required to integrate a third party service with a corporate IdP. This document serves to build upon this by creating a tie between resources attested in the RPKI and their IdPs and RPs.¶
In addition to the peering API, there likely will be other APIs one may wish to establish between ASNs, and this OAuth extensions provides a natual basis for them.¶
For brevity, within this document the following terminology is used¶
All endpoints required for this protocol to function not defined herein, are to be discovered via OpenID Connect Discovery [OpenID.Discovery]¶
An RP must be able to verify that an IdP is allowed to issue authorization tokens for resources. To this end,
the JWK Key Set presented in the OpenID Connect Discovery jwks_url
MUST be an
RPKI Attested JWK Set. That is, the JWK used to sign the JWTs used in an OAuth exchange is itself signed
using the RPKI, attesting that this IdP is authoritative for Internet resources. An IdP is considered
authoritative for all resources in the EE Certificate contained in the RSM used to attest the JWK Key Set.¶
An RP SHOULD regularly check for updates to the JWK Key Set, and its associated attestation, and MUST not cache the attestation and its attested resources beyond the end of the validity of the RSM.¶
Once the RP of a Service Provider is aware which IdP will be used by the Consumer to authenticate to it, it must register with that IdP, if it hasn't done so already. This allows it to be issued an authentication token scoped to it, and to engage in Token Introspection [OpenID.Core] to verify tokens given in API requests.¶
The manner in which the base URL of an IdP is communicated to an RP is out of the scope of this document, and is intended to be defined in subservient documents.¶
The RP submits an OIDC Dynamic Client Registration request to the Consumer's IdP [OpenID.Registration], containing any well-known scopes as defined in subservient specifications required for which services the RP provides. Updates to these scopes in future may be made via the Client Configuration Endpoint.¶
Such that the Idp can validate the identity of the RP making the registration request, the request
MUST
be signed using HTTP signatures[RFC9421].
The signature keyid parameter MUST be URL to an RPKI Attested JWK Set.
The fragment of such a URL is used to identify the exact kid used to sign the request.¶
This signature MUST be over at least the following components:¶
The body of the HTTP request MUST be included in the signature by the use of a HTTP Digest [RFC9530].¶
This signature MUST contain at least the following parameters:¶
The response to such a registration request need not be signed, as the identity of the IdP is validated via its TLS domain identity and its attested discovery metadata.¶
An RPKI Attested JWK Set is as a normal JWK Set[RFC7517], that MUST contain an
rpki_attestation
parameter. The construction of such a parameter is the base64url encoding
[RFC7515]
of an RPKI
Signed Message over the JWK Set without the rpki_attestation parameter, using the JWK Thumbprint
JSON hash input calculation algorithm[RFC7638].¶
The audience field for such an RSM MUST be the Global Audience (1.3.6.1.5.5.TBD.0.0).¶
The purpose field for such an RSM MUST be the OAuth Attestation Audience (
1.3.6.1.5.5.TBD.1.1).¶
The security considerations of this protocol have been left until the protocol proper is further refined.¶
The IANA is requested to allocate a new OID under the "RPKI Signed Message well-known purposes" registry:¶
| Decimal | Description | References |
|---|---|---|
| 1 | OAuth Attestation | This document |