INTERNET-DRAFT James Seng draft-jseng-provreg-opp-00.txt William Tan 11 Apr 2001 i-DNS.net Expire 11 Oct 2001 Object Provisioning Protocol (OPP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a message-based, application layer protocol for the provisioning and management of objects stored in a shared central repository through service providers. 1. Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Node refers to a generic party involved in the provisioning of objects. In domain names context, it could be a registry, registrar, reseller or registrant. Object is the basic unit for provisioning. List refers to a set of objects that belongs to the same category/type. Schema refers to the format of objects used, request types used to perform operation, and expected response only meaningful in a specific application environment, for example, IP address registration. Provisioning node refers to a node that is doing provisioning (e.g. Registrant). Repository node refers to node in which the objects are stored (e.g. Registry). A router node refers to intermmediate node that is involved in the processing of an object provisioning between provisioning node and repository node. This document also makes use of a set of terms defined in the definition section of [GRRP]. 2. Introduction Object Provisioning Protocol (OPP) specifies a framework for the management of objects stored in some node (e.g. Registry). OPP defines a set of commands for manipulating these objects. OPP is focused on the integrity, authenticity and non-repudiation of the objects being provisioned from end-to-end nodes. This allows OPP to be used in a daisy chain or network of nodes. This is quite different from the [EPP] approach where it is provisioning between two nodes, namely, Registrar and Registry. OPP is independent of any transport protocol (e.g. TCP/IP, SSL, [BEEP]) and authorization (e.g. [SASL]) between nodes. This should be decided by the outcome of the design team. However, it is important to note that some transport optimization may be required to fit OPP. OPP is only concerned with the transaction between end-to-end nodes. As such, it will have to assume that the transport protocol is reliable with failure notification or resume capability. Transactions may transit multiple nodes applying or depending on other rules (e.g. policy, technical, business etc). +--------+ +--------+ +--------+ | Node |-----| Node |---...Transport...---| Node | +--------+ +--------+ +--------+ ^ ^ | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | v v +--------+ +--------+ | Object |<-- Object Provisioning Protocol -->| Object | +--------+ +--------+ OPP uses eXtensible Markup Language [XML] to encapsulate its object. OPP defines only a common object schema. It does not define any specific objects or the detail schema of any object. +-------------+-------------------+---------+ +-----+ | Domain name | Internet Protocol | Keyword |....| URI | +------------------------------------------------------+ | Common Object Schema | + - - - - - - - - - - - - - - - - - - - - - - - - - - + | Object Provisioning Protocol (OPP) | +------------------------------------------------------+ OPP is not concerned with policies such as rules imposed on object manipulation or authorization between two nodes etc. 3. Unique Handles Unique Handles are use to identify and differentiate between Node, List, Objects or Attributes. It is based on a URI schema. A typical node has the following syntax: opp://host/ A list has the following syntax: opp://host/list An object has the following syntax: opp://host/list/object An attribute has the following syntax: opp://host/list/obj/att In some case, a node unique handler could also be in object syntax: opp://host/list/object object refers to an Owner Object (see Section 6.1). 4. Transaction Object provisioning is done by transaction. Transactions in OPP are between end-to-end nodes. However, OPP is designed to allow messages (be it request, response or answer) to travel through intermediate nodes (router nodes) before reaching the destination node. Each transaction MUST be in the in a REQUEST/RESPONSE/ANSWER sequence. Transaction not of these sequences MUST be considered incomplete and discarded. - REQUEST REPLY ANSWER: the originating node sends a request to perform a certain task, the receiving node performs the task, and responds with a positive reply and the originating node answers with an acknowledgement. - REQUEST ERROR ANSWER: the originating node sends a request to perform a certain task, the receiving node does not perform the task, and responds with a negative error and the originating node answers with an acknowledgement. - REQUEST DELAY ANSWER: the originating node sends a request to perform a certain task, the receiving node cannot decide if it can performs the task, and responds with a neutral reply, and the originating node response with an acknowledgement. The originator node would have to perform another transaction at some future date to retry the transaction again with the same transaction ID. 5. Frame Each step (REQUEST, RESPONSE, ANSWER) in the transaction is atomic operation and is encapsulated in an frame with the following structure: A frame has the following structure <!ELEMENT frame ((request|response|answer),signature,path?)> <!ATTLIST frame source CDATA #REQUIRED> <!ATTLIST frame dest CDATA #REQUIRED> Attribute "source" refers to the unique handler of the node that generates the frame. Attribute "dest" refers to the unique handler of the destination node of the frame. 5.1. REQUEST Syntax The REQUEST has the following structure: <!ELEMENT request (add* | mod* | del* | sel*)> <!ATTLIST request id ID #REQUIRED> <!ATTLIST request tranid ID #REQUIRED> <!ATTLIST request timestamp TIME #IMPLIED> Each REQUEST can have multiple commands. All commands within a single REQUEST frame MUST be performed in an atomic fashion. A REQUEST may contain no commands. In such a case, it could be consider as a "PING" transaction. [What happen when 'router' split request into pieces? While we can claim that no router Node should split the request, there are cases whereby it is unavoidable during a single atomic operation. e.g. a request to register a domain name with domain name and contact stored in different node.] The "id" attribute is generated unique identifier for the "request" element. The "tranid" attribute is a globally unique transaction ID generated based on [UUID]. This transaction ID will be reference in the subsequent RESPONSE and ANSWER frame to identify a transaction. The "timestamp" attribute is implied by the time of when this frame is generated. 5.1.1. ADD request The ADD request is used to add an object to a repository. The ADD request has the following structure: <!ELEMENT add (object)> <!ATTLIST add type CDATA #REQUIRED> You can add one object for each ADD request. Attribute "type" refers to the list in the repository node which this object going to be added to. 5.1.2. MOD request The MOD request is used to modify an existing object within a repository. The MOD request has the following structure: <!ELEMENT mod (object)> <!ATTLIST mod uid CDATA #REQUIRED> You can modify one object for each MOD request. The "uid" attribute refers to the unique handler of the object to be modified. "object" element in this case contains a sub-set of attributes that is to modify by this transaction. 5.1.3. DEL request The DEL request is used to delete an existing object within the repository. The DEL request has the following structure: <!ELEMENT mod> <!ATTLIST mod uid CDATA #REQUIRED> You can delete one object for each MOD request. The "uid" attribute refers to the unique handler of the object to be deleted. 5.1.4. SEL request The SEL request is used to retrieve an object from the repository. The SEL request has the following structure: <!ELEMENT sel (object)> <!ATTLIST sel uid CDATA #REQUIRED> The "uid" attribute refers to the unique handler of the object to be retrieved. 5.2. RESPONSE syntax When a REQUEST arrives at the repository node, it MUST return a RESPONSE. <!ELEMENT response (reply | error | delay)> <!ATTLIST response id ID #REQUIRED> <!ATTLIST response tranid IDREF #REQUIRED> <!ATTLIST response timestamp TIME #IMPLIED> The "id" attribute is generated unique identifier for the element. The "tranid" attribute refers to the "request's tranid" that this "response" is targeted at. The "timestamp" attribute is implied by the time of when this frame is generated. 5.2.1. REPLY response REPLY indicates a successful request. However, the transaction may not permanent at this point. This is to signal the provision node that the command has passed the rules and policies checking and has no possibility of failure. Upon receipt of a REPLY, the provisioning node MUST send an ANSWER back to commit the changes, if any (see section 8). The REPLY response has the following structure: <!ELEMENT reply (text+ | object?)> <!ATTLIST reply code CDATA #REQUIRED> <!ELEMENT text (#PCDATA)> <!ATTLIST text lang CDATA #REQUIRED> The reply code is returned in the "code" attribute. Repository schema MUST list the reply codes meaningful within the schema. Textual description SHOULD be given using one or more "text" elements. Multiple "text" elements are possible, in different languages identified by the "lang" attribute. If the provisioning node made an ADD request, then the REPLY response MUST have the "object" element. The "object" element MUST contain at least the "ObjID" attribute. 5.2.2. ERROR response ERROR response is used to indicate an error condition as a result of a REQUEST. The ERROR response has the following structure: <!ELEMENT error (text+ | object?)> <!ATTLIST error code CDATA #REQUIRED> <!ELEMENT text (#PCDATA)> <!ATTLIST text lang CDATA #REQUIRED> The error code is returned in the "code" attribute. Repository schema MUST list the error codes meaningful within the schema. Textual description of the error condition SHOULD be given using one or more "text" elements. Multiple "text" elements are possible, in different languages identified by the "lang" attribute. 5.2.3. DELAY response DELAY response indicates that the command cannot be processed immediately. This could be happened when a REQUEST may not be process as it may require manual intervention and/or additional verification. The DELAY response has the following structure: <!ELEMENT delay (text+ | object?)> <!ATTLIST delay code CDATA #REQUIRED> <!ATTLIST delay retry TIME> <!ELEMENT text (#PCDATA)> <!ATTLIST text lang CDATA #REQUIRED> The delay code is returned in the "code" attribute. Repository schema MUST list the delay codes meaningful within the schema. Textual description of the delay condition SHOULD be given using one or more "text" elements. Multiple "text" elements are possible, in different languages identified by the "lang" attribute. A "retry" attribute MAY be generated to notify the provisioning node when it should try to retry the REQUEST (with the same "tranid") again. 5.3. ANSWER Syntax ANSWER is used to confirm that RESPONSE has been received. It also signifies the completion of a transaction. For provisioning which add, modify or delete object(s) in a repository node, ANSWER is required to complete the transaction or the transaction would be aborted. <!ELEMENT answer (checksum)> <!ATTLIST answer id ID #REQUIRED> <!ATTLIST answer tranid CDATA #REQUIRED> <!ATTLIST answer timestamp TIME #IMPLIED> <!ELEMENT checksum (#PCDATA)> <!ATTLIST checksum method CDATA> The "id" attribute is generated unique identifier for the element. The "tranid" attribute refers to the "response's tranid" that this "answer" is targeted at. The "timestamp" attribute is implied by the time of when this frame is generated. If the method of the checksum is not specified, Message Digest [MD5] is assumed. 5.4. Signature Syntax In order to provide integrity, authentication, and non-repudity, every command MUST be accompanied by a signature block, as specified in [xmldsig]. This is especially important considering that OPP allows messages to transit intermediate nodes before reaching the destination node. DTD for the signature block is specified in [xmldsig], and will not be reproduced here due to its size, and to reduce human errors. Following is an example frame for the "add" request, including the signature block: <frame source="opp://opp.i-dns.net/holder/JS1452" dest="opp://opp.i-dns.net/"> <request id="IDNS1203" tranid="IDNS120319213"> <add> <object> ... </object> </add> </request> <Signature xmlns="http://www.w3c.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="IDNS1203"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature> </frame> The URI attribute of the <Reference> element indicates the REQUEST/RESPONSE/ANSWER element being signed. Since the signature references a local sibling element, the XML digital signature adopted here is neither enveloping nor enveloped, as defined in [xmldsig]. The Reference URI should always be the "id" attribute of the corresponding request/response/answer block for which this signature endorses. Since the "id" attribute of any given XML element within a communication stream MUST be unique, this allows the signature to refer to a block unambiguously. Elements such as DigestValue, Algorithm, and CanonicalizationMethod MAY be fixed by OPP in order to reduce network load, but is up to the concensus of the working group. 5.5. PATH Syntax Path is used to record the Nodes that the frame has passed through before reaching its destination. It is optional and frames can be processed with or without the Path content. <!ELEMENT Path (Node*)> <!ELEMENT Node> <!ATTLIST Node Receive-from CDATA #REQUIRED> <!ATTLIST Node By CDATA #REQUIRED> <!ATTLIST Node Time TIME #REQUIRED> It is optional for a Node to add itself to the Path element (i.e. transparent/invisible Node). 5.6. Routing Frame Provisioning nodes will be responsible to generate request frames and send them out. There will be router nodes that will 'route' these frames to the right repository node so that it can be processed. The response and answer frames are processed in a similar way. Each frame will contain unique handler of source and destination node. With these information, router nodes would be able to determine how to transfer a frame to its peer. Peering relationship between two nodes MAY be based on business rules. Node may have multiple peering relationships for different provisioning services. For example, one peer could be set-up for the registration of ".COM domain names", another peer for ".SG domain names", another peer for "Internet Keywords", and another peer for "Digital Certificate" etc. [Note: Need to complete the section on routing, how a network of resellers, registrars and registries (nodes) could be combined into a network routing these frames to form a P2P-exchange on registration data.] 6. Object Object is the basic unit for all provisioning. The objectives of the OPP is that schema of the objects are not defined beyond the basic which is required for this Protocol to function. This includes: - ObjID : An Unique Handler for the Object. See Section 3. - Owner : An Unique Handler to a "Owner Object" (See Section 6.1). OPP does not define any type (or list) of objects. This is subjected to changes depending on the objects we are provisioning. It is important to note that policy and access control are very much an integrated part of any provisioning process. For instance, using domain names as an example, a request to modify the registrant name (commonly known as Transfer), would involve changing the value of the "Registrant" attribute in some objects. Hence, authorization and access control list (ACL) are needed, not only on per list, per object, but also per attribute. Relationships between objects are referenced using URL Attribute type. Therefore, Node repositories MUST clearly specify the list, object and schema of the object they used and the policy with respect to access control on the repository. Hence, the minimal DTD for an Object would be <!ELEMENT object (#PCDATA)> <!ATTLIST object ObjID CDATA> <!ATTLIST object Owner CDATA> 6.1 Owner Object Schema Owner Object MUST contain the attributes including - ObjID - An Unique Handler for Owner Object. See Section 3. - Owner - An OPP ObjID that MUST be the same as ObjID. - PublicKey รป Public Key of the Owner Schema MAY extend the Object format to include other attributes. Internationalization (I18N) Consideration The character set for OPP is ISO10646/Unicode [ISO10646]. The character encoding scheme (CES) is UTF-8 [UTF-8] only. - Within the OPP frame, all I18N script is represented using UTF-8 any hex-encoding. An optional language tag as described in [RFC3066] may be specify using "lang" property. - Within OPP Unique Handler Specification, all I18N script is represented using hex-encoding of UTF-8. Security Consideration Since OPP relies a lot of Digital Signature for authorization and data integrity, the standard security loopholes for Digital Signature also applies to OPP. The following security issues are identified. OPP frames are transmitted in plaintext without encryption. Hence, it is possible that an intermediate node may intercept Request Frames and relay its own commands (e.g. "ADD") in place of the legitimate one. An intermediate node could maliciously fake itself as the intended repository. Therefore, the sender MUST verify the response signature of the destination node. References [GRRP] Generic Registry-Registrar Protocol Requirements, S. Hollenbeck, draft-hollenbeck-grrp-reqs [EPP] Extensible Provisioning Protocol, S. Hollenbeck, draft-hollenbeck-epp [RFC3080] The Blocks Extensible Exchange Protocol Core, M. Rose, RFC3080 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in preparation), ISO/IEC 10646-2 (in preparation), plus corrigenda and amendments to these standards. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC822, August 1982. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [xmldsig] XML-Signature Syntax and Processing, Eastlake, Reagle, Solo, RFC 3075 Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgements The initial idea of OPP originated from the Innovation Group of i- DNS.net. The participants (excluding the authors) in the study group are: Zhu Yu <zhu.yu@i-dns.net> Tan Juay Kwang <tanjk@i-dns.net> Jiang Ming Liang <jiang@i-dns.net> The Authors would like to thanks the following people for their valuable contribution: ... Authors' Information James Seng <jseng@i-dns.net> William Tan <wil@i-dns.net> i-DNS.net International 8 Temasek Boulevard #24-02 Suntec Tower Three Singapore 038988 Tel: +65 2486-188 Fax: +65 2486-189