1st draft agenda for DB-WG in Lisbon

Dear colleagues,

below you will find a draft document describing a comprehensive 
authorisaion and notification model for the database.
This will replace the guardian machanism for ASes and communities.
It is still lacking the examples at the end but all the substance
is there. I will send around the examples as soon as they are finished.

This document will be up for decision at the db-wg meeting.








      Authorisation and Notification of Changes in the
                       RIPE Database


                     Daniel Karrenberg
                          RIPE NCC

                      Marten Terpstra
                          RIPE NCC

                         D R A F T

                   Document ID: ripe-auth
                    Obsoletes: ripe-096




                          ABSTRACT

          Two  new  attributes  are  defined  for   all
     objects in the RIPE database in order to implement
     a generalised method for authorising  changes  and
     to  notify  interested parties of any changes made
     to a specific database object.  Further the  main-
     tainer  object  is  defined  to represent entities
     maintaining database objects.




History

Updates to the RIPE database [ref] are currently done almost
exclusively  by electronic mail which is processed automati-
cally.  The number of updates processed is substantial  [ref
qtly].   Historically  there was no authorisation and anyone
could change any object in  the  database.  From  the  start
extensive audit trails of changes have been kept in order to
identify problems with  automatic  processing  or  to  trace
unintended  changes.  During more than 4 years of experience
with this model we have yet to encounter the first  instance
of  a malicious change to an object.  The amount of acciden-
tal unwanted changes is also surprisingly low.

In order to help detect unwanted changes the  notify  attri-
bute was introduced [ripe-096].  It will be described below.

Nonetheless the RIPE community  felt  a  need  to  introduce
authorisation  and  authentication mechanisms for updates to



ripe-auth.txt
                           - 2 -


the RIPE database.  The specific need arose when  the  data-
base started to be used as a routing registry [ripe-81].

As a simple straightforward  measure  guarded  objects  were
introduced.  All aut-num and community objects were guarded.
Any update to such an object had to be  manually  authorised
by  RIPE  NCC  staff.   While  this was easy to implement it
obviously does not scale well.

The data representation schema used for the routing registry
also combined allocation and routing registry information in
a single  object,  the  inetnum  object.   Routing  registry
information  is not necessarily maintained and controlled by
those controlling the corresponding allocation  information.
In  order  to  solve  this  the special mechanism of guarded
attributes was introduced [ref ripe-81?].  This  has  turned
out  to  be  unwieldy  since it uses a special mechanism for
updates to some attributes of an  object  and  is  not  well
integrated into the database update model.

For this and other reasons  the  representation  of  routing
information in the RIPE database has been changed to clearly
separate routing from allocation information by storing them
in  different  objects.   Consequently  the authorisation of
changes can again be done at the object level.































ripe-auth.txt
                           - 3 -


Authorisation Model

The new model for authorisation of changes to  the  database
is  fully  integrated into the database model and applies to
any object.

Optionally each database object can be associated  with  one
or more maintainers who are authorised to make changes. Only
those maintainers and the RIPE NCC are  then  authorised  to
change or delete the object.

Each maintainer is also represented in the database  by  its
own  mntner  object which stores information such as contact
persons, authorisation and notification details.

Whenever a change to  an  object  is  attempted  the  mnt-by
attribute of the current database object is examined.

If there is no mnt-by attribute, the update always  proceeds
causing  any notifications specified in notify attributes of
the object.  This ensures  backward  compatibility.   It  is
also  a  perfectly  legitimate authorisation model for those
objects that do not need sophisticated authorisation.   Also
we  would  like  to stress that using stronger authorisation
requires timely processing of update requests. An  unrespon-
sive  maintainer  preventing others from making updates fre-
quently is a worse solution than no authorisation.

If the update is originated by a maintainer referenced in  a
mnt-by  attribute,  the  update  also  proceeds  causing the
necessary  notifications.  There  are  various  methods   to
authenticate  the  origin of an update request. These can be
configured in the mntner object described below.

If a new object with a mnt-by  attribute  is  added  to  the
database  or  a  mnt-by attribute is added to an object that
previously had no such attribute, the authorisation step  is
performed on the maintainer to be added.

If authentication fails or  the  originator  of  the  update
request  is  not  a  maintainer for the object concerned the
update request is forwarded  to  the  maintainer(s)  of  the
object  for  processing and the originator of the request is
notified.  No other  notifications  are  performed  in  this
case.

If an update is not authorised and no appropriate maintainer
can  be identified the request will be forwarded to the RIPE
NCC for action.

See the separate section below for details on authentication
methods and related matters.




ripe-auth.txt
                           - 4 -


The Maintained-By Attribute

