[apnic-announce] Deprecation of the MAIL-FROM auth scheme (fwd)

  • To: apnic-announce at lists dot apnic dot net
  • Subject: [apnic-announce] Deprecation of the MAIL-FROM auth scheme (fwd)
  • From: Anne Lord <anne at apnic dot net>
  • Date: Wed, 27 Mar 2002 11:56:40 +1000 (EST)
  • Cc: sig-db at lists dot apnic dot net
  • Reply-to: apnic-talk@apnic.net
  • Sender: owner-apnic-announce@lists.apnic.net
    • 
      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.