grow Q. Misell Internet-Draft AS207960 Intended status: Standards Track 30 June 2025 Expires: 1 January 2026 Attesting the Identities of Parties in OpenID Connect (OIDC) using the Resource Public Key Infrastructure (RPKI) draft-blahaj-grow-rpki-oauth-00 Abstract 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. Discussion 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. Status of This Memo 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 Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Misell Expires 1 January 2026 [Page 1] Internet-Draft RPKI Attested OIDC June 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Endpoint Discovery . . . . . . . . . . . . . . . . . . . . . 4 5. Extensions to IdP Metadata . . . . . . . . . . . . . . . . . 4 6. Extensions to Dynamic Client Registration . . . . . . . . . . 4 7. RPKI Attested JWK Set . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9.1. RPKI Signed Message well-known purposes . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. 1.1. 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 [BCP14] when, and only when, they appear in all capitals, as shown here. Misell Expires 1 January 2026 [Page 2] Internet-Draft RPKI Attested OIDC June 2025 2. Problem statement 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. 3. 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. Misell Expires 1 January 2026 [Page 3] Internet-Draft RPKI Attested OIDC June 2025 4. Endpoint Discovery All endpoints required for this protocol to function not defined herein, are to be discovered via OpenID Connect Discovery [OpenID.Discovery] 5. 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. 6. 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 [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: * @method Misell Expires 1 January 2026 [Page 4] Internet-Draft RPKI Attested OIDC June 2025 * @target-uri * content-digest 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: * @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. 7. RPKI Attested JWK Set 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). 8. Security Considerations The security considerations of this protocol have been left until the protocol proper is further refined. 9. IANA Considerations 9.1. RPKI Signed Message well-known purposes The IANA is requested to allocate a new OID under the "RPKI Signed Message well-known purposes" registry: Misell Expires 1 January 2026 [Page 5] Internet-Draft RPKI Attested OIDC June 2025 +=========+===================+===============+ | Decimal | Description | References | +=========+===================+===============+ | 1 | OAuth Attestation | This document | +---------+-------------------+---------------+ Table 1 10. References 10.1. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . Misell Expires 1 January 2026 [Page 6] Internet-Draft RPKI Attested OIDC June 2025 [I-D.ramseyer-grow-peering-api] Aguado, C., Griswold, M., Ramseyer, J., Servin, A., and T. Strickx, "Peering API", Work in Progress, Internet-Draft, draft-ramseyer-grow-peering-api-05, 30 May 2024, . [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", The OpenID Foundation, 15 December 2023, . [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", The OpenID Foundation, 15 December 2023, . [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2", The OpenID Foundation, 15 December 2023, . Author's Address Q Misell AS207960 Cyfyngedig 13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom Email: q@as207960.net, q@magicalcodewit.ch URI: https://magicalcodewit.ch Misell Expires 1 January 2026 [Page 7]