[apnic-talk] [apnic-announce] Deprecation of the MAIL-FROM auth scheme (
Dear Colleagues,
The email below from the RIPE NCC to the RIPE community describes
the proposed change to authentication methods in the RIPE database.
Under the proposed change, 'MAIL-FROM' will no longer be accepted
to authenticate changes in the RIPE database.
APNIC recognises this initiative as important and proposes to
adopt the proposal in respect of APNIC database and would welcome
comments, suggestions and feedback regarding this proposal.
Discussion should take place on the Database SIG mailing list.
You need to be subscribed to the list to post to the list. The
list is managed by majordomo. Details of how to subscribe via
the web site are available from:
http://www.apnic.net/net_comm/lists/index.html
We look forward to receiving your input.
Best wishes,
Anne Lord
_____________________________________________________________________
APNIC Secretariat <secretariat at apnic dot net>
Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100
PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199
Level 1,33 Park Road, Milton, QLD http://www.apnic.net
----------------------------------------------------------------------
---------- Forwarded message ----------
Date: Mon, 25 Mar 2002 13:58:10 +0100
From: Andrei Robachevsky <andrei at ripe dot net>
Organization: RIPE NCC
To: db-wg at ripe dot net
Subject: Deprecation of the MAIL-FROM auth scheme
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.
---------
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.