[ARIN-consult] Consultation on Requiring Two-Factor Authentication (2FA) for ARIN Online Accounts

[Gary Buhrmaster]

On Tue, May 24, 2022 at 4:46 PM ARIN <info at arin.net> wrote:
>
> **Background**
>


First up, I am not a DMR, nor do I expect I will ever be
one at this point.  So, technically, I have (in my opinion)
at best, "observer" status in ARIN. That said, since
ARIN asked for opinions, I have one (there is an old
adage, be careful what you ask for, for you may get it,
and as with many of my opinions, you may not like mine).

I look at this consultation as, in fact, two different issues
(2FA and SMS usage), and believe those issues should
be addressed separately (I will do so below).


Background

The NIST 800-63 suite of guidelines provide a useful
framework to come to some common understandings
and approaches, and provides advice for operating in
best (or at least good) practices.  I recommend everyone
read the suite of guidelines.

While ARIN is not obliged to follow the NIST guidelines
well run organizations should be expected to document
their reasoning and needs to diverge from the NIST
guidance.

I will not strictly adhere to the NIST terms in my
comments below, but I believe the usage is aligned
with the intent.



Issue: SMS

While NIST acknowledges the wide prevalence of orgs
using SMS / PSTN for verification, the latest guidance
has finally (they initially proposed doing so five or so
years ago) moved to discourage SMS / PSTN factors,
calling SMS a "Restricted Authenticator".  That means
that ideally new implementations should not use it, and
organizations should start to make plans to migrate
away from it (perhaps required to do so on very short
notice).  In addition, it is expected that orgs that use
restricted authenticators must add in additional
notifications and safeguards (which are, themselves,
somewhat complicated to validate (I have no idea how
to check if the phone number entered is a real mobile
with MFA enabled, or a ITSP VoIP phone which
accepts SMS (or the number has been ported to a
ITSP VoIP phone after the number was entered, or
if the number is set to ring in multiple locations), for
example, although that might actually be a solved
problem and simply reflects my lack of knowledge
in that specific use case of knowing where a SMS
really ends up)).

At this point, it is my belief that ARIN should not
adopt SMS / PSTN for a new factor ("Just say NO
to SMS!") and if another factor type is desired to add
to the current list to complete the work they have already
agreed to do, which is implementing FIDO2.  All the
leading tech companies have agreed that (and are
putting substantial efforts behind) FIDO2 as the way
towards a future passwordless world (and I, for one,
look forward to a day that I don't *need* to have various
password management processes for hundreds of
different site passwords, although I suspect my lifetime
will be shorter than the date of that being finally
accomplished, and there will always continue to be
valid use cases where simple pin/password identification
is acceptable due to the low value/risk of the information
retrieved).



Issue: 2FA

Generically, multifactor.  NIST discusses both identity
assurance levels and risk evaluations.

It is an *org's* responsibility to determine *their* risk to
*their* resources.  And those orgs should be able to
require identity verification to *their* level of required
assurance.  Some orgs may be fine with a password,
some may choose to require a pin/password and (say)
a TOTP value, or even require a pin/password, and a
TOTP and biometric data.  Their information, their
risk evaluation, their choice.

ARINs responsibility should be to make sure that
orgs are aware of their responsibility to make their
own choices, and to enable orgs to enforce those
choices for ARIN online accounts that access *their*
resources in ARIN's registry.

And the action requested may change the level
requirements in some organizations' thoughts.  I
suspect many reading this comment (if anyone is
still reading at this point) have encountered sites
where doing something like changing your profile
requires one to up their level of identity assurance
(too many sites still use SMS) at the time of the
more impactful action.

I would be surprised to learn that ARIN has the
capability to allow an organization to differentiate
their identity assurance requirements for every
different action on ARIN online (using Owen's
example, looking at tickets might just require a
password, while modifying org data might need
the TOTP pin) which means at best an org might
be able to specify the level of assurance required
for an ARIN online account to access any of their
resources.

For those who have ARIN online accounts that can
access multiple orgs resources, I would guess the
easiest implementation will be to force the most
restrictive org's level of identity assurance for login,
and require one to have multiple ARIN online
accounts if one desires to only use a lower assurance
level for those orgs that have not required a higher
level if identity assurance, but some future
implementation should be considered where the
ARIN online account login allows one to login without
MFA, but a message of the form "Your view is currently
restricted because one/more orgs require an additional
level of identity assurance.  Please login using MFA
to enable access to all your organizations data").  That
may not be a worthwhile investment in resources, but
at least it is out there as a possible future option.

Note that while organizations should be allowed
to specify their minimal level of identity assurance
for their resources, individuals should be able to
choose a higher level requirement for themselves
(there are individuals who, due to their specifics,
are, or may be, chosen targets, and who believe
they should always use MFA (I'll use as an example
a theoretical CEO of an Internet Registry, whose
account might be considered at greater risk of
being seen as a useful target if compromised and
would logically expect to be individually targeted
and should want to require MFA "for the good
in the innertubes" (FD: Google keeps telling me
my account should require MFA because of access
to various resources and commit access to various
repos, even though my account actually already
does require MFA (and I use it), but at least
Google is trying to do the right thing)).

So, I do not believe ARIN should *require* 2FA,
it should provide the infrastructure to allow orgs
to require it if *they* so choose, based on *their*
risk evaluation.




Now that I have mostly rejected most of the proposal,
I think it is only fair to offer a few top of the head (not
fully fleshed out) alternatives to consider:

If ARIN wants to encourage MFA adoption, implement
FIDO2 as agreed, and send out two FIDO2 keys to all
ARIN online account holders who control resources
under an RSA and who requests them (I'll bet most
orgs can afford the keys, and would even prefer they
do their own sourcing, but why give some orgs yet
another reason to not use MFA?  Make it easy).
FD: I was an early adopter of U2F, and have more
FIDO2 keys than one can shake a stick at, and
whenever I can, I use the keys for the site(s) I have
access to.

Any change to an ARIN online account, or by an
ARIN online account, should allow both the online
account, and the impacted organization the ability
to be notified (both to the old and new contact
details).   "The phone number associated with your
online account has been changed.  If you did not
perform this action, contact ARIN immediately".
"The ARIN online account which has access to your
organizational data has been updated.  If you do
not approve of this action, contact ARIN...".

While time based forced password changes are
also discouraged by NIST, require all ARIN online
accounts that do not have MFA enabled by a
certain date to change their password before next
use where ARIN will be able to (at least) ensure
that password is not (currently) in one of the
many lists of known compromised passwords
(one can brute force any password with enough
time, and the list of compromised passwords
is added to all the time but a fair number of the
brutes will use the various known password
dictionary sets).  I suppose if you want to be
especially annoying, require a password change
every six months if the account does not use MFA
(although I do not really think that is a good thing).

If implementing proper MFA is currently considered
too hard, outsource the MFA support to companies
such as okta, duo, or others (review Gartner's
quadrants), which allows one to specific exactly
what level identify assurance is required for the
transaction being performed and authenticate
appropriately.

If not already done, add a captcha challenge to
multiple failed password attempts against an
account (if you fail nnn times, you are going to
get slowed down just a bit as you have to identify
the ships/trains/automobiles). Multiple different
IP sources should also trigger the challenge (yes,
I hate captcha as much as the next person, maybe
more, but they do have some benefit of training
a company's self driving AI to not drive into the
train (which is generally considered a bad thing)).



Gary