Authenticating References to Objects
Dear Working Group, as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects. Currently, only references to organisation objects can be protected with the mnt-ref attribute. However, we could extend this protection to other types of objects: - Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s) This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email). Please let me know your feedback on this proposal. Regards Ed Shryane RIPE NCC
On Mon, May 27, 2019 at 11:42:37AM +0200, Edward Shryane via db-wg wrote: Dear Edward,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email).
Please let me know your feedback on this proposal.
Sounds good. Please, go ahead. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
Hi, On Mon, May 27, 2019 at 12:02:41PM +0200, Piotr Strzyzewski via db-wg wrote:
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
Sounds good. Please, go ahead.
+1 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
Ed, On 27/05/2019 11.42, Edward Shryane via db-wg wrote:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
Indeed the reason that "mnt-ref:" was chosen as a name instead of "mnt-org:" or the like was so that it could be general-purpose.
This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email).
Please let me know your feedback on this proposal.
In principle wider use of "mnt-ref:" makes sense, but I'm not sure exactly what is being proposed. If you mean allowing "mnt-ref:" on *specific* PERSON, ROLE, and MNTNER objects then I think that this is a potential source of confusion, and needlessly complicates the database. (For example, only PERSON objects used as a "tech-c:".) If you mean allowing "mnt-ref:" on *all* PERSON and ROLE objects, then I support that. I am unsure if "mnt-ref:" is necessary on MNTNER objects, as I thought that they already required authentication by the MNTNER object itself to be referred to anywhere ("mnt-by:", "mnt-lower:", "mnt-domains:", or "mnt-routes:")? So, isn't "mnt-ref:" already implicit for MNTNER objects? Also, it's not clear if the proposal includes adding "ref-nfy:" along with "mnt-ref:". I think that should be included as well. Cheers, -- Shane
+1 On Mon, May 27, 2019, 11:42 Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email).
Please let me know your feedback on this proposal.
Regards Ed Shryane RIPE NCC
* Edward Shryane via db-wg <db-wg@ripe.net> [2019-05-27 11:43]:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email).
Sounds good, on the premise that this is done to the generic object type and not dependent on the usage of them. Meaning that if I put mnt-ref on a person/role you cannot reference it *anywhere* unless your maintainer is listed in mnt-ref. Same for maintainers. 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
it wouldn't really work for maintainers, as it becomes a recursive loop. mnt-1 wants to edit mnt-2's object, mnt-2 can't add mnt-1 and mnt-1 can't add mnt-2 to mnt-ref... - Cynthia On Fri, May 31, 2019, 15:05 Sebastian Wiesinger via db-wg <db-wg@ripe.net> wrote:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with
* Edward Shryane via db-wg <db-wg@ripe.net> [2019-05-27 11:43]: the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects
(e.g. to impersonate a third party or mis-direct abuse email).
Sounds good, on the premise that this is done to the generic object type and not dependent on the usage of them.
Meaning that if I put mnt-ref on a person/role you cannot reference it *anywhere* unless your maintainer is listed in mnt-ref. Same for maintainers.
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
and also keep in mind what the goal of this is. Anyone can create a new PERSON/ROLE object with the same content as one of yours. In other words make an exact copy. They can then add your MNTNER and then remove theirs after making references to it. Adding an additional MNTNER doesn't require authorisation from that MNTNER. So they can still set up their data to look as if it is managed by you. cheersdenis co-chair DB-WG On Friday, 31 May 2019, 15:11:48 CEST, Cynthia Revström via db-wg <db-wg@ripe.net> wrote: it wouldn't really work for maintainers, as it becomes a recursive loop. mnt-1 wants to edit mnt-2's object, mnt-2 can't add mnt-1 and mnt-1 can't add mnt-2 to mnt-ref... - Cynthia On Fri, May 31, 2019, 15:05 Sebastian Wiesinger via db-wg <db-wg@ripe.net> wrote: * Edward Shryane via db-wg <db-wg@ripe.net> [2019-05-27 11:43]:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email).
Sounds good, on the premise that this is done to the generic object type and not dependent on the usage of them. Meaning that if I put mnt-ref on a person/role you cannot reference it *anywhere* unless your maintainer is listed in mnt-ref. Same for maintainers. 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, Not sure how I got added here but would love to throw my 2 cents in. What i'm trying to do is block spammers and all of these cloud servers, hosting companies etc. Something that would help me is an "abuse email or previous owner field". When i'm doing whois searches on many of these ips, the spammers appear to be using new domains to appear like a new hosting company. It looks like once their ips start getting heavily blocked on the internet, they are letting them "rest" and "selling" them to their selves and changing the domain name. This would help stop the problem. Thanks! On Fri, May 31, 2019 at 6:39 AM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
and also keep in mind what the goal of this is. Anyone can create a new PERSON/ROLE object with the same content as one of yours. In other words make an exact copy. They can then add your MNTNER and then remove theirs after making references to it. Adding an additional MNTNER doesn't require authorisation from that MNTNER. So they can still set up their data to look as if it is managed by you.
cheers denis
co-chair DB-WG
On Friday, 31 May 2019, 15:11:48 CEST, Cynthia Revström via db-wg < db-wg@ripe.net> wrote:
it wouldn't really work for maintainers, as it becomes a recursive loop. mnt-1 wants to edit mnt-2's object, mnt-2 can't add mnt-1 and mnt-1 can't add mnt-2 to mnt-ref...
- Cynthia
On Fri, May 31, 2019, 15:05 Sebastian Wiesinger via db-wg <db-wg@ripe.net> wrote:
Dear Working Group,
as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects.
Currently, only references to organisation objects can be protected with
* Edward Shryane via db-wg <db-wg@ripe.net> [2019-05-27 11:43]: the mnt-ref attribute.
However, we could extend this protection to other types of objects:
- Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s)
This would prevent unauthorised references to an organisation's objects
(e.g. to impersonate a third party or mis-direct abuse email).
Sounds good, on the premise that this is done to the generic object type and not dependent on the usage of them.
Meaning that if I put mnt-ref on a person/role you cannot reference it *anywhere* unless your maintainer is listed in mnt-ref. Same for maintainers.
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
* Cynthia Revström via db-wg <db-wg@ripe.net> [2019-06-01 06:31]:
it wouldn't really work for maintainers, as it becomes a recursive loop. mnt-1 wants to edit mnt-2's object, mnt-2 can't add mnt-1 and mnt-1 can't add mnt-2 to mnt-ref...
Okay, let's say authorization is done wherever feasible. :) 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
Sebastian and all, On 03/06/2019 16.30, Sebastian Wiesinger via db-wg wrote:
* Cynthia Revström via db-wg <db-wg@ripe.net> [2019-06-01 06:31]:
it wouldn't really work for maintainers, as it becomes a recursive loop. mnt-1 wants to edit mnt-2's object, mnt-2 can't add mnt-1 and mnt-1 can't add mnt-2 to mnt-ref...
Okay, let's say authorization is done wherever feasible. :)
You can include any number of authentications in a database update, so in principle this should not be a problem. However, if using SSO stuff then the server would need to provide a way for multiple authentications to a single update. Maybe it already does (I don't represent an LIR so I've never actually used that...)? Cheers, -- Shane
participants (8)
-
Cynthia Revström -
Edward Shryane -
Gert Doering -
Piotr Strzyzewski -
ripedenis＠yahoo.co.uk -
Sebastian Wiesinger -
Shane Kerr -
steve