Each RIPE database has an optional attribute  called  mnt-by
(maintained  by).   The  value  of the mnt-by attribute is a
reference to a mntner object in the database which describes
those  authorised  to make changes to the object.  See below
for details.

Multiple mntner objects can be referenced by separating them
with blanks, which is preferred, or by using multiple mnt-by
attributes per object.

In this case all maintainers referenced are equally  author-
ised  to  make  changes to the object.  For instance this is
applicable to person objects maintained by both  a  toplevel
domain registry and a local address space registry.  Because
close  coordination is required if an object is to be  main-
tained  by  multiple maintainers, this is expected to be the
exception rather than the rule.

When responding to queries, the RIPE whois server  will  not
automatically  return  the associated mntner object with any
matching object as is done with contact persons.

































ripe-auth.txt
                           - 5 -


The Maintainer Object

The mntner object represents an entity  maintaining  objects
in  the  RIPE  database.   The  maintainer is identified and
referred to by a unique maintainer name.  The mntner  object
is  used  every  time a object database object with a mnt-by
attribute is added, updated or deleted to determine  whether
the  originator  of the update request is authorised to make
the update.

Adding a new mntner object has to be authorised manually  by
RIPE NCC staff.  Updates to mntner objects follow the normal
authorisation rules but  receive  special  scrutiny  by  NCC
staff too.


mntner:         [mandatory]          [single]
descr:          [mandatory]          [multiple]
admin-c:        [mandatory]          [multiple]
tech-c:         [optional]           [multiple]
upd-to:         [mandatory]          [multiple]
mnt-nfy:        [optional]           [multiple]
auth:           [mandatory]          [multiple]
remarks:        [optional]           [multiple]
notify:         [optional]           [multiple]
mnt-by:         [optional]           [multiple]
changed:        [mandatory]          [multiple]
source:         [mandatory]          [single]


Each attribute has the following syntax:


mntner:
     Maintainer name.

     Format:
          An  upper   case   text   string   consisting   of
          alphanumerics  and  "-"  not the same as any main-
          tainer name already defined.  The name has  to  be
          unique with regard to other maintainer names only.
          It can be the same as handles,  autonomous  system
          or community names.

     Examples:

          mntner: FOO-NOC

          mntner: NN-DOMREG

     Status: mandatory, only one line allowed





ripe-auth.txt
                           - 6 -


descr:
     A short description of the maintainer entity.

     Format:
          free text

     Examples:

          descr: FOO Networking Inc. NOC
          descr: Serving all customers of FOO Networking Inc.

          descr: Domain Registrar for the NN toplevel domain.

     Status: mandatory, multiple lines allowed


admin-c:
     Full name or uniquely assigned NIC-handle of an  admin-
     istrative  contact  person.  This  is the one with whom
     coordination should be done.

     Format:
          <firstname> <initials> <lastname> or <nic-handle>

     Example:

          admin-c: Joe T Bloggs
          admin-c: JTB1

          The handle form is preferred  because  it  is  not
          ambiguous.
     Status: mandatory, multiple lines allowed


tech-c:
     Full name or uniquely assigned NIC-handle of a  techni-
     cal  contact  person.  If defined this is someone to be
     contacted for technical problems such as bounced e-mail
     etc.

     Format:
          <firstname> <initials> <lastname> or <nic-handle>

     Examples:

          tech-c: John E Doe
          tech-c: JED31

          The handle form is preferred  because  it  is  not
          ambiguous.
     Status: optional, multiple lines allowed





ripe-auth.txt
                           - 7 -


upd-to:
     Updates to.  Any  unauthorised  update  request  of  an
     object  maintained by this maintainer will be forwarded
     to this address.


     Format:
          RFC-822 address


     Example:

          mnt-nfy: noc at foobar.net

          mnt-nfy: domreg at nn-nic.nn

     Status: mandatory, multiple lines allowed


mnt-nfy:
     Maintainer  notification.  This  e-mail  address   will
     receive  notification messages if any object maintained
     by this maintainer is added, changed  or  deleted.  The
     functionality is exactly the same as if a notify attri-
     bute had been defined in  the  object.   Specifying  it
     here   has  the  advantage  that  any  changes  of  the
     address(es) affect only one object.  For more  informa-
     tion see the section about the notify attribute.


     Format:
          RFC-822 address


     Example:

          mnt-nfy: noc at foobar.net

          mnt-nfy: domreg at nn-nic.nn

     Status: optional, multiple lines allowed


auth:
     specifies  which  scheme  will  be  used  identify  and
     authenticate update requests from this  maintainer.

     Format:
          <scheme-id> <auth-info>

          The scheme-ids currently defined are: NONE,  MAIL-
          FROM  and  CRYPT-PW.   The auth-info is additional
          information required by a particular scheme.  When



