On 2003-04-15 19:04:54 +0200, Hank Nussbacher wrote:

Back in March 2002 we started to deprecate auth=MAIL-FROM. In August we finished it: http://www.ripe.net/ripencc/pub-services/db/mailfrom.html

We did not do the same for auth=NONE and the RIPE announcement stated:

"Though NONE "auth" scheme is even weaker it is not supposed to be consciously used for object protection, but rather as notification facility. Therefore NONE "auth" scheme is outside the scope of this proposal."

It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects.

[ example removed ]

RIPE NCC won't deprecate auth=NONE without us telling them to do it. Why would we not want this?

There are reasons why NONE may be useful: - People may still use NONE maintainers to "tag" their objects, allowing a simple inverse query to find all objects maintinaed. - It acts as a centralised place to keep notification e-mail addresses (as opposed to putting a "notify:" attribute on each object). We (the RIPE DB team) think that probably most people are just using NONE because it is easy, and not worrying about protection, rather than relying on it for either of these. But in practice, since RIPE DBM can undo any damage by a malicious user, there is not that much motivation to use strong authentication, as notifications are reliable. Aside from the possibility that NONE may actually be useful, there is a further issue, which is that when the database was converted from RIPE-181 to RPSL objects that did not have a maintainer had RIPE-NCC-NONE-MNT added as their maintainer. This insured that operationally the objects worked the same as before - no protection. The main use of this maintainer is for inetnum objects. There are over 65000 such objects - about 8.5% of the inetnums. Updates for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all updates. As far as the actual process of deprecating NONE authentication, we can probably do it mostly the same way that we deprecated MAIL-FROM. In that case we converted all "auth:" attributes with MAIL-FROM into a "remarks:" attribute. Originally we inteded each user to send us a fax to unlock the maintainer if they had not done so before the deadline, but there were a very large number of faxes, so we ended up generating an MD5-PW password and providing a mechanism to retrieve it: http://www.ripe.net/db/mailfrom.html It is not clear what to do about objects that have RIPE-NCC-NONE-MNT as their maintainer. One possibility is to make a "well-known" password in a new maintainer, and note it in the "remarks:" of that object: mntner: RIPE-NCC-RPSL-MNT descr: This maintainer's password is 'rpsl' descr: This password will never change. auth: MD5-PW $1$3/2GjScs$FMfB8nFHYdNJZ8z3ZuR6A/ mnt-by: RIPE-DBM-MNT . . . Objects with RIPE-NCC-NONE-MNT would then be updated to use this maintainer as their "mnt-by:". We would notify the "admin-c:" and/or "tech-c:" of objects protected by RIPE-NCC-NONE-MNT in advance of the pending change. This still leaves these objects effectively unprotected. Another option is to "lock" these objects, behind a maintainer that does not allow them to be updated. There are a couple of concerns with this: 1. It may result in people not updating their data, for example leaving old contacts, since they cannot easily update their information. 2. It may result in a significant load for RIPE DBM, possibly resulting in delay in answering other tickets, issuing maintainers to these users and updating the locked objects. If the community feels that there is no need for written approval, we can create a system to generate maintainers and update objects "on demand" for these objects, using a scheme similar to that used for MAIL-FROM only maintainers. It is also possible that we can generate unique maintainers in advance, although that will increase our maintainer count from 9000 to 75000. This is not necessarily bad, but it is a large increase. For the record, I am just exploring the topic. The RIPE NCC will be happy to implement whatever changes the community feels useful. :) -- Shane Kerr RIPE NCC