Felipe, All,

I’m still of the opinion that *mandatory* API key expiry is a very bad idea, as I have stated earlier.

For some members it could be a requirement to rotate API keys, and they are fully equipped to handle this. Other members might not have a requirement or wish to do so. I believe the members should have a choice in how they want to handle API key expiry, that is why I suggested giving the members an option whether to auto expire an API key.

Forcing API key expiration is not the right way forward. NCC should not enforce certain security practices without having a valid alternative (OAuth 2.0 for example) in place or having an opt-out mechanism available for those members that do not want this.

Regards,

Wessel

Van: Felipe Silveira <fvictolla@ripe.net>
Verzonden: woensdag 23 oktober 2024 15:24
Aan: Job Snijders <job@sobornost.net>
CC: db-wg <db-wg@ripe.net>
Onderwerp: [db-wg] Re: API Key Expiry and Shared Credentials in the RIPE Database

Dear Job, all,

Thank you for your suggestion.

Implementing an API for API key management would require a significant effort. Looking ahead, we plan to introduce OAuth 2.0 authentication, which will provide automation, including key rollover. We therefore believe it would be more efficient to prioritise the implementation of OAuth 2.0 rather than duplicating similar functionality for API keys.

We appreciate your understanding and remain open to any further suggestions or discussions. I will be in Prague next week, so feel free to approach me (or anyone from my team) if you'd like to chat further about the best way forward.

Kind regards,

Felipe Victolla Silveira

Chief Technology Officer

RIPE NCC

On Fri, 11 Oct 2024 at 00:38, Job Snijders <job@sobornost.net> wrote:

Dear Felipe, RIPE NCC,

Thank you for your efforts to improve account security for LIRS. I
appreciate the approach to tie API keys to individual RIPE NCC Access
accounts. I imagine the approach might help improve employee
off-boarding processes.

I want to comment on one specific aspect that I'm not entirely
comfortable with:

On Wed, Oct 09, 2024 at 02:28:26PM +0200, Felipe Silveira wrote:
> Secondly, we will implement mandatory API key expiration dates. We
> will allow the user to choose the expiry date when creating a new key,
> but expiry cannot be more than one year. We will notify the RIPE NCC
> Access user in advance by email and on our web interface(s), if any of
> their API keys are due to expire soon.

I don't see the security advantage here. The "expires after a
year"-approach means that once a year API users need to copy private key
material from RIPE portal to internal tooling, get the change approved,
test the results, etc.

Such events are are both a security sensitive operation and also a
potential operational problem when the API key isn't replaced in time. I
fear I see a potential for folks ending up working under time pressure.
If the expiry happens to coincidence with a change freeze it'll be
unwelcome.

Introducing an ability which allows users to set expiry dates on API
keys seems fine, but the maximum expiry of 1 year seems to short. I'd
prefer it if the expiry moment is left as a decision to the user.

Kind regards,

Job