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]> 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/