ripe-auth.txt
                           - 8 -


          more  than auth attribute is specified any of them
          can be used for authentication  of  updates,  i.e.
          specifying  NONE  and  others  does  not make much
          sense.  The auth attribute is not protected infor-
          mation  in  any  way; it is returned normally like
          any attribute by the whois server and available in
          stored  copies of the database. The strength of an
          authentication scheme  thus  has  to  lie  in  the
          scheme itself and cannot be based on the obscurity
          of the auth  attribute.   See  the  section  about
          authentication schemes for more details.

     Example:

          auth: NONE

          auth: CRYPT-PW dhjsdfhruewf

          auth: MAIL-FROM .*@ripe.net

     Status: mandatory, multiple lines allowed


remarks:
     Remarks/comments, to be used only for clarification.

     Format:
          free text

     Example:

          remarks: This is a test/example object.

     Status: optional, multiple lines allowed

notify:
     The notify attribute contains an email address to which
     notifications of changes to this object should be send.
     See also the appropriate section of this document.

     Format:
          <email-address>

          The <email-address> should  be  in  RFC822  domain
          syntax wherever possible.

     Example:

          notify: Marten.Terpstra at ripe.net

     Status: optional, multiple lines allowed

mnt-by:



ripe-auth.txt
                           - 9 -


     This attribute specifies who maintains this  object  in
     the RIPE database.  See also the appropriate section of
     this document.

     Format:
          <maintainer name>

     Example:

          maintainer: FOO-NOC

     Status: optional, multiple lines allowed

changed:
     Who changed this object last, and when was this  change
     made.

     Format:
          <email-address> YYMMDD

          <email-address> should be the address of the  per-
          son  who  made the last change. YYMMDD denotes the
          date this change was made.

     Example:

          changed: johndoe at terabit-labs.nn 900401

     Status: mandatory, multiple lines allowed

source:
     Source of the information.

     This is used to  separate  information  from  different
     sources  kept  by  the same database software. For RIPE
     database entries the value is fixed to RIPE.

     Format:
          RIPE
     Status: mandatory, only one line allowed
















ripe-auth.txt
                           - 10 -


Authentication Schemes

The authorisation  model  supports  multiple  authentication
schemes.   Currently  only relatively weak authentication is
defined. It is entirely possible to use stronger authentica-
tion  schemes  based  on  cryptographic  methods such as PGP
[ref] or PEM [ref].  It is expected that such  schemes  will
be defined as the need arises.

Please note again that the  authentication  scheme  and  the
additional  <auth-info>  is  public information available in
the database.  The strength of an authentication scheme must
be  inherent in that scheme and not be based on keeping this
information secret.  The reason for this is that it is  very
difficult  to keep the information confidential and thus the
RIPE NCC cannot take this responsibility.


NONE This is the simplest  authentication  scheme  which  is
     entirely  backwards  compatible  with the one currently
     used. No authentication is provided, i.e. it is assumed
     that  all  update requests originate from an authorised
     maintainer or are at least coordinated with one.   Any-
     one  in doubt whether it is OK to issue update requests
     should check with the maintainer concerned first.  When
     making  any  changes the mnt-by attribute should not be
     changed without explicit consent from the current main-
     tainer.

     Admittedly this authentication is rather weak. The only
     reason  for  its  existence is that maintainers have to
     specify it  explicitly  and  thereby  clearly  document
     their intentions.

     This scheme is for those who want to give everyone  the
     possibility  to  make  changes  while  at the same time
     using the mnt-by attribute  for  its  notification  and
     documentation  features.   A  good  reason  to use this
     scheme is that the maintainer cannot  guarantee  timely
     processing of updates himself.


MAIL-FROM
     This authentication  method  checks  the  RFC822  From:
     header of an update request against the regular expres-
     sion specified as <auth-info>. If the  regular  expres-
     sion matches the content of the From: header the update
     request is authenticated.  The regular expressions  are
     exactly  those  supported  by  the perl language [ref].
     The minimum supported is ".*". As it is  expected  that
     most  regular expressions will either be literals or of
     a form similar to .*@some\.domain\.or\.other an  exten-
     sive  description  of  the  possibilities  will  not be



ripe-auth.txt
                           - 11 -


     given.

     It should be stressed that this  authentication  scheme
     is very weak.  Forging RFC822 headers has been achieved
     by first grade school children.   The  reason  for  the
     scheme's  existence is that it easily prevents acciden-
     tal updates rather than allowing them first and  fixing
     them later when notified.

     This scheme is for those who want to prevent accidental
     updates  by  others  and  are  able  to  process update
     requests in a timely manner.



