Re: 1st draft agenda for DB-WG in Lisbon
- Date: Wed, 31 Aug 1994 12:03:09 +0200
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@localhost
mnt-nfy: domreg@localhost
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@localhost
mnt-nfy: domreg@localhost
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 .*@localhost
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@localhost
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@localhost 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 .*@localhost\.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@localhost.
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
|
you are here: RIPE -> RIPE Maillists > Archives
