Dear Colleagues,
Another issues that was discussed at the RIPE-41 meeting is deprecation
of a MAIL-FROM authentication scheme. It was agreed that the weakness of
this auth form does not allow to provide real protection to the database
objects and it should be deprecated.
As a matter of fact recently we had to deal with several incidents when
objects were hijacked using the flaw of the MAIL-FROM. It took time and
resources from the ripe-dbm to investigate the matter and restore the
objects, to say nothing about possible damage to the owners of such
objects should the incident has gone unnoticed.
Please find enclosed the migration plan to a more secure database.
Your comments are welcome.
Regards,
Andrei Robachevsky
DB Group Manager
RIPE NCC
Deprecation of MAIL-FROM authentication and authorisation scheme (auth scheme)
==============================================================================
Motivation
==========
This authentication method checks the content of the RFC2822 From: header of
an update request against the regular expression specified as <auth-info>
field of the "auth:" attribute. If the regular expression matches the
content of the From: header the update request is authenticated
successfully. The matching is applied to the whole content of the From:
header including comments if present. No attempt is made to isolate the
mailbox part.
This authentication scheme is very weak. Forging RFC2822 headers can be done
very easily. With the existence of more secure "auth" schemes in the RIPE
Database, it does not make much sense to support it any more.
Currently 41% (~2700) of all mntner objects in the RIPE Database are using
this weak "auth" scheme.
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.
Transition phases
==================
I Notifying mntners with MAIL-FROM auth scheme
-----------------------------------------------
An announcement presenting this proposal and encouraging the owners of the
mntners to remove MAIL-FROM auth scheme from their objects will be send.
The distribution list will be compiled from e-mail addresses listed in
"upd-to:", "mnt-nfy:" attributes of the mntners, as well as using contact
information (e-mail) from "admin-c:" and "tech-c:" references.
II Rejecting updates for mntner objects containing MAIL-FROM auth scheme
-------------------------------------------------------------------------
An update of a mntner object will be rejected if the new version of the
mntner contains MAIL-FROM auth scheme. This will be reported as a syntax
error in the "auth:" attribute.
III Rejecting using the MAIL-FROM auth scheme for authorisation
---------------------------------------------------------------
When processing an update for an object protected by a mntner that contains
MAIL-FROM auth scheme, this scheme will be ignored. That means that if
mntner defines other auth schemes different from MAIL-FROM, the credentials
relevant to these schemes may be used. If the only auth scheme defined is
MAIL-FROM, no update can be authorised by such mntner. In case of failure
the acknowledgement will indicate that MAIL-FROM "auth" scheme is not valid
any more.
IV Cleanup
----------
The mntners still containing "auth:" attribute with the MAIL-FROM auth
scheme will be modified so that such attributes will be removed from the
objects. Before this a final call will be sent to the owners of these
mntners ("upd-to:", "mnt-nfy:" attributes of the mntners, as well as to the
contacts from "admin-c:" and "tech-c:" references).
A "remarks:" attrubute will be added with clear explanation of the
situation.
In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it
will be replaced with a CRYPT-PW scheme with a DES string that cannot be
matched.
