Passkey Authentication and Tokens v2

[alilleybrinker]

Hi everyone, Andrew here from the CVE development team at MITRE!

Earlier this week we previewed our concept for two improvements to authentication and authorization in CVE's systems to the Automation Working Group (AWG):

• The introduction of passkeys for phishing-resistant multi-factor authentication via the upcoming CVE Data Registry application.
• The introduction of an improved CVE Services API token format which we call "Tokens v2."

We're currently working to implement both of these changes, and are intending for future testing with the AWG and with our broader set of CNA and ADP partners to identify challenges with adoption of passkeys or use of the new token format.

This discussion is being opened as the go-to place for AWG participants and other stakeholders to offer feedback on the proposed concept.

---

Passkeys

Today, CVE does not have a mechanism for interactive authentication of users within our systems. Our sole authentication mechanism for CVE Services is the API token, and possession of the API token is taken as proof of identity. This is plainly insufficient for a piece of critical security infrastructure.

To alleviate this deficiency, we're proposing introducing passkey-based authentication to the upcoming Data Registry application. Existing users of CVE Services would be invited to enroll their first passkey, and would then to be able to authenticate to the Data Registry app with their passkey, manage their passkeys, and manage their API tokens (including the new "Tokens v2" format, covered below).

Passkeys were chosen as they are a form of phishing-resistant multi-factor authentication, unlike weaker alternatives like a plain username and password (single factor, easily phished), SMS-based codes (multi-factor but easily phished or intercepted), OTP codes (multi-factor but easily phished), and others.

We also considered pursuing OpenID Connect (OIDC) integration with CNA and ADP partner's Identity Provider (IdP) systems, but determined the complexity would likely be substantial given the large and growing number of partner organizations for CVE. Additionally, not all partner organizations operate their own IdP infrastructure, so an OIDC-based solution would still need alternatives to cover those cases, if pursued. Given these challenges, we are not pursuing an OIDC-based authentication solution for CVE.

We are still determining the exact configuration of CVE's server requirements for passkeys, and this question will be a key focus of our intended testing with partner CNAs and ADPs. We want to be as strict as we can be while enabling our partners to successfully enroll and use passkeys on their respective devices. We know some CNA and ADP users may be operating in restricted computing environments or on uncommon operating systems or hardware platforms, and we want to be sensitive in balancing support for those contexts alongside a desire for strong authentication guarantees from users' passkeys.

Tokens v2

We are also intending to introduce a new API token format for the CVE Services API.

Today, API tokens for CVE Services face several limitations:

• They are 1-per-user.
• They do not expire automatically; they only stop working when manually reset by the associated user, an administrator of that user's organization, or a member of the CVE Secretariat org (MITRE).
• They have the full permissions of their associated user.

The Tokens v2 design resolves these issues. These newer tokens would mean:

• Users can have as many tokens as they need.
• Tokens would have an automatic expiry date, set when they're created. Tokens could still be manually expired early if necessary.
• Tokens would have specific permissions, set when they're created. The available operations of a token would be the union of the token's permissions and the associated user's permissions.

Additionally, the new tokens would be higher entropy (from 144 bits to 256 bits, a ~77% increase), would feature a domain separation prefix to aid users and secret scanners in identifying tokens, and would include a checksum at the end to enable clients and secret scanners to identify whether a token is syntactically valid non-interactively with CVE's infrastructure.

One open question on which we'd appreciate feedback is what a reasonable maximum expiry limit would be for Tokens v2. We recognize the trade-off between security and operational complexity with shorter lifetimes for API tokens. Longer-lived tokens require fewer rotations by operators, but also prolong the usable lifetime of the token if exposed to attackers. We do not want to continue to permit the creation of tokens with an unlimited lifetime, but we also recognize that too short a maximum lifetime for tokens may be a burden on CNAs or ADPs who find themselves rotating tokens too frequently.

Finally, with Tokens v2, tokens would be submitted to the CVE Services API with the standard Authorization: bearer <token> HTTP header, rather than the Tokens v1 trio of CVE-API-KEY, CVE-API-USER and CVE-API-ORG. This should improve the developer experience of interacting with the CVE Services API.

You can view a detailed Request For Discussion document outlining the plan for Tokens v2 and its implementation in the CVE Data Registry and CVE Services API for more information on this proposal.

Testing

Both of these changes would be tested in CVE's public test environment before landing for general use. Our current intent is to test passkeys first, followed by tests for Tokens v2. Each test would be split into a "small cohort" phase with AWG-engaged partners, and a second "large cohort" phase open to all CNA and ADP partners.

This testing period would enable us to gather feedback on key questions, including:

• What server requirements for passkeys should we use to best balance security with client support across CNA and ADPs?
• What maximum expiry should we allow for Tokens v2, balancing the exposure risk of longer-lived tokens with the operational burden of more frequent token rotations?

Additionally, if there are specific concerns you have about the testing concept, or about the intended changes themselves, please let us know!

Eventual Rollout

When testing is eventually completed for both sets of changes, assuming no feedback which prompts a rejection of the approach, our current intent is that both passkeys and Tokens v2 would launch together.

For Tokens v2, there would be a period where legacy API tokens ("Tokens v1") would continue to be usable with the CVE Services API, before their eventual deprecation and replacement with Tokens v2. The specific timeframes for this overlap, deprecation, and eventual removal would all be clearly communicated by the CVE Program well in advance of their deadlines.

Conclusion

We are committed to improving the state of authentication and authorization for CVE today, and believe our current proposals for passkeys and Tokens v2 substantially address limitations and risks present in our systems.

We're presenting these concepts with the goal of gathering feedback, to make sure that we're adequately considering the needs of our CNA and ADP partners before introducing these new features into our systems.

If you have thoughts or concerns on the proposed designs or their test plans, please share them here!

[Tanish-26]

Thanks for sharing this proposal. I really like the direction of Tokens v2, especially the move toward scoped and expiring tokens.

One additional idea that came to mind while going through the proposal is whether CVE could consider making token management a little more integration-friendly.

Since users will be able to have multiple tokens, it could be useful to let each token have a name/description (for example, “GitHub CVE Automation” or “Internal CNA Tool”), along with information such as when it was created, when it was last used, and when it expires.

This could make it much easier for users and organizations to understand where their credentials are being used and to quickly identify/revoke a particular token if an integration is compromised, rather than having to rotate everything.

It might also be interesting to consider a simple “rotate token” workflow, where a replacement token can be created with the same permissions while allowing the old token to remain active briefly during deployment.

Just throwing this out as an idea for discussion. I think the move to multiple, scoped and expiring tokens creates a good opportunity to make the token lifecycle and operational side of credential management stronger as well.