Update of mntner object with mixed authentication
I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself? Puzzled, -- Alex
I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself?
I don't see a way of doing that as it is, you can't use PGP to authenticate a request for an object, so either, everybody have to remove their passwords from the RFC3068-MNT or all those that want to be able to update it need to keep a password in. (Until this gets better I'm reluctantly keeping a password there) /Anders
Dear Alex, The current arrangement of hiding MD5 password hashes is based on a series of community discussions and two iterations of the implementation. Although the consensus is that hiding the hashes is beneficial from a security point of view, unfortunately this does result in some corner cases that are not easy to resolve. This is an extreme example of such a corner case with so many people sharing the use of one MNTNER. Currently there is no simple way for a user with only PGP credentials to modify a MNTNER object like this one. Only one of the users with a password can query the full object. Wilfried has suggested one work around. Bear in mind that these corner cases only occur when there is a mixture of credential options. If all users used either password or PGP there is no issue. So another work around in this case could be for the PGP users to included a strong password as well. As there are already so many passwords in this object, perhaps this would not affect the overall security level. The RIPE NCC is currently re-developing the whole of the RIPE Database update software. As part of this process the RIPE NCC would like to put a proposal to the community for additional authentication options including an extension to the RIPE NCC Single Sign On service (SSO) to cover authentication of updates to the RIPE Database. This could provide a long term solution to the MNTNER problem. We are still in the early stages of this re-development, which we expect to last for a few months. So we don't yet have the full details of additional authentication options. But when we do we will submit it to the community for consideration. The RIPE NCC is also always open to suggestions from the community for solutions to known problems. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 18/07/2012 13:04, Anders Mundt Due wrote:
I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself?
I don't see a way of doing that as it is, you can't use PGP to authenticate a request for an object, so either, everybody have to remove their passwords from the RFC3068-MNT or all those that want to be able to update it need to keep a password in.
(Until this gets better I'm reluctantly keeping a password there)
/Anders
Hi Denis On Wed, 18 Jul 2012 15:11:01 +0200, Denis Walker <denis@ripe.net> said:
The current arrangement of hiding MD5 password hashes is based on a series of community discussions and two iterations of the implementation. Although the consensus is that hiding the hashes is beneficial from a security point of view, unfortunately this does result in some corner cases that are not easy to resolve. This is an extreme example of such a corner case with so many people sharing the use of one MNTNER.
Currently there is no simple way for a user with only PGP credentials to modify a MNTNER object like this one. Only one of the users with a password can query the full object. Wilfried has suggested one work around. Bear in mind that these corner cases only occur when there is a mixture of credential options. If all users used either password or PGP there is no issue. So another work around in this case could be for the PGP users to included a strong password as well. As there are already so many passwords in this object, perhaps this would not affect the overall security level.
Yes, that's the path I've taken.
The RIPE NCC is currently re-developing the whole of the RIPE Database update software. As part of this process the RIPE NCC would like to put a proposal to the community for additional authentication options including an extension to the RIPE NCC Single Sign On service (SSO) to cover authentication of updates to the RIPE Database. This could provide a long term solution to the MNTNER problem.
We are still in the early stages of this re-development, which we expect to last for a few months. So we don't yet have the full details of additional authentication options. But when we do we will submit it to the community for consideration. The RIPE NCC is also always open to suggestions from the community for solutions to known problems.
For the case at hand, it would be enough to have a method to authenticate *queries* for mntner objects with any of the valid methods for updates (not just passwords). Regards, Alex
Hi Alex! Alexander Gall wrote:
I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself?
This is one of the (unwanted) side-effects of removing hashes from the whois output: the DB object can no longer be used as the primary/authoritative copy of the object, and retrieved for submitting an update. It should still work as follows, assuming that "one party" still has a "full" copy of the object and uses password authentication: 1) get a plain copy of the unfiltered object from a reliable source 2) modify the object as planned 3) sign the message with your PGP Key or X509 Key 4) send the modified and signed object back to where you got it from 5) have the "keeper of the master copy" submit the update by attaching the password, or rather signing the update, too 6) ask the "k.o.t.m.c" to store the modified object for future ref ;-)
Puzzled,
This *should* work, imho, fingers crossed... -Wilfried PS: don't forget the use of the -B flag (or equivalent) to prevent loss of all accumulated changed: lines ;-)
Hello Wilfried Long time no seen :) On Wed, 18 Jul 2012 14:32:11 +0200, "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> said:
Alexander Gall wrote:
I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself?
This is one of the (unwanted) side-effects of removing hashes from the whois output: the DB object can no longer be used as the primary/authoritative copy of the object, and retrieved for submitting an update.
It should still work as follows, assuming that "one party" still has a "full" copy of the object and uses password authentication:
Yes, but that's not exactly practical :/ I can see a workaround for this with webupdate. Instead of accecpting only passwords for authentication, the system could create a challenge that somebody who has a X509 or PGP key could encrypt offline and present to the system, which could verify it with the corresponding public key referenced by the mntner object. -- Alex
On Jul 18, Alexander Gall <gall@switch.ch> wrote:
I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself? When I noticed the same issue with TEREDO-MNT I discussed it with the other maintainers and then removed all password authentication attributes. I contacted the dozen or so of people who had provided passwords and IIRC only one requested to add their key. No problems so far.
-- ciao, Marco
participants (5)
-
Alexander Gall -
Anders Mundt Due -
Denis Walker -
md＠Linux.IT -
Wilfried Woeber, UniVie/ACOnet