Hi Alex Thanks for the explanation. I am not against increased accountability and removal of the anonymity of MNTNER objects. I have been pushing for that for many years. But I think it is better to discuss this upfront and have agreement rather than slip it in with an update to a user interface. Anyone who wants to update their MNTNER now and needs to query it will find they have to create an SSO account and link it to the MNTNER before they can even query it. That should have been made clear in advance. I am also not convinced by this religious campaign that passwords are evil. Perhaps the way they are implemented in the RIPE Database is not good, but that is down to the data model. That thing that is long over due for a serious review but no one dares to talk about. You now have a situation where updates using the API must be done with a password, updates done with Webupdates must be done with SSO and updates done by email should be done with PGP. So you have actually increased the complexity of the already over complex authorisation model. cheers denis On 01/12/2015 12:44, Alex Band wrote:

Hi Denis,

It's only mandatory to be logged in with a RIPE NCC Access account to *use* webupdates. It is still possible to create and update objects with MD5 passwords, although we strongly encourage users to adopt our Single Sign-On system. The new interface will actively help users with that process.

The reasons for this strategy are the numerous downsides to MD5 passwords, with the most important one being the fact that forgotten passwords are frustrating for users and in most cases require intervention from the RIPE NCC. This actually accounts for a vast amount of support tickets, each one requiring meticulous identity verification to prevent attempted resource hijackings.

The implementation is quite ambitious, but the result is that almost a thousand maintainers have been migrated to using SSO in less than a week. A softer approach would have likely sustained the current issues for years to come. Ultimately, RIPE NCC Access offers users better security, seamless authentication across all RIPE NCC services, optional two-step verification and the ability to reset a lost password without RIPE NCC intervention.

Kind regards,

Alex

...

On 30 Nov 2015, at 18:07, ripedenis@yahoo.co.uk wrote:

Hi guys

When was it discussed, agreed or announced that Webupdates will no longer allow objects to be created or updated with a password?

As Webupdates is the only way to access an unfiltered version of your own MNTNER object, it is no longer possible to even retrieve a version of your own MNTNER without signing up for an SSO account. I did not realise this has become mandatory.

So has it been agreed that SSO is the only authorisation method allowed to access the RIPE Database? Did I miss the announcement that passwords and PGP are being deprecated?

cheers denis

Hi Job, group, world You said you would welcome my thoughts...so here they are...I know the data model is a taboo subject. But I hope you and others will actually read this email and think about what I said. It is quite clear that every time I mention it with other matters in any email the bit where I mention the data model is cut out of replies, never discussed, never even acknowledged. I am starting to believe my own conspiratorial theories about why the small group of people who 'control' the development of the RIPE Database don't want a simplified data model so that new members (commercial competitors?) don't need a full day course to learn how to make the most basic entries, and still get it wrong. This model was designed way back in the 90s. It has passed it's sell by date and is no longer fit for purpose in the 21st century. We are constantly dancing round the constraints of this old design. Instead of fixing the root cause we keep trying to invent ever more complex high level solutions to bolt on top of a bad design. Security of data and permissions in the RIPE Database is one of these areas that is fundamentally broken and cannot be fixed with this data model, no matter how many tweaks you make. Who else, but the RIRs, publish to the world so much detail about how you manage and secure your data? Do you see Google, Apple, Microsoft, Facebook, Twitter, Yahoo, Anyone publishing details of their users accounts? There are basically two types of data in the RIPE Database: Operational data - the stuff this public registry exists to record and publish along with details of who to contact if you have any issue with any operational data. Management data - the details of how you, as an individual or corporate entity, manage your operational data in this database. This includes details of your security credentials, who has permission to do what, who gets notified when things happen, etc. So the MNTNER object for example is clearly management data. Who, outside of your organisation, needs to see anything in your MNTNER object? Why do we tell the world that you have 3 passwords, 2 PGP and 4 SSO accounts managing your data? Why do we tell everyone who has permission to create more specific customer operational data in the database for your organisation ("mnt-lower:")? Why do we let the world know that you have not set up any notifications so you will not notice if this data is changed? A few years ago I did a presentation to Wilfried and Nigel about how easy it would be to separate the operational and management data in the database so that the whole of the management data could be hidden. User accounts for organisations/people who manage the operational data could be created to manage security, permissions, notifications, audit trails, etc. I even showed how it could be done in a backwards compatible way so that no one would be forced to change anything. I even threw in significant improvements using inheritance in a backwards compatible way. But then for a year or so I was not in a position to discuss any database issues publicly so the whole idea ground to a halt. If you are serious about improving security, the time has come to stop dancing round these issues with ever more complex solutions and address the problems head on. All I am proposing is that members/users/interested parties acknowledge that the data model is old and could be improved and be willing to seriously discuss the possibilities. If you are willing to throw off the constraints of this old model many new and improved possibilities open up. cheers denis On 01/12/2015 13:52, Job Snijders wrote:

Hi Denis, group,

On Tue, Dec 01, 2015 at 01:23:21PM +0100, denis wrote:

...

You now have a situation where updates using the API must be done with a password, updates done with Webupdates must be done with SSO and updates done by email should be done with PGP. So you have actually increased the complexity of the already over complex authorisation model.

This is an excellent summary, I wonder what a good way forward would be. Possibly enable PGP authenticated API access? Or introduce a concept of "API Keys" which a user can tie to an application and for instance restrict which source IP addresses are allowed to use that key? I welcome your thoughts on this matter

Kind regards,

Job

All, The idea that this model is old is quite accurate. Much of these data models have a legacy that dates back the to the times where we were pushing emails around with authentication done using mail from. That was really broken. PGP and some of the earlier guardian initiatives tried to secure the problem but killed the user experience. These solutions lacked a fundamental ability to provide an elegant programatic interface, recall nasty perl scripts interpreting email. The maintainer system has survived this long because even as a blunt tool it was effective. As we talk about modernization efforts, I propose an Oauth solution as is the industry norm across most larger web properties today. This solves the SSO issue, while also offering the ability to federate authentication and separating from authorization. This is also applicable to API keys and enabling interfaces to access features programmatically. All of these would be great things. In regards to the data, All of this data was originally intended as a directory service for operational and research data. While the Internet was a much smaller (arguably different) network back then, this still holds mostly true today. I support the idea that this data should be used for network contact data including operational and abuse. It has also become increasingly important to contact the actual holder of a resource. I can also see the benefits of geo-loc capabilities and perhaps historical details. The academic research capabilities seem less important or may already enabled from making the rest of this data available. It is the marketing applications that everyone always frowns upon. This is where people try to implement security features and limit access to certain data. Other objections tend to be a lack of interest in publishing a customer list, which negates the usefulness of sub-delegations. Any updates we consider should focus on the impact of keeping the database accurate. This is probably a much larger discussion as a whole, appropriate for a future RIPE meeting. I would like to ask the community, what authorization model provides the trust so that people will continue to use, updates, and keep their data accurate? As for the current SSO solution, it is effective and seems to be fairly robust. I like the improved customer experience for resets and other maintenance items. I am not a huge fan of being required or forced down this path, or that the identity provider is required to be RIPE. The idea that we could authenticate from other places like a Github with this solution seems appropriate given the trends from the past ten years and the progress made in these areas. Maintainer recovery on older legacy blocks continues to provide challenges so I applaud any effort to enable self-service interfaces for users. Thanks, Billy

On Dec 2, 2015, at 6:48 AM, Shane Kerr <shane@time-travellers.org> wrote:

Denis,

At 2015-12-01 15:49:10 +0100 denis <ripedenis@yahoo.co.uk> wrote:

...

You said you would welcome my thoughts...so here they are...I know the data model is a taboo subject. But I hope you and others will actually read this email and think about what I said.

Is it? I didn't get the e-mail declaring data model off-limits, but maybe it's in my spam filter. ;)

...

Security of data and permissions in the RIPE Database is one of these areas that is fundamentally broken and cannot be fixed with this data model, no matter how many tweaks you make. Who else, but the RIRs, publish to the world so much detail about how you manage and secure your data? Do you see Google, Apple, Microsoft, Facebook, Twitter, Yahoo, Anyone publishing details of their users accounts?

All of those are big, for-profit American companies. Their design constraints are different from a small, membership-driven European organization.

Look at it another way. When I go to GitHub I can see who has contributed to a repository, including every change in every file. Yet you would hopefully not argue that GitHub is "fundamentally broken". ;)

...

There are basically two types of data in the RIPE Database:

Operational data - the stuff this public registry exists to record and publish along with details of who to contact if you have any issue with any operational data.

I'd further divide "operational data" into "number registry data" and "routing registry data". Routing policy information is definitely operational, but not managed by the RIPE NCC.

...

Management data - the details of how you, as an individual or corporate entity, manage your operational data in this database. This includes details of your security credentials, who has permission to do what, who gets notified when things happen, etc.

This is basically meta-data. I'd divide this also, into secret and non-secret management data. Information about who made changes and when is not strictly necessary operationally, but can be useful, so perhaps should be non-secret. As an example, we have this today with the "last-modified:" attribute.

I am careful not to use the word "public", because information can be private but non-secret, or published under limited access and non-secret. I tend to prefer everything be as open as possible, but others may not share that view and there may be valid reasons to restrict certain access.

...

So the MNTNER object for example is clearly management data. Who, outside of your organisation, needs to see anything in your MNTNER object? Why do we tell the world that you have 3 passwords, 2 PGP and 4 SSO accounts managing your data? Why do we tell everyone who has permission to create more specific customer operational data in the database for your organisation ("mnt-lower:")? Why do we let the world know that you have not set up any notifications so you will not notice if this data is changed?

Fair enough. The whole "maintainer" concept was always kind of awful :(

...

All I am proposing is that members/users/interested parties acknowledge that the data model is old and could be improved and be willing to seriously discuss the possibilities. If you are willing to throw off the constraints of this old model many new and improved possibilities open up.

Also fair enough. As long as we keep the "second system syndrome" in mind I think this makes sense.

Perhaps you can give an outline of your earlier (closed door) proposal?

Cheers,

-- Shane