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@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@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@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@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@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@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
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 Is auth: NONE still valid or not? 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@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@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@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@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@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@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
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!?
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@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@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@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@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@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@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
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@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@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@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@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@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@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.
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
Is auth: NONE still valid or not?
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, I just searched through the maintainers, and there are no maintainers with the NONE password. The graph is incorrect. My guess is that we are looking for the word "none" in the object, without actually looking for the "auth: none" attribute. Apologies for this, we'll have a look and fix it. -- Shane
Shane Kerr wrote:
I just searched through the maintainers, and there are no maintainers with the NONE password.
Or rather, with the NONE authentication scheme. We don't know if your password is "NONE". You can use it, but I don't recommend it. ;) -- Shane
participants (4)
-
Hank Nussbacher -
Kristian Larsson -
Shane Kerr -
Ziya Suzen