call for application authorisation ideas
Hi group, I know all of you have automated their interactions with the RIPE database entirely. :-) As it currently stands, there are two ways to automate interaction with the RIPE DB: a) send GPG signed emails (and wait for the dumb greylisting to clear) b) call the http://rest.db.ripe.net/{source}/{objecttype}/{key}?password=XXX restful API Option A works, but is not very nice if you want something done immediatly and require a confirmation that the operation succeeded. The advantage of option A is that you don't need any auth: MD5-PW lines in your mntner object and RIPE stores no sensitive data. Option B goes very well with modern programming paradigms, but the disadvantage is that you need to have an "auth: MD5-PW XXX" line in your maintainer, and should that pass ever leak somehow it could be used through webupdates / email / api, from any location. I think all in the group agree that it would be very nice if you can perform 100% of all operations without the need for any MD5-PW. I'll even go as far as stating that we should not be looking at successors such as SHA3-PW, let's leap forward and make the PW auth concept entirely obsolete. :-) CALL FOR IDEAS ============== Now that personalised authorisation is covered and in progress, what about our poor applications? How should they authenticate with the RIPE DB? I see value in stuff like signalling to RIPE "this token can only be used for the API from this source IP address", I've also heard that OAUTH2 is magic and populair for app2app auth. Or maybe all of this is is overkill and we just need to GPG sign the payload of the requests to rest.db.ripe.net and call it a day? DB-WG, please speak up and voice your ideas! Kind regards, Job
Hi, On Thu, Aug 20, 2015 at 02:40:43PM +0200, Job Snijders wrote:
the RIPE DB:
a) send GPG signed emails (and wait for the dumb greylisting to clear) b) call the http://rest.db.ripe.net/{source}/{objecttype}/{key}?password=XXX restful API
c) syncupdates - works with PGP-signed objects Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Thu, Aug 20, 2015 at 10:24:20PM +0200, Gert Doering wrote:
Hi,
On Thu, Aug 20, 2015 at 02:40:43PM +0200, Job Snijders wrote:
the RIPE DB:
a) send GPG signed emails (and wait for the dumb greylisting to clear) b) call the http://rest.db.ripe.net/{source}/{objecttype}/{key}?password=XXX restful API
c) syncupdates - works with PGP-signed objects
Mmmm interesting, you just POST against https://apps.db.ripe.net/syncupdates/simple-rpsl.html? How do you properly catch errors and such? Kind regards, Job
Hi, On Thu, Aug 20, 2015 at 11:19:34PM +0200, Job Snijders wrote:
On Thu, Aug 20, 2015 at 10:24:20PM +0200, Gert Doering wrote:
On Thu, Aug 20, 2015 at 02:40:43PM +0200, Job Snijders wrote:
the RIPE DB:
a) send GPG signed emails (and wait for the dumb greylisting to clear) b) call the http://rest.db.ripe.net/{source}/{objecttype}/{key}?password=XXX restful API
c) syncupdates - works with PGP-signed objects
Mmmm interesting, you just POST against https://apps.db.ripe.net/syncupdates/simple-rpsl.html?
The script I downloaded from RIPE about a decade ago seems to post to http://syncupdates.db.ripe.net/ but otherwise, yes.
How do you properly catch errors and such?
It spits out about the same return message you get from the e-mail robot - with SUMMARY OF UPDATE and everything. So yes, a bit of parsing is needed, but for our fairly basic use cases (create new person: objects, add/update and delete inetnum:) this is easy enough. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert and others On 22/08/2015 22:37, Gert Doering wrote:
Hi,
On Thu, Aug 20, 2015 at 11:19:34PM +0200, Job Snijders wrote:
On Thu, Aug 20, 2015 at 10:24:20PM +0200, Gert Doering wrote:
c) syncupdates - works with PGP-signed objects
Mmmm interesting, you just POST against https://apps.db.ripe.net/syncupdates/simple-rpsl.html?
The script I downloaded from RIPE about a decade ago seems to post to http://syncupdates.db.ripe.net/
This is an ancient URL that still works because it is redirected to the apps.db.ripe.net address. I was never a great fan of keeping old URLs alive indefinitely and maintaining a mass of redirects. If one of these redirects gets dropped accidentally during some system upgrade or maintenance a service suddenly fails for many users. The apps URL has been around now for a few years. Users should be advised to change to it and a time limit given for when old URLs are dropped from service. cheers denis
Hi All I stand corrected :) On 24/08/2015 11:23, denis wrote:
Hi Gert and others
On 22/08/2015 22:37, Gert Doering wrote:
Hi,
On Thu, Aug 20, 2015 at 11:19:34PM +0200, Job Snijders wrote:
On Thu, Aug 20, 2015 at 10:24:20PM +0200, Gert Doering wrote:
c) syncupdates - works with PGP-signed objects
Mmmm interesting, you just POST against https://apps.db.ripe.net/syncupdates/simple-rpsl.html?
The script I downloaded from RIPE about a decade ago seems to post to http://syncupdates.db.ripe.net/
This is an ancient URL that still works because it is redirected to the apps.db.ripe.net address. I was never a great fan of keeping old URLs alive indefinitely and maintaining a mass of redirects. If one of these redirects gets dropped accidentally during some system upgrade or maintenance a service suddenly fails for many users. The apps URL has been around now for a few years. Users should be advised to change to it and a time limit given for when old URLs are dropped from service.
The http://syncupdates.db.ripe.net/ is still a valid URL for scripts to use whereas https://apps.db.ripe.net/syncupdates/simple-rpsl.html is a web form for end users to use. But my argument still stands that there are some redirects still in use and these should have a time limit. cheers denis
cheers denis
Hi Job On 20/08/2015 14:40, Job Snijders wrote:
Hi group,
I think all in the group agree that it would be very nice if you can perform 100% of all operations without the need for any MD5-PW. I'll even go as far as stating that we should not be looking at successors such as SHA3-PW, let's leap forward and make the PW auth concept entirely obsolete. :-)
Why? I have never understood this almost religious obsession to get rid of passwords in the RIPE Database. Most of you life online involves passwords. Including lots of financial, legal and government interactions. What makes the RIPE Database so much more important that it should not use passwords? When it was suggested to hide the password hash I thought that was a mistake. We should have hidden the whole MNTNER object from public view. Why does anyone outside of my organisation need to see anything in my MNTNER object? Why should you know if I use a password or PGP or whatever? This is my business not yours. When personalised auth is introduced why should anyone outside of my organisation know 'who' in my organisation is responsible for maintaining my data? This is all my data management and has nothing to do with any internet operations.
CALL FOR IDEAS ==============
Now that personalised authorisation is covered and in progress, what about our poor applications? How should they authenticate with the RIPE DB?
I see value in stuff like signalling to RIPE "this token can only be used for the API from this source IP address", I've also heard that OAUTH2 is magic and populair for app2app auth. Or maybe all of this is is overkill and we just need to GPG sign the payload of the requests to rest.db.ripe.net and call it a day?
Whatever method is adopted let me suggest we avoid introducing a new 'anonymous' element to authentication. One or more people should take responsibility for running automated processes. So whatever token is chosen it should be in PERSON objects. cheers denis
DB-WG, please speak up and voice your ideas!
Kind regards,
Job
On Fri, Aug 21, 2015 at 01:58:46AM +0200, denis wrote:
CALL FOR IDEAS ==============
Now that personalised authorisation is covered and in progress, what about our poor applications? How should they authenticate with the RIPE DB?
I see value in stuff like signalling to RIPE "this token can only be used for the API from this source IP address", I've also heard that OAUTH2 is magic and populair for app2app auth. Or maybe all of this is is overkill and we just need to GPG sign the payload of the requests to rest.db.ripe.net and call it a day?
Whatever method is adopted let me suggest we avoid introducing a new 'anonymous' element to authentication. One or more people should take responsibility for running automated processes. So whatever token is chosen it should be in PERSON objects.
I beg to differ, applications are not persons, and applications are not tied to persons (at least not in the organisations where I have done work). If someone leaves the company, the application must continue to able operate. I agree it would be highly preferable if (if any) new token is not 'anonymous', it should be easy for the owner of the process to identify which application the token belongs to. Kind regards, Job
On Fri, Aug 21, 2015 at 01:58:46AM +0200, denis wrote:
On 20/08/2015 14:40, Job Snijders wrote:
I think all in the group agree that it would be very nice if you can perform 100% of all operations without the need for any MD5-PW. I'll even go as far as stating that we should not be looking at successors such as SHA3-PW, let's leap forward and make the PW auth concept entirely obsolete. :-)
Why? I have never understood this almost religious obsession to get rid of passwords in the RIPE Database. Most of you life online involves passwords.
https://www.google.nl/webhp?#safe=on&q=passwords+suck :-) I personally prefer asymmetric forms of authentication: should there be an incident or we at some point realise we should not have exposed certain aspects, there is nothing of value in the internal DB except public components of asymmetric methods.
Including lots of financial, legal and government interactions. What makes the RIPE Database so much more important that it should not use passwords?
Their function in society does not automatically designate them as proper thought leaders ;-)
When it was suggested to hide the password hash I thought that was a mistake. We should have hidden the whole MNTNER object from public view. Why does anyone outside of my organisation need to see anything in my MNTNER object? Why should you know if I use a password or PGP or whatever? This is my business not yours.
This seems to play into another thread, where someone had trouble retrieving the proper value of some "auth:" lines. It would be worth exploring how we can hide all "auth:" lines yet make them easily accessible to the owner. Kind regards, Job
Hi job On 21/08/2015 02:32, Job Snijders wrote:
On Fri, Aug 21, 2015 at 01:58:46AM +0200, denis wrote:
When it was suggested to hide the password hash I thought that was a mistake. We should have hidden the whole MNTNER object from public view. Why does anyone outside of my organisation need to see anything in my MNTNER object? Why should you know if I use a password or PGP or whatever? This is my business not yours.
This seems to play into another thread, where someone had trouble retrieving the proper value of some "auth:" lines. It would be worth exploring how we can hide all "auth:" lines yet make them easily accessible to the owner.
Bear in mind that I have spent years thinking about some of these issues from many angles :) Sometimes a simple, quick fix is considered to be the appropriate course of action. I guess that is why we hid the password hashes. But in the end that proved to be not simple. Sometimes it is worth taking a step back and looking at a wider picture. If you hide anything there has to be some method for the right people to see what is hidden. Once you start trying to hide significant parts of an object it may be easier to hide the whole object. And there can be additional benefits in that. Notifications are part of the security system within the database. Just as with the security tokens, there is no justifiable reason why the public should have any knowledge of who gets notified within my organisation when data is changed or some attempt is made. If the whole MNTNER object is hidden it can be shown to authenticated users by an update with a pseudo attribute. Just as with a "dryrun:", if we have another pseudo attribute "show:" then instead of doing an update the full, current object is returned if the authorisation is valid. This will work with any of the authorisation tokens in the object. cheers denis
Kind regards,
Job
On Fri, 21 Aug 2015, denis wrote:
Hi job
On 21/08/2015 02:32, Job Snijders wrote:
On Fri, Aug 21, 2015 at 01:58:46AM +0200, denis wrote:
When it was suggested to hide the password hash I thought that was a mistake. We should have hidden the whole MNTNER object from public view. Why does anyone outside of my organisation need to see anything in my MNTNER object? Why should you know if I use a password or PGP or whatever? This is my business not yours.
This seems to play into another thread, where someone had trouble retrieving the proper value of some "auth:" lines. It would be worth exploring how we can hide all "auth:" lines yet make them easily accessible to the owner.
Bear in mind that I have spent years thinking about some of these issues from many angles :) Sometimes a simple, quick fix is considered to be the appropriate course of action. I guess that is why we hid the password hashes. But in the end that proved to be not simple. Sometimes it is worth taking a step back and looking at a wider picture.
If you hide anything there has to be some method for the right people to see what is hidden. Once you start trying to hide significant parts of an object it may be easier to hide the whole object. And there can be additional benefits in that. Notifications are part of the security system within the database. Just as with the security tokens, there is no justifiable reason why the public should have any knowledge of who gets notified within my organisation when data is changed or some attempt is made.
If the whole MNTNER object is hidden it can be shown to authenticated users by an update with a pseudo attribute. Just as with a "dryrun:", if we have another pseudo attribute "show:" then instead of doing an update the full, current object is returned if the authorisation is valid. This will work with any of the authorisation tokens in the object.
Somethin like that, yes. I agree that i might not be necessary for the whole world to know the exact persons listed in a maintainer object, as long as it is not hidden for those authorized. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
participants (5)
-
Daniel Stolpe -
denis -
Gert Doering -
Job Snijders -
Job Snijders