caguado
commented
11 months ago +1 on RFC9323 (or RTA too) to bind API requests to ASN holdership.
I would build on top of that to, instead of a dynamic challenge/response chain of trust between parties as I understand it, use the RSC/RTA to bind the INRs to a OAuth2 issuer via their well-known discovery point (RFC8414). This would allow to:
- reuse current identity management solutions based on bearer tokens for async validation
- maintain attestation of individual caller identities on API requests as well as the capability to constrain access to parts of the API defined in this doc via usual scopes or other claims
- extend the integrity checks to the entire API call payload, beyond reliance on a TLS transport, for proof of possession and HTTP signing when those become standard (e.g. RFC9449)
I would also defer this to a separate RFC process that builds atop this doc and now gather consensus on the peering API using a bespoke authz implementation.
job
jramseyer
RFC 9323 specifies a mechanism for Autonomous System holders to issue a signature over an arbitrary SHA256 message digest, then in turn, Relying Parties can verify this signature against the global RPKI.
This means that the Initiator and the Receiver can perform a challenge/response procedure based on the RPKI - which is cryptographically stronger than relying on PeeringDB's OAuth infrastructure.
The Initator and the Receiver can establish an arc of trust by having the Initator signal an arbitrary SHA256 hash over which the Receiver must produce a RPKI-RSC signature; the receiver can challenge the Initator in a similar manner. Once both parties have signed the other-party's challenge, both parties know that each party possesses access to private keys associated with the Autonomous Systems on both sides.