doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6394.txt b/doc/rfc/rfc6394.txt
new file mode 100644
index 0000000..921e4a1
--- /dev/null
+++ b/doc/rfc/rfc6394.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Barnes
+Request for Comments: 6394                              BBN Technologies
+Category: Informational                                     October 2011
+ISSN: 2070-1721
+
+
+        Use Cases and Requirements for DNS-Based Authentication
+                        of Named Entities (DANE)
+
+Abstract
+
+   Many current applications use the certificate-based authentication
+   features in Transport Layer Security (TLS) to allow clients to verify
+   that a connected server properly represents a desired domain name.
+   Typically, this authentication has been based on PKIX certificate
+   chains rooted in well-known certificate authorities (CAs), but
+   additional information can be provided via the DNS itself.  This
+   document describes a set of use cases in which the DNS and DNS
+   Security Extensions (DNSSEC) could be used to make assertions that
+   support the TLS authentication process.  The main focus of this
+   document is TLS server authentication, but it also covers TLS client
+   authentication for applications where TLS clients are identified by
+   domain names.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6394.
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 1]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Definitions .....................................................4
+   3. Use Cases .......................................................4
+      3.1. CA Constraints .............................................5
+      3.2. Service Certificate Constraints ............................6
+      3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
+      3.4. Delegated Services .........................................9
+   4. Other Requirements .............................................10
+   5. Acknowledgements ...............................................11
+   6. Security Considerations ........................................11
+   7. References .....................................................11
+      7.1. Normative References ......................................11
+      7.2. Informative References ....................................12
+
+1.  Introduction
+
+   Transport Layer Security (TLS) is used as the basis for security
+   features in many modern Internet application service protocols to
+   provide secure client-server connections [RFC5246].  It underlies
+   secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and
+   provides hop-by-hop security in real-time multimedia and instant-
+   messaging protocols [RFC3261] [RFC6120].
+
+   Application service clients typically establish TLS connections to
+   application servers identified by DNS domain names.  The process of
+   obtaining this "source" domain is application specific [RFC6125].
+   The name could be entered by a user or found through an automated
+   discovery process such as an SRV or NAPTR record.  After obtaining
+   the address of the server via an A or AAAA DNS record, the client
+   conducts a TLS handshake with the server, during which the server
+   presents a PKIX certificate [RFC5280].  The TLS layer performs PKIX
+
+
+
+Barnes                        Informational                     [Page 2]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   validation of the certificate, including verification that the
+   certificate chains to one of the client's trust anchors.  If this
+   validation is successful, then the application layer determines
+   whether the DNS name for the application service presented in the
+   certificate matches the source domain name [RFC6125].  Typically, if
+   the name matches, then the client proceeds with the TLS connection.
+
+   The certificate authorities (CAs) that issue PKIX certificates are
+   asserting bindings between domain names and the public keys they
+   certify.  Application service clients are verifying these bindings
+   and making authorization decisions -- whether to proceed with
+   connections -- based on them.
+
+   Clients thus rely on CAs to correctly assert bindings between public
+   keys and domain names, in the sense that the holder of the
+   corresponding private key should be the domain holder.  Today, an
+   attacker can successfully authenticate as a given application service
+   domain if he can obtain a "mis-issued" certificate from one of the
+   widely used CAs -- a certificate containing the victim application
+   service's domain name and a public key whose corresponding private
+   key is held by the attacker.  If the attacker can additionally insert
+   himself as a "man in the middle" between a client and server (e.g.,
+   through DNS cache poisoning of an A or AAAA record), then the
+   attacker can convince the client that a server of the attacker's
+   choice legitimately represents the victim's application service.
+
+   With the advent of DNSSEC [RFC4033], it is now possible for DNS name
+   resolution to provide its information securely, in the sense that
+   clients can verify that DNS information was provided by the domain
+   operator and not tampered with in transit.  The goal of technologies
+   for DNS-based Authentication of Named Entities (DANE) is to use the
+   DNS and DNSSEC to provide additional information about the
+   cryptographic credentials associated with a domain, so that clients
+   can use this information to increase the level of assurance they
+   receive from the TLS handshake process.  This document describes a
+   set of use cases that capture specific goals for using the DNS in
+   this way, and a set of requirements that the ultimate DANE mechanism
+   should satisfy.
+
+   Finally, it should be noted that although this document will
+   frequently use HTTPS as an example application service, DANE is
+   intended to apply equally to all applications that make use of TLS to
+   connect to application services identified by domain names.
+
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 3]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+2.  Definitions
+
+   This document also makes use of standard PKIX, DNSSEC, and TLS
+   terminology.  See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and
+   RFC 5246 [RFC5246], respectively, for these terms.  In addition,
+   terms related to TLS-protected application services and DNS names are
+   taken from RFC 6125 [RFC6125].
+
+   Note in particular that the term "server" in this document refers to
+   the server role in TLS, rather than to a host.  Multiple servers of
+   this type may be co-located on a single physical host, often using
+   different ports, and each of these can use different certificates.
+
+   This document refers several times to the notion of a "domain
+   holder".  This term is understood to mean the entity that is
+   authorized to control the contents of a particular zone.  For
+   example, the registrants of 2nd- or 3rd-level domains are the holders
+   of those domains.  The holder of a particular domain is not
+   necessarily the entity that operates the zone.
+
+   It should be noted that the presence of a valid DNSSEC signature in a
+   DNS reply does not necessarily imply that the records protected by
+   that signature were authorized by the domain holder.  The distinction
+   between the holder of a domain and the operator of the corresponding
+   zone has several security implications, which are discussed in the
+   individual use cases below.
+
+3.  Use Cases
+
+   In this section, we describe the major use cases that the DANE
+   mechanism should support.  This list is not intended to represent all
+   possible ways that the DNS can be used to support TLS authentication.
+   Rather, it represents the specific cases that comprise the initial
+   goals for DANE.
+
+   In the use cases below, we will refer to the following dramatis
+   personae:
+
+   Alice:  The operator of a TLS-protected application service on the
+      host alice.example.com, and administrator of the corresponding
+      DNS zone.
+
+   Bob:  A client connecting to alice.example.com.
+
+   Charlie:  A well-known CA that issues certificates with domain names
+      as identifiers.
+
+
+
+
+
+Barnes                        Informational                     [Page 4]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   Oscar:  An outsourcing provider that operates TLS-protected
+      application services on behalf of customers.
+
+   Trent:  A CA that issues certificates with domain names as
+      identifiers, but is not generally well-known.
+
+   These use cases are framed in terms of adding verification steps to
+   TLS server identity checking on the part of application service
+   clients.  In application services where the clients are also
+   identified by domain names (e.g., Extensible Messaging and Presence
+   Protocol (XMPP) server-to-server connections), the same
+   considerations and use cases are applicable to the application
+   server's checking of identities in TLS client certificates.
+
+3.1.  CA Constraints
+
+   Alice runs a website on alice.example.com and has obtained a
+   certificate from the well-known CA Charlie.  She is concerned that
+   other well-known CAs might issue certificates for alice.example.com
+   without her authorization, which clients would accept.  Alice would
+   like to provide a mechanism for visitors to her site to know that
+   they should expect alice.example.com to use a certificate issued
+   under the CA that she uses (Charlie) and not another CA.  That is,
+   Alice is recommending that the client verify that there is a valid
+   certificate chain from the server certificate to Charlie before
+   accepting the server certificate.  (For example, in the TLS
+   handshake, the server might include Charlie's certificate in the
+   server Certificate message's certificate_list structure [RFC5246]).
+
+   When Bob connects to alice.example.com, he uses this mechanism to
+   verify that the certificate presented by the server was issued under
+   the proper CA, Charlie.  Bob also performs the normal PKIX validation
+   procedure for this certificate, in particular verifying that the
+   certificate chains to a trust anchor (possibly Charlie's CA, if Bob
+   accepts Charlie's CA as a trust anchor).
+
+   Alice may wish to provide similar information to an external CA
+   operator, Charlie.  Prior to issuing a certificate for
+   alice.example.com to someone claiming to be Alice, Charlie needs to
+   verify that Alice is actually requesting a certificate.  Alice could
+   indicate her preferred CA using DANE to CAs as well as relying
+   parties.  Charlie could then check to see whether Alice said that her
+   certificates should be issued by Charlie or another CA.  Note that
+   this check does not guarantee that the precise entity requesting a
+   certification from Charlie actually represents Alice -- only that
+   Alice has authorized Charlie to issue certificates for her domain to
+   properly authorized individuals.
+
+
+
+
+Barnes                        Informational                     [Page 5]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   In principle, DANE information expressing CA constraints can be
+   presented with or without DNSSEC protection.  Presenting DANE
+   information without DNSSEC protection does not introduce any new
+   vulnerabilities, but neither does it add much assurance.  Deletion of
+   records removes the protection provided by this constraint, but the
+   client is still protected by CA practices (as now).  Injected or
+   modified false records are not useful unless the attacker can also
+   obtain a certificate for the target domain.  Thus, in the worst case,
+   tampering with these constraints increases the risk of false
+   authentication to the level that is now standard.
+
+   Using DANE information for CA constraints without DNSSEC provides a
+   very small incremental security feature.  Many common attacks against
+   TLS connections already require the attacker to inject false A or
+   AAAA records in order to steer the victim client to the attacker's
+   server.  An attacker that can already inject false DNS records can
+   also provide fake DANE information (without DNSSEC) by simply
+   spoofing the additional records required to carry the DANE
+   information.
+
+   Injected or modified false DANE information of this type can be used
+   for denial of service, even if the attacker does not have a
+   certificate for the target domain.  If an attacker can modify DNS
+   responses that a target host receives, however, there are already
+   much simpler ways of denying service, such as providing a false A or
+   AAAA record.  In this case, DNSSEC is not helpful, since an attacker
+   could still cause a denial of service by blocking all DNS responses
+   for the target domain.
+
+   Continuing to require PKIX validation also limits the degree to which
+   DNS operators (as distinct from the holders of domains) can interfere
+   with TLS authentication through this mechanism.  As above, even if a
+   DNS operator falsifies DANE records, it cannot masquerade as the
+   target server unless it can also obtain a certificate for the target
+   domain.
+
+3.2.  Service Certificate Constraints
+
+   Alice runs a website on alice.example.com and has obtained a
+   certificate from the well-known CA Charlie.  She is concerned about
+   additional, unauthorized certificates being issued by Charlie as well
+   as by other CAs.  She would like to provide a way for visitors to her
+   site to know that they should expect alice.example.com to present a
+   specific certificate.  In TLS terms, Alice is letting Bob know that
+   this specific certificate must be the first certificate in the server
+   Certificate message's certificate_list structure [RFC5246].
+
+
+
+
+
+Barnes                        Informational                     [Page 6]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   When Bob connects to alice.example.com, he uses this mechanism to
+   verify that the certificate presented by the server is the correct
+   certificate.  Bob also performs the normal PKIX validation procedure
+   for this certificate, in particular verifying that the certificate
+   chains to a trust anchor.
+
+   The security implications for this case are the same as for the "CA
+   Constraints" case above.
+
+3.3.  Trust Anchor Assertion and Domain-Issued Certificates
+
+   Alice would like to be able to generate and use certificates for her
+   website on alice.example.com without involving an external CA at all.
+   Alice can generate her own certificates today, making self-signed
+   certificates and possibly certificates subordinate to those
+   certificates.  When Bob receives such a certificate in a TLS
+   handshake, however, he doesn't automatically have a way to verify
+   that the issuer of the certificate is actually Alice, because he
+   doesn't necessarily possess Alice's corresponding trust anchor.  This
+   concerns him because an attacker could present a different
+   certificate and perform a man-in-the-middle attack.  Bob would like
+   to protect against this.
+
+   Alice would thus like to publish information so that visitors to her
+   site can know that the certificates presented by her application
+   services are legitimately hers.  When Bob connects to
+   alice.example.com, he uses this information to verify that the
+   certificate presented by the server has been issued by Alice.  Since
+   Bob can bind certificates to Alice in this way, he can use Alice's CA
+   as a trust anchor for purposes of validating certificates for
+   alice.example.com.  Alice can additionally recommend that clients
+   accept only her certificates using the CA constraints described
+   above.
+
+   As in Section 3.1 above, Alice may wish to represent this information
+   to potential third-party CAs (Charlie) as well as to relying parties
+   (Bob).  Since publishing a certificate in a DANE record of this form
+   authorizes the holder of the corresponding private key to represent
+   alice.example.com, a CA that has received a request to issue a
+   certificate from alice.example.com could use the DANE information to
+   verify the requestor's authorization to receive a certificate for
+   that domain.  For example, a CA might choose to issue a certificate
+   for a given domain name and public key only when the holder of the
+   domain name has provisioned DANE information with a certificate
+   containing the public key.
+
+
+
+
+
+
+Barnes                        Informational                     [Page 7]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   Note that this use case is functionally equivalent to the case where
+   Alice doesn't issue her own certificates, but uses Trent's CA, which
+   is not well-known.  In this case, Alice would be advising Bob that he
+   should treat Trent as a trust anchor for purposes of validating
+   Alice's certificates, rather than a CA operated by Alice herself.
+   Bob would thus need a way to securely obtain Trent's trust anchor
+   information, namely through DANE information.
+
+   Alice's advertising of trust anchor material in this way does not
+   guarantee that Bob will accept the advertised trust anchor.  For
+   example, Bob might have out-of-band information (such as a
+   pre-existing local policy) that indicates that the CA advertised by
+   Alice (Trent's CA) is not trustworthy, which would lead him to decide
+   not to accept Trent as a trust anchor, and thus to reject Alice's
+   certificate if it is issued under Trent's CA.
+
+   Providing trust anchor material in this way clearly requires DNSSEC,
+   since corrupted or injected records could be used by an attacker to
+   cause clients to trust an attacker's certificate (assuming that the
+   attacker's certificate is not rejected by some other local policy).
+   Deleted records will only result in connection failure and denial of
+   service, although this could result in clients re-connecting without
+   TLS (a downgrade attack), depending on the application.  Therefore,
+   in order for this use case to be safe, applications must forbid
+   clients from falling back to unsecured channels when records appear
+   to have been deleted (e.g., when a missing record has no NSEC or
+   NSEC3 record).
+
+   By the same token, this use case puts the most power in the hands of
+   DNS operators.  Since the operator of the appropriate DNS zone has
+   de facto control over the content and signing of the zone, he can
+   create false DANE records that bind a malicious party's certificate
+   to a domain.  This risk is especially important to keep in mind in
+   cases where the operator of a DNS zone is a different entity than the
+   holder of the domain, as in DNS hosting/outsourcing arrangements,
+   since in these cases the DNS operator might be able to make changes
+   to a domain that are not authorized by the holder of the domain.
+
+   It should be noted that DNS operators already have the ability to
+   obtain certificates for domains under their control, under certain CA
+   policies.  In the current system, CAs need to verify that an entity
+   requesting a certificate for a domain is actually the legitimate
+   holder of that domain.  Typically, this is done using information
+   published about that domain, such as WHOIS email addresses or special
+   records inserted into a domain.  By manipulating these values, it is
+   possible for DNS operators to obtain certificates from some well-
+   known certificate authorities today without authorization from the
+   true domain holder.
+
+
+
+Barnes                        Informational                     [Page 8]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+3.4.  Delegated Services
+
+   In addition to guarding against CA mis-issue, CA constraints and
+   certificate constraints can also be used to constrain the set of
+   certificates that can be used by an outsourcing provider.  Suppose
+   that Oscar operates alice.example.com on behalf of Alice.  In
+   particular, Oscar then has de facto control over what certificates to
+   present in TLS handshakes for alice.example.com.  In such cases,
+   there are a few ways that DNS-based information about TLS
+   certificates could be configured; for example:
+
+   1.  Alice has the A/AAAA records in her DNS and can sign them along
+       with the DANE record, but Oscar and Alice now need to have tight
+       coordination if the addresses and/or the certificates change.
+
+   2.  Alice refers to Oscar's DNS by delegating a sub-domain name to
+       Oscar, and has no control over the A/AAAA, DANE, or any other
+       pieces under Oscar's control.
+
+   3.  Alice can put DANE records into her DNS server but delegate the
+       address records to Oscar's DNS server.  This means that Alice can
+       control the usage of certificates, but Oscar is free to move the
+       servers around as needed.  The only coordination needed is when
+       the certificates change, and then it would depend on how the DANE
+       record is set up (i.e., a CA or an end-entity certificate
+       pointer).
+
+   Which of these deployment patterns is used in a given deployment will
+   determine what sort of constraints can be expressed by which actors.
+   In cases where Alice controls DANE records (1 and 3), she can use CA
+   and certificate constraints to control what certificates Oscar
+   presents for Alice's application services.  For instance, Alice might
+   require Oscar to use certificates under a given set of CAs.  This
+   control, however, requires that Alice update DANE records when Oscar
+   needs to change certificates.  Cases where Oscar controls DANE
+   records allow Oscar to maintain more autonomy from Alice, but by the
+   same token, Alice cannot enforce any requirements on the certificates
+   that Oscar presents in TLS handshakes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 9]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+4.  Other Requirements
+
+   In addition to supporting the above use cases, the DANE mechanism
+   must satisfy several lower-level operational and protocol
+   requirements and goals.
+
+   Multiple Ports:  DANE should be able to support multiple application
+      services with different credentials on the same named host,
+      distinguished by port number.
+
+   No Downgrade:  An attacker who can tamper with DNS responses must not
+      be able to make a DANE-compliant client treat a site that has
+      deployed DANE and DNSSEC like a site that has deployed neither.
+
+   Encapsulation:  If there is DANE information for the name
+      alice.example.com, it must only affect application services hosted
+      at alice.example.com.
+
+   Predictability:  Client behavior in response to DANE information must
+      be defined in the DANE specification as precisely as possible,
+      especially for cases where DANE information might conflict with
+      PKIX information.
+
+   Opportunistic Security:  The DANE mechanism must allow a client to
+      determine whether DANE information is available for a site, so
+      that a client can provide the highest level of security possible
+      for a given application service.  Clients that do not support DANE
+      should continue to work as specified, regardless of whether DANE
+      information is present or not.
+
+   Combination:  The DANE mechanism must allow multiple DANE statements
+      of the above forms to be combined.  For example, a domain holder
+      should be able to specify that clients should accept a particular
+      certificate (Section 3.2) as well as any certificate issued by its
+      own CA (Section 3.3).  The precise types of combination allowed
+      will be defined by the DANE protocol.
+
+   Roll-over:  The DANE mechanism must allow a site to transition from
+      using one DANE mechanism to another.  For example, a domain holder
+      should be able to migrate from using DANE to assert a domain-
+      issued certificate (Section 3.3) to using DANE to require an
+      external CA (Section 3.1), or vice versa.  The DANE mechanism must
+      also allow roll-over between records of the same type, e.g., when
+      changing CAs.
+
+   Simple Key Management:  DANE should have a mode in which the domain
+      holder only needs to maintain a single long-lived public/private
+      key pair.
+
+
+
+Barnes                        Informational                    [Page 10]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   Minimal Dependencies:  It should be possible for a site to deploy
+      DANE without also deploying anything else, except DNSSEC.
+
+   Minimal Options:  Ideally, DANE should have only one operating mode.
+      Practically, DANE should have as few operating modes as possible.
+
+   Wildcards:  The mechanism for distributing DANE information should
+      allow the use of DNS wildcard labels (*) for setting DANE
+      information for all names within a wildcard expansion.
+
+   Redirection:  The mechanism for distributing DANE information should
+      work when the application service name is the result of following
+      a DNS redirection chain (e.g., via CNAME or DNAME).
+
+5.  Acknowledgements
+
+   Thanks to Eric Rescorla for the initial formulation of the use cases,
+   Zack Weinberg and Phillip Hallam-Baker for contributing other
+   requirements, and the whole DANE working group for helpful comments
+   on the mailing list.
+
+6.  Security Considerations
+
+   The primary focus of this document is the enhancement of TLS
+   authentication procedures using the DNS.  The general effect of such
+   mechanisms is to increase the role of DNS operators in authentication
+   processes, either in place of or in addition to traditional third-
+   party actors such as commercial certificate authorities.  The
+   specific security implications of the respective use cases are
+   discussed in their respective sections above.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+
+
+
+
+Barnes                        Informational                    [Page 11]
+
+RFC 6394                     DANE Use Cases                 October 2011
+
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+7.2.  Informative References
+
+   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
+              RFC 2595, June 1999.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              Transport Layer Security", RFC 3207, February 2002.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, March 2011.
+
+Author's Address
+
+   Richard Barnes
+   BBN Technologies
+   9861 Broken Land Parkway
+   Columbia, MD  21046
+   US
+
+   Phone: +1 410 290 6169
+   EMail: rbarnes@bbn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 12]
+