You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Database Working Group

Threaded
Collapse

[db-wg] API keys for database maintenance

User Image

Tore Anderson

2020-02-21 11:53:35 CET

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

User Image

Cynthia Revström

2020-02-21 12:54:51 CET

Hi Tore, WG,

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.

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.

- Cynthia

On Fri, Feb 21, 2020 at 11:54 AM Tore Anderson via db-wg <db-wg _at_ ripe _dot_ 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
>
>
User Image

Tore Anderson

2020-02-21 13:08:08 CET

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

User Image

Cynthia Revström

2020-02-21 13:10:56 CET

Hi Tore,

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?

- Cynthia

On Fri, Feb 21, 2020 at 1:08 PM Tore Anderson <tore _at_ fud _dot_ no> wrote:

> 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
>
User Image

Tore Anderson

2020-02-21 13:28:31 CET

* 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

User Image

Cynthia Revström

2020-02-21 13:36:08 CET

Hi,

I am against this proposal unless any other arguments can be made, as I
believe that the NCC's resources can be better used doing other things.
(I would think that this would require quite a large amount of work due to
how split the DB and LIR portal are.)

- Cynthia

On Fri, Feb 21, 2020 at 1:28 PM Tore Anderson <tore _at_ fud _dot_ no> wrote:

> * 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
>
User Image

Sebastian Wiesinger

2020-03-11 12:22:25 CET

* Tore Anderson via db-wg <db-wg _at_ ripe _dot_ 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
User Image

Kirilo Vasiliskovs

2020-03-16 11:51:36 CET

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 _at_ ripe _dot_ net>:

> * Tore Anderson via db-wg <db-wg _at_ ripe _dot_ 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
>
User Image

Cynthia Revström

2020-03-16 11:55:18 CET

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 _at_ ripe _dot_ 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 _at_ ripe _dot_ net>:
>>
>> * Tore Anderson via db-wg <db-wg _at_ ripe _dot_ 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

User Image

Ed Shryane

2020-03-17 18:00:55 CET

RIPE NCC staff member

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 _at_ ripe _dot_ 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
> 

User Image

Cynthia Revström

2020-03-17 20:11:00 CET

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 _at_ ripe _dot_ 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 _at_ ripe _dot_ 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
> >
>

User Image

Gunnar Guðvarðarson

2020-03-18 09:45:42 CET

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-----Original Message-----From: db-wg <db-wg-bounces _at_ ripe _dot_ net> On Behalf Of Edward Shryane via db-wgSent: 2020-03-17 17:01To: Tore Anderson <tore _at_ fud _dot_ no>Cc: db-wg <db-wg _at_ ripe _dot_ net>Subject: Re: [db-wg] API keys for database maintenanceDear 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.RegardsEd ShryaneRIPE NCC> On 21 Feb 2020, at 11:53, Tore Anderson via db-wg <db-wg _at_ ripe _dot_ 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>

User Image

Ed Shryane

2020-03-18 16:29:27 CET

RIPE NCC staff member

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 _at_ advania _dot_ 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

User Image

Gunnar Guðvarðarson

2020-03-18 17:23:11 CET

Hey,

My main issue with API Keys is them being attached to SSO accounts. What about when the employee leaves the company?
He gets removed from auth on the mntner, all the apps he set-up break? Making admins hesitant about removing user access.

API access needs to be bound to the mntner in some form imho.

Additionally, would api keys allow querying the API and getting unfiltered data? Or would it just be for `post`ing updates to objects?

--

I suspect the signed updates have little usage for two major reasons:

  *   Figuring out if the update succeeded requires receiving and parsing emails
  *   Figuring out if the object is up to date on the ripe database is practically impossible* due to filtering (auth: SSO# Filtered)

Sending requests with x509 client cert auth means you know who is sending the request and you have no need to filter data (like the auth sso entries) out for objects the mntner has permissions for, making idempotent api clients so much easier to make.

--

The logic i might want to implement, in pseudocode:

while true
mntners = database(mntners)
foreach mntners as mntner
objects = rest api request for all objects with mnt-by = mntner
foreach objects as object
if object not in database
notify admin .... or delete it
continue
if object == database(object)
continue
rest api request to update object with data from database
sleep for a while

--
p.s. sorry about my earlier, mangled email, my email client seems to have gone a bit nuts...

* okay not "impossible" but really annoying, you'd have to store the last updated timestamp from ripe, for all objects, and if it changes in the ripe db, then we'd have to post the object to see if it changes?

________________________________
From: Edward Shryane
Sent: Wednesday, March 18, 2020 15:29
To: Gunnar Guðvarðarson
Cc: Tore Anderson; db-wg _at_ ripe _dot_ net
Subject: Re: [db-wg] API keys for database maintenance

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 _at_ advania _dot_ 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

User Image

Tore Anderson

2020-03-20 11:38:13 CET

* Gunnar Guðvarðarson via db-wg

> My main issue with API Keys is them being attached to SSO accounts. What about when the employee leaves the company?
> He gets removed from auth on the mntner, all the apps he set-up break? Making admins hesitant about removing user access.
> 
> API access needs to be bound to the mntner in some form imho.

Agreed. Well, one does not need to rule out the other - it ought to be possible to support both personal API keys (bound to an SSO account) and impersonal API keys (bound to an LIR and/or mntner).

For what it is worth, the current API keys implementation *appears* to be impersonal, i.e., my colleague can see the API keys I created and vice versa.

However, we can also see who created the keys in the first place. I did not test to see if all keys created by a specific user account would be removed if that user account is deleted or removed from the LIR account.

Tore

User Image

Theodoros Polychniatis

2020-03-23 15:40:09 CET

RIPE NCC staff member

Dear Tore,

The API Keys created by a user in the LIR Portal are not removed when
the user is removed from the registry.

Best Regards,
Theodoros Polychniatis
RIPE NCC

On 20/03/2020 11:38, Tore Anderson via db-wg wrote:
> * Gunnar Guðvarðarson via db-wg
>
>> My main issue with API Keys is them being attached to SSO accounts. What about when the employee leaves the company?
>> He gets removed from auth on the mntner, all the apps he set-up break? Making admins hesitant about removing user access.
>>
>> API access needs to be bound to the mntner in some form imho.
> Agreed. Well, one does not need to rule out the other - it ought to be possible to support both personal API keys (bound to an SSO account) and impersonal API keys (bound to an LIR and/or mntner).
>
> For what it is worth, the current API keys implementation *appears* to be impersonal, i.e., my colleague can see the API keys I created and vice versa.
>
> However, we can also see who created the keys in the first place. I did not test to see if all keys created by a specific user account would be removed if that user account is deleted or removed from the LIR account.
>
> Tore
>