May 2015 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

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

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

Personalised authorisation
by Tim Bruijnzeels 02 Jun '15

02 Jun '15

Dear working group, Yesterday during the WG session we presented a proposal for implementing personalised authorisation: https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-au… <https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-au…> https://ripe70.ripe.net/archives/video/123 <https://ripe70.ripe.net/archives/video/123> As recorded in the first cut of the minutes: > D. Personalised authentication (Tim Bruijnzeels, RIPE NCC) > (See presentation) > This will allow one click creation of person objects > Maintain credentials in one place. > Allow better auditing. > Done by extending person object to have multiple optional auth: attribute > This will ultimately allow existing auth: sso references to be cleaned up > Last auth: attribute should not be removed from a person object that is used in an authorisation context. Apart from questions about possible additions below, there seemed to be general approval for the above as an addition to the existing maintainer mechanism. We would very much like to implement this soon. We are already working on improving the way users can log in and use the web updates, and manage maintainers (and who is authorised for them), so having this would be extremely useful for that effort. Technically I don't think the above has to depend on further extensions below. Roles can be added at any time that we consensus on them, and showing audit logs is a separate effort - building on this. > Should this be extended to the role object as well? This would involve additional business rules but is technically possible. I understand and fully agree that there is a need to maintain a list of authorised persons centrally. But in effect a maintainer can be used for this purpose. Multiple objects can be maintained by the same maintainer, and the list of persons authorised can then be managed on this single maintainer: obj1 ---\ ---> mnt1 ---> pers1 obj2 ---/ \--> pers2 In other words, just like role objects can group persons in a 'contact' context, 'maintainers' could group persons in a 'authorisation' context, where also other things such as "upd-to:" etc can find a home. So, technically I don't think there is a need to have another role object here: obj1 ---\ ---> mnt1 ---> role1 ---> pers1 obj2 ---/ \--> pers2 Conceptually this can work of course, but it adds some complexity, and things to resolve: a) referencing roles from maintainers, and authorised persons from roles The proposal was to refer to authorised persons from maintainers like this: auth: person-<nichandle> Can we resolve this by allowing: = auth: role-<nichdl> on maintainers = auth: person-<nichdl> on roles But no other auth: flavours for now. Also note that this person is not necessarily an authorisation *contact* for others. If we follow current practice consistently we would filter this value for security purpose. b) business rules regarding auth->role Suggestion: - A role can only be added to a maintainer as "auth: role-<nichdl>" if it has at least one "auth: person-<nichdl>" - The last "auth: person" can not be removed from a role if it's referenced anywhere as "auth: role-" - As before: "auth: person-<nichl>" can only be added if the person has at least one "auth: <something>" - As before: the last "auth:" can not be removed from a person if it's referenced anywhere as "auth: person-" > It would be useful to record what credential (maintainer) was used to make a particular change to an object and this change > would facilitate this. RV was asked to raise this on the mailing list. Currently we do know internally which maintainer was used to submit a successful update, but not which credential. Technically this could be added of course. And in case of SSO or PGP people can get some idea of which user did the update. But showing which password hash was used for an update may not be best security practice. With authorisation delegated to persons (possibly through roles) we will be able to give a much more better output. We can refer to the name of the person, rather than a credential that should be private to that person. Also note that for any of this we will also need to be sure that the user viewing this information is authorised to see this. So what we had in mind here is to show this only on the web interface for logged in users authorised for at least one mnt-by of the object they are looking at.

5 7

abuse-c on legacy resources
by denis walker 29 May '15

29 May '15

Hi Piotr During the RIPE Meeting you suggested the idea of legacy resource holders adopting the practice of referencing an abuse contact using the one accepted method currently in use in the RIPE Database with "abuse-c:". In terms of responsible management of internet resources I don't think anyone could argue against all resources documented in the RIPE Database making reference to an abuse contact via an ORGANISATION object showing who is responsible for a resource. Many ideas raised at RIPE Meetings are quickly forgotten after the meeting. How can we move this idea forward so it does not become another of those 'good idea, but never implemented'? cheersDenisIndependent Netizen

3 5

History lost ...
by Erik Bais 21 May '15

21 May '15

Hi, With the IP transfers going in full swing, it is quite common these days that the larger prefix size is broken up in to multiple smaller prefixes.. As the original prefix is split up, the IPRAs remove the original prefix from the database .. and with it .. the history Is there a way to preserve that data to be able to still lookup the data using list-versions or show-version # Regards, Erik Bais

13 24

Prevent use of RIPE-NCC-RPSL-MNT in a mnt-by
by denis 18 May '15

18 May '15

6 6

created, last-modified mandatory?
by Daniel Zepeda 15 May '15

15 May '15

It wasn't clear to me from the provided documentation here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… if or when the 'created' and 'last-modified' attributes would be mandatory? Thanks! DZ

1 1

Cancel
by Luciano Panza 15 May '15

15 May '15

1 0

Minutes from RIPE 70
by Nigel Titley 14 May '15

14 May '15

Folks Here is the first cut at the minutes. Additions and corrections to me, please Nigel

1 0