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

Scott Leibrand scottleibrand at gmail.com
Thu Aug 8 18:16:55 EDT 2024


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>
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> 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.
> _______________________________________________
> 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/9d7882ca/attachment.htm>


More information about the ARIN-consult mailing list