Network Working Group C. Huitema/INRIA Internet Draft P-A. Pays/INRIA December 1993 A. Zahm/TS-E3X Expiration Date: June 1994 A. Woermann/TS-E3X Simple Object Look-up protocol (SOLO) 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. 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 "work- ing draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. [Huitema et alii] [Page 1] Internet Draft SOLO December 1993 Abstract We present here a simple access protocol to a "white page" service. This protocol is based on the experience acquired in several X.500 based "white page" pilots, and builds upon such developments as the "user friendly naming" notation or the "centroids" concept developped in the "whois++" project. Although largely inspired by the X.500 protocol, SOLO does not try fol- low the X.500 model. Designing a SOLO front-end to an X.500 server is very easy, but the SOLO internetworking is not based on X.500 -- the navigation part is based on the WHOIS++ centroids. In fact, one can as well design a SOLO front-end to a WHOIS server, and only minor efforts are needed for redesigning a "finger" daemon to provide the SOLO ser- vice. Conversely, the SOLO service is powerful enough to make gatewaying between X.500 access protocols and SOLO easy. The first section of this memo present the basic SOLO protocol. The second section presents the methods which are used for "networking" SOLO servers. The third section is a formal definition of the SOLO protocol. Section 4 list the various SOLO information messages. Section 5 addresses the security implications of providing a SOLO service. 1. Presentation of the SOLO protocol: The SOLO protocol consists of two main operations: a simple look-up operation that enables clients to request information on a name object, and a "zone transfer" operation used by index handlers. These operations are carried upon TCP-IP connections; the requests and results use a simple text format. Three additional commands are defined, i.e. a "signal" to notify the need to poll a server, a "reset" to abort an ongoing operation, and a "quit" to close the connection. 1.1. A basic example: In order to request information on an object, a client will set up a TCP-IP connection towards the server. Servers will be awaiting requests on port . After establishing the [Huitema et alii] [Page 2] Internet Draft SOLO December 1993 connection, the client will send a request of the form: SOLO ? CN, O, OU, Phone, Email; In this line, SOLO is the command name (other commands are for example QUIT or POLL). It is followed by the "name" of the object, which is expressed using the "user friendly name" con- ventions, by a question mark, and by a list of "attribute names", using the acronyms defined for the white page pilot. If the server was able to find the information, it will send a "matched" reply, followed by the values of the attributes, end- ing by a dot on a line by itself, e.g.: 500 Matches: CN: Christian Huitema OU: Sophia, Sophia-Antipolis, "Unite de recherche de Sophia Antipolis" O: INRIA, "INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET AUTOMATIQUE" Phone: +33 93 65 77 77 Email: Christian.Huitema@sophia.inria.fr . Indeed, several errors could have occured, for example if the name was ambiguous or non existent, or if the server did not hold the information locally. After receiving the response, the client has the choice to send another command, e.g. to get information on another object, or to close the connection. 1.2. Name errors SOLO servers distinguish three kinds of name errors, ambiguous specifications, incorrect specifications and over specifica- tions. They reply to these errors by an appropriate error mes- sage, optionally followed by one or several "hints", i.e. sug- gested references. The following dialogue is an example of [Huitema et alii] [Page 3] Internet Draft SOLO December 1993 ambiguous reference: SOLO ? Phone, Email; 201-Ambiguous name: 301-Partial Match: 400-Suggestion: 400 Suggestion: There were several "Martin" at INRIA, and the server just pro- vide the names of all entries that matched the request. The next dialogue is an example of incorrect reference: SOLO ? Email; 202-No such name: 301-Partial Match : 400-Suggestion: 400 Suggestion: Note that the server applied here a local strategy to derive possible matches -- it tried a "phonetic" match on the name token "Huttema". Also note the presence in both examples of a "partial match" information line: it signals that the upper com- ponents of the name assertion, in this case , were exactly matched by the server and correspond to the dis- tinguished name . Note that there could be examples where intermediate components are ambiguous, for example: SOLO ? Email; 201-Ambiguous name: 400-Suggestion: 400-Suggestion: 400 Suggestion: In that case, the suggestion contains potential candidates for "continuation" queries. The server can use two methods to con- struct the "suggested name", i.e.: [Huitema et alii] [Page 4] Internet Draft SOLO December 1993 (1) replace the "upper part" components of the initial query by a "distinguished" value, (2) provide the "distinguished name" of candidate entries. In the first case, the suggested name is not necessarily a "dis- tinguished" name, but merely a hint that can be used in a further query. Over specification occurs when a requestor present a set of nam- ing attributes, some of which cannot be matched: SOLO ? Email; 203-Over specified name: 301-Partial Match: 400 Suggestion: 1.3. Partial name matches and redirections A SOLO server may not always be able to fully match a query. There will be cases however where the local server can provide some "hint" on the resolution of some of the "name parts". For example, a server that knows that the company E3X has recently changed names may be able to respond to a query by a partial match indication: SOLO ? Email; 301-Partial Match: 400 Suggestion: In the previous exchange, the SOLO server did not provide an indication of where to submit the next query. It could indeed have provided such information through a "suggested server" mes- sage: SOLO ? Email; 301-Partial-Match: 302-Suggested-server: mitsou.inria.fr 302-Suggested-server: osi.e3x.fr 400 Suggestion: [Huitema et alii] [Page 5] Internet Draft SOLO December 1993 Note that we have suggested here two different servers. The client will presumably chose one based on local information. 1.4. Absolute matches: There are some cases where the SOLO user wants to completely specify the name of the requested object, without leaving any interpretation possibility to the server. This is specified by a particular format of the SOLO request: SOLO ! Email; The differences between this format and a standard request are the following: (1) The name should be fully specified. The separator between the name and the list of attributes is an exclamation mark (!) instead of a question mark (?). The SOLO server can only respond positively to this query if it finds an entry that exactly matches the purported name. 1.5. Attributes and Universal Resource Locators (URL) It is often impractical for a server to provide a complete attribute value: some objects like photographies or voice seg- ments are too bulky to be transmitted easily. Others may not be available on the SOLO server itself. In these cases, the SOLO server may elect to return a pointer to the value, in the form of an "Universal Resource Locator", instead of the value itself. The presence of an URL in the value field is signalled by a placing an hyphen in front of the attribute type, as in: SOLO ? Photo, Email; 500 Matches: -Photo: "http://zenon.inria.fr:2220/peoples/huitema/photo" Email: Christian.Huitema@sophia.inria.fr . [Huitema et alii] [Page 6] Internet Draft SOLO December 1993 In fact, some clients may want to force this facility, in order to be able to locate an attribute without having to actually receive the data. They can achieve this by prepending an hyphen in front of the attribute type in their request, as in: SOLO ? -Email, -Photo; 500 Matches: -Photo: "httl://zenon.inria.fr:2220/peoples/huitema/photo" -Email: "solo://mitsou.inria.fr:8888/!Email" . Note the special form of universal resource locator used for the "Email" attribute: this is the normal way to designate a resource reachable through within a SOLO server. Clients cannot force SOLO servers to return a value instead of the URL: this could be outside of the server's capabilities. However, servers should always return the full attribute value when this is available. 1.6. Aliases and alternate values: Some SOLO servers will be implemented as access points to an X.500 service. It is important that the SOLO clients recognize some oddities which can result from the X.500 support of aliases and alternate values, e.g.: SOLO ?Email; 500 Name matches: Email: "bolot@mitsou.inria.fr" SOLO ?Email; 500 Name matches: Email: "s.mendes@osi.e3x.fr" . In the first case, the first name specification "Jean" was matched by one of the multiple values declared for the first name attribute, although the common name refers to the dis- tinguished value "Jean-Chrysostome". In the second case, the [Huitema et alii] [Page 7] Internet Draft SOLO December 1993 entry for "Suzan Mendes" was an alias, pointing to her real entry in the X.500 server of TS-E3X. In fact, X.500 is probably not the only name service that pro- vides aliasing or alternate names. We are likely to observe the same "oddities" with many data bases. 1.7. Filters and substrings: There are cases where the clients will not be able to completely specify the name of the object they are searching. The SOLO pro- tocol allow these clients to enter "loose" specifications by means of substrings or filter. Any name part can be replaced by a substring specification, using the special character "*", as in for example: SOLO ? Email; 500 Matches: Email: huitema@sophia.inria.fr . As implied by well established conventions, the "*" can be matched by any sequence of characters. The "User Friendly Name" syntax allows users to combine several "attribute assertions" in a name part, using the "+" character as a delimiter, e.g.: SOLO ? Email; The "+" character is in fact equivalent to an "AND" operator. The SOLO syntax extends this possibility by also allowing the character "|" as an OR operator, e.g.: SOLO ? Email; Which can be matched by either value. Indeed, the "+" and "|" can be combined, in which case "natural" precedence rules apply, [Huitema et alii] [Page 8] Internet Draft SOLO December 1993 i.e. the AND operation takes precedence over the OR. For exam- ple, the previous specification is equivalent to: SOLO ?Email; Experts will note that this notation is more restrictive than the full set of boolean combinations allowed by X.500 filters. This restriction is based on the desire to keep SOLO simple, and also supported by the substantial experience acquired by the authors when deploying X.500 systems. We believe that the pro- posed compromize is just right. Experts will also remember that the "User Friendly Name" specif- ication imposes a restriction on the use of the "+" delimiter: when multiple assertions are stated in a name part, then they should be explicitely typed. This restriction does not apply in SOLO. The following command: SOLO ? Email; is explicitely allowed. 1.8. Limiting the size of the output: The filters, the substring notation, or even the use of partial matches, may enable the user to specify extremely fuzzy names. Such fuzzy names can potentially be matched by a very large number of entries. Sending very long lists of "suggested" names is inadequate for several reasons: o it may be a very inefficient use of network resources, o it may impose unexpected constraints to the user interface which is not necessarily rigged to handle long lists, o it may also be a privacy violation, as it would allow intruders to easily obtain complete listings of an [Huitema et alii] [Page 9] Internet Draft SOLO December 1993 organization's personal. SOLO servers are allowed to limit the number of names which can be returned by a single command. A limited set of result will be signaled by a specific error report: SOLO ? Email; 201-Ambiguous name: 400-Suggestion: 400-Suggestion: 204 Too many names to list them all. In fact, the privacy argument is so compelling that SOLO servers are encouraged to impose a relatively low limit, e.g. not larger than 8. The precise value of this limit should be set by the local administrator, as well as a policy choice to display a random set of suggested names first and then the error message, or to not display any name at all if the command is too fuzzy. 2. Networking white page informations: The SOLO server may want to maintain "indexing" information. This is done according to the "centroid" model. The informations held by a given server are summarized in a centroid, i.e. a gigantic entry that contain for all indexed attribute types the list of attribute values found in any of the data base entries. 2.1. Using the index request: In order to obtain the indexing information belonging to a server, a client or another server may set up a TCP connection to the server using the port, then send the index com- mand: POLL S, OU, O, L, C; Where POLL is the command, <> an empty name specification, and where the rest of the command just lists the attributes for which indexing information is required. A typical response will be: [Huitema et alii] [Page 10] Internet Draft SOLO December 1993 501 Sending indexes. S: Name1, Name2, Name3, Name4, name5 OU: Unit1, Unit2 O: The local org name C: XX . Errors can indeed occur, e.g. if the server is unwilling to send the requested information. A special form of the command allows the clients to obtain the list of attributes managed by the server, i.e. by specifying an empty list of attributes. POLL ; 502 Providing attribute list C, L, O, OU, S, G . Indexing servers will keep this information and organize it in tables in order to manage navigation. In some cases, the server may be unwilling to provide a full listing: for example, providing the names of all the employees of a company may be perceived as a serious security violation. In this case, the server may elect to replace the attribute values by a simple "star": POLL S, OU, O, L, C; 501 Sending indexes. S: * OU: Unit1, Unit2 O: The local org name C: XX . This procedure may also be used when listing all values would be unpractical. [Huitema et alii] [Page 11] Internet Draft SOLO December 1993 2.2. Signalling secondary servers In order to set up or maintain the network of SOLO servers, a POLL command is not sufficient: the index servers have no way to guess that a new server has becomed operational, or that a remote data base has been updated. The SGNL command allows remote servers to "signal" their existence. More precisely, it allows administrators to notify the presence of remote servers, as in: SGNL mitsou.inria.fr 403 Will poll: mitsou.inria.fr Where an administrator signalled the need to poll the server "mitsou.inria.fr", and where the index server responded that he scheduled the emission of a POLL command. There can indeed be cases where the server will not schedule this emission, such as: SGNL matso.inrja.fr 111 No such host: matso.inrja.fr SGNL felix.inria.fr 112 No SOLO server on host: matso.inrja.fr SGNL tom.inria.fr 113 Unwilling to poll: matso.inrja.fr Note that this simple "announce message" was prefered to a more radical transaction where the remote server will take the ini- tiative to download its indexing data in the local server for the following reasons: o we want to allow administrators to use a client interface to signal the need to poll. o polling the servers and fetching the data is simpler to organize, as the data are naturally available. o pushing the data to an unprepared index server would be distateful, as the recipient is not necessarily ready to receive. [Huitema et alii] [Page 12] Internet Draft SOLO December 1993 A similar problem was analyzed in the WHOIS++ effort. 2.3. Relaying of queries SOLO servers which cannot fully solve a query have two choices. They may simply send back the "partial matches" and/or "sug- gested servers" informations described in section 1. But they may also decide to immediately relay the query towards one or several of the suggested servers. When doing so, the server will forward the query using the SOLO protocol, then send the result back to the user. The server which takes the decision to relay a query may chose one of the possible servers, or try several of them and con- struct a response by merging the various results. Whether one or several server are tested, whether they are tested in parallel or in sequence, and how the answer is constructed is fully a local decision: we do not believe that we have acquired enough experience to write down a mandatory recommendation. However, it is obvious that some indication of the decision, and in particu- lar some indication of the source of the data, should be given back to the user. This is done through a specific information message, indicating the decision to relay, as in the following example: SOLO ? Email; 301-Partial-Match: 302-Suggested-server: mitsou.inria.fr 302-Suggested-server: osi.e3x.fr 402-Relaying: mitsou.inria.fr 500 Matches: Email: woermann@osi.e3x.fr . The "relaying" information shows the request that was deduced from the original query, as well as the name of the server to which this request was relayed. It is followed by the messages received from the this server. [Huitema et alii] [Page 13] Internet Draft SOLO December 1993 As relayed commands can be further relayed, it is important to include some protection against loops in the protocol. This is achieved by inserting an optional "count of relays" between the SOLO request code and the request itself, as in: SOLO 1 ? Email; SOLO servers should increment the count of relay when relaying a request. They should never relay a request where the count as already reached a value equal to 8, or larger. An absent count is equivalent to a count of zero. 2.4. Use of caches: The experience has showed that name queries tend to be repeti- tive, and that a "working set" effect can be efficiently exploited. It is thus highly desirable that servers exploit this working set effect by keeping a cache of the "most frequent" requests. There are three types of information that can be cached by the SOLO: the full or partial name matches, the binding between names and servers, and the attribute values. Full matches are obtained through the "Matches" information lines (code 500). Partial matches are obtained by the similarly named information lines (code 301). In both cases, the cache entry will associate a name request to the matched value. Server suggestions are obtained through the "Suggested-server" lines (code 302). The cache entry will associate a name to one or several suggested servers. Attribute values are obtained as a result of successfull queries. Servers should be careful to time out cache entries after a rea- sonable duration, so as to avoid keeping aged information alive. It is suggested to avoid keeping any cache entry more than a [Huitema et alii] [Page 14] Internet Draft SOLO December 1993 day. 2.5. Networking with other technologies: In some cases, SOLO server will be able to determine that the requested object cannot be accessed through the SOLO service, but could be obtained using another technology, e.g. whois, finger or X.500. They can pass this information through the "suggested service" command, e.g.: SOLO ? Phone; 301-Partial match: 401-S-service: x500://cs.ucl.ac.uk:107/ 401 S-service: finger://cs.ucl.ac.uk:79/Baker The end of the code 401 line carries an "universal resource locator". How this information is acquired is outside the scope of this memo. 2.6. Stacking multiple requests: The SOLO protocol follows a very simple client/server model. Clients ask questions, and servers reply by a list of informa- tions. In some cases, clients may want to send several requests in one session. They normally do so by sending one question at a time, waiting for an answer, then proceeding to the next ques- tion. Clients may however send further commands on the TCP connection without waiting for the answer to the previous one. 3. Protocol specification: 3.1. The format of a request: All requests of the SOLO protocol start by a four letter request code, e.g. SOLO, POLL, SGNL, RSET, QUIT. The codes can be [Huitema et alii] [Page 15] Internet Draft SOLO December 1993 expressed in upper or lower cases, or a combination of both. In the case of the SOLO request, the command includes: (1) a variable number of spacing characters (spaces or tabs). (2) an optional "count of relays" indicator, encoded using one decimal digit, followed if present by a variable number of spacing characters. (3) the name of the requested object, enclosed within angle brackets. (4) a variable number of spacing characters (spaces or tabs). (5) a precision specifier, which can be either a question mark (?) or an exclamation mark (!). (6) a list of attributes, terminated by a semicolon (;). In the case of the POLL request, the command includes: (1) a variable number of spacing characters (spaces or tabs). (2) a list of attributes, terminated by a semicolon (;). lp In the case of the SGNL request, the command includes: (3) a variable number of spacing characters (spaces or tabs). (4) the domain name of the server that should be polled. The RSET and QUIT request don't contain any information after the command code. All commands are terminated by an "end of line" mark, composed of the two characters "carriage return" and "line feed". [Huitema et alii] [Page 16] Internet Draft SOLO December 1993 3.2. The format of the replies: The replies sent by the SOLO servers are always composed of one of several information lines, followed in some cases by a data line. The information lines are always composed of: (1) A three digit information code, (2) A continuation character, i.e. a space character if this is the last information line or an hyphen otherwise, (3) A free form text composed of letters, white spaces and digits. If the line does not contain additional information, the free form text is terminated by a dot(.). If it contains additional information, the free text is followed by a semi-colon (:) and the information. This information is composed of a name specifi- cation enclosed in angle brackets, optionally followed by another name enclosed in angle brackets, for partial match reports, or the domain name of a suggested server. In one case (code 401), the information is composed of an "universal resource locator"; in a few other (111, 112, 113, 403), the information consists solely of a "domain name". All information lines are terminated by an "end of line" mark, composed of the two characters "carriage return" and "line feed". When the first digit of the last information line has the value "5", this line is followed by a list of attribute values. 3.3. Format of name specifications: Name specifications occur in the SOLO request and in several error messages. Names are formatted according to the rules specified in RFC-1485 (string representation of distinguished [Huitema et alii] [Page 17] Internet Draft SOLO December 1993 names)... 3.4. Format of attribute lists: Attribute lists are present in the SOLO and POLL requests. Attribute lists are composed of attribute names separated by commas (,). An arbitrary number of spacing characters (space, tab) can be inserted around the attribute names. The attribute list is always terminated by a semi-colon. An attribute list may be empty. The attribute type can be preceded by an hyphen to indicate, within the POLL command, that pointers (URL) are requested instead of values. 3.5. List of attribute values: A list of attribute values is composed of several attribute values. Each attribute value is encoded of one or several lines of texts; all lines of text are terminated by a carriage return and a line feed. The list is terminated by a line containing a single dot character. The list may be empty, i.e. it may be the case that the dot line is the only line in it. The first line of an attribute value starts by the encoding of the attribute type, followed by a colon. All other lines should start by one or several spacing characters (space or tab). Each line contains one or several values, encoded according to the rules specified in RFC-1488 (String representation of standard attribute syntaxes), and separated from the following value by a comma and an arbitrary number of linear spaces. Within the values returned by the POLL command, the attribute type can be optionally preceded by an hyphen. In this case, the values returned are universal resource locators, instead of actual values. [Huitema et alii] [Page 18] Internet Draft SOLO December 1993 3.6. Attribute names: Attribute names are encountered in name specifications, in attribute lists and in attribute values. The attribute names can be: o simple keywords, as defined in RFC-1488 (String representa- tion of standard attribute syntaxes) or in the Whois++ lookup service. o text renditions of object identifiers. Official keywords should be prefered whenever possible. The fol- lowing table list a set of key words which are expected to be recognized by SOLO servers, as well as their WHOIS and "User Friendly Name" equivalents: ________________________________________________ | Whois (RFC-1274) | RFC-1485 | SOLO | |_______________________|____________|__________| | Name (CommonName) | CN | CN | | (Surname) | S | S | | (First name) | | First | | (Country) | C | C | | (StateOrProvinceName) | ST | ST | | (LocalityName) | L | L | | Organization | O | O | | Department | OU | O | | Title | | Title | | Work-telephone | | Phone | | Fax-telephone | | Fax | | Work-address | | Address| | Email-address (RFC822)| | Email | |_______________________|____________|__________| The "First" keyword is derived from the "first" command line argument to "whois"; the "Phone", "Fax" and "Email" [Huitema et alii] [Page 19] Internet Draft SOLO December 1993 simplications come from the wide usage of these arguments and the desire to focus on "business" attribute by default (see the "security" section for a rationale). The corresponding "object identifiers" can be found in RFC-1274 (X.500 directory schema). 3.7. Values: Values are encoutered in name specifications and in value lists. There are three possible encodings for a value: o a set of printable characters, excluding any occurence of the special characters comma(,), colon(:), equal(=), semi- colon(;) question mark (?) and of the angle brackets (< and >). In this syntax, multiple occurence of white spaces can be replaced by a single white space. o a quoted string, optionally preceded by an alphabet nota- tion, and delimited by double quotes. In this case, the MIME "quoted text" format is used. o a binary string, encoded as defined in the "base64" nota- tion, and delimited by simple quotes. Only the first two formats can be used within the command line. When the value is an universal resource locator, use of the quoted text notation is encouraged. 4. A list of information codes: Information codes fall within 5 categories: (1) System errors are numbered from 100 to 199. (2) Name errors are numbered from 200 to 299. (3) Intermediate informations are numbered from 300 to 399. [Huitema et alii] [Page 20] Internet Draft SOLO December 1993 (4) User informations are numbered from 400 to 499. (5) Completion reports are numbered from 500 to 599. 4.1. System errors System errors indicate that the query could not be further pro- cessed. The following errors have been defined: ________________________________________________________ | 100| Unrecognized command | | | 101| Incorrect name specification | | | 102| Incorrect attribute list | | | 103| Incorrect command parameters | | | 104| Momentary congestion, try later | | | 105| Server problem | | | 106| Data base problem | | | 107| Timing out after relaying | | | 108| Abandoning the request | | | 110| Too many relays, probably looping| | | 111| No such host | domain-name| | 112| No SOLO server on host | domain-name| | 113| Unwilling to poll | domain-name| |____|___________________________________|______________| [Huitema et alii] [Page 21] Internet Draft SOLO December 1993 4.2. Name errors Name errors occurs when the name specification is invalid. The following errors have been defined: _________________________________________________ | 201| Ambiguous name | | | 202| No such name | | | 203| Over specified name | | | 204| Too many names to list them all| | |____|_________________________________|_________| 4.3. Intermediate informations Intermediate informations are informations that can be "cached" by the server. The following codes are defined: ______________________________________________ | 301| Partial Match | | | 302| Suggested-server| domain-name| |____|__________________|_____________________| 4.4. User informations User informations are suggestions that can be passed to the user. The following codes have been defined: ________________________________________ | 400| Suggestion| | | 401| S-service | URL | | 402| Relaying | domain-name| | 403| Will poll | domain-name | |____|____________|_____________________| [Huitema et alii] [Page 22] Internet Draft SOLO December 1993 4.5. Completion reports Completion reports precede a list of attribute values. Two reports are defined: ________________________________ | 500| Matches | | | 501| Sending indexes| | |____|_________________|________| 5. Security considerations: The SOLO protocol is designed to widely publicize information about people, e.g. telephone numbers or electronic mail addresses. As such, the most important considerations relate to the protection of personal privacy: notification and filtering, listing and browsing. Then, one finds the classical problem of "name server" attacks. The attention of the administrators is also drawn onto the particular problem of embedding login information into mail addresses. 5.1. Notification and removal In several countries, the privacy protection laws require that users be notified of their listing in any data base containing personal information; in some countries, one has to sollicit their explicit agreement before listing their informations. The matter is only made worse by the international nature of the Internet: information placed in a connected data base should be considered as publicized on a world wide basis. Even when the local laws do not require it, it is good practice to observe the following guidelines: o Notify people listed in the SOLO server that you are pub- lishing their personal information, o Be ready to remove some people from their data bases. There are a number of people who may have good reasons not to be [Huitema et alii] [Page 23] Internet Draft SOLO December 1993 listed at all. o Don't publish more data than necessary. We clearly need to list identification data such as first names or surnames, and there are very good reasons for listing an email address, a fax number or an office phone number. But one should clearly think twice before listing a home address or the list of ongoing projects... Local regulations may impose stronger protections. These regula- tions should indeed be followed. 5.2. Listing and browsing Practicians of the "privacy laws" are adamant against the risks posed by "remote listing" procedures. When available without restriction, services such as the X.500 "LIST" operation allow complete foreigners to copy a data base and use it for "innova- tive" purposes, e.g. correlate it with another base, or use it as the start of a "mailing" operation. We have seen in the section on "limiting the size of the output" the need to limit the number of names returned by the "SOLO" command. A similar risk is posed by the "POLL" command, as: POLL CN; would allow to list the names of all the person present in the data base. In the absence of secure communications, if the remote party cannot be precisely identified, administrators of the SOLO service would be well inspired to limit the set of attributes returned by the POLL command to only those that iden- tify the organization, e.g. Organization name, Unit name, Coun- try, Region and City. The "CN=*" facility should be used instead of returning a full listing of names. [Huitema et alii] [Page 24] Internet Draft SOLO December 1993 5.3. The name server attacks The SOLO service will be used to store communication data, e.g. phone numbers or electronic mail addresses. There is a classic attack against this service, in which an intruder "emulates" a server and return forged addresses, so that he or an accumplice receives the information that was meant to be sent to a third party. X.500 protects clients against this attack by "strongly authen- ticating" request and responses, so that there is no way to emu- late a server or to alter the information. SOLO does not include strong authentication. Two alternate methods could be used: (1) Run SOLO on top of a secure network, e.g. using IP security. (2) Protect the data themselves, e.g. have them signed and scealed, as e.g. PEM certificates. One should note that the second alternative is the only one that maintain the protection even when caches are used. 5.4. Logins and addresses Email addresses are often build as a combination of a host name and a login name or account number. It is well known that expos- ing these combinations facilitates the task of intruders -- they only have to "guess a password" instead of having to guess both an account number and a password. This problem is however not specific to SOLO. Any other white page service or any message sent to a wide distribution list would also publicize the infor- mation. 6. Acknowledgments: We would like to thank the members of the IETF "directory service" working groups and the participant to OPAX, PARADISE and various other white page pilots for their encouragements. The use of URLs [Huitema et alii] [Page 25] Internet Draft SOLO December 1993 was suggested by Marshall Rose in a discussion on the "future of X.500", and was also discussed in the RARE "WG-NAP" working group. The members of the RARE WG-NAP initiated the analysis of the privacy requirements which is reported in the "security" section. Several members of the INRIA and TS-E3X teams reviewed the draft. Also, we would like to pay tribute to the member of the WNILS working group, as we shamelessly copied the "centroid" concept which was developped for the WHOIS++ service. 7. References: (1) Gargano, Joan, Weiss, Ken. Whois and Network Information Lookup Service, Whois++. RFC in preparation. (2) Weider, Chris, Fulton, Jim, Spero, Simon. Architecture of the Whois++ Index Service. RFC in preparation. (3) Howes, T. , Kille, S., Yeong, W., Robbins, C. The X.500 String Representation of Standard Attribute Syntaxes. RFC-1488. (4) Kille, Steve, Using the OSI Directory to achieve User Friendly Naming. RFC-1484. July 1993. (5) Kille, Steve, A String Representation of Distinguished Names. RFC-1485. July 1993. (6) CCITT. X.500 series of recommendations. 1988. (7) Barker, Paul, Kille, Steve, The COSINE and Internet X.500 Schema. RFC-1274. November 1991. [Huitema et alii] [Page 26] Internet Draft SOLO December 1993 8. Authors' Addresses Comments should be sent to: Christian Huitema INRIA 2004 Route des Lucioles BP 93 06902 Sophia-Antipolis Cedex France Email: Christian.Huitema@sophia.inria.fr Paul-Andre Pays INRIA BP105 78153 Le Chesnay Cedex France Email: Paul-Andre.Pays@faugeres.inria.fr Alain Zahm, Ascan Woermann TS-E3X Groupe France Telecom, Les Algorithmes, Route des Lucioles, Bat. Pythagore A 06560 Valbonne France Email: zahm@osi.e3x.fr, Woermann@osi.e3x.fr Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 2 1 Presentation of the SOLO protocol: .............................. 2 1.1 A basic example: .............................................. 2 1.2 Name errors ................................................... 3 1.3 Partial name matches and redirections ......................... 5 1.4 Absolute matches: ............................................. 6 [Huitema et alii] [Page 27] Internet Draft SOLO December 1993 1.5 Attributes and Universal Resource Locators (URL) .............. 6 1.6 Aliases and alternate values: ................................. 7 1.7 Filters and substrings: ....................................... 8 1.8 Limiting the size of the output: .............................. 9 2 Networking white page informations: ............................. 10 2.1 Using the index request: ...................................... 10 2.2 Signalling secondary servers .................................. 12 2.3 Relaying of queries ........................................... 13 2.4 Use of caches: ................................................ 14 2.5 Networking with other technologies: ........................... 15 2.6 Stacking multiple requests: ................................... 15 3 Protocol specification: ......................................... 15 3.1 The format of a request: ...................................... 15 3.2 The format of the replies: .................................... 17 3.3 Format of name specifications: ................................ 17 3.4 Format of attribute lists: .................................... 18 3.5 List of attribute values: ..................................... 18 3.6 Attribute names: .............................................. 19 3.7 Values: ....................................................... 20 4 A list of information codes: .................................... 20 4.1 System errors ................................................. 21 4.2 Name errors ................................................... 22 4.3 Intermediate informations ..................................... 22 4.4 User informations ............................................. 22 4.5 Completion reports ............................................ 23 5 Security considerations: ........................................ 23 5.1 Notification and removal ...................................... 23 5.2 Listing and browsing .......................................... 24 5.3 The name server attacks ....................................... 25 5.4 Logins and addresses .......................................... 25 6 Acknowledgments: ................................................ 25 7 References: ..................................................... 26 8 Authors' Addresses .............................................. 27 [Huitema et alii] [Page 28]