Hi Ronald

You have touched on several issues here. I will take them one at a time.

The current model of the RIPE Database was deployed in 2001. Before that there was another version that did not require mandatory authorisation. So when the data was migrated to the current data model any objects that did not have any authorisation had this 'ripe-ncc-none-mnt' added as an "mnt-by:". This MNTNER object did not have any password or pgp. It had the "auth: none" value. This meant that no authorisation was needed but made the objects syntactically correct. As with any major change backwards compatibility was essential. So anyone could use the auth value 'none' in their own MNTNER objects. This allowed users who were not familiar with using authorisation in the RIPE Database to comply with the syntax but not add any real authorisation.

As you may have realised there is lots of static data in the RIPE Database. This is data that is still correct and still in use but has not needed to be changed in any way for, possibly, decades. For the users who manage this data they generally don't follow RIPE Database events and don't spend any time 'actively' managing this data. Everything just works so if it ain't broken there is no need to fix it.

In 2003 it was proposed that this 'false' concept of authorisation was deprecated. That happened in 2004. Despite the publicity, many users with this static data simply got on with life. So now, 12 years later, there are still objects in the database that are maintained by this 'ripe-ncc-locked-mnt' from this security fix in 2004.

Now lets jump forward to more recent times. The MNTNER object 'ripe-ncc-locked-mnt' is used by the RIPE NCC in any situation where data needs to be locked. It was used recently to lock the remaining unmaintained PERSON and ROLE objects.

Until about 3 or 4 years ago (when the software was re-written in java), authorisation was not validated on object creation. So anyone could create any object referencing any MNTNER object in the database, including 'ripe-ncc-locked-mnt'. Of course as soon as you created it you were locked out as you would not have the authorisation for that MNTNER you referenced. But if you didn't need to modify it the object would sit quite happily in the database and you could still reference it.

With the re-write of the software that issue was closed. So now you do need to authorise object creations. Another change that was added is that no one outside the RIPE NCC can add or remove any of the RIPE NCC's MNTNER objects. This includes the 'ripe-ncc-locked-mnt' object. If you try this now you get these errors:

Create FAILED: [person] AUTO-1   test guy

person:         test guy
address:        amsterdam
phone:          +31
nic-hdl:        AUTO-1
mnt-by:         ripe-ncc-locked-mnt
source:         RIPE

***Error:   Authorisation for [person] TG5494-RIPE failed
            using "mnt-by:"
            not authenticated by: RIPE-NCC-LOCKED-MNT

***Error:   You cannot add or remove a RIPE NCC maintainer

I did a free text search to find some ROUTE object that had this MNTNER, 'ripe-ncc-locked-mnt'. I found this example:
    route-set:       rs-AS327795
    descr:           Tanzania e-Government Agency
    tech-c:          GM16-AFRINIC
    admin-c:         GM16-AFRINIC
    mnt-by:          RIPE-NCC-LOCKED-MNT
    mnt-lower:       eGA-MNT
    created:         2015-04-01T14:16:38Z
    last-modified:   2016-04-25T13:09:57Z
    source:          RIPE

But if you look at the history of this object you will see the original object was this:

route-set:      rs-AS327795
descr:          Tanzania e-Government Agency
tech-c:         GM16-AFRINIC
admin-c:        GM16-AFRINIC
mnt-by:         RIPE-NCC-RPSL-MNT
mnt-lower:      eGA-MNT
created:        2015-04-01T14:16:38Z
last-modified:  2015-04-01T14:16:38Z
source:         RIPE

This was another fix done by the RIPE NCC that was requested by the community. The MNTNER 'ripe-ncc-rpsl-mnt' has a public password listed in a "remarks:" in the object. So it is not secure. This object only exists to create ROUTE objects for out of region resources. Again it is not possible now for any user to create an object referencing this MNTNER. But many objects were created until recently with this MNTNER. So the RIPE NCC locked all such objects as another security fix.

I could have jumped straight to this example, but I thought the history behind all these changes may help with understanding why some situations exist/existed.

cheers
denis

From: Ronald F. Guilmette <rfg@tristatelogic.com>
To: db-wg@ripe.net
Sent: Sunday, 20 November 2016, 5:21
Subject: [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT



I am having a bit of trouble decyphering the explanation/description of
RIPE-NCC-LOCKED-MNT given on the following page, and I hope someone will
help me to understand.

https://www.ripe.net/publications/news/announcements/deprecation-of-the-none-authentication-scheme


It appears from the above, that there was a transition/reorganization
that took place back around 2004, and that RIPE-NCC-LOCKED-MNT was set
as the maintainer on various objects that were present in the data base
at that time (specifically objects which were not already adequately
password protected) in order to protect some such objects from unauthorized
modification.

Is that description approximately accurate, I mean to a first approximation?
(I understand that I'm probably glossing over a number of the fine points
here, but I am doing so just because I doubt that any of those are even
pertinent to my real question.)

So anyway, my real question is this:

If in fact RIPE-NCC-LOCKED-MNT was just something which was used as a
sort-of "passing phase" stop-gap mechanism, i.e. as just a convenient
expedient for securing things that would otherwise poorly secured,
and if it was only applied in this way back in 2004, and for perhaps
a year or two afterwards, then what would be the explanation for a
*recently created* data base object (e.g. a route object) that has a
created: date of, say, 2014, 2015, or 2016 and also a mnt-by value of
RIPE-NCC-LOCKED-MNT?


Regards,
rfg