Improved separation between IRR records and authentication

[mxsasha]

This is the big picture issue for RPSL authentication improvements in IRRD. Some of it may be split off to smaller issues, and this is an initial plan that will probably be adjusted. Replaces #122

Current problems

In traditional IRR databases, including the current IRRDv4, authentication is performed by creating mntner objects in the database, which have one or more authentication methods. This is not an ideal setup: it mixes the operational IRR data with authentication data.

There are several issues with this design. First, hashed passwords are directly contained in the mntner objects. As mntners are RPSL objects like others, they are fundamentally public, which is problematic for authentication information. For this reason, IRRDv4 already masks authentication hashes, but this is not an ideal solution. It makes it complex for users to update objects, and especially difficult and error prone when they would like to provide access under multiple different passwords. A second issue is that, while email notifications are supported, it is difficult for users to discover what modifications have been made to their objects, and how those were authorised. Third, this design is not very extendable. Fourth, IRRDv4 allows administrators to bypass authentication for any object using a single override password, which is a low level of security for such extensive access.

New authentication options

The more fundamental solution is to separate authentication data, which is private, from the operational RPSL data in the IRR, which is public by design. This not only resolves issues around authentication hashes, but also allows new features like API keys or having users with different permission levels. In the future, it could allow RPSL authentication to be linked to an SSO solution.

The initial implementation plan is as follows. All of this is opt-in, i.e. IRRD can keep working entirely as is for operators who prefer that.

• The IRRD database will be extended with user and authentication data. This
  will be a separate data store, which is not mixed with regular IRR objects. It
  will be part of the existing PostgreSQL database.
• Existing legacy maintainers will function as before. They can be migrated to
  new style maintainers. In new style maintainers, the IRR object is kept simple,
  and all authentication data is kept in IRRD’s authentication store.
• IRRD will provide an authentication/authorisation website, designed for
  human users. This is the portal where authentication information will be
  managed.
• Users can create an account here, based on an e-mail address, password and
  optional two factor authentication. The e-mail address will be validated.
• After creating an account, a user can migrate a current mntner, by providing a
  valid current password for that mntner, and a confirmation link sent to the mntner’s
  admin-c. The current user is automatically authorised on the mntner at user
  management permission levels.
• During migration, existing authentication methods are migrated as well, so
  that existing integrations continue working. They will be removed from the
  object in the IRR database and moved to IRRD’s authentication store.
• A user with user management permissions on a mntner can add or remove
  other users (that have already made an account) to/from a mntner.
• The new web interface will allow users to submit updates directly to IRRD, in
  the same format as an email, without needing manual authentication
  information (similar to RIPE syncupdates).
• This new web interface for manual object submission will also be open to users
  using legacy password authentication, offering a more secure channel than
  emailing tokens or passwords.
• All users can add API tokens to their account, to be used with the existing
  object submission interfaces over email and the HTTPS API. API tokens can
  be restricted to a submission method and/or IP range.
• All current authorisations and API tokens are visible to all users with user
  management permissions, for that mntner.
• A log will be kept of all authenticated actions associated with a migrated
  mntner, including those performed with API keys, and changes to objects.
  This is visible to all users with user management permissions.
• When users forget their password, they can reset their password by e-mail.
  Resetting the two factor authentication can only be done by IRRD
  administrators.
• The two factor authentication will support TOTP, compatible with Google
  Authenticator, Authy and many other apps, and U2F tokens, like the
  YubiKey, on supported browsers.
• Override access can be moved to the same portal, removing the need to share
  a single password. The initial user in this case is created through a new IRRD
  command.
• Legacy maintainers, that have not been migrated, will keep working as before.
  They will not gain new features like the action log.
• The new authentication data will not be included in NRTM exports, as this
  data is not in IRR objects. An additional import/export method will be
  designed for this data.
• Draft release notes block
• Look over docs coherency

Other ideas to consider:

• [ ] OAuth integration (out of scope at this time)

[fischerdouglas]

Have you considered to support Oauth integrations?
PeeringDB already supports to be an OAuth base.

I believe we will see something in this direction by the RIRs in some time from now.
And that would be fantastic to IRRs.

[mxsasha]

Have you considered to support Oauth integrations? PeeringDB already supports to be an OAuth base.

Not yet, but it's an interesting idea. Added it to the list to explore.

[mxsasha]

This is completed by #812, #811, #807, #792, #787, #671. Docs: https://irrd.readthedocs.io/en/latest/admins/webui/