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 <[email protected]> Verzonden: woensdag 23 oktober 2024 15:24 Aan: Job Snijders <[email protected]> CC: db-wg <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
