Send ARIN-consult mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.arin.net/mailman/listinfo/arin-consult
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-consult digest..."
Today's Topics:
1. Re: Consultation on API Key Handling (William Herrin)
2. Re: Consultation on API Key Handling (Chris Woodfield)
3. Re: Consultation on API Key Handling (Jo Rhett)
4. Re: Consultation on API Key Handling (Jo Rhett)
5. Re: Consultation on API Key Handling (John Curran)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Aug 2024 15:58:17 -0700
From: William Herrin <[email protected]>
Cc: [email protected]
Subject: Re: [ARIN-consult] Consultation on API Key Handling
Message-ID:
<cap-gugxax1zpdb9b3zvwf-9ehbb66bm+69ismhvgcnr3wyv...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, Aug 8, 2024 at 8:20?AM ARIN <[email protected]> wrote:
> We are seeking community input on the priority for updating the methods for
> the handling of API keys in ARIN?s RESTful provisioning system.
In my opinion...
Unless ARIN intends to release and maintain high-quality client
software libraries in each of the top 20 programming languages, it
should avoid security designs more complex than sharing a plain-text
secret within an HTTPS session. The client implementation for a
complex security scheme is pretty much always challenging and the
documentation is never good enough to get things to match byte for
byte as the security scheme tends to require.
Regards,
Bill Herrin
--
William Herrin
[email protected]
https://bill.herrin.us/
------------------------------
Message: 2
Date: Thu, 8 Aug 2024 16:27:23 -0700
From: Chris Woodfield <[email protected]>
To: William Herrin <[email protected]>
Cc: [email protected]
Subject: Re: [ARIN-consult] Consultation on API Key Handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
I?m working on the assumption that the implementation will be no more complex
than an "Authorization: Token XXXX? HTTP header, which is a well-established
pattern for API authentication. If the implementation were to be more complex
than that, I?d raise an objection as well.
-C
> On Aug 8, 2024, at 15:58, William Herrin <[email protected]> wrote:
>
> On Thu, Aug 8, 2024 at 8:20?AM ARIN <[email protected]> wrote:
>> We are seeking community input on the priority for updating the methods for
>> the handling of API keys in ARIN?s RESTful provisioning system.
>
> In my opinion...
>
> Unless ARIN intends to release and maintain high-quality client
> software libraries in each of the top 20 programming languages, it
> should avoid security designs more complex than sharing a plain-text
> secret within an HTTPS session. The client implementation for a
> complex security scheme is pretty much always challenging and the
> documentation is never good enough to get things to match byte for
> byte as the security scheme tends to require.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin
> [email protected]
> https://bill.herrin.us/
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult
> Mailing
> List ([email protected]).
> 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 [email protected] if you experience any issues.
------------------------------
Message: 3
Date: Thu, 8 Aug 2024 16:48:09 -0700
From: Jo Rhett <[email protected]>
To: Chris Woodfield <[email protected]>
Cc: William Herrin <[email protected]>, [email protected]
Subject: Re: [ARIN-consult] Consultation on API Key Handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> Unless ARIN intends to release and maintain high-quality client software
> libraries in each of the top 20 programming languages,
...
> I?m working on the assumption that the implementation will be no more complex
> than an "Authorization: Token XXXX? HTTP header, which is a well-established
> pattern for API authentication. If the implementation were to be more complex
> than that, I?d raise an objection as well.
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 Rhett
--
Jo Rhett
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.arin.net/pipermail/arin-consult/attachments/20240808/6d128738/attachment-0002.htm>
------------------------------
Message: 4
Date: Thu, 8 Aug 2024 16:48:09 -0700
From: Jo Rhett <[email protected]>
To: Chris Woodfield <[email protected]>
Cc: William Herrin <[email protected]>, [email protected]
Subject: Re: [ARIN-consult] Consultation on API Key Handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> Unless ARIN intends to release and maintain high-quality client software
> libraries in each of the top 20 programming languages,
...
> I?m working on the assumption that the implementation will be no more complex
> than an "Authorization: Token XXXX? HTTP header, which is a well-established
> pattern for API authentication. If the implementation were to be more complex
> than that, I?d raise an objection as well.
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 Rhett
--
Jo Rhett
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.arin.net/pipermail/arin-consult/attachments/20240808/6d128738/attachment-0003.htm>
------------------------------
Message: 5
Date: Fri, 9 Aug 2024 13:44:49 +0000
From: John Curran <[email protected]>
To: Jo Rhett <[email protected]>
Cc: "<[email protected]>" <[email protected]>
Subject: Re: [ARIN-consult] Consultation on API Key Handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Aug 8, 2024, at 7:48?PM, Jo Rhett <[email protected]> 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/d205a367/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-consult mailing list
[email protected]
https://lists.arin.net/mailman/listinfo/arin-consult
------------------------------
End of ARIN-consult Digest, Vol 108, Issue 4
********************************************
