diff --git a/draft-blahaj-grow-rpki-oauth.xml b/draft-blahaj-grow-rpki-oauth.xml index 9f8ac77..d884345 100644 --- a/draft-blahaj-grow-rpki-oauth.xml +++ b/draft-blahaj-grow-rpki-oauth.xml @@ -70,6 +70,37 @@ +
+ 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 @@ -84,37 +115,117 @@
Endpoint Discovery All endpoints required for this protocol to function not defined herein, are to be discovered - via OpenID Connect Discovery + 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 an AS. To this end, - the JWK Key Set presented in the OpenID Connect Discovery jwks_url MUST be an - RPKI Attested JWK Set. + 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 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 to verify tokens given in API - requests. - - 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 may be made via the Client Configuration Endpoint. - The registration request MUST be signed using HTTP signatures . + 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. + 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 + . + + 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. +
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 + 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 . + 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: + + + + + + + + + + + + + + + + +
DecimalDescriptionReferences
1OAuth AttestationThis document
+
@@ -129,10 +240,12 @@ + +