Internet DRAFT - draft-crispin-srs
draft-crispin-srs
Network Working Group K. Crispin
INTERNET-DRAFT D. Crocker
<draft-crispin-srs-00.txt> R. Gaetano
Expires in six months S. Langenbach
November, 1998
Shared Registry System Protocol (SRSP)
STATUS OF THIS MEMO
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 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
ABSTRACT
This specification describes a protocol for a Shared Registry
System (SRS) that allows multiple registrars to register domain
names within a single Top Level Domain (TLD). The protocol is
high-level, text-based, and can be used over many underlying
transport mechanisms, including email. The semantic content of
the protocol is expressed as a set of keyword-value pairs; the
semantics and structure of this content is, in this document,
loosely described as the "payload".
The protocol described herein is essentially identical to the SRS
version 1.5 protocol, specified by the CORE SRS RFP and developed
by Curt Meyer of Emergent Corporation.
TABLE OF CONTENTS
1. ARCHITECTURE FOR A SRS
1.1. Communications
1.1.1. Failure model
1.1.2. Transaction State
1.1.3. Trust
1.1.4. SRS multiplexing of email and wire protocol
1.1.5. Encapsulation
1.2. Disaster recovery
1.3. Administration
1.4. Database Publishing
1.4.1. Whois
1.4.2. Zone Files
1.4.3. Fielded data
2. SRS PROTOCOL
2.1. Generic Syntax
2.1.1. Character Set
2.1.2. Keyword-value Pairs
2.1.3. Overall Composition
2.2. Requests
2.2.1. Generic Fields
2.2.2. Operations-Specific Fields
2.3. Responses
2.3.1. Generic Fields
2.3.2. Response-specific fields
2.4. Error Conditions
2.4.1. Error categories
2.4.2. Specific errors
2.5. Notes
2.5.1. Field checking
2.5.2. Remove Contact
2.5.3. Policy Decisions
2.5.4. More sophisticated syntax
2.5.5. Host leaks
2.5.6. Handle namespace
3. SRS TRANSPORT
3.1. SRS over Email
3.1.1. Encapsulation and Exchange
3.1.2. Errors
3.1.3. Notes
3.2. SRS over TCP
Encapsulation and Exchange
3.2.1. Connection
3.2.2. Errors
4. SECURITY CONSIDERATIONS
4.1. Definitions
4.1.1. Contact
4.1.2. Key
4.1.3. Owner
4.1.4. PGP
4.1.5. Crypt
4.2. Key Management
4.2.1. Registrar Keys
4.2.2. Registry and Dispute Resolution Agency Keys
4.2.3. Master Key Compromise
4.2.4. Agent Key Compromise
4.3. Authentication Schemes
4.3.1. PGP Signatures
4.3.2. Crypt Authentication
4.4. Notes
5. ACKNOWLEDGEMENTS
6. AUTHORS' ADDRESSES
7. REFERENCES
8. FULL COPYRIGHT STATEMENT
1. ARCHITECTURE FOR A SRS
This section describes a reference architecture for a shared
domain name registry system. Explicit goals of this system
include having mutually distrustful registrars, simple transfer
by a domain holder between registrars, extensive use of public
key signatures for authentication and nonrepudiation, robustness
in the face of failure of any component, and ease of
implementation. Note that this reference model is based on the
actual CORE implementation, and is therefore more specific than
is necessary to describe the protocol.
Three entities is party to most SRS operations:
* Domain holders (the customers),
* Registrars (hereafter referred to as the client), and
* Shared Registry System (hereafter referred to as the SRS).
This reference architecture is mostly concerned with the
interaction between the registrar and the SRS. Communications,
billing, authentication, etc., between the domain holder and the
registrar are beyond the scope of this document, and are expected
to vary widely, given the variation in registrar business models.
1.1. Communications
A Shared Registry is assumed to be composed of three tiers of
machines: client machines, operated by the registrars, and
fronted and database machines, operated by the registry. The
split between fronted and database machines is motivated by
two factors -- performance and security/integrity of the
database. The fronted and the database could be the same
machine, especially with a small registry. The
front-end/database machine(s) are collectively referred to as
the SRS.
In a large installation both the fronted machines and the
database machines may be replicated for performance and
robustness, as well, with the front ends specialized for
secure network communications, and the database machines
specialized database engines.
The client machines interact only with the fronted machines,
and the database machines interact only with the front-ends
as well. The client <-> fronted protocol is the focus of
this document, and it is what we refer to as the "SRS
protocol".
1.1.1. Failure model
An end-to-end acknowledgement is generated by both the
SRS and the client when requests or replies are received.
This ack allows fault recovery to be very
straightforward.
All operations that modify state can be reissued benignly
given appropriate duplicate detection logic in the
database machines. Given this characteristic, a
communications failure at any point can be recovered by
the client retrying the operation in question.
1.1.2. Transaction State
All changes to the SRS initiated by a registrar are
uniquely identified by a transaction identifier generated
by the client. This transaction id will consist of a
registrar key, a date, and a serial number.
We assume that no state is maintained on the fronted
machines. All state is distributed between the database
servers, and the client machines. A recovery protocol is
used to synchronize the client and database server's idea
of a request's state. Digital signatures are used to
detect forged state changes.
1.1.3. Trust
All requests are signed by the issuing registrar. A
transfer request is optionally signed by the domain
holder. The registrar's public key was signed by the
registry, and this certificate was communicated to the
SRS when the registrar was entered into the system.
Each database object has a registrar of record; only that
registrar may issue changes to that object. A transfer
operation is the operation of changing the registrar of
record. A backend process notifies, via email, the
previous registrar of a transfer of an object to another
registrar. Each domain and host also has a set of
contacts, each of which may have an associated key. A
transfer request must be signed by one of these contacts.
All replies sent to a client contain the associated
request body. This reply body is itself signed by the
database server. This reply is a nonrepudiatable
certificate that the operation actually completed. The
SRS database logs all of these certificates. A wise
client would keep records of all signed reply bodies
indefinitely, as they are nonrepudiatable proof of a
completed transaction.
The SRS private key is stored on each of the database
servers, and is used to sign all replies, and sign the
zone files for each TLD. The database servers also
verify the signature on all requests.
The fronted machines simply route traffic to client
machines, send and receive email, and distribute signed
zone files. At all times, it is assumed that the fronted
machines have been compromised, and thus, all successful
attacks on the front-ends result in at most a denial of
service. Since the front-ends have little state, they
can be reloaded from a known-good root disk image, and
restarted. As the front-ends are likely to be
replicated, these restarts will probably not even be
noticed by clients.
1.1.4. SRS multiplexing of email and wire protocol
The SRS protocol is designed to support both interactive
and email-based clients. The fronted machines all may
receive email, and generate acknowledgement email
messages when the requests have been accepted by the
database server.
In the CORE implementation the fronted encapsulates the
email request into a wrapper identifying the reply to
address, and sends the request to the database. When the
database replies to the request, it then copies the
wrapper from the request, and sends the reply to the
fronted. The fronted strips the wrapper, and generates
and sends an email message from the reply.
Likewise in the CORE implementation, an interactive
request has a wrapper identifying which connection the
reply should be sent on. As the client will
automatically retrieve any undelivered replies if the
connected front-end fails, this wrapper is a hint,
allowing prompt notification in most cases.
1.1.5. Encapsulation
All messaging is human-readable, ASCII, using MIME
multipart message encapsulation and format. All messages
that do not have the exact expected number of parts are
discarded, as are all messages that do not verify
signatures.
1.1.5.1. Signatures
PGP signatures use SHA1/DSS signatures as generated
by pgp5.0 international. The signature is packaged
as the second part of a two part multipart signed
message. The signed message is the first part. The
mime parameters for the message must include
micalg=pgp-sha1 and
protocol=application/pgp-signature. Multiple
signatures, which are used to countersign transfer
requests, are simply implemented as nested signed
messages.
1.1.5.2. Replies
Replies, as distinct from acks, are formed as an SRS
signed message, consisting of a two part,
multipart/mixed MIME message. The first part is the
reply body, and the second is the request that this
reply responds to. All signatures in the request are
intact, and thus replies are a certificate,
nonrepudiatable in both directions.
1.2. Disaster recovery
Several failure modes are not recovered from automatically;
indeed, a gross accident could destroy both fronted machines
and database servers. Replicated state offsite is important
to recover from this class of disaster. Frequent backups of
the database servers set an upper bound to the amount of lost
state in the SRS. Daily delivery of backup media to offsite
storage will safeguard against data center destruction, and
allow a rebuild up to the point of the backup.
As clients have been sent nonrepudiatable certificates of
request completion, when a client connects to a resurrected
SRS, the SRS may request a replay of these certificates.
These will then be used to resync up to the instant of
failure. Any unacknowledged requests are re-sent by the
client as in the communications failure case. Geographically
colocated clients could be affected by the same disaster, and
in this case, data will be lost.
A future, related approach, has all these certificates being
sent to a set of geographically well-distributed sites. On
resurrection, these sites are queried for up-to-the-crash
certificates, which are replayed. The advantage of this is
that no certificates need be kept on the clients.
A final, expensive approach has the database itself
replicated, with automatic failover. Oracle has several
different mechanisms to support this option.
1.3. Administration
The SRS has an administrative interface, allowing full
database control from on-site only. Backups are online, not
interrupting database access, and zone file generation is
automatic, placing the zone files on the fronted machines for
distribution via BIND.
A TLD name server is refreshed frequently from a signed zone
file; if a signature does not verify, the zone file is not
loaded, and an alarm triggered, causing an expert to be
automatically paged.
1.4. Database Publishing
A periodic extract of all data is performed. This single
extract is used to generate whois information, new zone
files, and fielded data files.
1.4.1. Whois
As whois is a primitive interface, a read-only database
optimized for text searching is loaded onto the fronted
machine designated as the whois server.
1.4.2. Zone Files
A total count of rows is calculated at extract time for
each TLD. A generated zone file must have this many rows
contained within it. If this comparison fails, the zone
file is not signed or distributed. DNSSEC is expected to
be deployed during 1998, so complex signing will need to
be phased in.
1.4.3. Fielded data
Interested parties may download the entire database, or
changes since the last download, in a well-defined form,
to be documented.
2. SRS PROTOCOL
This section specifies the SRS Protocol "payload", or
request/reply semantic content, for each of the operations the
SRS will support. The transport and authentication related
"wrapper" portions of the protocol are described in later
sections.
2.1. Generic Syntax
One of the design goals of the SRS protocol and payload is to
allow the use of unauthenticated[DHC1] communications paths,
placing all responsibility for security on a well-controlled
database backend server. A variety of communications layers
can be used as transport for the identical payload, including
email. Thus, the payload is in a form suitable for manual
composition of this email by a human operator. The general
form of the payload is thus similar to any number of other
textual field-based protocols.
2.1.1. Character Set
The payload will be expressed in the 7-bit ASCII
character set. ASCII double-quotes ('"'), newlines, and
backslashes ('\') have special meaning as described in
2.2, and lack special meaning except in the specific
contexts described.
2.1.2. Keyword-value Pairs
A payload consists of successive keyword-value pairs,
expressed either as in 2.2.1 or 2.2.2.
2.1.2.1. Unquoted
A keyword-value pair may be expressed as follows:
KEYWORD lwsp ':' lwsp VALUE lwsp newline
Where KEYWORD consists of a sequence of printable,
non-whitespace ASCII characters excluding colon
(':'). VALUE consists of a sequence of printable
ASCII characters, including whitespace.
VALUE will be terminated by an ASCII newline, except
that a newline immediately preceded by a backslash
will not terminate VALUE, but will instead cause the
backslash-newline sequence to be ignored. Thus,
backslash-newline will cause the concatenation of
textual lines of payload into a single value (not
including the backslash-newlines themselves).
Whitespace ("lwsp") between the delimiting colon and
the first subsequent non-whitespace character will
not be considered a part of VALUE, nor will the
terminating newline, nor will whitespace immediately
preceding the terminating newline.
Note that a VALUE whose last character is backslash
may be expressed by the inclusion of one or more
whitespace characters between the backslash and the
terminating newline.
2.1.2.2. Quoted
Alternatively, if the first non-whitespace character
after the colon is an ASCII double-quote, the
keyword-value pair is taken to be expressed in quoted
form:
KEYWORD lwsp ":" lwsp "VALUE" lwsp newline
KEYWORD consists of a sequence of printable,
non-whitespace ASCII characters excluding colon.
VALUE is taken to be every character between the
initial double-quote and the next double-quote in the
payload, including whitespace and newlines, excluding
the double-quotes themselves.
However, if the initial double-quote is immediately
followed by another double-quote, VALUE is considered
to be unquoted as described in 2.2.1, except that the
two leading double-quotes will be taken as a single
double-quote character.
Note that the quoted form does not allow for the
expression of double quotes anywhere in VALUE. This
form is intended to permit the simple inclusion of
multi-line base-64 PGP signatures in payloads; as
base-64 encoding does not use the ASCII double-quote
character, this simple alternative will suffice.
2.1.3. Overall Composition
The term "field" shall be used hereinafter to refer to a
keyword-value pair, and a specific field may be referred
to by its keyword.
No two fields in the same request may contain the same
keyword.
Unless otherwise specified, field values may be up to 255
bytes in length. The entirety of a payload, with
attached signatures and encapsulations may not exceed
65536 bytes.
Any ill-formed payload in a request will result in the
failure of the request, resulting in the SRS sending an
appropriate error message.
2.1.3.1. Case Sensitivity
Keywords are not case-sensitive. Unless otherwise
specified, field values are case-sensitive -- case
information will be stored in the database as
supplied, and matching operations will be
case-sensitive.
2.1.3.2. Dates
All dates communicated to and from the SRS will be
UTC dates in the format
YYYYMMDD [HH:MM:SS]
where HH represents the hours on a 24-hour clock.
Dates without the HH:MM:SS portion shall be
considered to be midnight at the beginning of the
specified day.
2.1.3.3. Localization
It is expected that the Keywords specified herein
will eventually be translated to multiple human
languages, with appropriate changes in encapsulation.
However, character set will still be restricted as in
2.1 above.
2.2. Requests
This section documents the contents of the payload associated
with an SRS request.
2.2.1. Generic Fields
The following fields must appear IN ORDER as the first
fields in a payload.
2.2.1.1. Payload-Version
This field specifies the version of the SRS protocol
the remainder of the payload uses. The remainder of
the payload must be compliant with the corresponding
version of this document, and the client is expected
to be able to appropriately process any reply message
generated according to the same version of this
document.
The only currently defined value for this field is
the literal "1.0".
This field is mandatory.
2.2.1.2. Registrar-Id
The previously assigned identifier for this registrar
in the SRS. Among other things, this value will be
used to determine the type and key for cryptographic
verification of the request.
This field is generally the fully qualified domain
name of the registrar.
This field is mandatory.
2.2.1.3. Transaction-ID
This is a single printable word (no whitespace).
This field specifies the identifier to be used to
denote this transaction. This identifier must be
unique across all transactions submitted by a
particular registrar. The registrar may use any
policy to generate a transaction-ID. It is strongly
recommended that transaction-IDs begin with the
registrar-ID as defined in 3.1.2.
In the case of a transaction status inquiry, this
field should be the Transaction-ID submitted with the
request for which status is desired.
This field is mandatory for all operations. While
the initial implementation of the SRS will respond to
status and query requests synchronously, this allows
future implementations to respond asynchronously
without changes to the protocol.
2.2.1.4. Request-Type
This field specifies the request type. All values of
this field will be stored and treated as lower-case.
Currently defined values for this field are:
"create" lwsp "contact"
"create" lwsp "host"
"create" lwsp "domain"
"modify" lwsp "contact"
"modify" lwsp "host"
"modify" lwsp "domain"
"remove" lwsp "host"
"remove" lwsp "domain"
"transfer" lwsp "host"
"transfer" lwsp "domain"
"inquire" lwsp "domain"
"inquire" lwsp "contact"
"inquire" lwsp "host"
"renew" lwsp "domain"
"status" "query"
Note that we do not currently specify a "remove
contact" operation. This is to ease the tracking of
events associated with a domain; we don't potentially
have to go through history attempting to recreate
contact information as well as domain information.
This field is mandatory.
2.2.1.5. Signer-Handle
The handle of a pre-existing contact whose
authentication information is used to authenticate
the request.
This field must exist if and only if the request is
doubly signed (the other signature being that of the
registrar) as described in the SRS Architecture
Specification, or if the request is authenticated
using a stored secret.
A request will fail if one of the following occurs:
(1) It is required to be doubly signed by the SRS
Security Policies document, and is not.
(2) The value of this field is not a valid contact
who is authorized to authenticate this transaction
according to the SRS Security Policies document.
This check is made before the application of this
request.
(3) Authentication, performed according to the
information in the contact record associated with
this field, fails.
Note that if a request is doubly signed and one of 2
or 3 above fail, the request will fail even if it is
not required by the SRS Security Policies document to
be doubly signed.
2.2.1.6. Authenticating-Key
The secret key used to authenticate a request.
This field must only exist if the contact specified
in the mandatory Signer-Handle value uses Crypt
authentication.
2.2.2. Operations-Specific Fields
This section documents fields that are specific to each
possible value of the Request-Type field. Unless
otherwise specified, these fields may appear in any order
(after those specified in 3.1)
2.2.2.1. Create Contact
The create contact operation results in the creation
of a contact record in the SRS. In order to support
the potential exchange of TLD databases,
functionality to support user-specified handles is
included.
No checking is performed to prevent the creation of
duplicate contacts (with different handles).
Handle
A single printable word (no whitespace), not
beginning with '=', case-insensitive. All values
of this field will be stored and treated as upper
case.
This field is optional; if specified, an attempt
is made to create the contact with the specified
handle. If the specified handle already exists
in the database, the operation fails and no
contact information is created.
Name
A printable string (may include whitespace). The
name of the contact.
This field is mandatory.
Title
A printable string (may include whitespace). The
contact's title.
This field is optional.
Organization
A printable string (may include whitespace). The
organization to which the contact belongs.
This field is optional. (In particular, it is
clearly inapplicable to the nominative domain.)
Address-1,
Address-2,
City,
State,
Postal-Code,
Country
All of these fields are printable strings (may
include whitespace).
These contain the contact's postal address
information. No checking is performed to ensure
correctness or completeness of the address;
specification of an accurate address is strongly
encouraged, for obvious reasons. In particular,
unspecified country fields may not be assumed to
be the United States.
All of these fields are optional.
Email
A printable string (may include whitespace). The
contact's email address. No checking will be
performed to ensure its validity.
This field is mandatory.
Phone
A printable string (may include whitespace). The
contact's international telephone number. No
checking will be performed to ensure its
validity. Specification of a complete telephone
number, including country code, is strongly
encouraged; telephone numbers may not be assumed
to be in the United States.
This field is optional.
Auth-Type
This field specifies the type of authentication
to be performed in order to verify this contact's
digital signature. All values of this field will
be stored and treated as lower case. Currently
defined values are:
pgp5
crypt
none
This field is mandatory.
Auth-Key
A printable string of up to 1,023 characters (may
include whitespace). Specifies the key to be
used to verify the validity of a request to
change this contact. Its contents are dependent
on the value of the Auth-Type field.
This field is mandatory, unless the value of the
Auth-Type field is "none", in which case it must
not be specified.
Fax
A printable string (may include whitespace). The
contact's international fax telephone number. No
checking will be performed to ensure its
validity. Specification of a complete telephone
number, including country code, is strongly
encouraged; telephone numbers may not be assumed
to be in the United States.
This field is optional.
2.2.2.2. Create Host
The create host operation results in the creation of
a new host record in the SRS.
This operation may implicitly create contact records
and other information in the SRS. If these
operations fail for any reason, the entire operation
fails and no change is made to the SRS.
Handle
A single printable word (no whitespace), not
beginning with '=', case-insensitive. All values
of this field will be stored and treated as upper
case.
This field is optional; if specified, an attempt
is made to create the host with the specified
handle. If the specified handle already exists
in the database, the operation fails and no host
information is created.
IP-Address
This field is a list of 4-octet IP addresses for
the nameserver. IP addresses are expressed in
decimal-"dot" format; each of the four octets is
represented as decimal ASCII text, separated by
'.' (e.g., "140.174.2.181").
No verification is performed on this field beyond
syntactic correctness. In particular, no
duplicate checking is performed, so multiple host
records can exist for the same IP address. This
enables a user to administer several different
"sets" of domains on one nameserver if so
desired.
This field is mandatory.
Domain-Name
This field is a valid fully-qualified domain name
as specified in RFC 1034 et seq. It is taken to
be the domain name of this host. All values of
this field will be stored and treated as lower
case.
Contact Information
Each host must have contact information
associated with it. This contact may either be
supplied as the handle of a pre-existing contact,
or it may be created "implicitly" from
information supplied as part of the Create Host
operation.
The presence of valid contact information
supplied by one of these two methods is
mandatory; if an error occurs, the entire create
host operation fails and no changes are made to
the SRS.
Contact-Handle
The handle of a pre-existing contact generated by
the SRS. All values of this field will be stored
and treated as upper case.
This contact is associated with the host. If
this contact handle does not exist, the entire
create host operation fails and no changes are
made to the SRS.
Implicit Contact Creation
Contacts may be created implicitly by specifying
contact information in fields named by prepending
the string "Contact-" to the field names
specified in 3.2.1.2 -- 3.2.1.9.
Fields are mandatory and subject to validity
checking as specified in 3.2.1.2 -- 3.2.1.9. If
an error occurs during implicit contact creation,
the operation fails and no changes are made to
the SRS.
2.2.2.3. Create Domain
The create domain operation results in the creation
of a domain record in the SRS. This operation may
also implicitly create contact records and other
information in the SRS. If any of these operations
fail for any reason, the entire operation fails and
no change is made to the SRS.
TLD
This field specifies the top-level domain in
which the domain should be created. All values
of this field will be stored and treated as lower
case.
This field must match one of the top-level
domains being managed by this SRS; otherwise, the
operation fails.
This field is mandatory.
SLD
A valid second-level domain name, as defined in
RFC-1034 et seq. This field is not
case-sensitive, and will be mapped to lower case
for storage in the database. If both the TLD and
SLD fields match those attributes of a
preexisting domain record, the operation will
fail.
This field is mandatory.
Nameservers
Each domain has no fewer than two and no more
than twelve host records associated with it.
These hosts are expected to act as the domain's
nameservers.
This protocol supports both the use of
pre-existing hosts by handle and the implicit
creation of hosts by the specification of host
creation information in a domain creation
operation.
The nameservers for a domain are numbered
sequentially, starting from 1. Each of the
nameservers for the domain may be a pre-existing
host, referenced by handle, or an
implicitly-created host.
Each nameserver is handled identically. For the
purposes of the remainder of 3.2.3.3 and for
3.2.3.7, "<nsnum>" may be replaced with the
concatenation of "NS" (case-insensitive) and the
decimal ASCII representation of the sequential
number of the nameserver.
<nsnum>-Handle
The handle of a pre-existing host. If a host
with this handle does not already exist in the
SRS, the entire domain creation operation fails
and no changes are made to the SRS.
If this field is specified for a nameserver
number, implicit host creation may not be
specified for that nameserver.
This field is case-insensitive.
Implicit Host Creation
Hosts may be created implicitly by prepending the
string "<nsnum>-" to the fields specified in
3.2.2.2 -- 3.2.2.4. Implicit contact creation as
part of implicit host creation, as described in
3.2.2.4.2, is supported by prepending
"<nsnum>-Contact-" to the field names described
in 3.2.1.2 -- 3.2.1.9.
A linked contact specification is supported for
the host contact handle
("<nsnum>-Contact-Handle") as specified in
3.2.3.7. If an error occurs during this process,
the entire domain creation operation fails and no
changes are made to the SRS.
If implicit creation is used for a nameserver,
<nsnum>-Handle may not be specified for that
nameserver. Implicit host creation with a
user-supplied handle is not supported.
Contact Information
Each domain has exactly three contacts associated
with it: a technical contact, an administrative
contact, and a billing contact. Any two or more
of these may be the same contact. Each of the
three contact types is handled identically, so
for the purposes of the remainder of 3.2.3.4, the
string "<type>" may be replaced by one of
"Admin", "Tech", or "Billing".
As described below, contact information for each
contact type must either be specified as the
handle of a preexisting contact, or a contact
record must be implicitly created.
If any operation fails for any contact, the
entire domain creation operation fails, and no
changes are made to the SRS repository.
<type>-Contact-Handle
A single printable word (no whitespace),
case-insensitive.
If the value of this field begins with '=', the
value of the field is a linked contact
specification as described in 3.2.3.7. If the
value of this field does not begin with '=', the
value must be a pre-existing contact handle, in
which case the contact with that handle is
associated with the domain.
If the contact does not exist, the entire domain
creation fails. If <type>-Contact-Handle is
specified, implicit contact creation may not be
used for that contact type; specification of any
other contact information fields for that contact
type causes the operation to fail. This implies
that a specific contact handle may not be
requested as part of an implicit contact
creation.
Implicit Contact Creation
Contacts may be created implicitly by specifying
contact information in fields named by prepending
the string "<type>-Contact-" to the field names
specified in 3.2.1.2 -- 3.2.1.9.
If implicit contact creation is used for a
contact type, <type>-Contact-Handle may not be
specified for that contact type.
Fields are mandatory and subject to validity
checking as specified in 3.2.1.2 -- 3.2.1.9.
Status
This field specifies the status of the domain.
All values of this field will be stored and
treated as lower case. Currently defined values
are:
reserved
production
expired
hold
This field is mandatory. The semantic meanings
for these values are defined in the section
describing the Dispute Resolution Agent (DRA)
interface.
Linked Contact Specification
A domain creation operation can result in the
implicit creation of a number of contact records,
both as domain and host contacts. The SRS
supports the use of multiple instances of the
same implicitly created contact as part of a
domain creation; e.g., "Implicitly create a
contact as the domain technical contact, and also
use that contact as the domain administrative
contact and the host contact for nameserver
five."
This is accomplished by specifying contact
handles beginning in '=', followed by one of
"admin", "tech", "billing", "ns1", "ns2", "ns3",
... (case insensitive). When a contact handle
field is specified as one of these equivalences,
the contact whose type is the remainder of the
field value after the '=' is also used for the
specified contact.
For example, if the line "Admin-Contact-Handle:
=ns3" appears in a domain creation, whatever
contact is used as the host contact for the third
nameserver of the domain will also be used as the
administrative contact. Note that the actual
contact handle is stored in the SRS repository;
if the host contact for the third nameserver is
subsequently changed, the domain's administrative
contact will not be.
Circular references are, of course, not allowed.
Also note that "<nsnum>-Handle" (3.2.3.3.1) and
"<nsnum>-Contact-Handle" (3.2.3.3.2) are NOT
equivalent; the former is the handle of a host,
while the latter is the handle of the host's
contact.
Organization
The name of the Entity or Organization
registering the domain.
This field is mandatory.
2.2.2.4. Modify Contact
This operation is used to modify a contact record in
the SRS.
Handle
The value of this field must be a pre-existing
contact handle. This field is case-insensitive.
There is no facility for modifying a contact's
handle. All other information may be modified,
but the handle is considered unique and invariant
for the life of the contact.
This field is mandatory.
Contact Information
Any of the fields specified in 3.2.1.2 -- 3.2.1.9
may be specified here.
None of these fields are mandatory in the context
of a modify operation, except that Auth-Key must
be specified if Auth-Type is specified.
If specified, the value of a field is subject to
the same verification criteria as in 3.2.1, after
which its value replaces the previous value for
the specified attribute of the contact.
If any errors occur, the entire operation fails,
and no changes are made to the SRS repository.
2.2.2.5. Modify Host
This operation is used to modify a host record in the
SRS. It may also be used to implicitly create a new
contact record for the host as specified in
3.2.2.4.2.
Handle
This is the handle of a pre-existing host in the
SRS. This field is case insensitive.
This field is mandatory, and specifies the host
to be modified by this operation.
Host Information
Any of the fields described in 3.2.2.2 -- 3.2.2.4
may be specified here. Any or all of these
fields may be specified independently, except
that the specification of a contact handle and
the implicit creation of a new contact are
mutually exclusive as specified in 3.2.2.4.
The modification of a contact is not allowed in
the context of a host modification.
Specification of any Contact field as in
3.2.2.4.2 will be considered to be an attempt to
associate the host with a different,
newly-created contact of the specified type. The
problem of erroneous creation of new contacts due
to this is expected to be minimal, as most
requests that attempt to implicitly modify a
contact as part of a host modification will
likely be missing one or more of the fields
required for contact creation (such as
authentication information fields), causing the
entire host modification request to fail.
If any errors occur, the entire operation fails,
and no changes are made to the SRS repository.
2.2.2.6. Modify Domain
This operation is used to modify a domain record in
the SRS. It may also be used to implicitly create
new contacts or nameserver hosts for the domain, in
the manner specified in 3.2.3.
TLD, SLD
Both of these fields must match a pre-existing
domain in the SRS. These fields are
case-insensitive.
There is no facility for renaming a domain. All
other information may be modified, but the domain
name is considered unique and invariant for the
life of the domain. It is expected that a
"rename domain" be executed as a "create domain"
followed by a "remove domain".
These fields are mandatory.
Domain Information
Any of the fields specified in 3.2.3.3 -- 3.2.3.6
may be specified here. With the exceptions
documented below, any or all of these fields may
be specified independently. They will be subject
to the same verification checks as in 3.2.3, and
will then replace the old attributes of the
domain that correspond to these fields.
Implicit contact and host creation may be a part
of the domain modification operation, as
specified in 3.2.3.3.2 and 3.2.3.4.2, may be a
part of the modify domain operation.
If an error occurs, the entire domain
modification operation will fail and no changes
will be made to the SRS.
Fields may be specified independently as
described in 3.2.3.3 -- 3.2.3.6, according to the
following additional rules:
Nameservers Replaced as a List
The nameservers associated with a domain must be
replaced as a list. nameservers in a modify
domain operation must be specified sequentially
starting from 1, and the entire list of
nameservers for a domain will be replaced with
the list specified in the modify operation.
No Implicit Modification
The modification of a contact or host record
cannot be specified as an implicit part of a
domain modification request.
Specification of any explicit creation fields
from 3.2.3.3.2 or 3.2.3.4.2 will be considered to
be an attempt to associate the domain with a
different, newly-created object of the specified
type. The problem of erroneous creation of new
objects due to this is expected to be minimal, as
most requests that attempt to implicitly modify
an object as part of a domain modification will
likely be missing one or more of the fields
required for object creation, causing the entire
domain modification request to fail.
Linked Contact Specification
The linked contact specification described in
3.2.3.7 is allowed. Changes are made in order of
dependency, such that for a field entry of
"<type1>-Contact-Handle: =<type2>", the <type2>
contact would be updated before its transitive
assignment to the <type1> contact.
2.2.2.7. Remove Host
This operation removes a host from the SRS
repository. Removal of disused host records is
strongly encouraged.
Handle
A pre-existing host handle in the SRS, case
insensitive. This host is removed from the
repository.
This field is mandatory.
2.2.2.8. Remove Domain
This operation removes a domain record from the SRS
repository.
TLD, SLD
Both of these fields must match a pre-existing
domain in the SRS. These fields are
case-insensitive. Naturally, these fields
specify which domain to remove.
These fields are mandatory.
2.2.2.9. Transfer Contact
This operation transfers the registration function of
a contact from its previous registrar to the
requesting registrar.
Handle
A pre-existing contact handle in the SRS
repository, case insensitive. This contact will
be transferred to the requesting registrar.
This field is mandatory.
2.2.2.10. Transfer Host
This operation transfers the registration function of
a host from its previous registrar to the requesting
registrar.
Handle
A pre-existing host handle in the SRS repository,
case insensitive. This host will be transferred
to the requesting registrar.
This field is mandatory.
2.2.2.11. Transfer Domain
This operation transfers the registration function of
a domain from its previous registrar to the
requesting registrar.
TLD, SLD
Both of these fields must match a pre-existing
domain in the SRS. These fields are
case-insensitive. These fields specify which
domain to transfer.
These fields are mandatory.
2.2.2.12. Status
This operation allows a registrar to query the
database for the status of a transaction previously
submitted by that registrar. It is a request to the
SRS to resend the reply information of a transaction;
if the request has been completed, it will cause
another copy of the authenticated reply to the
transaction to be returned to the user.
Records of old transactions, and thus the information
required to reconstruct replies, are not guaranteed
to persist in the SRS database indefinitely. It is
anticipated that a registrar can determine the
completion of an old transaction by determining the
status of a domain through a mechanism such as whois.
This request is not valid for transaction IDs of
query requests.
The Transaction ID for which the reply is requested
is conveyed in the Transaction-ID field (3.1.3).
Since this operation is a solicitation for a resend
of a transaction reply, it does not have a
transaction ID of its own. Thus, the status
operation does not have any fields other than those
documented in 3.1.
2.2.2.13. Query
This operation allows a registrar to request a list
of its past requests that satisfy a Boolean
predicate. A list of all transaction ID's of
requests submitted by the querying registrar in the
SRS database's stored history that satisfy all of the
specified clauses is returned.
History records will not be preserved online in the
SRS database indefinitely. It is expected that a
registrar can deduce the results of a sufficiently
old transaction by a mechanism such as whois.
All of the fields documented in below are optional.
To be included in the returned list of transaction
ID's, a request must satisfy all predicates
specified.
Request-State
This field is a set of one or more
case-insensitive keywords separated by
whitespace. Requests whose state matches one of
the keywords as of the execution of the query
satisfy this clause.
Valid keywords are the request states listed in
4.2.2.1.
Submitted-Since
This field is a UTC date and time, as specified
in 2.3.2. Requests queued for processing after
the specified time satisfy this clause.
Submitted-Before
This field is a UTC date and time, as specified
in 2.3.2. Requests queued for processing before
the specified time satisfy this clause.
Completed-Since
This field is a UTC date and time, as specified
in 2.3.2. Requests whose processing completed
after the specified time satisfy this clause.
Completed-Before
This field is a UTC date and time, as specified
in 2.3.2. Requests whose processing completed
before the specified time satisfy this clause.
2.2.2.14. Domain Inquiry
Registrars may inquire all the SRS database state of
a domain. This is accomplished via the Inquire
Domain Request. This is a synchronous request.
TLD, SLD
Both of these fields must match a pre-existing
domain in the SRS. These fields are
case-insensitive and mandatory.
2.2.2.15. Contact Inquiry
Related to domain inquiry, registrars have the
ability to resolve contact handles to keyword-value
pairs defining that contact.
This is a synchronous request.
Handle
The value of this field must be a pre-existing
contact handle.
This field is case-insensitive and mandatory.
2.2.2.16. Host Inquiry
Related to the domain inquiry, registrars have the
ability to resolve host handles to keyword-value
pairs defining that host. A Contact-Handle keyword
is supplied by the registrar and the SRS replies
accordingly. This is a synchronous request.
Handle
This is the handle of a pre-existing host in the
SRS. This field is case-insensitive and
mandatory.
2.2.2.17. Renew Domain
This operation adds a system-defined interval to the
domain's expiration date in the SRS repository.
TLD, SLD
Both of these fields must match a pre-existing
domain in the SRS. These fields are
case-insensitive. Naturally, these fields
specify which domain to renew.
These fields are mandatory.
Any attempt to renew a domain outside of the
registries policy-defined threshold for renewal
will cause the request to fail.
2.3. Responses
This section documents the various fields that may appear in
the server's responses to an operation.
2.3.1. Generic Fields
The following fields appear in order in all responses.
2.3.1.1. Registrar-ID
This is the registrar ID supplied in the request that
elicited this response.
This field will not be supplied in the event of a
request parse error occurring before the registrar ID
could be determined. However, if the wireline
protocol is used to communicate with the SRS, such a
"short" reply will be synchronous as defined by the
wireline protocol.
2.3.1.2. Transaction-ID
This is the transaction ID supplied in the request
that elicited this response.
This field will not be supplied in the event of a
request parse error occurring before the transaction
ID could be determined. However, if the wireline
protocol is used to communicate with the SRS, such a
"short" reply will be synchronous as defined by the
wireline protocol.
2.3.1.3. Response-Type
This field designates the type of response.
Currently defined values are:
ack
reply
2.3.1.4. Resolver-Sequence
The sequence number of the resolution of this
request. Fully explained in the FAIRNESS
DESCRIPTION document.
2.3.2. Response-specific fields
This section documents fields that appear in specific
response types.
2.3.2.1. Ack
This is an acknowledgement of a request and a
confirmation that it has been queued for processing.
Estimated-Completion
This is a UTC date and time, as specified in
2.3.2. It represents an estimate by the SRS as
to the completion time of the request. It is by
no means a commitment.
This field may or may not be returned.
2.3.2.2. Reply
This is the reply to a request, returned by the SRS
either on completion of a request or in response to a
status request by the client.
Request-State
This describes the current state of the request
in the SRS server. Currently defined values are:
pending
in-process
succeeded
failed
The success or failure of the operation is
authoritatively described by the content of this
field, regardless of the content of any other
field in the reply (including the Error-Code
field).
This field will be returned for all replies.
Error-Code
This is the decimal ASCII representation of a
number between -2^31 and 2^31, exclusive, that
specifically describes any errors or exceptions
that occurred during request processing.
Defined values for this field are described in
section 5 of this document. Note that an error
code may be returned with any value of the
Request-State field.
This field will only be returned in the event of
an error or exception.
Error-Text
This is a single line of ASCII text that more
specifically describes any errors that occurred.
This field will only be returned if there is an
error or exception for which the SRS can supply
meaningful additional information.
Contact-Handle
This field is a single printable word (no
whitespace). It specifies the handle of a
contact that was created with a Create Contact
(3.2.1) request, or the new contact of a host,
either implicitly created or explicitly
referenced as part of a Create or Modify Host
operation (3.2.2 or 3.2.5).
This field is only returned for a successful
Create Contact or Create or Modify Host request.
Host-Handle
This field is a single printable word (no
whitespace). It specifies the handle of a host
that was created with a Create Host request
(3.2.2).
This field is only returned for a successful
Create Host request.
<type>-Contact-Handle
These fields are single printable words (no
whitespace). <type> can be one of:
admin
tech
billing
ns1
ns2
ns3
etc
These fields specify the handles of all contacts
newly associated with a domain, whether
implicitly created or explicitly referenced, as
part of a Create or Modify Domain request (3.2.3
or 3.2.6).
Each of these fields is returned in the event of
the successful association of a contact with a
domain for the corresponding contact type.
<nsnum>-Handle
These fields are single printable words (no
whitespace). <nsnum> is "NS" concatenated with
the ASCII representation of a nameserver's
ordinal number in a domain creation or
modification. They specify the handles of any
hosts that are newly associated with a domain,
whether implicitly created or explicitly
referenced, as part of a Create or Modify Domain
request.
Each of these fields is returned in the event of
the successful association of the specified host
with the domain.
Transaction-IDs
This field is a list of zero or more Transaction
ID's for requests that satisfy the predicate of a
Query request (3.2.13), separated by whitespace.
The length of the value of this field will exceed
neither 1,024 transaction ID's nor 30,000 octets.
To discourage the submission of large query
requests, query requests whose result set
violates the size restriction will fail without
returning any ID's.
This field will only be returned for a successful
query request.
Expiration-Date
This field is returned by a successful renew
domain request and denotes the new expiration
date.
2.4. Error Conditions
This section enumerates the error conditions that can be
returned in the Error-Code field. An error is expressed as
the ASCII representation of a positive decimal number less
than 2^31. The return of an error may not indicate the
failure of a request; the request-status field is the
authoritative indicator of a request's success or failure.
2.4.1. Error categories
SRS-generated error codes are six-digit positive decimal
numbers. They are divided into broad categories by their
leading two digits. The first digit describes the
severity of the error, while the second describes its
general category:
First digit (10^5):
1 - Informationals
2 - Warnings
3 - Transient errors
4 - Errors (typically causing operation failure)
Second digit (10^4):
1 - Transport errors
2 - Request syntax errors
3 - Request semantic errors
4 - Authentication errors
9 - SRS internal errors
2.4.2. Specific errors
[TBD]
2.5. Notes
2.5.1. Field checking
Arguably, statements of the form "the following checking
will not be performed" should not be a part of the
protocol specification, as they might be taken as a
guarantee that an incorrect field value will not cause an
operation to fail. Rather, they are intended as a
warning to the SRS client developer that the SRS server
will not necessarily perform these checks; no _guarantee_
is made that more extensive validity checking will not be
performed.
2.5.2. Remove Contact
Do we want to implement a "remove contact" operation?
Right now, we don't, in order to ease tracking of history
-- to reconstruct the sequence of events associated with
a domain, we don't have to reconstruct possibly defunct
contact information as well. Yes, this does mean the
contact table is growing monotonically...
2.5.3. Policy Decisions
Several items in this document reflect policy decisions
that must be made by the registry, and are specified for
discussion purposes only. Specifically:
Limits and defaults on domain expiration
date are registry policy decisions
Limits on the number of nameservers in a
domain
Do we want to only allow one handle per
nameserver IP address? It'd be easy to do...
2.5.4. More sophisticated syntax
A slightly more sophisticated grammar that expresses the
relationships between objects might be cleaner. For
example, this syntax doesn't express the nesting of
implicit host and contact creation very well.
2.5.5. Host leaks
When domains are deleted or hosts modified, it is not
clear that disused host records will be cleaned up in any
more than a small minority of cases.
2.5.6. Handle namespace
In order to ensure transferability of information between
SRS's, steps should be taken to ensure that the
namespaces each SRS uses for generated names are
disjoint.
3. SRS TRANSPORT
3.1. SRS over Email
This section of the document describes the details of the
transport of SRS payloads over email. It is assumed that the
reader is familiar with MIME messages and the use of PGP
within the MIME context. The SRS Payload Specification
defines what is contained within the email message itself.
All SRS communications are encapsulated within multipart MIME
messages. Each part of a multipart may in turn contain
another multi-part, as needed. The outermost layer is signed
by the originator of the message using PGP.
3.1.1. Encapsulation and Exchange
A single SRS request is contained within a single email
message.
3.1.1.1. Reply-To
Acks and Replies are sent to the Reply-To: RFC822
Header of the email request. If there is no
Reply-To:, From: is used.
3.1.1.2. Selecting a server
A destination email address is formed by taking the
TLD, appending .nic.info, and prepending reg@fe.
Thus, to register a name in .web, send email to
reg@fe.web.nic.info.
3.1.2. Errors
Three interesting failure modes exist: lost requests,
lost acks, and lost replies. Most of the error recovery
hinges on the idempotence of operations.
3.1.2.1. Lost Requests
[TBD]
3.1.2.2. Lost Acks
[TBD]
3.1.2.3. Lost Replies
[TBD]
3.1.3. Notes
Content-Encoding is currently totally ignored;
eventually, some localization may be possible.
3.2. SRS over TCP
A registrar may communicate with the SRS over a persistent
TCP connection.
Encapsulation and Exchange
A registrar sends a stream of MIME-encapsulated
independent requests over the connection, and reads
replies and acks on the reverse channel.
These requests differ from email-based MIME in that
nothing may follow the trailing delimiter of a message;
more specifically, the next thing immediately following a
ending boundary is the Content-Type of the next message.
This is because MIME encapsulation is used to detect the
boundaries of requests.
A request is outstanding while it has not been acked by
the SRS. If there is an outstanding request, another may
not be sent.
3.2.1. Connection
A connection is established on a well-known port on one
of a collection of fronted machines that serve
registrations for a TLD. These machines all have names
of the form: feXX.TLD.nic.info, where XX is a two digit
ASCII decimal number, and TLD is the appropriate Top
Level Domain.
It is guaranteed that XX starts at 00 and there are no
unresolved names between that and the highest numbered
host. This can be used to load balance as follows: look
up the IP address of each host in turn, starting at 00.
as soon as the first one fails, the total number of
fronted machines has been determined. Select one at
random, and attempt to connect to it. Repeat until a
connection is accepted.
The SRS operator can add fronted machines as needed,
without notifying any registrar. The SRS operator need
only update the TLD.nic.info zone when adding or deleting
machines.
3.2.2. Errors
Most server or client errors are handled by
disconnection, establishing known correction state,
querying the state of any pending request, reissuing lost
requests, and soliciting undelivered replies.
Disconnection
A server-initiated disconnection is indicative of a
fronted failure. Any unacked requests should be
resent to a new fronted connection. All pending
replies should be solicited by sending a query
followed by a status command for each completed
request.
A client-initiated disconnection may result in a
pending request being processed, with the ack being
dropped. The unknown state of the request should be
resolved by issuing a query operation against the
transaction id. If the operation is pending or
completed, the request should not be reissued.
4. SECURITY CONSIDERATIONS
This specification provides for database access and modification.
Affected data bases are an integral part of Internet
infrastructure. Hence, misbehavior or compromise of the protocol
or its operation can have considerable impact on Internet
operations.
Other discussions concerning trust and security occur elsewhere
in the specification.
This section provides mechanisms, to protect against these
dangers. In particular, this section specifies the SRS security
policies as they relate to authentication and object
modification.
4.1. Definitions
4.1.1. Contact
A contact is a person who is associated with one or more
objects in the SRS. Each contact has a unique contact
handle, assigned by the SRS; an authentication type, and
an Authentication key.
4.1.2. Key
A key is a pair of data objects, one kept secret by the
signer, and one widely published, including to the SRS.
Keys may be of several sizes, the larger keys more
difficult to crack, and more expensive in time to use.
It is suggested that default size (1024 DSS/2048
Diffie-Hellman) keys be used.
4.1.3. Owner
Every object in the SRS has a set of associated contacts.
Any of these contacts may initiate modification of the
object.
4.1.4. PGP
Pretty Good Privacy software, version 5.0i. This
software is resident outside of the United States, and
has no export issues. It is recommended that the SRS not
use PGP to encrypt, nor should it use the IDEA block
cypher. It is expected that each registrar would license
PGP5.0 from PGP incorporated or it's agents for
commercial use. When using PGP authentication, the
entire PGP public key is sent to the SRS and is stored
with the contact.
4.1.5. Crypt
The US National Bureau of Standards has defined a Data
Encryption Standard, DES. Unix systems have used a
uniform method of scrambling plaintext passwords into a
non-invertable hash using DES. This uniform method is
available both inside and outside the US, and so has no
export control issues.
When using Crypt authentication, user plaintext is
encrypted, as for unix crypt(3), using a salt of '00',
and the cyphertext is sent to the SRS and stored with the
contact.
Crypt style authentication is only valid for
non-registrar contacts.
4.2. Key Management
PGP has no notion of key certifying authorities. Public keys
are validated by a web of trust model.
4.2.1. Registrar Keys
The SRS requires each registrar to have a master key and
a set of agent keys. The master registrar key is
communicated to the SRS by the registry, and agent keys
are communicated to the SRS by the registrar using the
master key.
4.2.2. Registry and Dispute Resolution Agency Keys
Registries and Dispute Resolution Agencies have identical
key infrastructure to registrars. Both entities may
issue modify registrar requests to manipulate its set of
associated agent contacts. Special handles are defined
for these entities.
4.2.3. Master Key Compromise
It may occur that a registrar loses its master key, or
some person illicitly acquires the registrar's master
key. These are different cases, and have different
methods of recovery.
4.2.3.1. Lost Master Key
Typically, this is a lost passphrase. Without this
passphrase, the encrypted private key stored on the
registrar's machine can never be decrypted for use.
The registrar generates a new key, and communicates
it to the registry. The registry validates the new
key, to prevent human engineering, and sends A modify
contact request to the SRS, using the master contact
handle for that registrar. Operations proceed using
the new key. No database recovery is needed.
4.2.3.2. Stolen Master Key
A stolen key can be used to forge requests to the
SRS. When a stolen key is detected, a registrar
should immediately issue a modify contact request for
the master contact handle, setting the authentication
type to none. This will disable all further
operations on that registrar object until the
registrar is reactivated. The registrar notifies the
registry, and the registry notifies the SRS that a
registrar master key has been stolen. The SRS
operator will generate a report showing activity that
occurred using that key. All forged requests need to
be manually identified by the registrar, and the
requests need to be undone.
4.2.4. Agent Key Compromise
A registrar agent key may be lost or stolen as well.
4.2.4.1. Agent Key Loss
Agent contacts may be freely enabled and disabled by
the registrar without the registry's involvement.
The registrar should create a new contact, and set
that contact as a valid agent using a modify
registrar command.
4.2.4.2. Agent Key Theft
Stolen Agent keys should be immediately disabled
using a modify registrar command. The SRS operator
must be notified, and any illicit requests issued
using the stolen key must be rolled back, as for a
stolen master key.
4.2.4.3. User Key Compromise
If all user keys associated with a domain are lost,
the domain must be manually reauthenticated. This
can be achieved by using a variety of non-definitive
credentials to establish domain identity. Possession
of a registration certificate, a cancelled check to a
registrar, a copy successfully responding to the
email address in a contact, being located at the
listed phone number, faxing a drivers license to the
SRS, etc. When sufficiently authenticated, a domain
holder provides a new PGP5 key to the SRS, and the
SRS manually updates the relevant contact.
4.3. Authentication Schemes
4.3.1. PGP Signatures
Mime supports message authentication via its
multipart/signed data type. A cryptographic hash is made
of a message, and that hash is encrypted with the
signer's private key. The resulting signature is
packaged with the message. The SRS can detect both
message corruption and/or unauthorized requests using
this signature.
4.3.2. Crypt Authentication
A request using crypt authentication must have a valid
Signer-Handle value, and a Authenticating-Key value that
exactly matches the stored key.
A registrar should not store either the cleartext or the
cyphertext of the key, as this will allow the registrar
to forge requests for any objects protected by that
contact.
Similarly, a third party listening to the communication
between the user and the registrar can forge requests, so
a secure communications channel, such as SSL, should be
used if possible between the user and the registrar.
4.4. Notes
Mail-from authentication is not supported. Many attacks on
mail-from type authentication schemes are known, and offer no
serious security.
Crypt is basically registrar-based authentication.
5. ACKNOWLEDGEMENTS
This draft is heavily dependent on documentation provided by
Emergent Corporation as part of their contract with CORE. We
thank Curt Meyer and his colleagues at Emergent for the clear and
precise work they have done. ...
6. AUTHORS' ADDRESSES
K. Crispin
Songbird
6064 Skyfarm Drive
Castro Valley, CA 94552 USA
+1 510-886-7410
kent@songbird.com
D. Crocker
Brandenburg Consulting
675 Spruce Drive Sunnyvale, CA 94086 USA
+1 408 246 8253
dcrocker@brandenburg.com
R. Gaetano
roberto.gaetano@etsi.fr
S. Langenbach
svl@nrw.net
7. REFERENCES
...
8. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (1998). 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.
draft-crispin-srs-00-txt Shared Registry System Protocol November, 1998
Expires in six months
