1996-02-24 - InterNIC Guardian Object Draft

Header Data

From: Eric Eden <erice@internic.net>
To: cypherpunks@toad.com
Message Hash: bd403918ef50c6f7202a7d97efce0293c251dbf68408b2cc2ef73ddf28ff9841
Message ID: <199602241712.MAA26212@ops.internic.net>
Reply To: N/A
UTC Datetime: 1996-02-24 17:32:02 UTC
Raw Date: Sun, 25 Feb 1996 01:32:02 +0800

Raw message

From: Eric Eden <erice@internic.net>
Date: Sun, 25 Feb 1996 01:32:02 +0800
To: cypherpunks@toad.com
Subject: InterNIC Guardian Object Draft
Message-ID: <199602241712.MAA26212@ops.internic.net>
MIME-Version: 1.0
Content-Type: text/plain


 
We're distributing this to the Internet community for comments
and suggestions.  If you have any ideas for improving this draft
please let us know.

I apologize in advance for the length, but the authors are really  
interested in your thoughts.                

Thanks,



Eric Eden                                           erice@internic.net
InterNIC Registration Services                            703-736-0145


 [ URL ftp://rs.internic.net/policy/internic/internic-gen-1.txt ]  [ 2/96 ]
 
                                                               Jasdip Singh
                                                          Network Solutions
                                                               Mark Kosters
                                                          Network Solutions
 
 
                         The InterNIC Guardian Object
                                    DRAFT
 
 
 Table of Contents
 
 1. Introduction.......................................................   1
 2. Main Features of a Guardian........................................   1
 3. Guardian Attributes................................................   1
 4. Registering the Guardian Attributes................................   4
 4.1 Using the New Contact Template....................................   5
 4.2 Using the Modified Registration Templates.........................   5
 5. Linking Guardian Information to Existing Records...................   5
 6. Notification.......................................................   6
 7. Object Update Rules................................................   6
 7.1 Request from a Contact with Authentication Information............   7
 7.2 Request from a Contact without Authentication Information.........   7
 7.3 Request from a Sender not listed as a Contact.....................   7
 8. Object Use Rules...................................................   8
 8.1 Request from a Contact............................................   8
 8.2 Request from a Sender not listed as a Contact.....................   8
 9. Other Guardian Issues..............................................   8
 9.1 Number of Guardians per Object....................................   8
 9.2 Protecting Guardian Information...................................   9
 9.3 Displaying Guardian Information...................................   9
 10. Conclusion........................................................   9
 11. References........................................................   9
 12. Acknowledgements..................................................   9
 
 A. The Proposed Contact Template......................................  10
 B. The Proposed Link Template.........................................  12
 C. The Proposed Notify Template.......................................  14
 D. Object Update Rules................................................  15
 E. Object Use Rules...................................................  16
 F. Examples...........................................................  17
 F.1 How to Register a New Contact with Authentication Information.....  17
 F.2 How to Link Guardian Information to Existing Records..............  18
 F.3 How to Update a Guarded Record....................................  19
 F.4 WHOIS Display of Guardian Information.............................  20
 
 
 
 
 
 
 
                                                                   [Page i]
 
 1. Introduction
 
    This document proposes a model to authorize changes made to the Objects
    (Domains, Networks, Autonomous System Numbers, and Hosts) registered
    with the InterNIC.  The registration activity at the InterNIC has
    increased exponentially with the rapid growth of the Internet.  In the
    absence of a formal authorization model, the likelihood of making
    malicious changes to the registered Objects has also increased and
    could have serious consequences at the affected sites.  For example, an
    unauthorized update could lead a commercial organization to lose its
    presence on the Internet until that update is reversed.
 
 
 2. Main Features of a Guardian
 
    -  A Guardian is an Object that protects other Objects from unauthorized
       changes.  It is basically a Contact with Authentication Information.
 
    -  The different authorization schemes to authenticate a Guardian are
       MAIL-FROM, CRYPT-PW, and PGP.
 
    -  The use of a Guardian is optional.
 
    -  An Object may be guarded by multiple Guardians with each Guardian
       having an equal authority to make changes to the Object.
 
 
 3. Guardian Attributes
 
    Currently, the InterNIC allows a registered Object to be updated if
    the request came from one of its Contacts.  This model is weak due to
    potential mail spoofing.  To allow for stronger authorization schemes,
    the proposed authorization model defines a new Object called Guardian.
 
    A Guardian is basically a Contact with Authentication Information.
    It inherits the attributes of a Contact Object and has the additional
    authentication attributes.  The definition of a Guardian is derived
    from a Contact because a particular Contact (Administrative, Technical,
    or Billing) represents some form of holding of a registered Object and
    the holder of an Object is most likely to guard it also.
 
 
 
 
 
 
                                                                   [Page 1]
 
    The attributes of a Guardian are:
 
    Name               Required
    Type               Required
    Address            Required
    Phone              Required
    Fax                Optional
    Email              Required
    Notify Update      Optional
    Notify Use         Optional
    Auth Scheme        Required *
    Auth Info          Required *
    Public             Optional
 
    * The Auth Scheme and Auth Info attributes are required only for a
      Guardian Object (a Contact with Authentication Information) and not
      for a Contact Object (a Contact without Authentication Information).
 
    Name, Type, Address, Phone, Fax, Email, Notify Update, and Notify Use
    are the attributes a Guardian inherits from a Contact Object.  Auth
    Scheme, Auth Info, and Public are the additional authentication
    attributes of a Guardian.
 
    Name
 
       Name of a Guardian.
 
    Type
 
       Type of a Guardian.  It can have values I (Individual) or R (Role
       Account).
 
    Address
 
       Postal address of a Guardian.
 
    Phone
 
       Phone number of a Guardian.
 
    Fax
 
       Fax number of a Guardian.
 
    Email
 
       Email address of a Guardian.
 
 
 
 
                                                                   [Page 2]
 
    Notify Update
 
       This attribute determines if and when a Guardian should be notified
       about the update of an Object the Guardian is responsible for.  It
       can have values BEFORE-UPDATE, AFTER-UPDATE, and NOT-CARE.
 
       BEFORE-UPDATE   The Guardian will be notified before updating the
                       Object.
 
       AFTER-UPDATE    The Guardian will be notified after updating the
                       Object.  AFTER-UPDATE is the default value.
 
       NOT-CARE        The Guardian will not be notified about the Object
                       update because it does not want to be notified.
 
       Currently, a Guardian's Notify Update attribute will be the same
       for all the Objects the Guardian is responsible for.  In future,
       it will be defined on a per Object basis for each of the Objects
       a Guardian is guarding.  
 
    Notify Use
 
       This attribute determines if and when a Guardian should be notified
       about the use of an Object the Guardian is responsible for.  For
       example, a Guardian of a Host may be notified when someone else
       lists it as a DNS server for a Domain.  It can have values
       BEFORE-USE, AFTER-USE, and NOT-CARE.
 
       BEFORE-USE      The Guardian will be notified before using the
                       Object.   
 
       AFTER-USE       The Guardian will be notified after using the
                       Object.  AFTER-USE is the default value.
 
       NOT-CARE        The Guardian will not be notified about the Object
                       use because it does not want to be notified.
 
       Currently, a Guardian's Notify Use attribute will be the same for
       all the Objects the Guardian is responsible for.  In future, it
       will be defined on a per Object basis for each of the Objects a
       Guardian is guarding.  
 
    Auth Scheme
 
       Authorization scheme used to authenticate a Guardian before updating
       the Object it is guarding.  The proposed schemes in an increasing
       order of strength are MAIL-FROM, CRYPT-PW, and PGP [1].
 
       MAIL-FROM    MAIL-FROM will parse the FROM: field in the mail header
                    of an update message and match it with the email address
                    of the Guardian guarding the Object to be updated.
                    MAIL-FROM is the default Auth Scheme.
 
 
                                                                   [Page 3]
 
       CRYPT-PW     CRYPT-PW will encrypt the cleartext password supplied
                    in an update message and match it with the encrypted
                    password of the Guardian guarding the Object to be
                    updated.  Initially when a new Guardian is being
                    registered or the authentication information is being
                    added to an existing Contact, the encrypted password
                    MUST be supplied.  The Unix crypt(3) routine SHOULD be
                    used to encrypt a cleartext password.
 
       PGP          PGP stands for Pretty Good Privacy [2].  The sender will
                    sign the update message with a Guardian's secret PGP
                    key.  The InterNIC will verify the received update
                    message with the Guardian's public PGP key.  How to
                    register a Guardian's public PGP key with the InterNIC
                    will be explained in another document.
 
    Auth Info
 
       Information for the selected authorization scheme.  The
       authentication information stored in the database for a Guardian
       registered with the InterNIC is:
 
       MAIL-FROM    Email address of a Guardian.
 
       CRYPT-PW     Encrypted password of a Guardian.
 
       PGP          Key ID of the public PGP key of a Guardian.
 
    Public
 
       Boolean indicating whether the authentication information for a
       Guardian will be public or not.  Public means visible in WHOIS.
       It can have values Y (Yes) or N (No).  The default value is Y.
 
    Note that the terms "Guardian" and "Contact with Authentication
    Information" are used interchangeably in the remaining document.
 
 
 4. Registering the Guardian Attributes
 
    There will be two alternatives available to register or update
    the Guardian attributes:
 
    -  Using the new Contact Template, or
 
    -  Using the registration templates for Domains, Networks, Autonomous
       System Numbers (ASNs), and Hosts modified to include the
       authentication information for the Contacts.
 
    Note that registering a PGP-authenticated Guardian will be a two-step
    process because the Guardian will first have to register its public
    PGP key with the InterNIC and then report the key ID as Auth Info
    using one of the above methods.
 
                                                                   [Page 4]
 
 4.1 Using the New Contact Template
 
    A new Contact Template is proposed to independently register or update
    a Contact with Authentication Information.  Appendix A describes the
    new Contact Template and its use.
 
 4.2 Using the Modified Registration Templates
 
    The registration templates for Domains, Networks, ASNs, and Hosts will
    be modified to include:
 
    a) The Authentication Information for the Contacts.
 
    b) The Authorization Section in the beginning of the template to
       authenticate the Guardian updating the Object.  It SHOULD be
       filled only when the Object is being modified or deleted, and
       if the Object is being guarded.  It has the following items:
 
       Auth Scheme
 
          Authorization scheme used to authenticate the Guardian updating
          the Object.  It can have values MAIL-FROM, CRYPT-PW, or PGP.
 
       Auth Info
 
          Information for the selected authorization scheme.  The different
          Auth Scheme and Auth Info combinations are:
 
          Auth Scheme   Auth Info
 
          MAIL-FROM     Ignored.  The FROM: field in the mail header of
                        an update message will be parsed to verify the
                        Guardian.
 
          CRYPT-PW      Cleartext password.
 
          PGP           Ignored.  The sender SHOULD sign the entire update
                        message with the secret PGP key of the Guardian
                        updating the Object and send it in cleartext to
                        the InterNIC.
    
 
 5. Linking Guardian Information to Existing Records
 
    There are two ways to link Guardian information to existing records:
 
    a) Once the authentication information is added to an existing
       Contact, all the database records the Contact is responsible for
       will be automatically guarded by that Contact and any subsequent
       update request from that Contact for one of those records will be
       first authenticated.  This approach should be used carefully because
       here a Contact guards either all or none of its Objects.
 
 
                                                                   [Page 5]
 
    b) A new Link Template is proposed to do a wholesale linkage of
       Contacts with Authentication Information (Guardian Objects) to
       database records (Guarded Objects) in a single transaction.  This
       approach is more flexible because the records that need to be
       guarded by a particular set of Guardians are listed explicitly in
       the Link Template.  Appendix B describes the new Link Template and
       its use.
 
 
 6. Notification
 
    The rules to update or use an Object will depend on when its Contacts
    are notified.
 
    There are two types of notification:
 
    Active Notification
 
       If the Notify Update attribute for a Contact of an Object is set to
       BEFORE-UPDATE, the Contact will be notified before updating the
       Object and the request will only be processed if an ACK
       (Acknowledgement) is received.
 
       If the Notify Use attribute for a Contact of an Object is set to
       BEFORE-USE, the Contact will be notified before using the Object
       and the request will only be processed if an ACK is received.
 
    Passive Notification
 
       If the Notify Update attribute for a Contact of an Object is set to
       AFTER-UPDATE, the Contact will be notified after the Object has been
       updated and the processed request will be revoked if a NAK (Negative
       Acknowledgement) is received.
 
       If the Notify Use attribute for a Contact of an Object is set to
       AFTER-USE, the Contact will be notified after the Object has been
       used and the processed request will be revoked if a NAK is received.
 
    An ACK or a NAK MUST be received within a certain time interval to
    be effective.  Clearly, active notification is safer than passive
    notification.  Appendix C describes the new Notify Template and
    its use.
 
 
 7. Object Update Rules
 
    A request to update an Object could possibly come from a Contact
    with Authentication Information, a Contact without Authentication
    Information or a sender not listed as a Contact for the Object. 
 
 
 
                                                                   [Page 6]
 
    The Object Update Rules for such requests are:
 
 7.1 Request from a Contact with Authentication Information
 
    The request will be processed immediately with notification to all
    the Contacts with Notify Update attribute set to BEFORE-UPDATE or
    AFTER-UPDATE.
 
 7.2 Request from a Contact without Authentication Information
 
 7.2.1 Object has at least one Contact with Authentication Information
 
    All the Contacts with Authentication Information will be notified before
    processing the request.  If the InterNIC receives an ACK first before
    the waiting time indicated on the Notify Template expires, the request
    will be processed.  Otherwise, the request will NOT be processed.
 
 7.2.2 Object has no Contacts with Authentication Information
 
 7.2.2.1 Object has at least one of the other Contacts with Notify Update
         Attribute set to BEFORE-UPDATE
 
    All the other Contacts with Notify Update attribute set to BEFORE-UPDATE
    will be notified before processing the request.  If the InterNIC
    receives an ACK first before the waiting time indicated on the Notify
    Template expires, the request will be processed.  Otherwise, the request
    will NOT be processed.
 
 7.2.2.2 Object has none of the other Contacts with Notify Update Attribute
         set to BEFORE-UPDATE
 
    The request will be processed immediately with notification to all
    the Contacts with Notify Update attribute set to AFTER-UPDATE.  The
    Contacts with Notify Update attribute set to NOT-CARE will not be
    notified.
 
 7.3 Request from a Sender not listed as a Contact
 
    All the Contacts will be notified before processing the request.  If
    the InterNIC receives an ACK first before the waiting time indicated
    on the Notify Template expires, the request will be processed.
    Otherwise, the request will NOT be processed.
 
    If the request from a sender not listed as a Contact is rejected, the
    sender MUST present an evidence that the organization using the Object
    has approved it to update the Object.  Another request from the same
    sender must be faxed to the InterNIC on the corporate letterhead and
    must contain the tracking number of the initial request.  The sender
    could also present its contract with the organization using the Object.
 
    Appendix D gives a summary of the Object Update Rules.
 
 
                                                                   [Page 7]
 
 8. Object Use Rules
 
    One of the more common registration problems is a Domain holder using
    without permission someone else's DNS servers or someone else's IP
    addresses to number its DNS servers.  The Object Use Rules will help
    prevent such illegal use of Objects, particularly Hosts and Networks.
 
    A request to use an Object could possibly come from one of its Contacts
    or a sender not listed as a Contact for the Object.
 
    The Object Use Rules for such requests are:
 
 8.1 Request from a Contact
 
    The request will be processed immediately with notification to all the
    Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE.
 
 8.2 Request from a Sender not listed as a Contact
 
 8.2.1 Object to be used has at least one Contact with Notify Use Attribute
       set to BEFORE-USE
 
    All the Contacts with Notify Use attribute set to BEFORE-USE will be
    notified before processing the request.  If the InterNIC receives an
    ACK first before the waiting time indicated on the Notify Template
    expires, the request will be processed.  Otherwise, the request will
    NOT be processed.
 
 8.2.2 Object to be used has no Contact with Notify Use Attribute set to
       BEFORE-USE
 
    The request will be processed immediately with notification to all the
    Contacts with Notify Use attribute set to AFTER-USE.  The Contacts with
    Notify Use attribute set to NOT-CARE will not be notified.
 
    Appendix E gives a summary of the Object Use Rules.
 
 
 9. Other Guardian Issues
 
 9.1 Number of Guardians per Object
 
    The number of Guardians for an Object will be equal to the number of
    its Contacts with Authentication Information.  Each Guardian will have
    an equal authority to make changes to the Object.  In future, multiple
    Contacts of the same type (for example, Technical) will be allowed for
    an Object.
 
    If an Object has no Contacts with Authentication Information, it will
    not be guarded at all.  
 
 
                                                                   [Page 8]
 
 9.2 Protecting Guardian Information
 
    By default, a Guardian will guard itself (that is, only the Guardian
    will have the authority to make changes to its information).  However,
    a Guardian can be guarded by another Guardian.
 
    If a Guardian is guarding itself and needs to update its authentication
    information or scheme, the update message MUST contain the Guardian's
    old authentication information.  Otherwise, the Guardian can not be
    authenticated before the update.  For example, if a Guardian's Auth
    Scheme is MAIL-FROM, and it needs to either update its email address
    or change its Auth Scheme, the update message must come from its old
    email address.
 
 9.3 Displaying Guardian Information
 
    The authentication information for a Guardian will be visible in WHOIS
    unless the Guardian chooses to keep it private.  This information will
    be public by default because a Guarded Object should be protected by
    the inherent strength of the selected authorization scheme rather than
    by hiding the authorization information for its Guardian.
 
    The WHOIS display for a Guarded Object will be extended to indicate
    that the Object is being guarded.  
 
 
 10. Conclusion
 
    The increased market value of the Objects registered with the InterNIC,
    particularly Domains and Networks, has necessitated the need for more
    secure database transactions.  This Guardian proposal will help solve
    most of the current, unauthorized Object update and use problems at
    the InterNIC.  It balances operational expediency with stronger
    authorization by allowing the Contacts of an Object to select the
    appropriate level of security (MAIL-FROM, CRYPT-PW, or PGP) for the
    Object.
 
 
 11. References
 
    [1] Karrenberg, D., Terpstra, M., "Authorisation and Notification of
        Changes in the RIPE Database", ripe-120, RIPE NCC, RIPE NCC.
 
    [2] Garfinkel, S., "PGP Pretty Good Privacy", O'Reilly & Associates,
        Inc.
 
 
 12. Acknowledgements
 
    The authors thank the InterNIC staff for some very useful suggestions,
    especially Eric Eden, Tom Newell, Kim Hubbard, Duane Stone, and Carley
    Johnson.
 
 
                                                                   [Page 9]
 
 Appendix A
 
 The Proposed Contact Template
 
    [ URL ftp://rs.internic.net/templates/Contact-template.txt ]   [ 1/96 ]
 
    ***************** Please DO NOT REMOVE Version Number *****************
 
    Contact Version Number: 1.0
 
    ************** Please see attached detailed instructions **************
 
    Authorization
    0a. Auth Scheme.............:
    0b. Auth Info...............:
 
    1.  (N)ew (M)odify (D)elete.:
 
    Contact Information
    2a. NIC Handle..............:
    2b. Name....................:
    2c. (I)ndividual (R)ole.....:
    2d. Street Address..........:
    2e. City....................:
    2f. State...................:
    2g. Postal Code.............:
    2h. Country Code............:
    2i. Phone Number............:
    2j. Fax Number..............:
    2k. E-Mailbox...............:
 
    Notify Information
    3a. Notify Update...........:
    3b. Notify Use..............:
 
    Authentication Information
    4a. Auth Scheme.............:
    4b. Auth Info...............:
    4c. Public (Y/N)............:
 
    The Contact Template will be used to independently register or update a
    Contact (with or without Authentication Information).
 
 
 
 
 
 
 
                                                                  [Page 10]
 
    Items 0a-0b SHOULD be filled only when a Contact is being modified or
    deleted, and if the Contact is being guarded.  These items contain
    the information to authenticate the Guardian updating the Contact.
    Item 0a is the authorization scheme for that Guardian.  It can have
    values MAIL-FROM, CRYPT-PW, or PGP.  Item 0b is the information for
    the selected authorization scheme.  The different items 0a and 0b
    combinations are:
 
    Item 0a      Item 0b
 
    MAIL-FROM    Ignored.  The FROM: field in the mail header of an update
                 message will be parsed to verify the Guardian.
 
    CRYPT-PW     Cleartext password.
 
    PGP          Ignored.  The sender SHOULD sign the entire update message
                 with the secret PGP key of the Guardian updating the
                 Contact and send it in cleartext to the InterNIC.
 
    Item 1 is the registration action type.  It can have values N, M, or D.
    N registers a new Contact.  M modifies the information for an existing
    Contact.  D deletes an existing Contact if it is no longer linked to
    any Object.
 
    Items 2a-2k contain the basic information for a Contact.  Item 2a is
    the NIC handle assigned to a Contact.  Items 2b, 2c, 2d-2h, 2i, 2j,
    and 2k are respectively the Name, Type, Address, Phone, Fax, and Email
    attributes of a Contact.
 
    Items 3a-3b contain the notification information for a Contact.
    Items 3a and 3b are respectively the Notify Update and Notify Use
    attributes of a Contact.
 
    Items 4a-4c contain the authentication information for a Contact.
    These items are optional, and are required only if either the
    authentication information is being added to an existing Contact or
    a new Contact with Authentication Information is being registered.
    Items 4a, 4b, and 4c are respectively the Auth Scheme, Auth Info,
    and Public attributes of a Guardian.
 
 
 
 
 
 
 
                                                                  [Page 11]
 
 Appendix B
 
 The Proposed Link Template
 
    [ URL ftp://rs.internic.net/templates/link-template.txt ]      [ 1/96 ]
 
    ***************** Please DO NOT REMOVE Version Number *****************
 
    Link Version Number: 1.0
 
    ************** Please see attached detailed instructions **************
 
    0.  (N)ew (M)odify (D)elete.:
 
    Object
    1a. Identifier..............:
    1b. Type....................:
    1c. Function................:
 
    Linked Object
    2a. Identifier..............:
    2b. Type....................:
 
    The Link Template will be used to do wholesale database changes in a 
    single transaction.  Some of the more commonly requested database
    changes are:
 
    a) Link or unlink Contacts (with or without Authentication Information)
       to or from existing Domains, Networks, ASNs, and Hosts.
 
    b) Link or unlink DNS servers to or from existing Domains and Networks.
 
    Item 0 is the registration action type.  It can have values N, M, or D.
    N links the Objects (Contacts or DNS servers) in the Object Sections to
    the Objects (Domains, Networks, ASNs, and Hosts) in the Linked Object
    Sections.  M modifies the linkage.  D unlinks the Objects in the Object
    Sections from the Objects in the Linked Object Sections.
 
    Items 1a-1c contain information for an Object (Contact or DNS server)
    in the Object Section.  Item 1a is the Identifier of the Object.
    Item 1b is the Type of the Object.  Item 1c is optional and is required
    only if the Object is a Contact.  It is the Function Type of a Contact.
    It can have values AC (Administrative Contact), TC (Technical Contact),
    or BC (Billing Contact).  The Object Section SHOULD be copied for each
    Object (Contact or DNS server).
 
    Items 2a-2b contain information for an Object (Domain, Network, ASN, or
    Host) in the Linked Object Section.  Item 2a is the Identifier of the
    Object.  Item 2b is the Type of the Object.  The Linked Object Section
    SHOULD be copied for each Object (Domain, Network, ASN, or Host).
 
 
 
 
                                                                  [Page 12]
 
    The different Identifiers and Types of the Objects are:
 
    Object     Identifier                 Type
 
    Domain     NIC Handle/Domain Name      D
    Network    NIC Handle/Network Name     N
    ASN        NIC Handle/AS Name          A
    Host       NIC Handle/Host Name        H
    Contact    NIC Handle                  I/R
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                                  [Page 13]
 

 
 Appendix C
 
 The Proposed Notify Template
 
    [ URL ftp://rs.internic.net/templates/notify-template.txt ]    [ 1/96 ]
 
    ***************** Please DO NOT REMOVE Version Number *****************
 
    Notify Version Number: 1.0
 
    ************** Please see attached detailed instructions **************
 
    0a. (A)ck (N)ak.....:
    0b. Comments........:
 
    Object
    1a. Identifier......:
    1b. Type............:
    1c. Tracking Number.:
 
    The Notify Template will be used to notify a Contact of an Object
    before or after updating or using the Object, and get its approval.
    The InterNIC will fill in the information for the requested Object
    update or use in the template (Items 1a-1c) and send it to a Contact
    of the Object for approval.  The Contact will, in turn, fill in the
    ACK/NAK response in the template (Items 0a-0b) and send it back to
    the InterNIC.  If no ACK or NAK is received within 4 days for an
    Object update request or 2 days for an Object use request, the
    InterNIC may assume an implicit ACK or NAK depending on the type of
    request.
 
    Items 0a-0b contain the response from a Contact.  Item 0a is the
    ACK/NAK response.  It can have values A (Ack) or N (Nak).  Item 0b
    contains the comments from the Contact on the approval or disapproval
    of the request.
 
    Items 1a-1c contain information for the requested Object update or use.
    Item 1a is the Identifier of the Object.  Item 1b is the Type of the
    Object. Item 1c is the Tracking Number of the request.
 
    The different Identifiers and Types of the Objects are:
 
    Object     Identifier                 Type
 
    Domain     NIC Handle/Domain Name      D
    Network    NIC Handle/Network Name     N
    ASN        NIC Handle/AS Name          A
    Host       NIC Handle/Host Name        H
    Contact    NIC Handle                  I/R
 
 
 
 
 
                                                                  [Page 14]
 

 
 Appendix D
 
 Object Update Rules
 
    IF Request from a Contact with Authentication Information
      Passive Notification to all the Contacts with Notify Update attribute
      set to BEFORE-UPDATE or AFTER-UPDATE after updating the Object
    ELSE IF Request from a Contact without Authentication Information
      IF Object has at least one Contact with Authentication Information
        Active Notification to these Contacts before updating the Object
      ELSE
        IF Object has at least one of the other Contacts with Notify Update
           attribute set to BEFORE-UPDATE
          Active Notification to these Contacts before updating the Object
        ELSE
          Passive Notification to all the Contacts with Notify Update
          attribute set to AFTER-UPDATE after updating the Object
        ENDIF
      ENDIF
    ELSE IF Request from a Sender not listed as a Contact
      Notification to all the Contacts before updating the Object
      IF the InterNIC receives an ACK
        Object updated
      ELSE IF the Sender faxes a copy of its contract with the Object Holder
        Object updated
      ELSE IF the Object Holder faxes the request on corporate letterhead 
        Object updated
      ELSE
        Object not updated
      ENDIF
    ENDIF
 
    Active Notification:
 
    IF the InterNIC receives an ACK first within 4 days
      Object updated
    ELSE
      Object not updated
    ENDIF
 
    Passive Notification:
 
    IF the InterNIC receives a NAK first within 4 days
      Object update revoked
    ELSE
      OK
    ENDIF
 
 
 
 
 
 
 
                                                                  [Page 15]
 

 
 Appendix E
 
 Object Use Rules
 
    IF Request from a Contact
      Passive Notification to all the Contacts with Notify Use attribute
      set to BEFORE-USE or AFTER-USE after using the Object
    ELSE IF Request from a Sender not listed as a Contact
      IF Object has at least one Contact with Notify Use attribute
         set to BEFORE-USE
        Active Notification to these Contacts before using the Object
      ELSE
        Passive Notification to all the Contacts with Notify Update
        attribute set to AFTER-USE after using the Object
      ENDIF
    ENDIF
 
    Active Notification:
 
    IF the InterNIC receives an ACK first within 2 days
      Object used
    ELSE
      Object not used
    ENDIF
 
    Passive Notification:
 
    IF the InterNIC receives a NAK first within 2 days
      Object use revoked
    ELSE
      OK
    ENDIF
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                                  [Page 16]
 

 
 Appendix F
 
 Examples
 
 F.1 How to Register a New Contact with Authentication Information
 
    [ URL ftp://rs.internic.net/templates/Contact-template.txt ]   [ 1/96 ]
 
    ***************** Please DO NOT REMOVE Version Number *****************
 
    Contact Version Number: 1.0
 
    ************** Please see attached detailed instructions **************
 
    Authorization
    0a. Auth Scheme.............:
    0b. Auth Info...............:
 
    1.  (N)ew (M)odify (D)elete.: N
 
    Contact Information
    2a. NIC Handle..............:
    2b. Name....................: Xary Y. Zmith
    2c. (I)ndividual (R)ole.....: I
    2d. Street Address..........: Fictitious Street
    2e. City....................: Imaginary
    2f. State...................: VA
    2g. Postal Code.............: 22079
    2h. Country Code............: US
    2i. Phone Number............: 1-703-999-8484
    2j. Fax Number..............: 1-703-999-8485
    2k. E-Mailbox...............: xyz@internic.net
 
    Notify Information
    3a. Notify Update...........: BEFORE-UPDATE
    3b. Notify Use..............: AFTER-USE
 
    Authentication Information
    4a. Auth Scheme.............: CRYPT-PW
    4b. Auth Info...............: %.d!Hr3@rm.Gh
    4c. Public (Y/N)............: Y
 
    Here, a new Contact Xary Y. Zmith is registered with CRYPT-PW as its
    Auth Scheme.  The Contact will be notified before updating or after
    using an Object it is responsible for.  The authentication information
    for the Contact will be visible in WHOIS.
 
 
 
 
 
 
 
 
                                                                  [Page 17]
 

 
 F.2 How to Link Guardian Information to Existing Records
 
    [ URL ftp://rs.internic.net/templates/link-template.txt ]      [ 1/96 ]
 
    ***************** Please DO NOT REMOVE Version Number *****************
 
    Link Version Number: 1.0
 
    ************** Please see attached detailed instructions **************
 
    0.  (N)ew (M)odify (D)elete.: N
 
    Object
    1a. Identifier..............: XYZ10000
    1b. Type....................: I
    1c. Function................: TC
 
    Linked Object
    2a. Identifier..............: HOST.EXAMPLE.COM
    2b. Type....................: H
 
    In Example F.1, the new Contact is registered with NIC handle XYZ10000.
    Here, the Contact XYZ10000 is linked as Technical Contact to the Host
    HOST.EXAMPLE.COM.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                                  [Page 18]
 

 
 F.3 How to Update a Guarded Record
 
    [ URL ftp://rs.internic.net/templates/Contact-template.txt ]   [ 1/96 ]
 
    ***************** Please DO NOT REMOVE Version Number *****************
 
    Contact Version Number: 1.0
 
    ************** Please see attached detailed instructions **************
 
    Authorization
    0a. Auth Scheme.............: CRYPT-PW
    0b. Auth Info...............: Cleartext Password
 
    1.  (N)ew (M)odify (D)elete.: M
 
    Contact Information
    2a. NIC Handle..............: XYZ10000
    2b. Name....................:
    2c. (I)ndividual (R)ole.....:
    2d. Street Address..........:
    2e. City....................:
    2f. State...................:
    2g. Postal Code.............:
    2h. Country Code............:
    2i. Phone Number............: 1-703-999-8486
    2j. Fax Number..............:
    2k. E-Mailbox...............:
 
    Notify Information
    3a. Notify Update...........:
    3b. Notify Use..............:
 
    Authentication Information
    4a. Auth Scheme.............:
    4b. Auth Info...............: 
    4c. Public (Y/N)............:
 
    Here, the authorization information in items 0a-0b is first verified
    and then the record for the Contact XYZ10000 is updated. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                                  [Page 19]
 

 
 F.4 WHOIS Display of Guardian Information
 
    Whois: XYZ10000
 
    Zmith, Xary Y. (XYZ10000)                xyz@INTERNIC.NET
       Fictitious Street
       Imaginary, VA 22079
       (703) 999-8486
       (703) 999-8485
 
       Auth Scheme: CRYPT-PW %.d!Hr3@rm.Gh
 
       Record last updated on 18-Jan-96.
 
    Here, the WHOIS display of the Guardian XYZ10000 contains its
    authentication information because its Public attribute is set to Y.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                                                                  [Page 20]
 

 






Thread