Skip to content

Commit

Permalink
refine spec and add problem statement
Browse files Browse the repository at this point in the history
  • Loading branch information
@q
q committed Jun 30, 2025
1 parent 9a42f2a commit 3d43eab
Showing 1 changed file with 130 additions and 17 deletions.
147 changes: 130 additions & 17 deletions draft-blahaj-grow-rpki-oauth.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,37 @@
</section>
</section>

<section>
<name>Problem statement</name>
<t>The Peering API currently under discussion at the Global Routing Operations Working Group
<xref target="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<xref target="RFC6480"/>, one that
is not tied to one entity, and is usable by anyone within the Internet ecosystem.
</t>

<t>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 <em>which agent</em> 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.
</t>

<t>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.
</t>

<t>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.
</t>
</section>

<section>
<name>Terminology</name>
<t>For brevity, within this document the following terminology is used</t>
Expand All @@ -84,37 +115,117 @@
<section>
<name>Endpoint Discovery</name>
<t>All endpoints required for this protocol to function not defined herein, are to be discovered
via OpenID Connect Discovery <xref target="OpenID.Discovery"/></t>
via OpenID Connect Discovery
<xref target="OpenID.Discovery"/>
</t>
</section>

<section>
<name>Extensions to IdP Metadata</name>
<t>An RP must be able to verify that an IdP is allowed to issue authorization tokens for an AS. To this end,
the JWK Key Set presented in the OpenID Connect Discovery <tt>jwks_url</tt> <bcp14>MUST</bcp14> be an
RPKI Attested JWK Set.</t>
<t>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 <tt>jwks_url</tt>
<bcp14>MUST</bcp14> 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.
</t>
<t>An RP <bcp14>SHOULD</bcp14> regularly check for updates to the JWK Key Set, and its associated attestation,
and <bcp14>MUST</bcp14> not cache the attestation and its attested resources beyond the end of the
validity of the RSM.
</t>
</section>

<section>
<name>Extensions to Dynamic Client Registration</name>
<t>Once an 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 already. This allows it to be issued an authentication token
scoped to it, and to engage in Token Introspection <xref target="OpenID.Core"/> to verify tokens given in API
requests.
</t>
<t>The RP submits an OIDC Dynamic Client Registration request to the Consumer's IdP <xref target="OpenID.Registration"/>,
containing any well-known scopes as defined in subservient specifications required for which services the RP provides.
Updates to these scopes may be made via the Client Configuration Endpoint.</t>
<t>The registration request <bcp14>MUST</bcp14> be signed using HTTP signatures <xref target="RFC9421"/>.
<t>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
<xref target="OpenID.Core"/>
to verify tokens given
in API requests.
</t>
<t>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.
</t>
<t>The RP submits an OIDC Dynamic Client Registration request to the Consumer's IdP
<xref target="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.
</t>
<t>Such that the Idp can validate the identity of the RP making the registration request, the request
<bcp14>MUST</bcp14>
be signed using HTTP signatures<xref target="RFC9421"/>.
The signature <tt>keyid</tt> parameter <bcp14>MUST</bcp14> be URL to an RPKI Attested JWK Set.
The fragment of such a URL is used to identify the exact <tt>kid</tt> used to sign the request. </t>
The fragment of such a URL is used to identify the exact <tt>kid</tt> used to sign the request.
</t>
<t>This signature <bcp14>MUST</bcp14> be over at least the following components:
</t>
<ul>
<li>@method</li>
<li>@target-uri</li>
<li>content-digest</li>
</ul>
<t>The body of the HTTP request <bcp14>MUST</bcp14> be included in the signature by the use of a HTTP Digest
<xref target="RFC9530"/>.
</t>
<t>This signature <bcp14>MUST</bcp14> contain at least the following parameters:
</t>
<ul>
<li>@created</li>
<li>@nonce</li>
<li>@keyid</li>
</ul>
<t>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.
</t>
</section>

<section>
<name>RPKI Attested JWK Set</name>
<t>An RPKI Attested JWK Set is as a normal JWK Set <xref target="RFC7517"/>, that <bcp14>MUST</bcp14> contain an <tt>rpki_attestation</tt>
parameter. The construction of such a parameter is the base64url encoding <xref target="RFC7515"/> of an RPKI
<t>An RPKI Attested JWK Set is as a normal JWK Set<xref target="RFC7517"/>, that <bcp14>MUST</bcp14> contain an
<tt>rpki_attestation</tt>
parameter. The construction of such a parameter is the base64url encoding
<xref target="RFC7515"/>
of an RPKI
Signed Message over the JWK Set without the <tt>rpki_attestation</tt> parameter, using the JWK Thumbprint
JSON hash input calculation algorithm <xref target="RFC7638"/>.</t>
JSON hash input calculation algorithm<xref target="RFC7638"/>.
</t>
<t>The audience field for such an RSM <bcp14>MUST</bcp14> be the Global Audience (<tt>1.3.6.1.5.5.TBD.0.0</tt>).
</t>
<t>The purpose field for such an RSM <bcp14>MUST</bcp14> be the OAuth Attestation Audience (<tt>
1.3.6.1.5.5.TBD.1.1</tt>).
</t>
</section>

<section>
<name>Security Considerations</name>
<t>The security considerations of this protocol have been left until the protocol proper is further refined.</t>
</section>

<section anchor="iana">
<name>IANA Considerations</name>
<section>
<name>RPKI Signed Message well-known purposes</name>
<t>The IANA is requested to allocate a new OID under the
"RPKI Signed Message well-known purposes" registry:
</t>
<table>
<thead>
<tr>
<th>Decimal</th>
<th>Description</th>
<th>References</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>OAuth Attestation</td>
<td>This document</td>
</tr>
</tbody>
</table>
</section>
</section>
</middle>

Expand All @@ -129,10 +240,12 @@
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
</referencegroup>

<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6480.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7517.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7515.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7638.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9421.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9530.xml"/>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ramseyer-grow-peering-api-05.xml"/>

Expand Down

0 comments on commit 3d43eab

Please sign in to comment.