[db-wg] Deprecation of the NONE Authentication Scheme

At 08:58 AM 07-11-05 +0100, Kristian Larsson wrote:
>On Mon, Nov 07, 2005 at 08:57:30AM +0200, Hank Nussbacher wrote:
> > At 04:52 PM 13-04-04 +0200, Ziya Suzen wrote:
> >
> > If auth:NONE was deprecated why is the weak password graph constantly
> > increasing:
> > http://www.ripe.net/projects/dbconstat/protect-weakpass.html
>Because people who have auth:NONE are doing more
>db changes.
>People are lazy and won't change auth scheme.
>
> > Is auth: NONE still valid or not?
>It is not to be used but I don't think there is
>anything actually forcing you to switch!?

The email below from April 2004 stated:

 > >Therefore, the plan for MNTNER objects with the NONE authentication
 > >scheme is:
 > >
 > >o Remove "auth: NONE" attributes from all MNTNER objects, by changing
 > >them to a "remarks:" attribute with a URL explaining the change.

I think that would force users to switch since auth=NONE shouldn't exist 
any longer.

-Hank

> >
> > According to ripe-358 it is not:
> > http://www.ripe.net/ripe/docs/db-query-manual.html
> >
> > If not, how is NONE being used - or is this graph plotting incorrect info?
> >
> > -Hank
> >
> > >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
> >
>
>
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.