------------------------------------------------------------------- APNIC Document identity Title: APNIC Maintainer Object Request Form Short title: maintainer-request Document ref: APNIC-026 Version: 001 Date of original publication: 1 September 1995 Date of this version: 1 September 1995 Review scheduled: n/a Obsoletes: APNIC-018 Status: Obsolete Comments: Obsoleted by APNIC-035 -------------------------------------------------------------------- APNIC Maintainer Object Request Form Issued: September 1, 1995 Expires: January 31, 1996 Please see comments at the bottom of this form regarding how to complete this application. Note that this form is parsed by machine and modification of lines starting with #[ or the field names will likely result in strange errors being returned to you and your request not being processed. After completing this form, please submit it via email to: maint-request@rs.apnic.net or in type written English via fax (discouraged) to: +81-3-5276-6239 or in type written English via postal mail (as a last resort) to: Asia Pacific Network Information Center c/o The United Nations University 53-70, Jingumae 5-Chome, Shibuya-ku, Tokyo 150, Japan If you have any questions, you may contact us via email at hostmaster@apnic.net (preferred), fax at the above number, postal mail at the above address or via telephone at +81-3-5276-3973. Note that we do not accept maintainer requests via telephone. Please allow up to one week for processing electronic mail requests and up to one month for other forms of submission. NOTE: IT IS NOT NECESSARY TO INCLUDE THIS HEADER NOR THE INSTRUCTIONS AT THE BOTTOM OF THIS FORM WITH YOUR APPLICATION. - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - #[MAINTAINER TEMPLATE V:2.0]# acct-no: mntner: descr: descr: admin-c: tech-c: upd-to: auth: remarks: notify: mnt-by: changed: source: APNIC #[PERSON TEMPLATE V:3.0]# person: address: address: phone: fax-no: e-mail: nic-hdl: changed: notify: mnt-by: source: APNIC #[PERSON TEMPLATE V:3.0]# person: address: address: phone: fax-no: e-mail: nic-hdl: changed: notify: mnt-by: source: APNIC #[TEMPLATES END]# Comments: - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - Instructions For Completing This Form ------------------------------------- For details on how to fill out the person template, please see ftp://archive.apnic.net/apnic/docs/apnic-025.txt. IF YOU HAVE AN APNIC ISSUED NIC HANDLE, PLEASE USE IT INSTEAD OF FILLING IN THE REST OF THE PERSON TEMPLATE. If you have filled in NIC handles for the admin-c and tech-c fields of the MAINTAINER template and no aspect of the person's contact information has changed, you do NOT need to complete the PERSON templates -- please leave the fields blank. Below are the instructions for filling in the MAINTAINER template for a Maintainer Object Request form. Please provide attributes for the tags listed correctly. Failure to do so may result in delays in service. All information provided in this form will be made available to the Internet via the APNIC Registration database. As always, if you have any questions or comments regarding this form, please contact hostmaster@apnic.net at your convenience. Maintainer Object Details ------------------------- acct-no: Please provide your APNIC account number if you have one. If you do not have an APNIC account number, please see APNIC-030 available from: ftp://archive.apnic.net/apnic/docs/apnic-030.txt Example: acct-no: 208789233 mntner: Please provide a symbolic name for this maintainer object. The name should be an upper case text string consisting of alphanumeric characters or a "-" (dash) which is not the same as any maintainer name already defined. The name must be unique with regard to other maintainer names and NIC handles only. It can be the same as network names, autonomous system or community names, etc. You must have only one mntner: tag per MAINTAINER object. Example: mntner: FOO-NOC descr: Please complete with a short description of the organization, including the location. The full postal address is not needed as this will be required in a person template. Please provide sufficient detail as to distinguish your organization from others in the APNIC database, i.e., "descr: Computer Center" is not sufficient. Also, please limit the number of descr: lines to 5. At least one descr: tag is required for all MAINTAINER objects. Example: descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown admin-c: Please provide the name or NIC handle of the person who is the administrative contact for the objects guarded by this maintainer object. The NIC handle (if known) is greatly preferred and will result in minimal delays when processing your request. The administrative contact must be someone who has administrative control over the guarded objects. If you specify a name instead of a NIC Handle, please do not use formal titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name is indexed and there are many people with the same titles. In addition, please do not add periods between the names or initials and list the name as you would be addressed in a letter salutation (e.g., given name followed by family name or family name followed by given name depending on the custom in your country). At least one admin-c: tag is required for all MAINTAINER templates. Example: admin-c: John E Doe or with a NIC handle (preferred) admin-c: JD1-HK tech-c: Please provide the name or NIC handle of the person who is the technical contact for the objects guarded by this maintainer object. The NIC handle (if known) is greatly preferred and will result in minimal delays when processing your request. The technical contact need not be someone physically located at the site(s) in question, but must be someone who can resolve technical issues such as network problems. If you specify a name instead of a NIC Handle, please do not use formal titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name is indexed and there are many people with the same titles. In addition, please do not add periods between the names or initials and list the name as you would be addressed in a letter salutation (e.g., given name followed by family name or family name followed by given name depending on the custom in your country). At least one tech-c: tag is required for all MAINTAINER templates. Example: tech-c: Mark A Smith or with a NIC handle (preferred) tech-c: MS4-NZ upd-to: Please indicate the RFC 822 fully qualified email address to which mail is sent whenever any unauthorised update request of an object maintained by this maintainer object is made. The email address should correspond to someone who will be capable of understanding and acting on the unauthorised request. There can be one or more upd-to: tags per MAINTAINER object. Example: upd-to: noc@foobar.net auth: Please specify which scheme will be used identify and authenticate update requests from this maintainer. The format for this tag is: where is one of NONE, MAIL-FROM, CRYPT-PW is dependent on the choice of . For NONE, no value is necessary for . For MAIL-FROM you will need a regular expression which describes the RFC 822 email addresses which are acceptible for updating guarded objects. For CRYPT-PW, a standard Unix crypted password must be supplied. Note: The auth: attribute is not protected information 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. At least one auth: tag is required for all MAINTAINER objects. Examples: auth: NONE auth: CRYPT-PW dhjsdfhruewf auth: MAIL-FROM .*@apnic.net changed: Please indicate the email address of the person who is completing the template, followed by the current date in the format of YYMMDD (YY is the last 2 digits of the current year, MM is the month and DD is the day, all values 0 filled). If you do not have email connectivity please leave blank and it will be filled in for you. Do not put "Please Assign" or similar for this field. If you have an email address, you should supply exactly one changed: tag per MAINTAINER template. Example: changed: johndoe@terabit.na 950225 notify: Please provide a electronic mailbox of who should be notified when this record changes. This can be useful if more than one person manage the same object. When a record is altered, either through the action of APNIC staff or via the database update mechanisms described in APNIC-019, an advisory email will be sent by the database system. If the update is not appropriate, you should immediately contact the APNIC database manager apnic-dbm@apnic.net. The format of this field is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. Please put 'dbmon@apnic.net' into this field if you do not wish to be notified of changes. If you specify a mailbox other than dbmon@apnic.net, be sure that the person at the other end of the mailbox understands what the update advisories mean. There should be at least one notify: tag per MAINTAINER template. Example: notify: dbmon@apnic.net mnt-by: Please provide the APNIC allocated maintainer ID which will guard the MAINTAINER object. You may specify the MAINTAINER object being created. There can be zero or more mnt-by: tags per MAINTAINER object, however each additional maintainer object specified must already exist in the APNIC Registration Database. Example: mnt-by: MAINT-FOO-JP source: Source of the information. For the purposes of APNIC forms, it will always be APNIC. This is information which is always required in the database, so it has been added to the forms already. Example: source: APNIC Supporting Notes ---------------- 1. Authorization Model The 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 APNIC are then authorized 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, authorization 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 is a perfectly legitimate authorization model for those objects that do not need sophisticated authorization. Also we would like to stress that using stronger authorization requires timely processing of update requests. An unresponsive maintainer preventing others from making updates frequently is a worse solution than no authorization. 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 described in detail in a later section. 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 authorization step is performed on the maintainer to be added. If authentication fails, the update request is forwarded to the mailbox listed in the upd-to: attribute of 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 authorized and no appropriate maintainer can be identified the request will be forwarded to APNIC for action. See the separate section below for details on authentication methods and related matters. 2. The Maintained-By Attribute Each APNIC database object 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 authorized to make changes to the object. 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 authorized 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 maintained by multiple maintainers, this is expected to be the exception rather than the rule. When responding to queries, the APNIC whois server will not automatically return the associated mntner: object with any matching object as is done with contact persons. 3. Maintainer Object The mntner: object represents an entity maintaining objects in the APNIC database. The maintainer is identified and referred to by a unique maintainer name. The mntner: object is used every time a database object with a mnt-by: attribute is added, updated or deleted to determine whether the originator of the update request is authorized to make the update. In addition the mntner: object provides the same kind of notification ability that is also available with the notify: attribute. When using the notify: attribute, the user must specify who to notify in every object that he is responsible for. If he wants to change who is notified, every object must be changed. By putting this notification information in the mntner: object, that information is centralized and can be managed more easily. Adding a new mntner: object will be authorised manually by APNIC staff. Updates to mntner: objects follow the normal authorisation rules but receive special scrutiny by APNIC staff as well. 4. Authentication Schemes The authorization model supports multiple authentication schemes. Currently only relatively weak authentication is defined. It is entirely possible to use stronger authentication schemes based privacy enhanced mail (PEM, PGP). It is expected that such schemes will be defined as the need arises. Please note again that the authentication scheme and the additional 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 APNIC cannot take this responsibility. The following s are defined: NONE This is the simplest authentication scheme. 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. Anyone in doubt whether it is OK to issue update requests should check with the maintainer concerned first, preferably at the mailbox specified in the upd-to: attribute. When making any changes the mnt-by: attribute should not be changed without explicit consent from the current maintainer. 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 content of the RFC822 From: header of an update request against the regular expression specified as . If the regular expression matches the content of the From: header the update request is authenticated successfully. The regular expressions supported are described in POSIX 1003.2 section 2.8. As it is expected that most regular expressions will either be literals or of a form similar to .*@some\.domain\.or\.other an extensive description of the possibilities will not be given. Note that 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. It should be stressed that this authentication scheme is very weak. Forging RFC822 headers does not take much effort or ingenuity. The reason for the scheme's existence is that it easily prevents accidental 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 compared. Since the original (cleartext) password cannot easily be computed from the encrypted version the encrypted password does not have to be kept secret. The is the encrypted password. This can either be obtained locally with the appropriate Unix tools or on e-mail request from . When sending in update requests the cleartext password must 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 determined malicious attacker. The crypt function is vulnerable 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 publishing the encrypted password in the database it is open to attack. The usual caveats about crypt passwords apply, so is not very wise to use words or combinations of words found in any dictionary of any language. See [R. Morris, K. Thompson: Password Security: A Case History] for more details about the scheme and its vulnerabilities. Multiple authentication methods can be specified in the same mntner: object. These will be used alternatively, i.e. any one of the authenticators is sufficient to authenticate the update request from the maintainer. If multiple maintainers maintain an object this feature should not be used. Multiple maintainers should be represented by multiple mntner objects referenced in the mnt-by: attribute. There is no way in the current model to require a combination of multiple authenticators to authenticate a request. 5. Examples Use of the authorization and notification scheme described in this document is totally optional. So the current object below remains fully valid: inetnum: 202.0.0.0 - 203.255.255.0 netname: APNIC-AP descr: Asia Pacific Network Information Center descr: c/o The United Nations University descr: 53-70 Jingumae 5-chome descr: Shibuya-ku, Tokyo 150, Japan country: JP admin-c: DC396 tech-c: DC396 notify: dbmon@apnic.net changed: hostmaster@apnic.net 950802 source: APNIC But even if notification is the only feature desired, adding a maintainer object can be useful. It documents who the maintainer is and it puts the e-mail addresses for notification in one place only: netname: APNIC-AP descr: Asia Pacific Network Information Center descr: c/o The United Nations University descr: 53-70 Jingumae 5-chome descr: Shibuya-ku, Tokyo 150, Japan country: JP admin-c: DC396 tech-c: DC396 mnt-by: MAINT-APNIC-AP notify: dbmon@apnic.net changed: hostmaster@apnic.net 950802 source: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 upd-to: staff@apnic.net mnt-by: MAINT-APNIC-AP auth: NONE notify: dbmon@apnic.net changed: davidc@apnic.net 950530 source: APNIC Note that the mntner: object itself is maintained by MAINT-APNIC-AP too, so notification will also happen if the object itself is changed. Changing the addresses can then be done by changing just the mntner: object and not all objects referring to the address. It is also easy to switch on authentication for all objects at once if needed: mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: MAIL-FROM .*@apnic.net notify: dbmon@apnic.net changed: davidc@apnic.net 950530 source: APNIC If stronger authorisation is needed it can be switched on with a single update to the mntner: object again. mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: CRYPT-PW 949WK1mIRby6c notify: dbmon@apnic.net changed: davidc@apnic.net 950530 source: APNIC Note that any update of this object must now be preceded by a line of the form password: NCC-PASS to be properly authenticated. Specifying alternative authentication methods is allowed. So if (for example) either of two passwords should be used to authenticate update requests this can be represented like this: mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: CRYPT-PW 949WK1mIRby6c auth: CRYPT-PW 95sF/QAyIMtgg notify: dbmon@apnic.net changed: davidc@apnic.net 950530 source: APNIC If on the other hand one object is maintained by multiple maintainers this should be expressed by using multiple mntner: objects. These will be equivalent in authentication checking. It speaks for itself that good coordination between the multiple maintainers of an object is an absolute necessity: netname: APNIC-AP descr: Asia Pacific Network Information Center descr: c/o The United Nations University descr: 53-70 Jingumae 5-chome descr: Shibuya-ku, Tokyo 150, Japan country: JP admin-c: DC396 tech-c: DC396 mnt-by: MAINT-APNIC-AP MAINT-UNU-JP notify: dbmon@apnic.net changed: hostmaster@apnic.net 950802 source: APNIC Acknowledgements ---------------- This document in derived in large part from documents written by the staff of the European Registry, RIPE-NCC , particularly, RIPE-120.