CRYPT-PW
     This scheme uses the Unix crypt(3)  routine,  which  is
     also used for login passwords under Unix.  This routine
     provides a so called "trap door" function, the  inverse
     of  which  is somewhat hard to calculate.  The password
     provided by the user is encrypted  with  this  function
     and  stored  in  its encrypted form only. When the user
     later provides the password again  for  authentication,
     the  encryption  is  repeated  and the results are com-
     pared.  Since the original (cleartext) password  cannot
     easily  be  computed  from the encrypted version the it
     does not have to be kept secret.

     The <auth-info> is the encrypted  password.   This  can
     either  be  obtained  locally with the appropriate Unix
     tools or on e-mail request  from   <ripe-dbm at ripe.net>.
     When  sending in update requests the cleartext password
     has to be provided in the message body by specifying

     password: cleartext-password

     at the beginning of a line  and  preceding  any  update
     requests  to  be thus authenticated.  The password will
     remain valid for all requests following it in the  same
     e-mail message or until another password is specified.

     This scheme is slightly  stronger  than  the  MAIL-FROM
     scheme.   It  is by no means meant to keep out a deter-
     mined malicious attacker. The crypt function is vulner-
     able  to  exhaustive  search by (lots of) fast machines
     and programs to do the searching are widely  available.
     For  this  reason  it  is  strongly  discouraged to use
     encrypted passwords also used for other  purposes  such
     as  Unix login accounts in this scheme. As you are pub-
     lishing the encrypted password in the  database  it  is
     open  to  attack.   The usual caveats about crypt pass-
     words apply, so is not very wise to use words or combi-
     nations  of  words  found  in  any  dictionary  of  any



ripe-auth.txt
                           - 12 -


     language.  See [R. Morris, K. Thompson: Password  Secu-
     rity: A Case History] for more details about the scheme
     and its vulnerabilities.





















































ripe-auth.txt
                           - 13 -


Special Rules in the Routing Registry

Because routes are  originated  by  autonomous  systems  the
autonomous system concerned should be the only one maintain-
ing route objects.  The maintainer of a route object is thus
expected  to  be  the  same as the one of the aut-num object
referenced in its origin attribute.  So far experience shows
that  it  is not necessary to enforce this rule strictly and
the added flexibility gained by not doing so  is  useful  in
many cases.

However in order to support the necessary routing  coordina-
tion,  special notification rules apply to the route object:
Whenever a route object is created or deleted or  the  comm-
list attribute changes, the guardians of all communities and
ASes referenced by the old and new objects will be  notified
in  addition to the normal notifications.  This rule ensures
that community maintainers  have  retroactive  control  over
community  membership  and that ASes get notified if someone
else adds a route originated by them.

The second special notification rule concerns  creation  and
deletion  of other route objects for the same route but with
different originators: Whenever a route object  for  exactly
the  same prefix is created or deleted, the guardians of all
route objects for this prefix are notified of this  and  the
existence  of  all  such  route objects.  This also includes
notification of the maintainers of  the  route  object  just
created.  This rule tries to ensure that multiple insertions
of the same route into the routing mesh are  coordinated  at
least  post  factum.   Due to the technical effort involved,
implementation of this rule may be effected  somewhat  later
than  the  rest  of the authorisation package.  Whether this
notification should also include more and less specific pre-
fixes is for experience to determine.





















ripe-auth.txt
                           - 14 -


The Notify Attribute

Each RIPE database object has an optional  attribute  called
notify.   The  value  of  the  notify attribute is one valid
RFC822 e-mail address.  There can be multiple notify  attri-
butes.   Whenever  the  object  concerned  is changed in the
database a notification message will be sent to each  e-mail
addresses appearing in a notify attribute.

This makes it straightforward to keep track  of  changes  to
specific  objects  and prevent changes from going unnoticed.
Multiple notify attributes make  it  possible  to  notify  a
number  of  interested parties.  This could be used to alert
all contact persons for an object or the local contact  per-
sons  as well as the relevant service provider.  Although it
may be tempting to put many notify  attributes  on  database
objects   in   order   to   notify  everyone  even  remotely
interested,  this  is  not  recommended.   A  very  few  key
addresses  should be sufficient.  Prior to entering any mail
address here, the explicit or implicit consent of the person
responsible   for   that  particular  mailbox  needs  to  be
obtained.

Obviously the notify attributes used  for  notification  are
those  stored  in  the database before the update. This also
guarantees proper notification about deletes.

Note that there is another way  to  effect  notification  of
changes  to  the  maintainer  of  an object. See the section
about the mntner object for details.


























ripe-auth.txt
                           - 15 -


Examples

To be added soon.





















































ripe-auth.txt