INTERNET DRAFT M. Ohta draft-ohta-simple-dns-00.txt Tokyo Institute of Technology August 1994 Simple Secure DNS 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 ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract An extension to DNS is proposed to make answers from it authenticated. The extension is designed to be minimal, which will be useful as a framework to make applications provide required level of authentication and/or confidentiality. The changes to the existing architecture of DNS is also minimized. 1. Introduction The purpose of the secure DNS protocol extension is to make data from DNS authenticated. In general, security has two aspects, authentication to make data unforgable and confidentiality to make data secret. As the fundamental role of DNS is to make its database available all around the world, no confidentiality is considered in this document. IQUERY, an optional feature of DNS, is inherently insecure, and not considered in this document. This document is written with the assumption that readers thoroughly understand the existing DNS described in RFC 1034 and RFC 1035. On the other hand, little knowledge on cryptography is assumed. M. Ohta Expires on Feb. 8, 1995 [Page 1] INTERNET DRAFT Simple Secure DNS August 1994 To make DNS secure, two cryptographic mechanisms: digesting and signature, are combined. Digesting is the mechanism to compute a short digest of a byte stream. The mechanism should be complex enough so that, given a digest value of some byte stream, it should be practically impossible to forge a different byte stream which has the same digest value. The other is the mechanism to give signature to a byte stream with some secret information. The mechanism should be complex enough so that, given a signature value of some data and the original data itself, it should be practically impossible to guess the secret information. The signature can be verified by sharing secret information between related parties or by using private/public key technology. This document does not specify the actual mechanisms to generate digests and signatures. As long as the above two basic authentication mechanisms are reliable, secure DNS is designed to be reliable against all forms of attacks save the denial of service attacks of the most basic form, which is least harmful. That is, the secure DNS may report a temporal failure against some form of denial of service attacks. But all the answers other than the temporal failure is reliable to the extent that the basic authentication mechanisms up to the root or other locally reliable zones are reliable. For example, if a resolver can communicate with no name servers because of some attack such as unplugging of cables, the only thing the resolver can do is to report the temporal failure, which is one of the most basic form of a denial of service attack. On the other hand, secure DNS can securely report negative answers that a node does not exists or that an RR type does not exist for a given node. Authentication is provided zone wise. A secure zone is a zone whose authentication is provided by the protocol whereas a secure node is a node authoritatively belongs to a secure zone. A secure zone has its own secret information to generate signatures for secure nodes in the zone. For the maximum security, both the secret information and the signature generation mechanism of a zone should be kept off-line. In this case, even if on-line name servers of the zone is compromised, security on the DNS information of the zone is not compromised. In cases where frequent and/or automatic update of a zone is desired, it is necessary to make signature generation mechanism of the zone accessible on-line. Still, it is worthwhile to keep the secret information and secure time stamping mechanism of the zone off-line. To make it easier, the protocol is designed to let signed information have the consistent format about time stamping and signature generation. Then, after the security of the signature generation mechanism is restored, signatures using the same secret information become reliable again. M. Ohta Expires on Feb. 8, 1995 [Page 2] INTERNET DRAFT Simple Secure DNS August 1994 Though the secure DNS can be a authenticated source of information to establish secure communication between hosts, it is out of the scope of this document and a separate document should be provided. A security aware name server is a name server which can perform authenticated communication between security aware name servers and resolvers in a way specified in this document. A security aware resolver is a resolver which can retrieve authenticated DNS data in secure zones. A security aware resolver is configured with a list of security aware name servers which is considered to be reliable. The actual mechanism for the communication between a security aware resolver and relied name server should be identical or parallel to secure IP and its detail is not discussed in this document. The problem is that security aware resolver can not rely on secure DNS. So, if secure IP relies on secure DNS, the security aware resolver should use statically configured information, instead. The protocol in this document is carefully designed so that existing name servers can cooperate with security aware resolvers and name servers. 2. Changes to the Existing Mechanism Important changes to the existing DNS architecture described in RFC 1034 and RFC 1035 are: A new OPCODE, NCQUERY, is added to retrieve authentication information of a node containing CNAME. As authentication information on a node of CNAME is added as other records of the node, it is necessary to have an opcode to suppress CNAME processing. As a side effect, it is now possible to have a zone which consists of a single CNAME node, which also have SOA and NS records. [Note: Though it is possible to add new query types which matches CNAME and other RRs in the node, it is not so clean. Moreover, as authentication data is usually large, it may cause UDP packetsize overflow]. SD (Security Desired) bit is added to DNS packets for query. Though a name server is free to ignore the bit, the secure resolvers expects their reliable name servers return secure answer. The bit may also affect additional section processing. SA (Security Assured) bit is added to DNS packets for answer, which means that a name server who answers the question assures that all the data in the answer section is secure. M. Ohta Expires on Feb. 8, 1995 [Page 3] INTERNET DRAFT Simple Secure DNS August 1994 MINTTL fields of SOA RRs no longer mean the actual minimal TTLs nor negative caching periods. They, instead, mean default TTLs. Cases are canonicalized to use only upper case characters. Lower case characters are converted to upper case in primary servers. The canonicalization is necessary to compute a consistent signature or digest value. 3. New Data Types New data types: RRD, NSIG and are added to secure nodes. ZA, ZSIG and ZL are added to secure zones. Actual RR type names or values for the data and their syntax may vary according to specific authentication algorithm. Detailed explanation, including the actual RR type values for new data types, are not given in this document. Square bracketed notation "[RR]" is used to designate a instance of a new data type "RR". In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. RRD (RR Digest) Digest value of all the data with a certain RR type in a secure node. [RRD] RRs have the following syntax ( and are omitted throughout the document): [RRD] where [RRD] is the RR name of RRD, is the digest of all the resource records of type of node . is the original TTL value of the records. is a 16 bit quantity, is a 32 bit quantity, is of variable length. When computing , records are represented in binary form in DNS packet without domain name compression. If there are multiple records of the same , they are sorted with dictionary order, comparing the first bytes first with unsigned arithmetic. When verifying the digest of received data in resolvers and name servers, TTL field of the records, which should be decreased M. Ohta Expires on Feb. 8, 1995 [Page 4] INTERNET DRAFT Simple Secure DNS August 1994 already, should be replaced with (original TTL). When caching authenticated data, name servers and resolvers should confirm that the TTL in the answer packet does not exceed the value in RRD data. A node, in general, has multiple [RRD] record for each RR type the node has. But, it is impossible and unnecessary to cover s of [RRD] [NSIG] and [ZSIG]. Still, it is necessary to have [RRD] of such s as protection against denial service attacks, that is, to authenticate negative response of non existing RR types. An [RRD] record for [NSIG] or [ZSIG] RR has the field of length zero. To compute of [RRD] RR type itself, the field of the record itself is first considered to have zero length (including length field of the record) and later replaced with the actual digest length and value. NSIG (Node SIGnature) Signature on RRD computed using secret information of the zone, added to secure nodes. [NSIG] RRs have the following syntax: [NSIG] where [NSIG] is the RR name of NSIG (such as ELGAMAL640, RSA or KERBEROS), is the time when the signature is computed. is the number of seconds the signature will be valid after . and are 32 bit quantities. is of variable length. Throughout the document, time is a 32 bit quantity, unless otherwise specified. Absolute time is counted by the number of seconds from 00:00:00 GMT, Jan. 1st. 1970 A.D. and wraps around after 2^32 seconds (about 136 years). As the 32 bit time value circulates, zone's secret information should be changed at least once per 50 years. Otherwise, stale data signed 136 years ago may be distributed with a valid signature. When computing ; , and of [RRD] are serialized with the byte order used in DNS packets and the resulting byte stream is signed by the zone's signature mechanism(s). No NSIG records are provided for non-authoritative data for a zone such as referral information. Thus, if a name server is compromised or its IP address is used by an attacker, it is possible to implant false referral information to a resolver. M. Ohta Expires on Feb. 8, 1995 [Page 5] INTERNET DRAFT Simple Secure DNS August 1994 Still, as child zones have its own information, ZSIG (Zone SIGnature) described later, to authenticate themselves, the attacked resolver can detect that the referral information is bogus. The result is no worse than a simple denial of service attack by compromising name servers of the parent zone. That is, it is not necessary nor meaningful to try to authenticate referral NSes or glue A records for child zones. ZA (Zone Authenticator) Data added to a secure zone to specify how to verify NSIGs of nodes within the zone. [ZA] RRs have the following syntax: [ZA] where [ZA] is the RR name of ZA, is the time from when the is used. is 32 bit absolute time. is of variable length. The actual content of varies by the authentication algorithm. It may be a public key of the zone or IP addresses of authentication centers of the zone which maintains secret information of related parties. field is useful to smoothly change zone's secret information. Usually, a zone has only one record of [ZA] type. But, a zone may have two such records when zone's secret information is being changed. Otherwise, authentication of RRs signed before the change fails with a new . If multiple [ZA]s exist during the transition, field of NSIG is compared to the fields in [ZA]s to select the [ZA] actually used for the signature. Older [ZA] should disappear after all the signature signed with it is assured to have expired. ZSIG (Zone SIGnature) Data added to a secure zone to specify how to verify ZA of the zone. ZSIG data contains a signature of digest of the zone's ZA signed by other secure zones, typically its parent zone. [ZSIG] RRs have the following syntax. [ZSIG] <[NSIG]> M. Ohta Expires on Feb. 8, 1995 [Page 6] INTERNET DRAFT Simple Secure DNS August 1994 where [ZSIG] is the RR name of ZSIG data, is a domain name of a zone who signs [ZA], <[NSIG]> is the methods used for signature (represented in RR type) used by the . , and are the same as that of [NSIG] except that the signature covers the sequence of , where is the field of [RRD] of [ZA] a signed zone. In general, only a who is a parent or ancestor of the signed zone or the root zone should be considered to be secure, though local administrator may add or remove reliable s according to their local security policy. For the root zone or locally reliable zones, name servers should be statically configured with information to authenticate [ZSIG]. ZL (Zone List) data used to store sorted list of all the nodes in a zone. The information is necessary for protection against denial of service attacks, that is, if a node does not appear in certain ZLs, a negative response that a queried node does not exist is authenticated. The simplest way to authenticate negative answer that some data does not exist is to have an authenticated list of all the existing data. But, unless the number of existing data is expected to be small, as in the case with [RRD], listing up is inefficient. Especially, for a very large zone such as "com.", the size of the list is impractically large. So, existing data are sorted in a certain order and segmented appropriately into multiple ZL records. To authenticate the non-existence of a node, only a ZL RR containing the node (according to the sorting order) needs to be returned. To not to cause UDP size overflow, ZL RRs are intended to be returned as a partial RR in the additional section of a negative answer with truncation bit set. To authenticate a partial ZL RR, it is necessary to attach authentication signatures to individual ZL RRs. With wildcarding, actual authentication is a little more complicated and is discussed in section 5.3: "Resolver Algorithm". ZL will have the following syntax. [ZL] ... where [ZL] is the RR name of ZL data, is the number of seconds appropriate for negative caching, is the number of domains covered by the record. The record contains all the domain M. Ohta Expires on Feb. 8, 1995 [Page 7] INTERNET DRAFT Simple Secure DNS August 1994 names of the zone (including the top level nodes of child zones but excluding the zone name itself) after (or including) and before sorted with dictionary order. and is merely a separator and should not be interpreted that such a node exists unless explicitly listed as . Comparison is performed first label by label. Top level labels are compared first and the leaf labels are compared last, which makes domain name compression work quite well. Within labels, first bytes are compared first. Thus, the name of the zone is ordered before all the other names in the domain. For the comparison purpose, when the name of the zone itself appears as , it is considered to be ordered after all the other names in the domain. For example, [ZL] 0 represents a zone consisting of only a single node. and are two byte integers. , , , ..., have the syntax of domain names. To make an authenticated response of non existent node resides within 512 byte UDP packet, it is recommeded that the length of a single [ZL] record be shorter than 400 bytes, after limited domain name compression (those information available within the record itself only, may be shared for compression). , and are the same as that of [NSIG] except that the signature covers the byte stream of the sequence of ... contained in the [ZL] record itself. 4. Name Server Operation Changes to the operation of name servers is minimal. A primary name server of a zone has access to signature mechanisms of the zone and derives authenticated data from them. A secondary name server is configured with IP addresses of other name servers from which zone information is transferred. It also have digest of ZA to authenticate zone transfers. So, if the primary server is compromised, secondary servers can detect it and reject bogus zone transfers and can continue operation with older information. M. Ohta Expires on Feb. 8, 1995 [Page 8] INTERNET DRAFT Simple Secure DNS August 1994 The section "4.3.2. Algorithm" of RFC 1034 must be replaced with the following description: The actual algorithm used by the secure name server will depend on the local OS and data structures used to store RRs. The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache: 0. If SD bit is not set, use the original algorithm in RFC 1034. Otherwise, set SA bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available secure zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: a. If the whole of QNAME is matched, we have found the node. If the data at the node contains a CNAME, and QTYPE doesn't match CNAME and OPCODE is not NCQUERY, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put authenticated addresses available from authoritative data or the cache. If they are unavailable, use glue RRs, if they exists. Go to step 4. c. If at some label, a match is impossible (i.e., the M. Ohta Expires on Feb. 8, 1995 [Page 9] INTERNET DRAFT Simple Secure DNS August 1994 corresponding label does not exist), look to see if a "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response. Put at least one RR of ZL data containing the name being looked for in the additional section. If there are a lot of ZL data, truncation is expected. Exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label unless the query type is of [RRD]. Go to step 6. 4. Start matching down in the cache. If authenticated QNAME is found in the cache, copy all authenticated RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. 5. Using the local resolver or a copy of its algorithm (see resolver section of this document) answer the query and set or reset SA bit appropriately. Store the results, including any intermediate CNAMEs, in the answer section of the response. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. For secure zone transfer, new query types [SXFR] are added. The actual name and value of [SXFER] depends on the authentication mechanism used. It is assumed that each secondary server is statically configured with digest of ZA of a zone it serves. A secure zone transfer is a byte stream with the following structure. +------------------+ ^ | length | |d +------------------+ |i | | |g | | |e | zone data | |s | | |t | | |e M. Ohta Expires on Feb. 8, 1995 [Page 10] INTERNET DRAFT Simple Secure DNS August 1994 +------------------+ vd ^ | timestamp | |s +------------------+ |i | expire | |g +------------------+ |n | digest | |e +------------------+ vd | signature | +------------------+ The secondary server extract [ZA] records which is just transferred, verify it with statically configured digest, and authenticate the signature of the transferred zone. Unlike AXFER, [SXFER] uses four bytes for zone data length to transfer large zones such as "com.". 5. Resolver 5.1 Client-Resolver Interface Client programs tells security requirements to the resolver. The requirement includes whether they need security or not and which digesting or signature mechanism they consider reliable. 5.2. Data Structures The resolver algorithm in the next subsection assumes that all functions have been converted to a general lookup function, and uses the following data structures to represent the state of a request in progress in the resolver: SNAME the domain name we are searching for. STYPE the QTYPE of the search request. SCLASS the QCLASS of the search request. SLIST a structure which describes the name servers and the zone which the resolver is currently trying to query. This structure keeps track of the resolver's current best guess about which name servers hold the desired information; it is updated when arriving information changes the guess. This structure includes the equivalent of a zone name, the known name servers for the zone, the known addresses for the name servers, [ZA] and [ZSIG] of the zone if the zone is secure, and history information which can be used to suggest which server is likely to be the best one to try next. The zone name equivalent is a match count of M. Ohta Expires on Feb. 8, 1995 [Page 11] INTERNET DRAFT Simple Secure DNS August 1994 the number of labels from the root down which SNAME has in common with the zone being queried; this is used as a measure of how "close" the resolver is to SNAME. SBELT a "safety belt" structure of the same form as SLIST, which is initialized from a configuration file, and lists servers which should be used when the resolver doesn't have any local information to guide name server selection. The resolver thinks those name servers reliable. The configuration file also contains information, such as shared secret or digest of public key, for authenticated communication to the reliable name servers. The match count will be -1 to indicate that no labels are known to match. CACHE A structure which stores the results from previous responses. Since resolvers are responsible for discarding old RRs whose TTL has expired, most implementations convert the interval specified in arriving RRs to some sort of absolute time when the RR is stored in the cache. Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search, or discards them during periodic sweeps to reclaim the memory consumed by old RRs. The cache also contains information whether the RR is considered to be authenticated by the resolver. In the CACHE, authenticated RR has precedence over unauthenticated RR. 5.3 Resolver Algorithm The four step algorithm in the section "5.3.3. Algorithm" of RFC 1034 must be replaced with the following: The top level algorithm has four steps: 1. See if the answer is in local secure information, and if so return it to the client. 2. Find the best servers to ask. 3. Send them queries with SD bit set until one returns a response. 4. Analyze the response, either: M. Ohta Expires on Feb. 8, 1995 [Page 12] INTERNET DRAFT Simple Secure DNS August 1994 a. if the response answers the question or contains a name error, try to authenticate it, cache the data and other authentication information as well as returning the answer back to the client. b. if the response contains a better delegation to other servers, try to retrieve and authenticate ZSIG and ZA of the delegated zone. If the delegation information is authenticated, put it to local cache and go to step 2. c. if the response shows a CNAME and that is not the answer itself, try to authenticate the CNAME, cache the CNAME and other authentication information, change the SNAME to the canonical name in the CNAME RR and go to step 1. d. if the response shows a servers failure, an authentication failure or other bizarre contents, delete the server from the SLIST and go back to step 3. Authentication by resolvers are done as follows: 1. If the answer is obtained from one of the trusted name servers through authenticated communication channel and SA bit is set, or if the answer is in the authoritative data of the name server co-located with the resolver, no authentication is necessary. 2. For NSIG or ZSIG, no authentication check is necessary, though authentication failure with cached NSIG or ZSIG should invalidate the cached information. 3. To authenticate RRD, use NSIG and authenticated ZA. 4. To authenticate ZL, use authenticated ZA. 5. To authenticate ZA, use RRD of ZA and ZSIG. 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. M. Ohta Expires on Feb. 8, 1995 [Page 13] INTERNET DRAFT Simple Secure DNS August 1994 7. if the response is a name error, that is, a node which matches query does not exist, confirm it by authenticating ZL data in the additional section of the response. For example, to authenticate that data matching "a.b.c.d." dose not exist in a zone "c.d.", it should be confirmed that nodes "a.b.c.d." and "*.b.c.d" do not exist but "b.c.d." does exist. Depending on the zone's structure (whether "b.c.d." exists or not), the same thing may be confirmed by the fact that nodes "a.b.c.d.", "*.b.c.d", "b.c.d" and "*.c.d" do not exist. 8. if the response is a data not found error, that is, the query does not match any RR type of the node, retrieve all the authenticated RRD type records of the node and confirm that they don't contain RR types which matches the query. Authentication chains between zones have the following structure: digest ZA of well known signer zone------>digest value statically | configured in name | servers | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<---------RRD of ZA of signer zone | | | signature ZSIG<----------RRD of ZA Figure 1. Authentication Chains of Zone Data Authentication chains within a zone have the following structure: ZA of the Node's Zone | | | signature M. Ohta Expires on Feb. 8, 1995 [Page 14] INTERNET DRAFT Simple Secure DNS August 1994 NSIG<---------RRD of RR type RRD ^ |digest | RRD of RR type ^ |digest | RR with RR type other than RRD nor NSIG Figure 2. Authentication Chain of Node Data 5. Secure Time and Secure DNS DNS is designed to be highly fault tolerant. That is, if a secondary server can't communicate with other servers, the secondary server can behave as authoritative until SOA period is reached. Thus, until a resolver securely knows that period has passed, a name server may give old but authenticated answer to a query whose node does not exist. Thus, period should be minimized. Moreover, clocks of signers and resolvers should be accurate enough. It is recommended that signers clock should have maximum allowable error of /20. When resolvers caching information, it should be confirmed that cached period is shorter than and *19/20 fractions rounded down minus the expected maximum error of the resolvers' clocks. Due to clock skew, a resolver may receive a dated in the future. The data should be relied if the error is below /10 fractions rounded down plus the expected maximum error of the resolver's clocks. To have an Internet wide upper bound on the life time of stale data, longer than a week should be shortened to a week. 6. Secure DNS and Additional Section Processing To authenticate DNS reply on a certain node, a lot of information about the node is necessary. Such information may be provided in the additional section. On the other hand, though the existing DNS suggests to add various information in the additional section, data on nodes which is not queried needs, such as additional As for MX, are not so useful if M. Ohta Expires on Feb. 8, 1995 [Page 15] INTERNET DRAFT Simple Secure DNS August 1994 they can't be authenticated. Thus, for secure DNS, it is recommended to add additional information with the following preference as long as the addition won't make the reply longer than 512 bytes. [ZL] data for protection against denial of service attacks. glue A records for referral. additional information on the queried node. other additional information. 7. Specification of a Secure DNS Architecture To specify secure DNS, a standard track RFC(s) must be provided which specify a mechanism for digesting a mechanism for signature RR type values for [RRD], [NSIG], [ZA], [ZSIG], [ZL], [ZA], [ZSIG] and [SXFR] Ranges of 256 RR type values are reserved by IANA for the actual values of [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] as follows: [RRD] X [NSIG] X+256 [ZA] X+512 [ZSIG] X+768 [ZL] X+1024 [SXFR] X+1280 where X is between Y and Y+255 (Y is to be determined by IANA). [RRD], [NSIG], [ZA], [ZSIG], [ZL] and [SXFR] sharing the same value of X form a single set of specification. Even if two specifications share the same digesting or signature mechanism, they have different [RRD] or [NSIG] values. 8. References [RFC1034] M. Ohta Expires on Feb. 8, 1995 [Page 16] INTERNET DRAFT Simple Secure DNS August 1994 [RFC1035] Security Considerations The entire document is devoted on a security issue to make answers from DNS authenticated over unreliable transport mechanisms. No confidentiality is considered. Author's Address Masataka Ohta Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5499-7084 Fax: +81-3-3729-1940 EMail: mohta@cc.titech.ac.jp M. Ohta Expires on Feb. 8, 1995 [Page 17]