Hello Cynthia,

I really do not see any benefits or reasons why we should change the API key system for the DB. Maybe I am missing something that you can elaborate on.

«An API key system for the DB» does not exist today. I do not propose to change this non-existent system. I propose to create one.

Additionally if this was to replace the existing system it would just make it unavailable for non-LIRs (such as orgs with PI resources) without any real reason.

I do not propose to replace any authentication or authorisation method that already exists today. Tore

* Cynthia Revström

But it does have something very similar, md5-pw and I really don't see why this is not adequate. Just generate a 64 character hex string put it as a password and boom you have an API key.

My question is, how would having a dedicated API key feature help? 

The API keys system in the LIR portal is much easier to use. You can very easily issue and revoke API keys, see which keys are already active, who issued them and when, etc. It does not make sense to me for the RIPE database APIs to not participate in this system. Again, and to be absolutely clear, I do not propose to remove the MD5-PW authentication method. If you are using it and you are happy with it, then rest assured that this proposal will not take anything away from you. Tore

Hi, I do really like Kirilo's ideas, I do think that there should be a way to limit API keys to an IP address/prefix. My main concern is that I would like it to remain separate from the LIR portal, if there is a way to do this without relying on the LIR portal, I am all for it :) I don't want too many features in the RIPE DB to rely upon the user being an LIR. - Cynthia On Mon, Mar 16, 2020 at 11:52 AM Kirilo Vasiļiskovs via db-wg <db-wg@ripe.net> wrote:

Hello,

I also vote for a proper way of doing things. Normally APIs have their own ways of access management. Some of API key features are essential for access control: - API keys can be easily regenerated without changing normal account access (ok, this one is arguable benefit as we can just change the MD5 password if needed) - API keys and APIs have some mechanism to restrict access to just certain IPs (I don't remember this feature for MD5 passwords at all) - NOC people that have access to mntner objects and software developers are often different people, and so their access should be specifically limited to their job (e.g. giving API keys to the developers instead of the full access to mntner object).

That's just a few advantages from the surface of my mind. I guess other people can add more.

Respectfully / Ar cieņu, Kirilo Vasiļiskovs.

ср, 11 мар. 2020 г. в 13:22, Sebastian Wiesinger via db-wg <db-wg@ripe.net>:

...

* Tore Anderson via db-wg <db-wg@ripe.net> [2020-02-21 11:54]:

...

Hi WG.

In the LIR Portal, at https://lirportal.ripe.net/api/, it is possible to issue API keys for use with several different RIPE NCC services.

However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW.

Hello,

I would support a modern approach to authorisation with the WEB API. I don't think it should be bound the LIR portal (as there might be users who are not an LIR). But some sort of API-friendly authentication for maintainers would be appreciated, maybe coupled to SSO user accounts. Just sending the password as an URL parameter is not really a modern approach, also you would need to change the maintainer password every time someone leaves the company.

Best Regards

Sebastian

-- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

Hi Ed, That sounds like a good plan to me, +1 :) - Cynthia On Tue, Mar 17, 2020 at 6:01 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote:

Dear Colleagues,

I support this proposal, it's an improvement for RIPE DB users and also benefits the DB team.

I propose implementing the feature within an SSO account, as both the LIR Portal and RIPE database (at least) can share the same feature, and we reduce the implementation cost.

We should not require an LIR Portal account for this feature, it should be available to all users.

If we associate the API key to an SSO account, then authentication is done as that user. By contrast, an MD5 password is associated with a (possibly shared) maintainer and is effectively anonymous.

If we store the API key outside the RIPE database, we also reduce the disk of a data breach of the RIPE database exposing user credentials.

Finally, this approach avoids schema changes to the RIPE database itself, which simplifies the implementation for the DB team.

Regards Ed Shryane RIPE NCC

...

On 21 Feb 2020, at 11:53, Tore Anderson via db-wg <db-wg@ripe.net> wrote:

Hi WG.

In the LIR Portal, at https://lirportal.ripe.net/api/, it is possible to issue API keys for use with several different RIPE NCC services.

However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW.

I propose that the API keys mechanism is extended to Syncupdates and the RESTful API.

The already existing default maintainer concept could be leveraged to accomplish this (similar to how NWI-8 was implemented). That is, using Syncupdates or the RESTful API with API keys will simply authenticate the client as the LIR's default maintainer.

Authorisation should remain handled by in-band mnt-* object attributes, as is currently the case.

It would be an acceptable limitation that API keys for database maintenance are unavailable for LIRs without a default maintainer.

Assuming the WG agrees that this is a good idea, I request an NWI.

Tore

Hi Gunnar, We're indeed also working on Client Certificate authentication (we have tested it, and now it's pending a security review). However, to make use of this, a user must: - Generate an X.509 certificate - Extract the certificate as text and create a key-cert object from it - Associate the key-cert with a maintainer in an auth: attribute - Configure the Whois client to send the client certificate when connecting to the REST API (or Syncupdates). This is not trivial to do, and we can see that although signed updates are supported in Whois, it has low usage. It is still worthwhile to support this, as the credential (secret) is only stored locally on the client. Hopefully API keys will be more "user friendly" and can be used in preference to MD5 hashed passwords. Regards Ed Shryane RIPE NCC

On 18 Mar 2020, at 09:45, Gunnar Gušvaršarson <gunnar.gudvardarson@advania.is> wrote:

Hey,I think that if we get x509 client certificate authentication for the API working, it might even be easier. All the UI to add certs and auth them on mntners is already there, the web services just need endpoints that request and use client provided certs. https://github.com/RIPE-NCC/whois/issues/534