INTERNET-DRAFT Expires June 1997 INTERNET-DRAFT STLD Working Group K. Crispin Category: Informational November 1996 Simple Protocol Supporting Shared TLDomain Registrars Status of this Memo This document is a submission to the Internet Ad Hoc Committee. This document is an Internet-Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any internet-draft, please check the "1id-abstracts.txt" listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract -------- This Internet-Draft describes a simple protocol supporting Shared Top-Level Domain Registrars called the Simple Registry Protocol (SRP). The primary purposes of the protocol are 1) to provide secure and authenticated communication between registrars, 2) provide impartial FCFS allocation of domain names, and 3) provide a secure multiple-updater interface to DNS or other database. The protocol makes use of DNS for certain semantics, but can support other databases as well. A primary design goal has been to minimize the amount of work that must be done by any centrally trusted entity. In SRP trust is vested in a single entity called the "master". No other entity, including the database and DNS, needs to be trusted. The master keeps no long term state except public and private keys. The master is only contacted when a domain name is created, minimizing the number of transactions, and thus keeping hardware and connectivity requirements. A complete failure of the master requires no restoration of state, and thus no expensive backup or redundant hardware is required. Introduction ------------ A registry with multiple registrars must contain at its heart a synchronization method to handle the problem of two registrars trying to register the same domain name at the same time. Though in practice such collisions should be extremely rare, the debris left over could be complicated to clean up. Therefore, it is worth expending a little effort to guard against them. The situation is complicated somewhat by the fact that in many if not all cases the registrars are mutually suspicious competing business entities. Therefore, strong authentication is required. Also important in a business context is support for non-repudiation and total accountability. Finally, there is the problem of "cheating", whereby a registrar uses trickery of some sort to get an unfair advantage. "Trickery" and "unfair" are subjective, of course, but the protocol should, where possible, prevent or minimize obvious opportunities to cheat. Another important factor that must be dealt with in the insecure internet is that vandals can attack or spoof the registry. This is more reason the dispersed registrars must have a secure and reliable means of authenticating themselves and their requests. The authentication in SRP is based on PGP, which is available worldwide. The underlying SRP data structure is an "SRP certificate", which is composed of sets of RFC822-like fields, optionally signed with PGP. Note that PGP is only used for generating and authenticating signatures, not encryption. There has been some controversy concerning the legalities of using PGP for commercial purposes. PGP, Inc sells a commercial version for use in the USA and Canada, while PGP2.6.3i can be used commercially in the rest of the world, provided a license for IDEA is purchased from Ascom Systec AG, in Switzerland. Detailed information for obtaining and using PGP is widely available. The fundamental architecture has three primary components -- a SRP client, a SRP master, and a database update daemon that interacts with DNS and possibly another repository database. The SRP master is trusted to be impartial, and is run by a Trusted Third Party. The Database Update Daemon (DBUD) interacts with the primary nameserver for the zone, which, because its operation is completely visible, does not need to be trusted as far as impartiality is concerned. (If the database is managed by an untrusted party, however, registrars must verify its operation. The price of the database updater not being trusted is constant vigilance. An error or fraud can always be detected and proven, but that detection and proof take effort.) All critical transactions between these three parties involve SRP certificates, and important state-changing transactions result in signed receipts or results that leave an audit trail of non-repudiatable records that makes any attempt at cheating perfectly visible. Assumed Technical Environment ----------------------------- It is assumed that there is a group of registrars that comprise a registry for a gTLD. All the registrars run the SRP client. One distinguished entity (the Master) runs the SRP master service. This entity also runs the SRP client, but, by virtue of its identity, can do anything *any* of the registrars can do -- as far as SRP operations are concerned, the master essentially has "root" privilege. The master is the single trusted entity in SRP. Logically, each registrar runs a nameserver with the entire gTLD zone. But if there are a great many registrars for the gTLD some subcontracting arrangements may be worked out such that one nameserver serves for more than one registrar. One of the nameservers for the zone is the primary nameserver; the others are secondaries. The primary may be run by one of the registrars, the master, or some third party -- such policies are not addressed here. It is assumed that each registrar keeps a Customer Database, in a format that the registrar chooses, and that each registrar makes available whois-compatible data from this database. Since the Customers deal directly with their registrars, the Customer databases at the registrars are the primary and authoritative sources of whois data for a gTLD. That is, the primary source of whois data for the registry is segmented across the registrars in disjoint sets. SRP provides support for keeping a copy of this data in DNS or any other central database. But of course, ultimately the responsibility for the consistency and accuracy of this information must rest on the registrars. Note that while this model does not preclude maintaining whois data for the entire gTLD in a central database, possibly co-located with the SRP master server, but it does not require it, either. SRP also supports a distributed interface to whois data through indirect references in a central database, or DNS. SRP Certificates ---------------- SRP Certificates are composed of a Certificate Body followed by by the ascii characters CRLF (in 'C', "\r\n"). A Certificate Body is either 1) a set of RFC822-style fields, 2) a SRP Certificate Body signed by PGP, or 3) a concatenation of 2 or more SRP Certificate Bodies. Notice that the definition of a Certificate Body is recursive. The phrase "RFC822-style" means that the fields do not follow the exact syntax of RFC822, but differ in the following ways: fields are delimited by a single LF character, instead of a CRLF. A single '\' as the last character before a '\n' character allows line folding. All implementations of SRP are expected to handle single lines of at least 255 characters. Fields in a cert must have unique names; it is undefined which field value will be used if there are multiple occurences of a field name in a single cert. [A formal specification using the augmented BNF of RFC822 will be appended.] The client, master, and updater ignore fields that they don't use. Thus, new fields can be added without changing running software. Furthermore, because of the structure of PGP signed text, the fields can be parsed out of signed certificates without going to the computational expense of verifying the signature, in appropriate circumstances. Here is an example of an unsigned certificate. It is an abbreviated example of a CREATE request: request: CREATE dom: test.tld registrar: registry@songbird.com Here is an example of a signed certificate, with additional fields appended -- it is a certificate signed by the client. The master has decoded the signature, and added a "signer:" field at the bottom. [The "signer:" field is not, strictly speaking, part of the protocol -- it is a field internally used by the master to notate a cert.] -----BEGIN PGP SIGNED MESSAGE----- request: CREATE dom: test.tld registrar: registry@songbird.com -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMrgoX/TO/sqmpV8tAQEHcAH/Y+Smxd8O/Z0Bp3CK2UUrDsCmpVMgHZ// LJzad71JcEU5mhCI+3i7S1oYZvZVH01r8TCOWaA9K8XCgXCcTogDsw== =VhAh -----END PGP SIGNATURE----- signer: registry@songbird.com These are the currently defined field names: request: A function specifier, defined below result: The normal result of a request dom: Name of the domain dom-exp: Date name will be deleted from dns. registrar: Registrar representing the domain expires: Expiration date for the cert timestamp: Approximate time of signing of the cert key: public key of domain name owner whois: URL or other indication of location of whois server The following fields are whois information that may be transported in a cert, in lieu of the "whois:" indirect pointer. handle: NIC-handle name: person or business name email: contact email address address: contact mail address phone: contact phone number fax: contact fax number ack: email for registrars to communicate status to owner These fields are used to convey nameserver information for the domain. While at least 2 nameservers are required, there comes a point of diminshing returns. Therefore, the upper limit of 7 [The InterNIC form supports 7 nameservers]. ns01: Hostname or IP address of nameserver 1 ns02: Hostname or IP address of nameserver 2 ns03: Hostname or IP address of nameserver 3 ns04: Hostname or IP address of nameserver 4 ns05: Hostname or IP address of nameserver 5 ns06: Hostname or IP address of nameserver 6 ns07: Hostname or IP address of nameserver 7 The following fields are optional fields that may appear in a cert, but that are reserved for internal purposes by the various software components. signer: notation of verified signature status: internal processing status debug: indicate to master to send debug information Certain certs signed by the master are used to authorize actions. These certs are good until 1) the master changes keys, or 2) the date and time specified in the "expires:" field is passed. The master guarantees that no two certs authorizing the same action and signed by the same master key will have overlapping validity periods. The "expires:" field is used for algorithmic purposes, and can also be used to prove priority in a dispute resolution scenario. SRP Requests ------------ Following is a list of explicit functions supported. A function is embodied in a "request cert". In most cases the request cert is signed by the requestor. The name of the function follows in the "request:" field in cert. Items in angle brackets indicate further distinguished fields in the certificate that are used as parameters to the function. Items in square brackets indicate data, in the form of cert fields, that are not fully specified. Thus, the example certificate above would be sent to the master to create the domain "test.tld". Note that the signature on a signed certificate contains an implicit specification of the signer. All functions also return a SRP certificate as a result -- a "result cert". A result cert may be a simple non-signed "result" certificate (a single "result:" field), or "result:" field followed by a signed certificate that serves as a receipt or a token enabling some further action. The "result:" field in this latter case is outside the signature block. All result certificates contain a "result:" field. The protocol does not require further parsing of the field body of a "result:" field -- the client can consider the field body as a message to be printed to the user. [The descriptions below do not yet include a complete specification of the result certs.] The functions supported are as follows: CREATE -- (client -> master) ------- CREATE , [other data]: If is already in DNS, return a failure message. If any registrar has a pending CREATE for , return a failure message. Otherwise, the master will sign and timestamp a new CREATE cert, one with all the data from the request cert, but with an "expires:" field inside the signature block. The "result:" field is prepended with a success indication, and the whole is returned as the result of the function. The master will set the "expires:" field in the result cert with a date/time = current_time + MAX_RESERVATION_TIME. The master will maintain a reservation on the domain for the registrar for RESERVATION_TIME + max_realistic_network_delay, to allow the registrar time to create the domain. After that time the master will forget the reservation, because the cert will have expired. The master will also forget the reservation if either 1) the registrar sends a CANCEL function, specifying the same domain name, or 2) the master detects in DNS that the domain has been created. However, if the master receives a new CREATE request for the same domain, and the request is from the same registrar, it will refresh the reservation. The result cert serves two purposes: First, it is forwarded to the DBUD to actually create the domain name. Second, it serves as a non-repudiatable record of the transaction. It is the responsibility of the registrar to send the signed CREATE result cert to the DBUD, and to keep the cert safe until the DNS update occurs. The DBUD will only honor CREATE certs signed by the master. When it receives such a cert, it spools the database update, signs the entire cert with the DBUD key, and returns it. A copy of this doubly-signed cert is proof that the authorized CREATE request was accepted by the DBUD. A copy of this receipt may be given to the end customer. CANCEL -- (client -> master) ------ CANCEL : Cancels the implicit reservation the master is maintaining for a pending CREATE request. Of course, only the registrar owning the reservation may CANCEL it. MODIFY -- (client -> database updater) ------ MODIFY , [data]: The database updater verifies the signature on the certificate. If the client is listed as the registrar for the domain, then the modification to DNS is queued, and a positive response returned. If the client is not the current registrar representing the domain, and there is a "key: record in DNS, the DBUD will attempt to verify a signature with "key:". If this attempt fails, return an error. Otherwise proceed with the update as above. Since DNS updates may take time to propagate, and errors may occur, a responsible client will later query DNS to verify that the update was made. DELETE -- (client -> database updater) ------ DELETE : A DELETE certificate will cause deletion of the domain and all associated information from DNS and any other database. Normally only the registrar that currently represents the domain can DELETE it from the zone, but if there is a "key:" field with the domain, then the same procedure described for the UPDATE function can be used. A note on "transfers" --------------------- A transfer from one registrar to another is in total a fairly complex process, and involves more than merely updating the DNS information. It requires the involvement of both registrars -- the new registrar needs to accept the responsibility for representing the domain, set up billing and other business minutiae, and so on. The old registrar needs to update its business records, clear accounts, etc. Thus, a transfer is an operation that requires a certain amount of human intervention, and most of the work must be handled outside the scope of the SRP. In non-disputed cases the transfer can be effected by sending a MODIFY to the DBUD, with the new registrar's name in the "registrar:" field. A question arises about the possibility of non-cooperation of the old registrar during a transfer. For example, a very valid reason for a customer wanting to transfer is the total incompetence of their current registrar, who could thus not be counted on to cooperate. If there is a "key:" field the transfer may be effected without the cooperation of the current registrar, using the method described for the "UPDATE" request, above. As a matter of policy (and hence outside the scope of the protocol), one would imagine that the new registrar would notify the old registrar. If there is not "key:" field the user has not recourse but to go through some dispute resolution process that will eventually involve the master functioning in its "root registrar" capacity. The case of malicious registrar who has modified or even deleted records is indeed a tricky problem. If the user has signed copies of all the CREATE and MODIFY certs for a domain these items can be presented to a disput resolution body as evidence for what the stored data should be. But such disputes must be resolved via a dispute resolution policy. Such circumstances may require the intervention of the master to move the users domain to a different registrar, and perhaps recreate the correct data. Establishing the circumstances under which this must be done is outside the scope of the protocol. The Master ---------- The master receives certificates from a client, and verifies the clients signature. If the signature is OK, the master looks at the "request:" field in the certificate, and takes action depending on the value, as described above. The normal sequence of operations is as follows: The registrar receives a request for a particular domain from a customer. The registrar client sends a CREATE cert to the master, receives a CREATE signed by the master in reply, and forwards it on to the database updater, which, directly or indirectly, updates DNS. The master guarantees first-come-first-served semantics between registries desiring to add the same named second-level-domain through the mechanism of the implicit reserve left by a successful CREATE request -- a CREATE request from a second registrar that arrives later will get an error. After the reservation expires the name is available again, if it hasn't appeared in DNS. The master should ensure to a high level that the "expires:" times in a cert will pass before the reservation expires. But it shouldn't make the grace period too long. Therefore, the master must keep a reasonably accurate monotonic clock. Accuracy is not as important as monotonicity, because the transit of certs through the network makes all times approximate, whereas establishing priority in time may be critical in a dispute. The master listens on an agreed upon port. It is not necessary that the port be a "privileged" port, since PK authentication is used. The master keeps local state on stable storage to remember reservations for a fixed period of time (the lifetime of the reservation). But the master does not itself keep a database. DNS is the authoritative record of what names are in the zone. In other words, the master acts as a caching front end to other databases, specially designed to facilitate registrar operations. A catastrophic failure of the master that causes loss of its records is a potentially serious problem, but there is a simple solution: Upon such a failure the master waits MAX_RESERVATION_TIME, and starts fresh. No new CREATEs can be issued while it waits, and all old ones will have expired. The Client ---------- In most cases the SRP client collects the data necessary for one of the of the SRP requests, generates a certificate with that data, signs it, sends it to the master or the DBUD for action, receives a reply, and saves the reply certificate. This straightforward client-server relationship covers all the requests except the CREATE, and the user-initiated forms of MODIFY and DELETE. The CREATE request is handled as a chained operation, first sending to the master to get a signature, then sending to the database updater to get the work done. In the case of the user-initiated MODIFY and DELETE the user first generates a signed cert, which is then countersigned by a registrar. The registrar then forwards the countersigned cert to the database updater for action. Functions that are sent the the database updater are generally queued there, and do not send back an immediate response -- updating the zone file every few seconds. In the case of a detected error the database updater will contact the registrar via some out-of-band method, probably email. But undected errors are perfectly possible. Therefore, it is always the client's responsibility to check later to be sure that DNS is updated as requested. For a CREATE the master will keep a reservation on the name until it appears in DNS (modulo certain drastic failure conditions). But the client should also keep the CREATE certificate signed by the master, until it is sure that the name has been correctly added to DNS. As a policy matter, it would be good if the client also gave a copy of the cert to the end user. Database Updater --------------- The Database updater is a logically distinct service from the master. They may be co-located, but there is no requirement that the DU, or the databases it supports, be trusted. Users and registrars have digitally signed receipts that provide irrefutable proof of the state of affairs that should obtain, and therefore, the database operator cannot cheat without being caught. Therefore, if the database is maintained in DNS, the DBUD can be operated as a low-overhead extra activity of one of the registrars -- the DBUD maintains the zone file(s) automatically. The DBUD periodically does a mechanical update of the zone database file, and signals the primary nameserver to read it. If the data is kept in a secondary database of some kind (whois, for example), the DBUD will update that data as well. It authenticates all the transactions that cause updates. As a practical matter, the DBUD may be implemented in several pieces. Key Management -------------- All registrars and the Master have unique PGP key pairs, and each of these must have the public key of every other. Distribution of keys would seem, therefore, to be an n-squared problem. However, two factors mitigate this: first of all, most changes in the key set are incremental; and second, the master is in a distinguished, trusted position, and therefore can act as a key distribution center for the registry. The master has to know all the registrar public keys, and each registrar has to know the masters public key, and then the master's public key ring can be mailed securely to each of the registrars. Implementation -------------- A prototype C language implementation of the client, master, and dbud are available at ftp://songbird.com/registry.tar. The client is a stand-alone program; the master is a daemon that runs under inetd; the dbud is partly a daemon that runs under inetd, and partly a program run by cron. Acknowledgments --------------- John Levine and David Kessens have supplied invaluable input into the design of this protocol. Author's Address ---------------- Kent Crispin L-61 Lawrence Livermore National Laboratory PO Box 808 Livermore, CA 94550 kc@llnl.gov kent@songbird.com +1 510 422 4273