From info at arin.net Thu Aug 8 11:20:49 2024 From: info at arin.net (ARIN) Date: Thu, 8 Aug 2024 11:20:49 -0400 Subject: [ARIN-consult] Consultation on API Key Handling Message-ID: 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/). 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. You can subscribe to this mailing list at 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) From rlaager at wiktel.com Thu Aug 8 12:52:19 2024 From: rlaager at wiktel.com (Richard Laager) Date: Thu, 8 Aug 2024 11:52:19 -0500 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: References: Message-ID: <5b69b41d-f8d6-4205-b80f-950c34db7e96@wiktel.com> 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 From jcurran at arin.net Thu Aug 8 13:31:54 2024 From: jcurran at arin.net (John Curran) Date: Thu, 8 Aug 2024 17:31:54 +0000 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: <5b69b41d-f8d6-4205-b80f-950c34db7e96@wiktel.com> References: <5b69b41d-f8d6-4205-b80f-950c34db7e96@wiktel.com> Message-ID: <4394BDAB-1964-4C30-9C92-67A06A360E3F@arin.net> > On Aug 8, 2024, at 12:52?PM, Richard Laager via ARIN-consult 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 From Daniel.Schatte at charter.com Thu Aug 8 18:02:06 2024 From: Daniel.Schatte at charter.com (Schatte, Daniel K) Date: Thu, 8 Aug 2024 22:02:06 +0000 Subject: [ARIN-consult] [EXTERNAL] Consultation on API Key Handling In-Reply-To: References: Message-ID: <7AA8FF1E-5762-44CE-B881-1DEA5FC98D5E@charter.com> 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" on behalf of 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/ ). 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 . You can subscribe to this mailing list at 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 ). 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. 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. From scottleibrand at gmail.com Thu Aug 8 18:16:55 2024 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 8 Aug 2024 15:16:55 -0700 Subject: [ARIN-consult] [EXTERNAL] Consultation on API Key Handling In-Reply-To: <7AA8FF1E-5762-44CE-B881-1DEA5FC98D5E@charter.com> References: <7AA8FF1E-5762-44CE-B881-1DEA5FC98D5E@charter.com> Message-ID: 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 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 on > behalf of 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 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 ). > 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 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: From chris at semihuman.com Thu Aug 8 18:36:13 2024 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 8 Aug 2024 15:36:13 -0700 Subject: [ARIN-consult] [EXTERNAL] Consultation on API Key Handling In-Reply-To: References: <7AA8FF1E-5762-44CE-B881-1DEA5FC98D5E@charter.com> Message-ID: <5FF4C825-10FD-4112-9B6D-B8FEBF206098@semihuman.com> 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 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 > 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" > on behalf of 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/ ). 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 >. You can subscribe to this mailing list at 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 >). >> 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. >> >> >> >> 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. > _______________________________________________ > 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: From bill at herrin.us Thu Aug 8 18:58:17 2024 From: bill at herrin.us (William Herrin) Date: Thu, 8 Aug 2024 15:58:17 -0700 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: References: Message-ID: On Thu, Aug 8, 2024 at 8:20?AM ARIN 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 bill at herrin.us https://bill.herrin.us/ From chris at semihuman.com Thu Aug 8 19:27:23 2024 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 8 Aug 2024 16:27:23 -0700 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: References: Message-ID: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> 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 wrote: > > On Thu, Aug 8, 2024 at 8:20?AM ARIN 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 > bill at herrin.us > https://bill.herrin.us/ > _______________________________________________ > 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. From geek at jorhett.com Thu Aug 8 19:48:09 2024 From: geek at jorhett.com (Jo Rhett) Date: Thu, 8 Aug 2024 16:48:09 -0700 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> References: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> Message-ID: <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> > 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: From geek at jorhett.com Thu Aug 8 19:48:09 2024 From: geek at jorhett.com (Jo Rhett) Date: Thu, 8 Aug 2024 16:48:09 -0700 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> References: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> Message-ID: <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> > 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: From jcurran at arin.net Fri Aug 9 09:44:49 2024 From: jcurran at arin.net (John Curran) Date: Fri, 9 Aug 2024 13:44:49 +0000 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> References: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> Message-ID: <9F0B2217-AE6E-4CC5-AB65-29098B06A8BD@arin.net> On Aug 8, 2024, at 7:48?PM, Jo Rhett 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: From athompso at athompso.net Fri Aug 9 09:55:57 2024 From: athompso at athompso.net (Adam Thompson) Date: Fri, 9 Aug 2024 13:55:57 +0000 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: <9F0B2217-AE6E-4CC5-AB65-29098B06A8BD@arin.net> References: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> <9F0B2217-AE6E-4CC5-AB65-29098B06A8BD@arin.net> Message-ID: 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 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 ________________________________ From: ARIN-consult on behalf of John Curran Sent: Friday, August 9, 2024 8:44:49 AM To: Jo Rhett Cc: Subject: Re: [ARIN-consult] Consultation on API Key Handling On Aug 8, 2024, at 7:48?PM, Jo Rhett 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: From da.sheppard at uwinnipeg.ca Fri Aug 9 12:59:45 2024 From: da.sheppard at uwinnipeg.ca (Daniel Sheppard) Date: Fri, 9 Aug 2024 16:59:45 +0000 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> References: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> Message-ID: There is nothing wrong with Bearer/Token Authentication, which is a well defined standard and widely used by many frameworks. "Authentication: Token XXXX" is not a "unique" model and I would say the simplicity of that is potentially more useful then moving to something like OAuth 2, JWT, or OpenID Connect. The simplicity of token authentication is actually why it is fairly widely recommended over using OAuth 2.0 Token Access for programmatic access to a RESTful API. You can use OAuth 2.0 to generate a token, but then your creds for generating that token are stored on your system, instead of just the limited access token itself. In fact, RFC6750 specifies the use of "Authorization: Bearer" for API endpoint access. TLDR; "Authorization: Token" is a valid, widely recognized "model" for REST API access. From: ARIN-consult On Behalf Of Jo Rhett Sent: Thursday, August 8, 2024 6:48 PM To: Chris Woodfield Cc: arin-consult at arin.net Subject: Re: [ARIN-consult] Consultation on API Key Handling You don't often get email from geek at jorhett.com. Learn why this is important Notice: This is external email. Verify the sender and use caution with any content. 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: From bill at herrin.us Fri Aug 9 18:35:54 2024 From: bill at herrin.us (William Herrin) Date: Fri, 9 Aug 2024 15:35:54 -0700 Subject: [ARIN-consult] Consultation on API Key Handling In-Reply-To: References: <0E4C5A42-5ADC-4920-B029-91D834883374@semihuman.com> <656B54AB-A045-45BC-8DC0-A540D9ACF742@jorhett.com> Message-ID: On Fri, Aug 9, 2024 at 9:59?AM Daniel Sheppard wrote: > There is nothing wrong with Bearer/Token Authentication, which is a well defined > standard and widely used by many frameworks. ?Authentication: Token XXXX? > is not a ?unique? model and I would say the simplicity of that is potentially more > useful then moving to something like OAuth 2, JWT, or OpenID Connect. Hi Daniel, OAuth is one of those complex schemes that I personally don't like working with. It usually gets used by presenting the core credentials to get a token for each set of operations anyway, just with extra steps for the programmer to deal with. I've worked with JWT before and it scares me. The typical use is to embed cryptographically authenticated authorizations within the token. The client literally tells the server what it's allowed to do, so if anyone ever manages to break the encryption you're wide open to the world. I haven't looked at OpenID Connect but it smells like a meta-layer on top of the other two, adding more complexity. I personally like embedding the shared secret in form-data. Yes it can be logged if embedded in a GET request, but it's easy to debug via a web browser and isn't recorded when embedded in a POST request. Server logging can be turned off or modified to discard everything after the "?" if ARIN is concerned about that aspect. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From info at arin.net Mon Aug 26 11:19:33 2024 From: info at arin.net (ARIN) Date: Mon, 26 Aug 2024 11:19:33 -0400 Subject: [ARIN-consult] Consultation on ARIN Online Change Notifications Message-ID: ARIN is seeking feedback from the community on a potential improvement (https://www.arin.net/participate/community/acsp/consultations/2024/2024-4/), suggested by a community member, that ARIN create a modern mechanism that allows resource holders to be notified of any changes to resources or accounts they manage. The stated benefit of this potential improvement is that it would allow greater control over valuable resources and increase the accuracy of ARIN?s database. We have identified two options to create these notifications: Email - The least ?modern? option, but this would be consistent with other ARIN notifications, and mirrors what is available through the other Regional Internet Registries (RIRs). This would take approximately three months to develop once work is scheduled. REST endpoint ? ARIN can define a REST endpoint, and customers would have to develop/deploy and then provide us the URL to send notifications to. This would take approximately six months to develop once work is scheduled. These options vary in complexity to develop, and the level of effort required for customer adoption. We are interested in community feedback on the value of a change notification feature and thoughts on the possible delivery methods described or others you may suggest. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open until 5:00 PM ET on 9 September. 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) From peter.potvin at accuristechnologies.ca Mon Aug 26 11:23:43 2024 From: peter.potvin at accuristechnologies.ca (Peter Potvin) Date: Mon, 26 Aug 2024 11:23:43 -0400 Subject: [ARIN-consult] Consultation on ARIN Online Change Notifications In-Reply-To: References: Message-ID: I would like to see email notifications implemented as a bare minimum, with the option for API-based notifications at a later date. Kind regards, Peter Potvin On Mon, Aug 26, 2024 at 11:19?AM ARIN wrote: > ARIN is seeking feedback from the community on a potential improvement ( > https://www.arin.net/participate/community/acsp/consultations/2024/2024-4/), > suggested by a community member, that ARIN create a modern mechanism that > allows resource holders to be notified of any changes to resources or > accounts they manage. > > The stated benefit of this potential improvement is that it would allow > greater control over valuable resources and increase the accuracy of ARIN?s > database. > > We have identified two options to create these notifications: > > Email - The least ?modern? option, but this would be consistent with other > ARIN notifications, and mirrors what is available through the other > Regional Internet Registries (RIRs). This would take approximately three > months to develop once work is scheduled. > > REST endpoint ? ARIN can define a REST endpoint, and customers would have > to develop/deploy and then provide us the URL to send notifications to. > This would take approximately six months to develop once work is > scheduled. > > These options vary in complexity to develop, and the level of effort > required for customer adoption. We are interested in community feedback on > the value of a change notification feature and thoughts on the possible > delivery methods described or others you may suggest. > > Please provide comments to arin-consult at arin.net. You can subscribe to > this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult > > This consultation will remain open until 5:00 PM ET on 9 September. 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). > 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: From kevinb at thewire.ca Mon Aug 26 11:29:22 2024 From: kevinb at thewire.ca (Kevin Blumberg) Date: Mon, 26 Aug 2024 15:29:22 +0000 Subject: [ARIN-consult] Consultation on ARIN Online Change Notifications In-Reply-To: References: Message-ID: The first option, email, is really the only choice for many organizations. Passing the cost on to a Small, X-Small etc Organization to deploy a REST API component doesn?t match the benefit. I would assume that the notifications would also show in ARIN online, similar to a log. Thanks, Kevin Blumberg From: ARIN-consult On Behalf Of Peter Potvin via ARIN-consult Sent: Monday, August 26, 2024 11:24 AM To: arin-consult at arin.net Subject: Re: [ARIN-consult] Consultation on ARIN Online Change Notifications I would like to see email notifications implemented as a bare minimum, with the option for API-based notifications at a later date. Kind regards, Peter Potvin On Mon, Aug 26, 2024 at 11:19?AM ARIN > wrote: ARIN is seeking feedback from the community on a potential improvement (https://www.arin.net/participate/community/acsp/consultations/2024/2024-4/), suggested by a community member, that ARIN create a modern mechanism that allows resource holders to be notified of any changes to resources or accounts they manage. The stated benefit of this potential improvement is that it would allow greater control over valuable resources and increase the accuracy of ARIN?s database. We have identified two options to create these notifications: Email - The least ?modern? option, but this would be consistent with other ARIN notifications, and mirrors what is available through the other Regional Internet Registries (RIRs). This would take approximately three months to develop once work is scheduled. REST endpoint ? ARIN can define a REST endpoint, and customers would have to develop/deploy and then provide us the URL to send notifications to. This would take approximately six months to develop once work is scheduled. These options vary in complexity to develop, and the level of effort required for customer adoption. We are interested in community feedback on the value of a change notification feature and thoughts on the possible delivery methods described or others you may suggest. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open until 5:00 PM ET on 9 September. 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). 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: From roman at intlos.org Mon Aug 26 11:47:11 2024 From: roman at intlos.org (Roman Tatarnikov) Date: Mon, 26 Aug 2024 08:47:11 -0700 Subject: [ARIN-consult] Consultation on ARIN Online Change Notifications In-Reply-To: References: Message-ID: I think both Email and API should be good. API gives ability to integrate all the notifications with some kind of CRM/ERP/Monitoring System, while emails will ensure that people who don't have such systems (or need for ARIN Notifications in them) can still remain in the loop. There actually has been one item I wanted to advise for email notifications for a while - it's to use X-Headers. This will allow for better filtration and prioritization. For example, I have the following rules: :0 * FROM ?? arin-tech-discuss(-bounces)?@arin\.net * SUBJECT ?? ^\[arin-tech-discuss\] Completion of ([A-Za-z]+ )?Operation Testing ([Aa]nd|\&) Evaluation( Monthly Maintenance)? | rm -f `grep -rlE '^Subject: \[arin-tech-discuss\] (Monthly )?Operational Testing (and|\&) Evaluation( Monthly Maintenance)?' ~/Maildir/.Inbox/new` The idea is that once OT&E is completed, the email announcing its start would be deleted. Pretty simple, except that Subject line varies a lot and this filter doesn't always work. Plus, the line of code is longer than 80 symbols, so it makes me want to pull my hair out. I know, my own fault, so lets move on. If there were X-Headers for various notification types then we wouldn't rely on verbiage of Subject and could filter everything better in GMail/`procmail`. For example: :0 * SUBJECT ?? your posts got .+ impressions last week * ^X-LinkedIn-Class: EMAIL-DEFAULT$ * ^X-LinkedIn-Template: email_weekly_analytics_recap$ /dev/null I know that tons of people say that they "never check email" and that's it's "so 90s", but a huge amount of people who are active in network operations and internet governance use email a lot. I suspect the audience that would interact with ARIN notifications is full of people who would prefer email. On Mon, Aug 26, 2024 at 11:23:43AM -0400, Peter Potvin via ARIN-consult wrote: > I would like to see email notifications implemented as a bare minimum, with > the option for API-based notifications at a later date. > > Kind regards, > Peter Potvin > > > On Mon, Aug 26, 2024 at 11:19?AM ARIN wrote: > > > ARIN is seeking feedback from the community on a potential improvement ( > > https://www.arin.net/participate/community/acsp/consultations/2024/2024-4/), > > suggested by a community member, that ARIN create a modern mechanism that > > allows resource holders to be notified of any changes to resources or > > accounts they manage. > > > > The stated benefit of this potential improvement is that it would allow > > greater control over valuable resources and increase the accuracy of ARIN?s > > database. > > > > We have identified two options to create these notifications: > > > > Email - The least ?modern? option, but this would be consistent with other > > ARIN notifications, and mirrors what is available through the other > > Regional Internet Registries (RIRs). This would take approximately three > > months to develop once work is scheduled. > > > > REST endpoint ? ARIN can define a REST endpoint, and customers would have > > to develop/deploy and then provide us the URL to send notifications to. > > This would take approximately six months to develop once work is > > scheduled. > > > > These options vary in complexity to develop, and the level of effort > > required for customer adoption. We are interested in community feedback on > > the value of a change notification feature and thoughts on the possible > > delivery methods described or others you may suggest. > > > > Please provide comments to arin-consult at arin.net. You can subscribe to > > this mailing list at https://lists.arin.net/mailman/listinfo/arin-consult > > > > This consultation will remain open until 5:00 PM ET on 9 September. 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) -- Roman V Tatarnikov | https://linkedin.com/in/rtatarnikov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From bill at herrin.us Mon Aug 26 12:23:26 2024 From: bill at herrin.us (William Herrin) Date: Mon, 26 Aug 2024 09:23:26 -0700 Subject: [ARIN-consult] Consultation on ARIN Online Change Notifications In-Reply-To: References: Message-ID: On Mon, Aug 26, 2024 at 8:19?AM ARIN wrote: > Email - The least ?modern? option, but this would be consistent > with other ARIN notifications, and mirrors what is available > through the other Regional Internet Registries (RIRs). This > would take approximately three months to develop once work is scheduled. For small holders, this would be valuable. It's helpful to receive a notice that something changed when you weren't expecting anything to change. It's even more helpful if there's a 1-click option to cancel or otherwise dispute the change. > REST endpoint ? ARIN can define a REST endpoint, and customers > would have to develop/deploy and then provide us the URL to send > notifications to. This would take approximately six months to > develop once work is scheduled. I don't know if this would be valuable. It'd take an awful lot of man-hours to do anything useful with it. I'd be interested if folks representing large holders would be willing to put in the software development time. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From jcolebeyond57 at gmail.com Fri Aug 23 01:21:07 2024 From: jcolebeyond57 at gmail.com (Jennifer Jackson) Date: Fri, 23 Aug 2024 00:21:07 -0500 Subject: [ARIN-consult] (no subject) Message-ID: Jennifer Jackson 5125389389 Beyondcorpenterprisellc at gmail.com beyond Trust Corporate Enterprise Jcolebeyond koalified -------------- next part -------------- An HTML attachment was scrubbed... URL: