- db-wg - mailman.ripe.net

NCC still enforcing descr: content
by Jan Saner 15 Aug '15

15 Aug '15

Hello Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html Quote: ----------------------------------------------------------- "> When will this change go into effect? We were thinking of mid April, for two reasons: 1) This gives the working group enough time to comment. 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." ----------------------------------------------------------- I personally know a case where the NCC went as far as to ignore German “umlauts” in the name and deliberately spell it wrong in the descr: field of the guy’s AUT-NUM object. When he tried to set it right (ae (ä) instead of a), the NCC reverted the change. Then there’s a case where someone tried to remove his middle name from the descr: field —> reverted. Another post on the same subject: https://www.ripe.net/ripe/mail/archives/members-discuss/2015-June/001737.ht… Looks like there’s still a lot of energy wasted in those descr fields now that the org pointer is mandatory. Cheers

10 17

Upcoming work by the RIPE NCC Database team
by Tim Bruijnzeels 14 Aug '15

14 Aug '15

Dear working group, Following working group discussions in different threads we would like to give you a quick overview of current and planned work. 1= SSO integration in Webupdates As you may know we have been working on this in the background for a while. The objective of this effort is to improve the integration of SSO with Webupdates. Where previously we were asking users to provide plain text (MD5) passwords, and storing them in the session, we now want to encourage everyone to use their SSO account instead. We expect that we will finish this work 2-3 weeks from now, and plan to deploy a new release 1.81 to the RC environment then. 2= Changed phase 3 - deprecating "changed:" We plan to work on this as soon as the SSO release is deployed to the RC environment. We we expect that we can have a release 1.82 for this ready for testing in the RC environment by the end of September. As mentioned before, because the impact of this change can be bigger than usual, we plan to have this release in RC for testing for 6 weeks before deploying it to production. 3= Descr We don't foresee major technical issues with the options being discussed currently, but can only present a definite implementation plan when consensus is reached on this. If consensus is reached in time, it may be an option to postpone the release of 1.82 above and have a bigger release that also includes this work - to avoid delays because of the long RC period required for that release. 4= Personalized Authorization We are very happy to have a mandate from the chairs to work on a proof of concept for personalised authentication. We look forward to implementing this as soon as we have the opportunity and working closely with the working group using the RC environment. In addition to core whois changes we will also deploy improvements to Webupdates in the RC environment when we work on this - to exemplify how we can make use of this to improve usability. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

1 0

Proposal about personalised authorisation
by Tim Bruijnzeels 12 Aug '15

12 Aug '15

The RIPE NCC has discussed the concept of personalised authorisation on various occasions, most recently at the DB WG session at RIPE 69. Following discussions and input from the working group we would now like to propose the following additions to the RIPE Database: = Extend the person object template with "auth:" as an optional, multiple attribute, with all current authentication methods. = Extend the mntner object "auth:" attribute with a new method that allows a reference to a person object that has at least one "auth:" attribute. There is no requirement to use these extensions, but users that choose to do so can benefit from the following advantages: = Currently it is is not always clear who uses the credentials in each "auth:" attribute on a mntner. There are two main problems with this. First of all this can result in authorisation being given to the wrong users, and second this makes it difficult to keep these objects up to date. For example it is not easy to remove the password for a specific user from a mntner without knowing, or deducing, which password hash is theirs. Having explicit references to person objects will make this clear. = Users who are authorised for multiple mntners will be able to maintain their own credentials in one place. = Audit logging can be improved. It will become possible to show to authorised users of the database which person made which change to their object. = The security of regaining lost access to a maintainer can be improved by letting users of the database reset the credentials on their own person object, rather than on a maintainer. Especially when the person object is linked with a Single Sign-On account. Allowing "auth:" attributes on person objects also allows us to make it easier for users to manage their person object in the RIPE Database in combination with their Single Sign-On (SSO) account on RIPE NCC Access as a single identity. To facilitate this we propose the following: = Being they are part of the same identity, person objects can only be associated with one SSO account, and vice versa. = Associated person objects and SSO accounts are automatically kept in sync. = SSO accounts can associated with new person objects, or existing person objects, provided that the user has access to both the SSO account and at least one maintainer of the person object. = Users will be able to decouple their own SSO account and person object.

4 4

Help needed to delete an object via email
by Hank Nussbacher 07 Aug '15

07 Aug '15

I believe I have encountered a bug with email processing of updates via auto-dbm@ripe and have not been able to engage the people there via ticket NCC#2015080034. I reported it and the ticket was quickly closed without being solved. I therefore ask for help from the hive-mind. The recently added "remarks:" line is causing parsing problems. The line looks like this: remarks: For information on "status:" attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources First I tried editing an object but the parser kept chopping the line as follows: >remarks: For information on "status:" attribute read >https: >//www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources >***Error: "https" is not a known RPSL attribute So I just deleted the line and was able to update the object. But now I want to delete an intenum object with the "remarks" line. When I do that I get: >remarks: For information on "status:" attribute read >https: >//www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources >... >created: 1970-01-01T00:00:00Z >last-modified: 2014-05-27T13:18:49Z >source: RIPE > >***Error: Object [inetnum] 192.114.48.0 - 192.114.63.255 doesn't match >version > in database The parser again chops the line at https and auto-starts a new line and therefore flags the entry as not macthing the version in the DB. Is there a workaround for this? Some escape character that will cause it not to break the line? Thanks, Hank

5 11

RIPE DB syntax check for mp-import
by Tomas Hlavacek 06 Aug '15

06 Aug '15

Hello! I just noticed that aut-num object for AS2852 in RIPE DB contains line mp-import: afi ipv6.unicastfrom AS39790 with 'afi ipv6.unicast' and 'from' keywords merged, which causs some confusion of my parsing scripts. Maybe I am missing something but I think this is not syntactically valid, is it? And if it is not, how could that get into RIPE DB? Tomas

3 2

ad-hoc RIPE db-wg meeting at IETF93
by Job Snijders 27 Jul '15

27 Jul '15

Dear best-db-working-group-in-the-world! I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-) I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage. Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details. Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest. Kind regards, Job

6 13

Release 1.80.1 deployed: warning users on failed update/delete, if maintainers had passwords removed
by Tim Bruijnzeels 16 Jul '15

16 Jul '15

Dear working group, We have just deployed whois release 1.80.1 to production. We have seen some cases where users were not aware that passwords had been removed from their maintainer, and they would only get an "authorisation failed" error. To help these users debug this issue better we now also include the following warning in case one or more of the maintainers had any passwords removed: "MD5 passwords older than November 2011 were removed for one or more maintainers of this object, see: https://www.ripe.net/removed2011pw" Example case (used by us for testing): > The following object(s) were found to have ERRORS: > > --- > Create FAILED: [person] AP1-TEST Another Person > > person: Another Person > address: Some Address > phone: +12 345 678 90 > nic-hdl: AP1-TEST > mnt-by: OWNER-MNT > source: TEST > > ***Error: Authorisation for [person] AP1-TEST failed > using "mnt-by:" > not authenticated by: OWNER-MNT > > ***Warning: MD5 passwords older than November 2011 were removed for one or more > maintainers of this object, see: https://www.ripe.net/removed2011pw Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team

1 0

MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
by Pierre Kim 14 Jul '15

14 Jul '15

Dear Database Working Group Members, I am contacting you to share the thoughts on the usage of MD5 in the RIPE database. I already discussed the problems concerning MD5 authentication with RIPE NCC Security<security(a)ripe.net> on 2 Apr 2015 and RIPE NCC Security officer encouraged me to contact your group to work together on this issue. In 2011, I had grabbed all the MD5s of the RIPE database before they were taken out from the public view and I don't think I was the only security researcher who downloaded all the hashes. This john-compatible file (containing MNT logins and MD5 hashs) was never exposed to public but the hashs can be (VERY) easily cracked. From the discussion with RIPE Security (who received a copy of this file), 27.000 usable hashes (on a total of 36.000) appeared to be valid til now. By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method. When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015. The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think. According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner. My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords. Please share your thoughts about this situation. I will be happy to debate with you. I want to thank Ivo Dijkhuis, RIPE NCC Information Security Officer, for the quality of the exchanges we had. Regards, -- Pierre Kim pierre.kim.sec(a)gmail.com @PierreKimSec https://pierrekim.github.io/

13 25

Release 1.80 deployed to production
by Tim Bruijnzeels 13 Jul '15

13 Jul '15

Dear working group, Release 1.80 was just deployed to production, introducing the following changes: = The “changed:” attribute is now optional, marking phase 2 of deprecating changed. = The "referral-by" attribute in maintainer objects is now deprecated. Update on upcoming releases: Over the past weeks we have been making good progress on improving the integration of web updates with the Single Sign-On system. This will help improve the usability of web updates, but it will also help to reduce the dependency of incidental users of the database on MD5 passwords. Considering the recent trouble with old MD5 passwords on maintainers we believe that there is a lot of value in finishing this work as soon as possible. We are close to a working solution and we will deploy it to the RC environment over the coming weeks, before releasing this to the production environment. As soon as this is done we will get back to implementing phase 3 of deprecating changed (deprecate the "changed:" attribute itself), which we expect to be ready to be deployed to the RC environment by the end of August. Please let us know if you have any questions or comments, Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team

1 0

Re: [db-wg] Temporary origins
by George Michaelson 09 Jul '15

09 Jul '15

On 25 June 2015 at 21:42, Job Snijders <job(a)instituut.net> wrote: > On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote: > > For your information, APNIC Hostmasters have moved to a mode of > > operation where for inetnum owners where the AS holder is not the same > > person, and a request is lodged with helpdesk for assistance, the > > hostmasters manually override and create the object for the inetnum > > holder, only removing it if an AS holder objects. The inetnum holder > > needs to be recognised in our systems. > > > > Its a hand-mediated inetnum-only route object. Previous practice was > > to wait for explicit approval from the AS holder. Now, its created > > first, and withdrawn if there is an objection. > > > > There have been no complaints. APNIC HM are considering portal changes > > and other process work to automate this. > > What is the benefit of the hand-mediation? Or is that just an artifact > of the software implementation? Its an artefact of the s/w implementation. I imagine once they work out how to do this in the portal, this will be changed. > Does APNIC send a notification to the AS > holder that an object was created in which they were referenced? > Yes. The following template is used: ====== Dear (ASN custodian), This is to inform you that the following route/route6 object has been registered in the APNIC Whois Database with your AS number referenced in the "origin" attribute. --- insert route object --- The IP addresses holder has asked that APNIC help register this route object in the APNIC Whois database. If you believe your AS number should not be referenced as the "origin" in this route object, please contact us by replying to this email. Kind Regards, ====== cheers -George > > Kind regards, > > Job >

9 9