Colleagues We would like some feedback on the following NWIs and their current status. I would also like to remind colleagues that we have posted a couple of questions on the Address Policy WG mailing list about policy requirements for contact details. We would appreciate some feedback on those questions on that mailing list. cheersdenisco-chair DB-WG NWI-7 abuse-c implementation If the RIPE NCC can confirm that the cleanup of PERSON, ORGANISATION, MNTNER and IRT objects has been done to remove any "abuse-mailbox:" attributes and the 'person' keyword has been updated to take account of the "abuse-c:", we would like to mark NWI-7 as 'Finished'. NWI-8 LIR´s SSO Authentication Groups We agreed on this problem definition: Problem DefinitionLIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Do we agree on this (staged) solution definition?(Draft) Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, will be contained in a default authentication group -Non billing users added or removed through the portal UI, who have an SSO authentication account, will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service -(Non billing users who did not have an SSO authentication account who then create one, will be automatically adjusted in this group - NCC, is this feasable?) -(Non billing users who are listed in the LIR's authentication group who then delete their SSO authentication account, will be automatically adjusted in this group - NCC, is this feasable?) Stage 2 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method NWI-9 In-band notification mechanism? ???Is there a wish to create this issue as an NWI with the following problem definition? Problem DefinitionThere is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status.
Hi Denis, * ripedenis--- via db-wg
NWI-8 LIR´s SSO Authentication Groups
We agreed on this problem definition:
Problem Definition LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database.
Do we agree on this (staged) solution definition? (Draft) Solution Definition
Stage 1
-Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, will be contained in a default authentication group
There seems to be a underlying presumption here that it is possible to have users in the LIR Portal which do not have SSO accounts. To the best of my knowledge, this is not the case - users associated with an LIR in the LIR Portal *are* SSO (i.e., RIPE NCC Access) accounts. Therefore, the «who have an SSO authentication account» part is redundant.
-Non billing users added or removed through the portal UI, who have an SSO authentication account, will be automatically adjusted in this group
See above - «who have an SSO authentication account» is redundant.
-This authentication group can be referenced in MNTNER objects by a new authentication method
Given https://www.ripe.net/ripe/mail/archives/db-wg/2019-February/006167.html, perhaps rewrite this one as: «This authentication group can be referenced directly in mnt-*: attributes in database objects, or if that is not feasible, as a new authentication method in MNTNER objects.»
-These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service
OK
-(Non billing users who did not have an SSO authentication account who then create one, will be automatically adjusted in this group - NCC, is this feasable?)
See above - this bullet can be removed completely.
-(Non billing users who are listed in the LIR's authentication group who then delete their SSO authentication account, will be automatically adjusted in this group - NCC, is this feasable?)
See above - this bullet can be removed completely.
Stage 2
-Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups
See above - «who have an SSO authentication account» is redundant.
-Each User can be a member of any number of named groups
OK
-The authentication groups can be configured using the portal UI
OK
-These groups can be referenced in MNTNER objects by the new authentication method
See above - rewrite to something like «these groups can be referenced directly in mnt-*: attributes in database objects, or by the new authentication method in MNTNER objects crated during stage 1». Tore
Hello, On 2019-04-09 12:58, Tore Anderson via db-wg wrote:
«This authentication group can be referenced directly in mnt-*: attributes in database objects, or if that is not feasible, as a new authentication method in MNTNER objects.»
AFAIK, mnt-* (mnt-by, lower, etc) defines what you are authorized to do, not how you are authorized. Authentication mechanisms defines how you are authorized. So to me a new auth method would make more sense. - Cynthia
* Cynthia Revström via db-wg
Hello,
On 2019-04-09 12:58, Tore Anderson via db-wg wrote:
«This authentication group can be referenced directly in mnt-*: attributes in database objects, or if that is not feasible, as a new authentication method in MNTNER objects.»
AFAIK, mnt-* (mnt-by, lower, etc) defines what you are authorized to do, not how you are authorized. Authentication mechanisms defines how you are authorized. So to me a new auth method would make more sense.
Hi Cynthia, The point here is simply to get rid of the need to always create «proxy» MNTNER objects. That is, instead of needing this: ###### inet6num: 2001:db8::/32 mnt-lower: MNT-MYLIR mnt-routes: MNT-MYLIR-ROUTES --> mntner: MNT-MYLIR auth: LIRPORTAL eu.mylir + mntner: MNT-MYLIR-ROUTES auth: LIRPORTAL eu.mylir/routes --> http://lirportal.ripe.net user: alice@mylir.eu user: bob@mylir.eu (member of group «routes») ###### The LIR could make do with something like this: ###### inet6num: 2001:db8::/32 mnt-lower: LIRPORTAL-eu.mylir mnt-routes: LIRPORTAL-eu.mylir/routes --> http://lirportal.ripe.net user: alice@mylir.eu user: bob@mylir.eu (member of group «routes») ###### The two mntner objects in the first example serve no real purpose, except to cause extra work and require LIR hostmasters to learn a concept they have no need for. Tore
Hi Tore It is not quite true to say the MNTNER objects serve no useful purpose. You are overlooking the mandatory "upd-to:' and optional "mnt-nfy:" attributes. The "upd-to:" notifies the maintainer of any unsuccessful attempts to modify an object maintained by that MNTNER. This could be an indication of attempts to hack your data. The "mnt-nfy:" notifies the maintainer of successful updates. Many people don't realise how this attribute can be used. If you set up the same email address in the "mnt-nfy:" of all an organisation's MNTNER objects you can have a centralised audit trail of all your data updates across the organisation. So bypassing the MNTNER object is quite a significant change to the security model of the RIPE Database. If, at some later stage, we were to add this type of notification setup into the SSO groups, managed through the portal UI, and with other options besides emails, then maybe we are starting to get a more modern interface to managing the RIPE Database...but it is significant change, so I suggest we start with the SSO groups and new auth method. cheersdenisco-chair DB-WG On Tuesday, 9 April 2019, 16:26:35 CEST, Tore Anderson via db-wg <db-wg@ripe.net> wrote: * Cynthia Revström via db-wg
Hello,
On 2019-04-09 12:58, Tore Anderson via db-wg wrote:
«This authentication group can be referenced directly in mnt-*: attributes in database objects, or if that is not feasible, as a new authentication method in MNTNER objects.»
AFAIK, mnt-* (mnt-by, lower, etc) defines what you are authorized to do, not how you are authorized. Authentication mechanisms defines how you are authorized. So to me a new auth method would make more sense.
Hi Cynthia, The point here is simply to get rid of the need to always create «proxy» MNTNER objects. That is, instead of needing this: ###### inet6num: 2001:db8::/32 mnt-lower: MNT-MYLIR mnt-routes: MNT-MYLIR-ROUTES --> mntner: MNT-MYLIR auth: LIRPORTAL eu.mylir + mntner: MNT-MYLIR-ROUTES auth: LIRPORTAL eu.mylir/routes --> http://lirportal.ripe.net user: alice@mylir.eu user: bob@mylir.eu (member of group «routes») ###### The LIR could make do with something like this: ###### inet6num: 2001:db8::/32 mnt-lower: LIRPORTAL-eu.mylir mnt-routes: LIRPORTAL-eu.mylir/routes --> http://lirportal.ripe.net user: alice@mylir.eu user: bob@mylir.eu (member of group «routes») ###### The two mntner objects in the first example serve no real purpose, except to cause extra work and require LIR hostmasters to learn a concept they have no need for. Tore
Hi, On 2019-04-09 17:25, ripedenis@yahoo.co.uk wrote:
It is not quite true to say the MNTNER objects serve no useful purpose. You are overlooking the mandatory "upd-to:' and optional "mnt-nfy:" attributes.
I would also like to add that for my purposes, I would need an MD5-PW auth on that mntner too since I use the WHOIS API. - Cynthia
Cynthia Revström via db-wg wrote on 09/04/2019 16:38:
I would also like to add that for my purposes, I would need an MD5-PW auth on that mntner too since I use the WHOIS API.
it might be a better idea to look at ways of improving authentication on the whois api rather than going a step backwards to md5-pw. Nick
Well regardless, my point is that I would like the ability to add additional auth schemes to the mntner. - Cynthia On 2019-04-09 21:16, Nick Hilliard wrote:
Cynthia Revström via db-wg wrote on 09/04/2019 16:38:
I would also like to add that for my purposes, I would need an MD5-PW auth on that mntner too since I use the WHOIS API.
it might be a better idea to look at ways of improving authentication on the whois api rather than going a step backwards to md5-pw.
Nick
* Nick Hilliard
Cynthia Revström via db-wg wrote on 09/04/2019 16:38:
I would also like to add that for my purposes, I would need an MD5-PW auth on that mntner too since I use the WHOIS API.
it might be a better idea to look at ways of improving authentication on the whois api rather than going a step backwards to md5-pw.
Indeed. When stage 1 of NWI-8 is implemented, I was planning to propose an NWI to allow for creating API keys for database maintenance at https://lirportal.ripe.net/api/ (i.e., for use with Syncupdates and the RESTful API). One could then use that API key to authenticate against the LIR's default authentication group. Tore
Hi, On Wed, Apr 10, 2019 at 07:19:59AM +0200, Tore Anderson via db-wg wrote:
Indeed. When stage 1 of NWI-8 is implemented, I was planning to propose an NWI to allow for creating API keys for database maintenance at https://lirportal.ripe.net/api/ (i.e., for use with Syncupdates and the RESTful API).
One could then use that API key to authenticate against the LIR's default authentication group.
+1 *want* Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
+1 good idea On 2019-04-10 07:19, Tore Anderson wrote:
Indeed. When stage 1 of NWI-8 is implemented, I was planning to propose an NWI to allow for creating API keys for database maintenance at https://lirportal.ripe.net/api/ (i.e., for use with Syncupdates and the RESTful API).
One could then use that API key to authenticate against the LIR's default authentication group.
Tore Anderson wrote on 10/04/2019 06:19:
Indeed. When stage 1 of NWI-8 is implemented, I was planning to propose an NWI to allow for creating API keys for database maintenance at https://lirportal.ripe.net/api/ (i.e., for use with Syncupdates and the RESTful API).
you mean a single-factor read/write authentication token, typically stored in a database in unencrypted format? :-) Nick
Hi, On Wed, Apr 10, 2019 at 08:48:38AM +0100, Nick Hilliard via db-wg wrote:
Tore Anderson wrote on 10/04/2019 06:19:
Indeed. When stage 1 of NWI-8 is implemented, I was planning to propose an NWI to allow for creating API keys for database maintenance at https://lirportal.ripe.net/api/ (i.e., for use with Syncupdates and the RESTful API).
you mean a single-factor read/write authentication token, typically stored in a database in unencrypted format? :-)
syncupdates needs some sort of credential. Either you put your LIR access (or mntner md5 password) into the script - which is arguably a bad idea - or you have API tokens that are restricted to *only* API, not "API and all else". You could, certainly, argue that nobody should do RIPE DB updates in an automated way... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 10/04/2019 08:52:
You could, certainly, argue that nobody should do RIPE DB updates in an automated way...
not at all - I love APIs. We need more APIs. I was just wondering out loud about how to store access tokens securely. Nick
Hi, On Wed, Apr 10, 2019 at 09:11:02AM +0100, Nick Hilliard wrote:
Gert Doering wrote on 10/04/2019 08:52:
You could, certainly, argue that nobody should do RIPE DB updates in an automated way...
not at all - I love APIs. We need more APIs.
I was just wondering out loud about how to store access tokens securely.
Well, it wasn't clear if "store unencrypted" referred to the client or server side. On the server side, yes, please store one-way hashed in a secure fashion. On the client side... if you want it automated, it needs to be accessible by the machine :-/ Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 10/04/2019 09:22:
Well, it wasn't clear if "store unencrypted" referred to the client or server side. On the server side, yes, please store one-way hashed in a secure fashion.
How though? Again, thinking out loud, it's easy enough if you implement using an unsalted hash except that's not considered to be secure. If you hash with salt, then you need to hash the incoming API key against all salt values stored from the DB because the only way you can figure out which API key is being used is to do a linear comparison against all API key hashes. This implies an authentication comparison load of O(n), where n is the number of API keys in the DB, so that's unlikely to scale well. Nick
On 10 Apr 2019, at 9:40, Nick Hilliard via db-wg wrote:
How though?
Wouldn’t use of either PGP or a TLS client credential by the (proposed, putative, whatever) API avoid the key-storage problem ? €0,02 /Niall
Hi, On Wed, Apr 10, 2019 at 09:40:05AM +0100, Nick Hilliard wrote:
Gert Doering wrote on 10/04/2019 09:22:
Well, it wasn't clear if "store unencrypted" referred to the client or server side. On the server side, yes, please store one-way hashed in a secure fashion.
How though? Again, thinking out loud, it's easy enough if you implement using an unsalted hash except that's not considered to be secure.
The attack vector against unsalted hashes is "rainbow tables"... make the API key something like 80 characters long, and no machine in the world can do anything but brute force. But why store the API key anyway. Have it contain permissions plus a crytographically sane signature, and all you need to know is "in the key". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 10/04/2019 11:08:
The attack vector against unsalted hashes is "rainbow tables"... make the API key something like 80 characters long, and no machine in the world can do anything but brute force.
which will work until the DB ends up on https://haveibeenpwned.com/
But why store the API key anyway. Have it contain permissions plus a crytographically sane signature, and all you need to know is "in the key".
Sounds like it would cause problems unless you maintained a key revocation list. Or unless you maintained salt-per-client in cleartext format, which doesn't sound like an improvement. Nick
* Nick Hilliard via db-wg
Gert Doering wrote on 10/04/2019 11:08:
The attack vector against unsalted hashes is "rainbow tables"... make the API key something like 80 characters long, and no machine in the world can do anything but brute force.
which will work until the DB ends up on https://haveibeenpwned.com/
Guys, JFYI - https://lirportal.ripe.net/api/ already exists and the API keys it issues can apparently be used to maintain your RPKI data. It doesn't seem to me like adding the possibility for database maintenance via an API key make things any worse from a security standpoint. Tore
Hi, auth-sso contains an identifier of an RIPE NCC Access SSO account. Actual details such as the email address and password are not stored in the RIPE DB. To me it would make sense to have a similar approach for API Tokens. Have some identifier that is kept on the MNTNER object, but store the actual sensitive data in a separate system. This would also allow future flexibility regarding which hashing and/or encryption to use. Essentially this would be an implementation detail that the RIPE NCC can look at, but which would not affect the whois as such. Tim
On 10 Apr 2019, at 12:41, Tore Anderson via db-wg <db-wg@ripe.net> wrote:
* Nick Hilliard via db-wg
Gert Doering wrote on 10/04/2019 11:08:
The attack vector against unsalted hashes is "rainbow tables"... make the API key something like 80 characters long, and no machine in the world can do anything but brute force.
which will work until the DB ends up on https://haveibeenpwned.com/
Guys,
JFYI - https://lirportal.ripe.net/api/ already exists and the API keys it issues can apparently be used to maintain your RPKI data.
It doesn't seem to me like adding the possibility for database maintenance via an API key make things any worse from a security standpoint.
Tore
Hi, On 2019-04-10 13:14, Tim Bruijnzeels via db-wg wrote:
Hi,
auth-sso contains an identifier of an RIPE NCC Access SSO account. Actual details such as the email address and password are not stored in the RIPE DB.
To me it would make sense to have a similar approach for API Tokens. Have some identifier that is kept on the MNTNER object, but store the actual sensitive data in a separate system. This would also allow future flexibility regarding which hashing and/or encryption to use. Essentially this would be an implementation detail that the RIPE NCC can look at, but which would not affect the whois as such.
Tim
Well there are 2 issues that I can see with this immediately, 1. as Denis has already mentioned a few months ago, the DB can not depend on the LIR portal being up due to it having less uptime. 2. What about people using the RIPE DB but are not LIRs, such as people/companies with PI resources? I don't really see a way to get around issue 1. Unless we are considering doing something like signed API messages, via PGP or something. - Cynthia
Hi Cynthia
On 10 Apr 2019, at 14:14, Cynthia Revström <me@cynthia.re> wrote:
Hi,
On 2019-04-10 13:14, Tim Bruijnzeels via db-wg wrote:
Hi,
auth-sso contains an identifier of an RIPE NCC Access SSO account. Actual details such as the email address and password are not stored in the RIPE DB.
To me it would make sense to have a similar approach for API Tokens. Have some identifier that is kept on the MNTNER object, but store the actual sensitive data in a separate system. This would also allow future flexibility regarding which hashing and/or encryption to use. Essentially this would be an implementation detail that the RIPE NCC can look at, but which would not affect the whois as such.
Tim
Well there are 2 issues that I can see with this immediately,
1. as Denis has already mentioned a few months ago, the DB can not depend on the LIR portal being up due to it having less uptime.
You are not dependent on the LIR Portal being up, you are dependent on the SSO system being up. While this introduces an extra system, it's far less complex than all of the LIR Portal. But yes having two systems is the price you pay for separating your authentication service (i.e. the need to store this data) from the authorisation being done in the database.
2. What about people using the RIPE DB but are not LIRs, such as people/companies with PI resources?
Anyone can create an SSO account, not just members. Presumably a similar thing could be done for tokens. But in any case.. I don't have a real stake in this - I just felt I should mention it as an option.
I don't really see a way to get around issue 1. Unless we are considering doing something like signed API messages, via PGP or something.
- Cynthia
Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Gert Doering wrote on 10/04/2019 09:22:
On the server side, yes, please store one-way hashed in a secure fashion.
How though?
RIPE DB API authentication is just password authentication, so you can just use bcrypt or some other modern unix crypt or PBKDF with a decent number of rounds. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Ardnamurchan Point to Cape Wrath: Variable 3 or less, becoming cyclonic 3 or 4. Smooth or slight, occasionally moderate later. Showers later in north. Good, occasionally moderate later in north.
* Cynthia Revström via db-wg
On 2019-04-09 17:25, ripedenis@yahoo.co.uk wrote:
It is not quite true to say the MNTNER objects serve no useful purpose. You are overlooking the mandatory "upd-to:' and optional "mnt-nfy:" attributes.
I would also like to add that for my purposes, I would need an MD5-PW auth on that mntner too since I use the WHOIS API.
You're right. I withdraw this suggestion. I'm OK with your original formulations about auth methods on MNTNER objects, Denis. Tore
Hi Denis, all,
On 9 Apr 2019, at 12:28, ripedenis--- via db-wg <db-wg@ripe.net> wrote:
NWI-9 In-band notification mechanism? ??? Is there a wish to create this issue as an NWI with the following problem definition?
From our perspective, absolutely. Kind regards, Aris
participants (9)
-
Aris Lambrianidis -
Cynthia Revström -
Gert Doering -
Niall O'Reilly -
Nick Hilliard -
ripedenis＠yahoo.co.uk -
Tim Bruijnzeels -
Tony Finch -
Tore Anderson