[arin-ppml] API Key Security Issue

Frank Bulk frnkblk at iname.com
Thu Dec 1 18:27:20 EST 2022


Thanks for your comprehensive reply and clarifications.

I may have misunderstood the emailed warning I received earlier this week -- I was initially led to think that email templates can work without an API key. But looking at the templates, it looks like an API key is required. If that's the case, what was the reason for the warning about email spoofing if the spoofer still needs the API key to make the change?

The reason I wrote the email to arin-ppl was because I was thinking of limiting our attack surface -- if our organization would always and only use the website to make registration changes, it would be ideal if I, as a super-admin (which doesn't exist), could disable the use of the API or email templates. Similarly, if an organization only ever used the API, allow the super-admin to disable the use of the web interface or email templates to make configuration changes.

If others also believe there should be configurable options to limit the mechanisms that can be used to make changes, please let me know and I can submit a suggestion.


-----Original Message-----
From: Jon Worley <jonw at arin.net> 
Sent: Thursday, December 1, 2022 1:37 PM
To: frnkblk at iname.com; arin-ppml at arin.net
Subject: Re: [arin-ppml] API Key Security Issue

Hi Frank,

I'll start by defining "authorized users" as any web user who's linked to a point of contact handle that's specified as an administrative or technical contact on your Org ID.

The only way to prevent processing of templates (1) and API calls (2) is to make sure no authorized user has an active API key (a shared secret generated and put into the template/call to identify the user). You can't directly do this. You can't view each authorized user and confirm they have no active API keys; you'd have to set a policy that asks that no authorized user has an active API key. There's also no switch to disable API keys. Were you to do this, the only way authorized users could do things would be via the web site (3). Again, though, you'd have to enforce this on your side. That being said, if you trust your authorized users to not create API keys, this would somewhat accomplish what you're asking to do.

A note: you CAN prevent processing of email templates based solely on MAIL-FROM by asking your authorized users not to add an email address to an active API key. Again, enforced by you. Note also that there's no requirement to have personal contact information publicly visible. You may have all points of contact be role contacts; each user can then link to those role contacts. The web account contact information is not publicly visible.

There is no way to prevent authorized users from making changes via the web site (3). You'd have to remove them as an authorized user to stop them from making changes via the web. 

Now, a caveat: we do have contact types other than admin/tech that can restrict authorization. Abuse and NOC contacts are display-only; web users linked only to those contacts cannot do anything other than edit their own contact information. They’re just publicly displayed with your records. We also have routing contacts and DNS contacts which are restricted to actions related to routing (IRR, RPKI, etc) and DNS (rDNS, DNSSEC, etc) respectively. The same restrictions as noted above apply; this just limits the sphere of authorized actions to routing/DNS.

Hope that answers your questions. We left a message with a callback number in case you want to set up a call to discuss further.

Thanks & best regards,

Jon Worley
Senior Technology Architect
American Registry for Internet Numbers (ARIN) 

On 11/30/22, 11:35 AM, "ARIN-PPML on behalf of Frank Bulk" <arin-ppml-bounces at arin.net on behalf of frnkblk at iname.com> wrote:

    We received an email today about the risk of using an email address that is
    publicly visible in WHOIS for our registered MAIL FROM authentication email

    Is there a way to turn off/turn on the following options:
    1. email templates for changing records2.
    2. API
    3. ARIN web GUI


    Frank Bulk
    Premier Communications 

    You are receiving this message because you are subscribed to
    the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
    Unsubscribe or manage your mailing list subscription at:
    Please contact info at arin.net if you experience any issues.

Links contained in this email have been replaced. If you click on a link in the email above, the link will be analyzed for known threats. If a known threat is found, you will not be able to proceed to the destination. If suspicious content is detected, you will see a warning.

More information about the ARIN-PPML mailing list