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

[Chris Woodfield]

I believe that one use case that hinges on ?apikey= is the desire to view the JSON output of a query in a web browser, which can’t be duplicated with a key carried in an Authorization header (at least not without using ModHeader or other extensions). That said, the practice also allows queries to be bookmarked with apikey included, which may be stored insecurely on a client device. 

If that is a compelling use case, then removing the ability to pass ?apikey= in the URL should be retained. I see it mainly as a convenience - apps such as PostMan handle this far more elegantly IMO.

I agree wholeheartedly with Daniel on the IP address range whitelist feature, and agree that it should be configurable in a way that allows an org to apply a given whitelist to any new keys created for an org.

Thanks,

-Chris

> On Aug 8, 2024, at 15:16, Scott Leibrand <scottleibrand at gmail.com> wrote:
> 
> Passing credentials in a URL is secure under certain common conditions (direct TLS to ARIN without any proxies), so IMO it shouldn't be necessary to retire it as an option, just remove/deprecate that method from documentation, frameworks, etc. in favor of defaulting to the more-secure header option.
> 
> -Scott
> 
> On Thu, Aug 8, 2024 at 3:02 PM Schatte, Daniel K <Daniel.Schatte at charter.com <mailto:Daniel.Schatte at charter.com>> wrote:
>> 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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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.
>> _______________________________________________
>> 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 Please contact the ARIN Member Services
>> Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20240808/6642dc8e/attachment-0001.htm>