------------------------------------------------------------------- APNIC Document identity Title: APNIC Maintainer Object Request Form Short title: maintainer-request Document ref: APNIC-056 Version: 001 Date of original publication: 30 May 1997 Date of this version: 30 May 1997 Review scheduled: n/a Obsoletes: APNIC-045 Status: Obsolete Comments: Obsoleted by APNIC-069 -------------------------------------------------------------------- APNIC Maintainer Object Request Form Issued: May 30, 1997 Expires: December 31, 1997* *) This form is valid until superseded by another form. After the date specified, please check the APNIC document store located at ftp://ftp.apnic.net/apnic/docs/maintainer-request for a later version of this 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: maint-request@rs.apnic.net or in type written English via fax (discouraged) to: +81-3-5500-0481 or in type written English via postal mail (as a last resort) to: Asia Pacific Network Information Center Tokyo Central Post Office Box 351 Tokyo, 100-91, Japan If you have any questions regarding this form, 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-5500-0480. 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.0 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, WAIS to wais.apnic.net (database APNIC), and ftp from the following URL: ftp://ftp.apnic.net/apnic/dbase/data/apnic.db 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, 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 hostmaster@apnic.net at your convenience. 2.0 Maintainer Object Request Details ------------------------------------- ACCT-NAME: Please provide your APNIC account name if you have one. If you do not have an APNIC account name, please see the APNIC Membership Application form available from: ftp://ftp.apnic.net/apnic/docs/membership-application Note that applications without account name will not be processed. Example: acct-name: APNIC-AP MNTNER: Please provide a symbolic name for this maintainer object which will be referenced 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. Note that in order to mark your maintainer object as being maintained within the APNIC registry database, we will append "-AP" to the end of your maintainer object name. 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 NETWORK templates. Example: descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown COUNTRY: Please give the two letter country code (ISO 3166) which is appropriate for the organisation requesting address space. Do NOT provide the country name or the three letter ISO 3166 country code. Please see the table of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/docs/iso-3166.txt if you do not know the appropriate ISO 3166 code for your country. 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 permited. Example: country: JP ADMIN-C: Please provide the NIC handle of the person who is the administrative contact for the network or the name of the person matching *EXACTLY* the name to be provided in a subsequent PERSON template if you do not have a NIC handle. 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 is physically located at the site of the network. If you specify a name instead of a NIC Handle, please do NOT use titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name are indexed and there are many people with the same titles. Further, please provide full given names, not initials as single characters are not indexed within the database. Please 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). The ADMIN-C field is optional. Example: admin-c: JD1-AP admin-c: Jon Q Doe TECH-C: Please provide the NIC handle of the person who is the technical contact for the network or the name of the person matching *EXACTLY* the name to be provided in a subsequent PERSON template if you do not have a NIC handle. The NIC handle (if known) is greatly preferred and will result in minimal delays when processing your request. 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. If you specify a name instead of a NIC Handle, please do NOT use titles like `Dr' or `Prof.' or `Sir' as the words which comprise a name are indexed and there are many people with the same titles. Further, please provide full given names, not initials as single characters are not indexed within the database. Please 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). The TECH-C field is optional. Example: tech-c: MS4-AP tech-c: Mark A Smith UPD-TO: Please indicate the RFC 822 compliant email address using a fully qualified domain name to which mail should be 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: 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 acceptible 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 crypted password must be supplied. When an update is submitted, the field password: will be included. The plain text password will then be crypted and compared against the value supplied in of the CRYPT-PW field. At least one AUTH tag is required for all MAINTAINER objects. 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. 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 YYMMDD (YY is the current year, MM is the month and DD is the day, all values 0 filled). If you do not have e-mail 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 e-mail address, you should supply exactly one CHANGED tag per MAINTAINER template if this is an application for a new maintainer object. Example: changed: johndoe@terabit.na 950225 MNT-BY: Please provide the appropriate maintainer ID. You may specify the maintainer ID you are creating with this application, but please remember to append the APNIC supplied "-AP" to your MNTNER name. Example: mnt-by: MAINT-FOO-AP 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 PERSON Object Details --------------------- PERSON: Please give the full name of the person this template will represent. If you have provided in the person's name in the ADMIN-C or TECH-C fields of the network template (i.e., the person does not yet have a NIC handle), the names MUST be written identically to those provided in the fields. 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 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). Further, as single characters are not indexed, please provide the full given name. 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 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 country code (ISO 3166) which is appropriate for the contact person. Do NOT provide the country name or the three letter ISO 3166 country code. Please see the table of ISO 3166 codes maintained on APNIC at ftp://ftp.apnic.net/apnic/docs/iso-3166.txt if you do not know the appropriate ISO 3166 code for this person's address. This tag is required for all PERSON templates, with only one COUNTRY tag permited. 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: +81-20-1233-4676 phone: +81-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: +81-20-1233-4678 E-MAIL: Please supply the electronic mail address for the person. The electronic mail address MUST be an Internet reachable valid 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 identifer 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. APNIC will provide you with one or you can reserve one for yourself using the procedures described in ftp://ftp.apnic.net/docs/database-update-info. 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. If you have a NIC handle assigned by another registry, e.g., InterNIC, please provide a full person template anyway and leave the NIC-HDL field blank -- the regional registries are currently investigating ways in which information such as this can be shared, but no solution has yet been implemented. If you do not have a NIC handle, please leave the field blank -- do NOT put 'Please Assign' or similar for this field. 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 YYMMDD (YY is the current year, MM is the month and DD is the day, all values 0 filled). If you do not have e-mail 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 e-mail address, 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, but please remember to append the APNIC supplied "-AP" to your MNTNER name. Example: mnt-by: MAINT-FOO-AP 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. 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. Adding a new MNTNER object will be authorised manually by APNIC staff. Updates to MNTNER objects follow the normal authorisation rules but may 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: Telecom Center East 4th Floor, Mailbox 1017 descr: 2-38 Aomi, Koto-ku, Tokyo 135-70 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: inetnum: 202.0.0.0 - 203.255.255.0 netname: APNIC-AP descr: Asia Pacific Network Information Center descr: Telecom Center East 4th Floor, Mailbox 1017 descr: 2-38 Aomi, Koto-ku, Tokyo 135-70 country: JP admin-c: DC396 tech-c: DC396 mnt-by: MAINT-APNIC-AP notify: dbmon@apnic.net changed: hostmaster@apnic.net 950802 source: APNIC acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center country: JP admin-c: DC396 tech-c: DC396 upd-to: staff@apnic.net auth: NONE mnt-by: MAINT-APNIC-AP 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: acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 country: JP upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: MAIL-FROM .*@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. acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 country: JP upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: CRYPT-PW 949WK1mIRby6c 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: acct-name: APNIC mntner: MAINT-APNIC-AP descr: Asia Pacific Network Information Center admin-c: DC396 tech-c: DC396 country: JP upd-to: ops@apnic.net mnt-by: MAINT-APNIC-AP auth: CRYPT-PW 949WK1mIRby6c auth: CRYPT-PW 95sF/QAyIMtgg 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: 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 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.