[ARIN-consult] Consultation on API Key Handling

[Adam Thompson]

I agree with some of the other commenters - security is not an area ARIN should be actively reinventing.

Simple is good when protected by a trusted layer (HTTPS).  Well, sorta trusted, but we all know its limitations fairly well by now.

That proposed change seems simple and harmless enough, but I think the point here is, please stop iterating on a home-grown design.

Instead, allocate resources to a v<next> API that relies on some well-established, pre-existing security architecture in the field that fits both ARIN and the community adequately.

We all like things where adding it to our automation looks like "import securitymodule;" at the top of our scripts or "-loverride_lib" in our makefiles.  (Yes, I'm exaggerating a bit here.  But pre-existing architectures tend to have pre-existing implementations and sample code and documentation.)

-Adam

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: ARIN-consult <arin-consult-bounces at arin.net> on behalf of John Curran <jcurran at arin.net>
Sent: Friday, August 9, 2024 8:44:49 AM
To: Jo Rhett <geek at jorhett.com>
Cc: <arin-consult at arin.net> <arin-consult at arin.net>
Subject: Re: [ARIN-consult] Consultation on API Key Handling


On Aug 8, 2024, at 7:48 PM, Jo Rhett <geek at jorhett.com> wrote:

There's no reason to build something raw and native. There are dozens of robust, well-tested security frameworks for authentication that are implemented by every platform and language already. OAuth 2, JWT, OpenID Connect, ...

Yes, those align with (but are greater than) plaintext headers. Don't go creating a unique model unless none of the well-established, widely used frameworks won't meet the needs.

Jo -

Interesting thoughts - this consultation primarily focuses on whether ARIN should improve key handling for its existing deployed APIs, but you raise some excellent questions.

To be clear, you’re advocating for ARIN to switch its API authentication towards a more common and accepted authentication framework (e.g. OAuth 2) rather than investing in improving the key handling for the existing RESTful API’s?    If that’s the case, are you recommending that the existing support for key-based API authentication be deprecated, or simply maintained as-is?

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20240809/88e4418c/attachment.htm>