[ARIN-consult] [EXTERNAL] Consultation on API Key Handling

[Schatte, Daniel K]

I am in support of adding in the option for adding the API keys into the header parameter. I would also support this as a phased approach where either way is acceptable for a given period (3-6 months) before the removal of the less secure methodology is retired. This would then remove the ability to pass the API key in clear text as part of the URL.

As far as limiting the IP Address ranges, that is something I'd like to see implemented as well. This would need to be visible and controllable at the Org ID level and not based upon a per account login for API keys that are created. That way administrators of an Org ID can ensure that anyone who creates API keys are being locked down to specific IP Address ranges and not left open.


-Daniel




On 8/8/24, 9:23 AM, "ARIN-consult on behalf of ARIN" <arin-consult-bounces at arin.net <mailto:arin-consult-bounces at arin.net> on behalf of info at arin.net <mailto:info at arin.net>> wrote:


CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.




ARIN is seeking feedback from the community on a potential improvement to increase the security for Application Programming Interface (API) key handling, specifically allowing the option to pass API keys in the header of a Restful Payload, and to use IP address range bounding to limit the validity of an API key (https://www.arin.net/participate/community/acsp/consultations/2024/2024-3/ <https://www.arin.net/participate/community/acsp/consultations/2024/2024-3/>). The benefit of this potential improvement is that it would give users options to make their API keys more secure and bring ARIN in line with best practices for API key handling.


ARIN’s RESTful Provisioning system leverages modern application interfaces and provides even stronger authentication. RESTful calls require the use of an API key. Since the development of these systems, best practices have evolved to make them more secure. When the API key is included in the payload, it is encrypted which increases the security of these programmatic transactions with ARIN systems. The current system relies on the security of the connection between the networks that transport these plain text API keys. How urgent is the need for ARIN to bring its API key handling in line with the current best practices?


By adding functionality to allow the API keys to be shared as a header parameter, ARIN would create an option for customers who prefer to encrypt their API keys. By further allowing customers to set IP address boundaries for an API key’s usage, they can better control how their API keys are used.


We are seeking community input on the priority for updating the methods for the handling of API keys in ARIN’s RESTful provisioning system.


Please provide comments to arin-consult at arin.net <mailto:arin-consult at arin.net>. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult <https://lists.arin.net/mailman/listinfo/arin-consult>.


This consultation will remain open until 5:00 PM ET on 23 August. ARIN seeks clear direction through community input, so your feedback is important.


Thank you for your continued support to improve ARIN’s services.


Regards,


John Curran
President and CEO
American Registry for Internet Numbers (ARIN)
_______________________________________________
ARIN-Consult
You are receiving this message because you are subscribed to the ARIN Consult Mailing
List (ARIN-consult at arin.net <mailto:ARIN-consult at arin.net>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-consult <https://lists.arin.net/mailman/listinfo/arin-consult> Please contact the ARIN Member Services
Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.



The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.