Re: [db-wg] Deprecating auth=NONE

[Shane Kerr <]

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