------------------------------------------------------------------- APNIC Document identity Title: APNIC Maintainer Object Request Form Short title: maintainer-request Document ref: APNIC-069 Version: 001 Date of original publication: August 1998 Date of this version: August 1998 Review scheduled: n/a Obsoletes: APNIC-056 Status: Obsolete Comments: This document also exists as an online web form (with appropriate modifications). -------------------------------------------------------------------- APNIC Maintainer Object Request Form This form is intended to be used by people or organizations wishing to request a maintainer object to enhance the authentication and authorization control over modifications to their records in the APNIC Registration database. All people and organizations with records in the APNIC Reigstration database are STRONGLY encouraged to obtain a maintainer object, particularly one with an authentication mechanism other than "NONE". Please see instructions 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: apnic-dbm@apnic.net or in type written English via fax (discouraged) to: 7-3367-0482 or in type written English via postal mail (as a last resort) to: Asia Pacific Network Information Center Level 1, 33 Park Road P. O. Box 2131 Milton, QLD 4064 Australia If you have any questions regarding this form, you may contact us via email at apnic-dbm@apnic.net (preferred), fax at the above number, postal mail at the above address or via telephone at 7-3367-0490 between the hours of 9:00 AM to 5:00 PM Australian Eastern Standard Time. 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:3.0]# #acct-name: mntner: descr: descr: country: admin-c: tech-c: upd-to: auth: remarks: mnt-by: changed: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: country: phone: fax-no: e-mail: nic-hdl: changed: mnt-by: source: APNIC #[PERSON TEMPLATE V:4.0]# person: address: address: country: phone: fax-no: e-mail: nic-hdl: changed: mnt-by: source: APNIC #[TEMPLATES END]# Additional Comments: - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - 1. Instructions For Completing This Form ---------------------------------------- Below are the instructions for filling in an Maintainer Object Request form. It is *EXTREMELY* important you provide attributes for the tags listed below correctly. Failure to do so WILL result in delays in service and thus may delay when you will receive your maintainer ID. Information provided in the MAINTAINER and PERSON templates will be made available over the Internet via WHOIS to whois.apnic.net and other mechanisms. This information is provided to the Internet community to aid in diagnosing and resolving issues related to the operation of the Internet. Any use outside of this context is expressly prohibited without written permission from APNIC Pty Ltd. As APNIC applications are machine processed, application forms *MUST* be submitted in plain ASCII, do not use MIME encoding unless that MIME encoding can be viewed without any form of decoding. In particular, do NOT encode your application using BASE64 encoding techniques. In addition, do not attempt to format your application in any fashion, e.g., do not justify text or insert extra blank lines between lines in a template. Failure to observe these restrictions will likely result in syntax errors being returned to you as the automated parsing system is not prepared to handle large deviations from the format presented in the form above. An example of a completed form is provided below. As always, if you have any questions or comments regarding this form, please contact apnic-dbm@apnic.net at your convenience. 2. Maintainer Object Request Details ------------------------------------ ACCT-NAME: Please provide your APNIC account name. If you do not have an account name but wish to become an APNIC member, please see the "APNIC Membership Application" form available at ftp://ftp.apnic.net/apnic/docs/membership-application If you do not wish to become a member, please see the "APNIC Non-Member Resource Request Application" form available at: ftp://ftp.apnic.net/apnic/docs/non-member-application In no case will an address request form be accepted without a completed account field. Note that applications will not be processed until APNIC has received payment in either the member or non-member cases. Example: acct-name: APNIC-AP MNTNER: Please provide a short but meaningfully descriptive name for this maintainer object which will be used in MNT-BY fields. The name should be an upper case text string consisting of alphanumeric characters or a "-" (dash) which is unique within the APNIC database. 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. Please provide sufficient detail as to distinguish your organization from others in the APNIC database, i.e., "descr: Computer Center" is not sufficient. Do NOT put advertising information such as "The best internet provider in Foo" in your description and please limit the number of DESCR lines to 5. This tag is required for all MAINTAINER templates. Example: descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown COUNTRY: Please give the two letter ISO 3166 country code appropriate for the organization requesting the maintainer. Do NOT provide the country name or the three letter ISO 3166 country code. If you do not know the appropriate ISO 3166 code for your country, please see the table of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/docs/iso-3166.txt We are aware listing a country may be ambiguous for networks crossing national boundaries, so choose the most appropriate country based on the location of the administrative contact. This tag is required for all NETWORK templates, with only one COUNTRY tag permitted. Example: country: JP ADMIN-C: Please provide the APNIC NIC handle (NIC handles from other registries are not currently accepted) of the person who is the administrative contact for the network. If you do not have an APNIC NIC handle, please see the section below entitled "Obtaining an APNIC NIC Handle". The administrative contact must be someone who is physically located at the site of the network. Unlike other objects in the APNIC database, the ADMIN-C tag is optional. Example: admin-c: JD1-AP TECH-C: Please provide the APNIC NIC handle (other registry NIC handles are not currently accepted) of the person who is the technical contact for the network. If you do not have an APNIC NIC handle, please see the section below entitled "Obtaining an APNIC NIC Handle". The technical contact need not be physically located at the site of the network, but rather is the person who is responsible for the day-to-day operation of the network. The TECH-C tag is optional. Example: tech-c: MS4-AP UPD-TO: Please indicate the RFC 822 compliant email address using a fully qualified domain name to which mail should be sent whenever any unauthorized 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 unauthorized 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: auth: where is one of NONE, MAIL-FROM, CRYPT-PW is dependent on the choice of . For NONE, no authentication mechanism will be used thus, no value is necessary for . For MAIL-FROM you will need a regular expression which describes the RFC 822 email addresses which are acceptable for updating guarded objects. These regular expressions will be applied to the email address the mail is coming from to verify the request is appropriate. For CRYPT-PW, a standard Unix encrypted password must be supplied. When an update is submitted, the field password: will be included. The plain text password will then be encrypted and compared against the value supplied in of the CRYPT-PW field. At least one AUTH tag is required for all MAINTAINER objects. 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. NOTE: If you wish to use the APNIC web forms to update objects protected by a maintainer object, you _must_ use CRYPT-PW authentication. Examples: auth: NONE auth: CRYPT-PW dhjsdfhruewf auth: MAIL-FROM .*@apnic.net REMARKS: The remarks attribute contains any remarks about this maintainer that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it provides extra information to users of the database, and usage should be kept to a minimum. Example: remarks: protecting person objects only CHANGED: Please indicate the e-mail address of the person who is completing the template followed by the current date in the format of YYYYMMDD (YYYY is the current year, MM is the month and DD is the day, all values 0 filled). You should supply exactly one CHANGED tag per NETWORK template if this is an application for a new provider block. Example: changed: johndoe@terabit.na 19950225 MNT-BY: Please provide the appropriate maintainer ID. You may specify the maintainer ID you are creating with this application as used in the MNTNER field. Example: mnt-by: MAINT-FOO-AP SOURCE: Source of the information. For the purposes of APNIC forms, it will always be APNIC. This information is always required in the database and has been added to the forms already. Example: source: APNIC 3. PERSON Object Details ------------------------ PERSON: Please give the full name of the person this template will represent. Do not use formal titles like `Dr' or `Prof.' or `Sir' and please provide full names, not initials. The name should be provided as the person 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). There can be exactly one PERSON field in a PERSON template. Example: person: John E Doe ADDRESS: Please complete with the full postal address written as you would for international postal mail (albeit without the country which is provided using the COUNTRY field described below) using one line for each part of the address as shown below. Example: address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NL-1234 Northtown COUNTRY: Please give the two letter ISO 3166 country code appropriate for the contact person. Do NOT provide the country name or the three letter ISO 3166 country code. If you do not know the appropriate ISO 3166 code for this person's address, please see the list of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/docs/iso-3166.txt This tag is required for all PERSON templates, with only one COUNTRY tag permitted per template. Example: country: JP PHONE: Please provide the work telephone number of the person specified above as it would be dialed internationally in your country (WITHOUT the prefix necessary to reach an international line). Please do not include the leading zero when specifying their area/city code unless it is required to correctly dial the number internationally. The format for the telephone number is: --- If an extension is necessary, please add "ext ". Please do not put 'x' or other abbreviations for "extension". More than one telephone number is fine; each telephone number should be put on a separate line and written in order of the most appropriate number for the person to the least. Example: phone: 20-1233-4676 phone: 20-1233-4677 ext 4711 FAX-NO: Please complete with the facsimile number of the person as it would be dialed internationally (WITHOUT the prefix necessary to reach an international line) in your country. Please do not include the leading zero when specifying their area/city code unless it is required to correctly dial the number internationally. The format for the facsimile number is: --- More than one facsimile number is fine. Each facsimile number should be put on a separate line and written in order of the most appropriate to the least. If the person does not have a facsimile number, please leave blank. Example: fax-no: 20-1233-4678 E-MAIL: Please supply the electronic mail address for the person. The electronic mail address MUST be a valid Internet reachable RFC-822 address with a fully qualified domain name. If you do not have Internet reachable e-mail connectivity, please leave this field blank. Multiple e-mail addresses may be specified, with each on a separate line and written in order of the most appropriate to the least. Example: e-mail: johndoe@terabit.na NIC-HDL: A NIC Handle is a unique identifier used within the Internet registry database to differentiate between people with the same names. NIC handles are assigned by registries -- if you do not have one, please do not make one up, a handle will be automatically generated for you if you follow the procedures described below in the section entitled "Obtaining an APNIC NIC Handle". If you have an APNIC NIC handle but do not remember it, please make a note of this in the ADDITIONAL COMMENTS section of the application form and leave this field blank. If you have a NIC handle assigned by another registry, e.g., InterNIC, please provide a full person template anyway using the auto-generating handles as described below -- the regional registries are currently investigating ways in which information such as this can be shared, but no solution has yet been implemented. Example: nic-hdl: JD401-AP CHANGED: Please indicate the e-mail address of the person who is completing the template followed by the current date in the format of YYYYMMDD (YYYY is the current year, MM is the month and DD is the day, all values 0 filled). You should supply exactly one CHANGED tag per PERSON template if this is a new person object. Example: changed: johndoe@terabit.na 960501 MNT-BY: Please provide the appropriate maintainer ID. You may specify the maintainer ID you are creating with this application or any other maintainer ID that already exists in the APNIC database. Example: mnt-by: MAINT-FOO-AP SOURCE: Source of the information. For the purposes of APNIC forms, it will always be APNIC. This information is always required in the database and has already been added to the forms. Example: source: APNIC 4. Supporting Notes ------------------- 4.1 Authorization Model The model for authorization 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 authorized 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. 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. 4.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 top-level 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. 4.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. Adding a new MNTNER object will be authorized manually by APNIC staff. Updates to MNTNER objects follow the normal authorization rules but may receive special scrutiny by APNIC staff as well. 4.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 authorized 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 (clear text) 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 clear text 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. Obtaining an APNIC NIC Handle -------------------------------- If you are completing a person template or want to reference a person in an another object in the APNIC registration database, you should use an APNIC NIC handle ('nic-hdl:'). NIC handles will give you a unique identifier attached to a person which you can use as a reference in those cases where multiple individuals have the same name. You can obtain an APNIC NIC handle by putting the following in the NIC-HDL field: nic-hdl: AUTO-1 (that's a one, not the letter 'ell'). This will result in the database software deriving creating an APNIC handle from your first and last initials. For example, if you submitted the following person object (please don't): person: David Conrad address: Asia Pacific Network Information Center address: Level 1, 33 Park Road address: P. O. Box 2131 address: Milton, QLD 4064 country: AU [...] nic-hdl: AUTO-1 [...] the database software would generate a NIC handle of the form DC###-AP where ### is the next available number that insures the APNIC NIC handle starting with DC would be unique. Alternatively, you can specify the initials to use as the prefix for the handle instead of having the database software generate them itself. If you specify the NIC-HDL as: nic-hdl: AUTO-1 where (without the '<' and '>') are no more than 4 characters, the database software will use those initials to create the handle. For example: person: David Conrad address: Asia Pacific Network Information Center address: Level 1, 33 Park Road address: P. O. Box 2131 address: Milton, QLD 4064 country: AU [...] nic-hdl: AUTO-1RC [...] the database software would generate a NIC handle of the form RC###-AP where ### is the next available number that insures the NIC handle starting with RC. You can use the same identifiers (AUTO-1 or AUTO-1) in the same update message in other objects as a reference. The database software will then fill in the freshly assigned NIC handles in the objects. Note that you can also use other numbers (example: AUTO-2) so that you can update more person objects and objects that reference the persons in one E-mail message. For example: [...] admin-c: AUTO-1 tech-c: AUTO-2 [...] person: David Conrad [...] nic-hdl: AUTO-1 [...] person: Yoshiko Chong [...] nic-hdl: AUTO-2 [...] will result in two new handles being created, one of the form DC###-AP filled in for the ADMIN-C and David Conrad's NIC-HDL fields and the other, YC###-AP filled in for the TECH-C and Yoshiko Chong's NIC-HDL fields. 6. 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 country: AU admin-c: DC23-AP tech-c: DC23-AP notify: dbmon@apnic.net changed: hostmaster@apnic.net 19950802 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: inetnum: 202.0.0.0 - 203.255.255.0 netname: APNIC-AP descr: Asia Pacific Network Information Center country: AU admin-c: DC23-AP tech-c: DC23-AP mnt-by: MAINT-APNIC-AP notify: dbmon@apnic.net changed: hostmaster@apnic.net 19950802 source: APNIC acct-name: APNIC-AP mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center country: AU admin-c: DC23-AP tech-c: DC23-AP upd-to: staff@apnic.net auth: NONE mnt-by: MAINT-APNIC-AP changed: davidc@apnic.net 19950530 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: acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC23-AP tech-c: DC23-AP country: AU upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: MAIL-FROM .*@apnic.net changed: davidc@apnic.net 19950530 source: APNIC If stronger authorization is needed it can be switched on with a single update to the MNTNER object again. acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC23-AP tech-c: DC23-AP country: AU upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: CRYPT-PW 949WK1mIRby6c changed: davidc@apnic.net 19950530 source: APNIC Note that any update of this object must now be preceded by a line of the form password: YeahRite 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: acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC23-AP tech-c: DC23-AP country: AU upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: CRYPT-PW 949WK1mIRby6c auth: CRYPT-PW 95sF/QAyIMtgg changed: davidc@apnic.net 19950530 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: inetnum: 202.0.0.0 - 203.255.255.0 netname: APNIC-AP descr: Asia Pacific Network Information Center country: AU admin-c: DC23-AP tech-c: DC23-AP mnt-by: MAINT-APNIC-AP MAINT-DRC notify: dbmon@apnic.net changed: hostmaster@apnic.net 19950802 source: APNIC 7. Acknowledgements ------------------- This document in derived in large part from documents written by the staff of the European Registry, RIPE-NCC , particularly, RIPE-120.