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 (Richard Laager)
2. Re: Consultation on API Key Handling (John Curran)
3. Re: [EXTERNAL] Consultation on API Key Handling
(Schatte, Daniel K)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Aug 2024 11:52:19 -0500
From: Richard Laager <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [ARIN-consult] Consultation on API Key Handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 2024-08-08 10:20, ARIN wrote:
> 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
Having that option seems to be pretty typical these days. I support ARIN
adding this option.
> and to use IP address range bounding to limit the validity of an API key
Having that option potentially increases security. I support ARIN adding
this option.
Whether it should be required to limit by IP is another question. It
doesn't sound like ARIN is proposing to require that. If I were ARIN, I
probably would not require that, at least not initially. As a user, for
my use cases, requiring IP limitation would be fine, though, so I
personally wouldn't object.
> When the API key is included in the payload, it is encrypted which increases
> the security of these programmatic transactions with ARIN systems.
I don't understand this. What payload encryption is being referenced?
> The current system relies on the security of the connection between the
> networks that transport these plain text API keys.
The current system allows HTTPS. So, yes, you rely on the security of
the connection, which is HTTPS. That is not a problem.
> How urgent is the need for ARIN to bring its API key handling in line with
> the current best practices?
It doesn't seem super urgent. But it seems pretty trivial to do. The
consultation will take more time than implementing it.
> 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.
Headers and body are equally encrypted when using HTTPS, so I do not
understand this sentence.
--
Richard
------------------------------
Message: 2
Date: Thu, 8 Aug 2024 17:31:54 +0000
From: John Curran <[email protected]>
To: Richard Laager <[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 12:52?PM, Richard Laager via ARIN-consult
> <[email protected]> wrote:
>
> On 2024-08-08 10:20, ARIN wrote:
>
>> 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.
>
> Headers and body are equally encrypted when using HTTPS, so I do not
> understand this sentence.
Apologies - this is less clear than it could be? URLs are often obtainable in
plain-text via web server & caching logs ? thus providing an option for passing
their API password via header parameter gives customers the ability to avoid
having their API password exposed in this manner.
Thanks,
/John
John Curran
President and CEO
American Registry for Internet Numbers
------------------------------
Message: 3
Date: Thu, 8 Aug 2024 22:02:06 +0000
From: "Schatte, Daniel K" <[email protected]>
To: ARIN <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [ARIN-consult] [EXTERNAL] Consultation on API Key
Handling
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
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"
<[email protected] <mailto:[email protected]> on behalf
of [email protected] <mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]>. 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 ([email protected] <mailto:[email protected]>).
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 [email protected] <mailto:[email protected]> 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.
------------------------------
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 2
********************************************
