API Key Expiry and Shared Credentials in the RIPE Database
Dear all, Thank you for your feedback during the recent DB-WG discussion on API key authentication for updates in the RIPE Database. After discussions and careful consideration of the points raised, we have come to the following decisions. Firstly, we will only support the use of API keys created and used by an individual RIPE NCC Access account. When multiple people share the same login credentials, it creates security risks, leaving the system open to potential abuse. For instance, a former employee with access to shared credentials could still access sensitive data after leaving the company. Additionally, it becomes impossible to track who made specific changes in the system, leading to a lack of accountability and an incomplete audit trail, making it difficult to investigate incidents or ensure compliance. Based on these risks, we have chosen not to offer a design that allows API key sharing for better security and traceability. We will help an LIR manage how API keys are used. The LIR Portal will list who has used API keys with the default maintainer in the LIR Portal. We will also display a warning in the LIR Portal when removing or changing a user’s role when they have API keys. 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. Our top priority is the security of everyone’s data. While I understand these decisions will require members to make changes to their scripts, it's essential that we remain compliant and follow best practices here. Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC
Hi, On Wed, Oct 09, 2024 at 02:28:26PM +0200, Felipe Silveira wrote:
Our top priority is the security of everyone???s data. While I understand these decisions will require members to make changes to their scripts, it's essential that we remain compliant and follow best practices here.
I think you've been reading the wrong books on security here... this design is actively discouraging use of API keys, because it breaks doing proper automatization on the LIR size. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I have to agree with Gert here. I think the intentions are good but it won't give the wanted result. Making it so API keys are tied to a user will cause people to create shared users to hold those keys. -Cynthia On Wed, 9 Oct 2024, 19:21 Gert Doering, <gert@space.net> wrote:
Hi,
On Wed, Oct 09, 2024 at 02:28:26PM +0200, Felipe Silveira wrote:
Our top priority is the security of everyone???s data. While I understand these decisions will require members to make changes to their scripts, it's essential that we remain compliant and follow best practices here.
I think you've been reading the wrong books on security here... this design is actively discouraging use of API keys, because it breaks doing proper automatization on the LIR size.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- 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/
Hi there, Given the focus on security and token management, was OAuth2 considered? It’s a widely adopted standard that includes built-in mechanisms for secure authentication and token expiration, and it supports various flows that might align with your requirements. If it was evaluated, could you please share any insights on why it wasn’t chosen? Regards, Laurent On Thu, Oct 10, 2024 at 12:58 PM Cynthia Revström via db-wg <db-wg@ripe.net> wrote:
I have to agree with Gert here. I think the intentions are good but it won't give the wanted result.
Making it so API keys are tied to a user will cause people to create shared users to hold those keys.
-Cynthia
On Wed, 9 Oct 2024, 19:21 Gert Doering, <gert@space.net> wrote:
Hi,
On Wed, Oct 09, 2024 at 02:28:26PM +0200, Felipe Silveira wrote:
Our top priority is the security of everyone???s data. While I understand these decisions will require members to make changes to their scripts, it's essential that we remain compliant and follow best practices here.
I think you've been reading the wrong books on security here... this design is actively discouraging use of API keys, because it breaks doing proper automatization on the LIR size.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- 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/
----- 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/
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
Dear all, First of all, I would like to thank you for the feedback provided. This is very much appreciated and helps us in deciding the way forward. Second, I understand the impact that these requirements can have on you and the inconvenience that they can cause. We need to find the right balance between security and ease of use, and sometimes this can be a difficult puzzle to solve. Now, answering some of the points raised. About OAuth2: we have indeed considered it and we do plan to support this in the future. It has a number of useful features as has been mentioned here. However, it was not chosen now because we want a straightforward replacement for passwords to help our users migrate more easily. Adding support for OAuth2 flows on the client is not as straightforward when compared to API keys. Also, we didn’t want to divide our focus internally by adding support for two different authentication methods simultaneously. About the expiry time for the API keys: we chose a maximum of one year expiry of API keys as a trade-off between security and ease of use. A long validity period is convenient but increases the risk the API key is exposed. In addition, a procedure to rollover the API key is necessary no matter the validity period. However, the longer the validity, the less frequently this procedure is performed. This can lead to a risk that staff will be unfamiliar with doing it, which may result in downtime if the procedure is not followed correctly. Before any API key expires, the RIPE NCC will notify the user via the website and by email, giving them time to perform a rollover. An organisation can also track the expiration themselves as part of their rollover procedure. Finally, we will not encourage the sharing of RIPE NCC Access accounts to share credentials. As already mentioned, it is a better practice for individuals to manage their own credentials separately. If you have further questions please let me know. 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
Dear Felipe, RIPE NCC, On Tue, Oct 15, 2024 at 12:05:51PM +0200, Felipe Silveira wrote:
I understand the impact that these requirements can have on you and the inconvenience that they can cause. We need to find the right balance between security and ease of use, and sometimes this can be a difficult puzzle to solve.
About the expiry time for the API keys: we chose a maximum of one year expiry of API keys as a trade-off between security and ease of use. A long validity period is convenient but increases the risk the API key is exposed.
In addition, a procedure to rollover the API key is necessary no matter the validity period. However, the longer the validity, the less frequently this procedure is performed. This can lead to a risk that staff will be unfamiliar with doing it, which may result in downtime if the procedure is not followed correctly. Before any API key expires, the RIPE NCC will notify the user via the website and by email, giving them time to perform a rollover. An organisation can also track the expiration themselves as part of their rollover procedure.
If you have further questions please let me know.
The main reason the APIs are used at all is because people like to automate things. I am not necessarily opposed to expiring / rotating secret materials, but I do have concerns about this being manually instrumented events. I agree folks need to have rollover procedures in place, but I'm not looking forward to an annual manual operation which doesn't improve security in my specific deployment for automated RPKI ROA management. Can an API be provided to facilitate API key management? Think along the lines of Let's Encrpt / ACME protocol: short-lived TLS certs are possible *because* the workflow is automated end-to-end. Kind regards, Job
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
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<mailto: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
If you're committed to mandatory API key expiry may I suggest delaying the MD5-PW removal until after OAuth2 is in place? That way we don't force people to change to something that they might only want to use for a year or so before OAuth2 is there. -Cynthia On Wed, 23 Oct 2024, 15:24 Felipe Silveira, <fvictolla@ripe.net> wrote:
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
----- 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/
participants (6)
-
Cynthia Revström -
Felipe Silveira -
Gert Doering -
Job Snijders -
Laurent Pellegrino -
Wessel Sandkuijl