Attesting the Identities of Parties in OpenID Connect (OIDC) using the Resource Public Key Infrastructure (RPKI)

Introduction An API allowing programmatic configuration of BGP peering sessions is defined in . 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Problem statement The Peering API currently under discussion at the Global Routing Operations Working Group 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, 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.

Terminology For brevity, within this document the following terminology is used

Service Provider: An AS offering a (e.g. REST API) service to other ASes.
Consumer: An AS consuming the service provided by the Service Provider.

Endpoint Discovery All endpoints required for this protocol to function not defined herein, are to be discovered via OpenID Connect Discovery

Extensions to IdP Metadata 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.

Extensions to Dynamic Client Registration 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 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 , 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. 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:

@method
@target-uri
content-digest

The body of the HTTP request MUST be included in the signature by the use of a HTTP Digest . This signature MUST contain at least the following parameters:

@created
@nonce
@keyid

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.

RPKI Attested JWK Set An RPKI Attested JWK Set is as a normal JWK Set, that MUST contain an rpki_attestation parameter. The construction of such a parameter is the base64url encoding of an RPKI Signed Message over the JWK Set without the rpki_attestation parameter, using the JWK Thumbprint JSON hash input calculation algorithm. 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).

Security Considerations The security considerations of this protocol have been left until the protocol proper is further refined.

IANA Considerations

RPKI Signed Message well-known purposes 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