[db-wg] Deprecation of the NONE Authentication Scheme

Dear Colleagues,

As announced at RIPE 47 the NONE authentication scheme will be
deprecated.

After 26 April 2004 the RIPE Whois Database will not accept updates using
the NONE authentication scheme.

If you have objects protected by a MNTNER object which has the NONE
authentication scheme, please assign another authentication scheme or
create another MNTNER object to protect these objects.

If you are a RIPE NCC member you can create new MNTNER objects through
the LIR Portal or send your update to <auto-dbm at ripe.net>.

History and details:
--------------------

1. Motivation

The RIPE Database protects data from unauthorised modification through
the use of references to maintainer objects.  The maintainer objects
contain an "auth:" attribute which specifiy how a user is
authenticated during updates to the database.

One of the allowed authentication schemes is "NONE", which is actually
not an authentication at all, but rather specifies that no
authentication is necessary.  NONE is intended to be used consciously,
as a notification facility or as a means to tag objects.  

In April 2003, a proposal was sent to the Database Working Group by
Hank Nussbacher:

    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.

It is likely that in many cases NONE is used simply because it is
easy.  Currently approximately 500 maintainers use NONE - about 5% of
all maintainers.


2. Plan

Normally with a database cleanup effort, an announcement is sent to
the appropriate mailing lists, posted to the RIPE web page, and also
sent to the specific users affected.  A period of time for cleanup is
given.  Finally, if the users have not fixed the data then it is
modified.

However, for the NONE deprecation, it is inadvisable to do this
as it means announcing what is in effect a security
vulnerability.  Also, our operational experience with past cleanups
shows that most users do not really participate through the phases of
the effort.

Therefore, the plan for MNTNER objects with the NONE authentication
scheme is:

o Announcement only to db-wg mailing list. (This announcement)

o Remove "auth: NONE" attributes from all MNTNER objects, by changing
them to a "remarks:" attribute with a URL explaining the change.

o If that is the only authentication scheme, update the mntner
objects, adding MD5-PW with a generated password.

o E-mail the "admin-c:" and "tech-c:" of the objects, and the e-mail
addresses listed in the "upd-to:" and "mnt-nfy:" attributes of the
objects, explaining the change and including the new password if one
is added.

o Passwords can be requested via an e-mail to <ripe-dbm at ripe.net>. 
 
The reply with the password will be sent to the same contacts.  After
a certain period of time the service will be discontinued.  Users
wishing to use these maintainers may contact <ripe-dbm at ripe.net> for
assistance.


3. RIPE-NCC-NONE-MNT

A maintainer with NONE authentication, RIPE-NCC-NONE-MNT, was added to
objects without any maintainer when the database was converted from
RIPE-181 format to RPSL format in April 2001.  There is a remark in
these objects which includes the following: 
 
remarks:      The RIPE NCC will never use this maintainer object to 
remarks:      enforce any sort of control over user's objects. 
 
It is possible this could have been interpreted to mean that no
restriction would ever be added to the object. 
 
One use of the RIPE-NCC-NONE-MNT has been to allow the creation of
objects representing routing policy for resources not allocated or
assigned by the RIPE NCC.  This is done by using "mnt-routes:
RIPE-NCC-NONE-MNT" or "mnt-lower: RIPE-NCC-NONE-MNT" as appropriate.

A new maintainer object will be created for these cases, with a well-
known password, published in the object:

mntner:       RIPE-NCC-RPSL-MNT
descr:        This maintainer may be used to create objects to represent
descr:        routing policy in the RIPE Database for number resources not
descr:        allocated or assigned from the RIPE NCC.
admin-c:      RD132-RIPE
upd-to:       ripe-dbm-notify at ripe.net
auth:         MD5-PW $1$GUExyzzy$XQtbZHGVqy9GW8BiAckBV1
remarks:      *******************************************************
remarks:      * The password for this object is 'RPSL', without the *
remarks:      * quotes.                                             *
remarks:      *******************************************************
mnt-by:       RIPE-DBM-MNT
referral-by:  RIPE-DBM-MNT
changed:      ripe-dbm at ripe.net 20040301
source:       RIPE

The main use of this maintainer is for INETNUM objects.  There are
approximately 60000 such objects - about 6% of the inetnums.  Updates
for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all
updates.

For objects using RIPE-NCC-NONE-MNT:

o If there are other "mnt-by:" attributes it will be changed to a
"remarks:" attribute.

o Otherwise, the "mnt-by:" will be changed to RIPE-NCC-LOCKED-MNT,
which has a locked password (or PGP key).

o A "remarks:" attribute will be added explaining how to generate a
maintainer.

o An e-mail will be sent to the "admin-c:" and "tech-c:" of the
objects, and the e-mail addresses listed in the "notify:" attributes
of the objects, explaining the change and giving a URL which will help
to generate a new maintainer or assign another existing maintainer.

o At the URL, the object will be automatically updated to have a new
maintainer.

o After a certain period of time the service will be discontinued.
Users wishing to use these maintainers may contact ripe-dbm at ripe.net
for assistance.


4. Other maintainers with "auth: NONE"

The RIPE-NCC-PN-NONE-MNT was used to mark PERSON objects not to be
deleted in the 2001 person cleanup.  It can be removed and the
maintainer deleted.

The LIM-MNT is used for limericks.  It will have a well-known password
similar to the RPSL maintainer.  It will also be maintained by another
maintainer (not itself, as currently).

--
Ziya Suzen
RIPE NCC