rfc2276.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   important.  Denial of service is probably the most difficult of these
   areas of threats both to detect and to prevent, and we will therefore
   set it aside for the present as well, although it will be seen that
   solutions to other problems will also mitigate some of the problems
   of denial of service.  Furthermore, because this is intended to be
   provide a global service to meet the needs of a variety of
   communities, the engineering tradeoffs will be different for
   different clients.  Hence the guidelines are stated in terms of, "It
   must be possible..."  It is important to note that the information of
   concern here is hint information, which by nature is not guaranteed
   to be correct or up-to-date; therefore, it is unlikely to be worth
   putting too much expense into the correctness of hints, because there
   is no guarantee that they are still correct anyway.  The exact choice
   of degree of privacy, authenticity, and integrity must be determined
   by the needs of the client and the availability of services from the
   server.

   To avoid confusion it is valuable to highlight the meanings of terms
   that have different meanings in other contexts.  In this case, the
   term "authoritative" as it is used here connotes the taking of an
   action or stamp of approval by a principal (again in the security
   sense) that has the right to perform such an act of approval.  It has
   no implication of correctness of information, but only perhaps an
   implication of who claimed it to be correct.  In contrast, the term
   is often also used simply to refer to a primary copy of a piece of
   information for which there may also be secondary or cached copies
   available.  In this discussion of security we use the former meaning,
   although it may also be important to be able to learn about whether a



Sollins                      Informational                     [Page 15]

RFC 2276            Uniform Resource Name Resolution        January 1998


   piece of information is from a primary source or not and request that
   it be primary.  This second meaning arises elsewhere in the document
   and is so noted there.

   It is also important to distinguish various possible meanings for
   "access control".  There are two areas in which distinctions can be
   made.  First, there is the question of the kind of access control
   that is being addressed, for example, in terms of hints whether it is
   read access, read and modify access, or read with verification for
   authenticity.  Second, there is the question of to what access is
   being controlled.  In the context of naming it might be the names
   themselves (not the case for URNs), the mapping of URNs to hints (the
   business of an RDS), the mapping of URNs to addresses (not the
   business of an RDS as will be discussed below in terms of privacy),
   or the resource itself (unrelated to naming or name resolution at
   all).  We attempt to be clear about what is meant when using "access
   control".

   There is one further issue to address at this point, the distinction
   between mechanism and policy.  In general, a policy is realized by
   means of a set of mechanisms.  In the case of an RDS there may be
   policies internal to the RDS that it needs to have supported in order
   to do its business as it sees fit.  Since, in general it is in the
   business of storing and distributing information, most of its
   security policies may have to do with maintaining its own integrity,
   and are rather limited.  Beyond that, to the degree possible, it
   should impose no policy on its customers, the publishers and users.
   It is they that may have policies that they would like supported by
   the RDS.  To that end, an RDS should provide a spectrum of "tools" or
   mechanisms that the customers can cause to be deployed on their
   behalf to realize policies.  An RDS may not provide all that is
   needed by a customer.  A customer may have different requirements
   within his or her administrative bounds than outside.  Thus, "it must
   be possible..."  captures the idea that the RDS must generally
   provide the tools to implement policies as needed by the customers.

   The first approach to URN resolution is to discover local hints.  In
   order for hints to be discovered locally, they will need to be as
   widely distributed as possible to what is considered to be local for
   every locale.  The drawback of such wide distribution is the wide
   distribution of updates, causing network traffic problems or delays
   in delivering updates.  An alternative model would concentrate hint
   information in servers, thus requiring that update information only
   be distributed to these servers.  In such a model the vulnerable
   points are the sources of the information and the distribution
   network among them.  Attackers on the integrity of the information
   stored in a server may come in the form of masquerading as the owner
   or the server of the information.  Wide replication of information



Sollins                      Informational                     [Page 16]

RFC 2276            Uniform Resource Name Resolution        January 1998


   among servers increases the difficult of masquerading at all the
   locations of the information as well as reducing the threat of denial
   service.  These lead us to three identifiable guidelines for our
   security model:

   * ACCESS CONTROL ON HINTS: It must be possible to create an
     authoritative version of each hint with change control limited only
     to those principals with the right to modify it.  The choice of who
     those principals are or whether they are unlimited must be made by
     the publisher of a hint.

   * SERVER AUTHENTICITY: Servers and clients must be able to learn the
     identity of the servers with which they communicate.  This will be
     a matter of degree and it is possible that there will be more
     trustworthy, but less accessible servers, supported by a larger
     cluster of less authenticatable servers that are more widely
     available.  In the worst case, if the client receives what appears
     to be unvalidated information, the client should assume that the
     hint may be inaccurate and confirmation of the data might be sought
     from more reliable but less accessible sources.

   * SERVER DISTRIBUTION: Broad availability will provide resistance to
     denial of service.  It is only to the extent that the services are
     available that they provide any degree of trustworthiness.  In
     addition, the distribution of services will reduce vulnerability of
     the whole community, by reducing the trust put in any single
     server.  This must be mitigated by the fact that to the extent
     trust is based on a linked set of servers, if any one fails, the
     whole chain of trust fails; the more elements there are in such a
     chain, the more vulnerable it may become.

   Privacy can be a double-edged sword.  For example, on one hand, an
   organization may consider it critically important that its
   competitors not be able to read its traffic.  On the other hand, it
   may also consider it important to be able to monitor exactly what its
   employees are transmitting to and from whom, for a variety of reasons
   such as reducing the probability that its employees are giving or
   selling the company's secrets to verifying that employees are not
   using company resources for private endeavor.  Thus, although there
   are likely to be needs for privacy and confidentiality, what they
   are, who controls them and how, and by what mechanisms vary widely
   enough that it is difficult to say anything concrete about them here.

   The privacy of publishers is much easier to address.  Since they are
   trying to publish something, in general privacy is probably not
   desired.  However, publishers do have information that they might
   like to keep private: information about who their clients are, and
   information about what names exist in their namespace.  The



Sollins                      Informational                     [Page 17]

RFC 2276            Uniform Resource Name Resolution        January 1998


   information about who their clients are may be difficult to collect
   depending on the implementation of the resolution system.  For
   example, if the resolution information relating to a given publisher
   is widely replicated, the hits to _each_ replicated copy would need
   to be recorded.  Of course, determining if a specific client is
   requesting a given name can be approached from the other direction,
   by watching the client as we saw above.

   There are likely to be some publishers publishing for a restricted
   audience.  To the extent they want to restrict access to a resource,
   that is the responsibility of the repository providing and
   restricting access to the resource.  If they wish to keep the name
   and hints for a resource private, a public RDS may be inadequate for
   their needs.  In general, it is intended for those who want customers
   to find their resources in an unconstrained fashion.

   The final privacy issue for publishers has to do with access control
   over URN resolution.  This issue is dependent on the implementation
   of the publisher's authoritative (in the sense of "primary) URN
   resolver server.  URN resolver servers can be designed to require
   proof of identity in order to be issued resolution information; if
   the client does not have permission to access the URN requested, the
   service denies that such a URN exists.  An encrypted protocol can
   also be used so that both the request and the response are obscured.
   Encryption is possible in this case because the identity of the final
   recipient is known (i.e.  the URN server).  Thus, access control over
   URN resolution can and should be provided by resolver servers rather
   than an RDS.

4. The Framework

   With these assumptions and guidelines in mind, we conclude with a
   general framework within which RDS designs may fall.  As stated
   earlier, although this framework is put forth as a suggested guide
   for RDS designers, compliance with it will in no way guarantee
   compliance with the guidelines.  Such an evaluation must be performed
   separately.  All such lack of compliance should be clearly
   documented.

   The design of the framework is based on the syntax of a URN as
   documented in RFC-2141 [6].  This is:

                              URN:<NID>:<NSS>

   where URN: is a prefix on all URNs, NID is the namespace identifier,
   and NSS is the namespace specific string.  The prefix identifies each
   URN as such.  The NID determines the general syntax for all URNs
   within its namespace.  The NSS is probably partitioned into a set of



Sollins                      Informational                     [Page 18]

RFC 2276            Uniform Resource Name Resolution        January 1998


   delegated and subdelegated namespaces, and this is possibly reflected
   in further syntax specifications.  In more complex environments, each
   delegated namespace will be permitted to choose the syntax of the
   variable part of the namespace that has been delegated to it.  In
   simpler namespaces, the syntax will be restricted completely by the
   parent namespace.  For example, although the DNS does not meet all
   the requirements for URNs, it has a completely restricted syntax,
   such that any further structuring must be done only by adding further
   refinements to the left, maintaining the high order to low order,
   right to left structure.  A delegated syntax might be one in which a
   host is named by the DNS, but to the right of that and separated by
   an "@" is a string whose internal ordering is defined by the file
   system on the host, which may be defined high order to low order,
   left to right.  Of course, much more complex and nested syntaxes
   should be possible, especially given the need to grandfather
   namespaces.  In order to resolve URNs, rules will be needed for two
   reasons.  One is simply to canonicalize those namespaces that do not
   fall into a straightforward (probably right to left or left to right)
   ordering of the components of a URN, as determined by the delegated
   naming authorities involved.  It is also possible that rules will be
   needed in order to derive from URNs the names of RDS servers to be
   used in stages.





























Sollins                      Informational                     [Page 19]

RFC 2276            Uniform Resource Name Resolution        January 1998


                            URN:<NID><NSS>
                                 |
                                 |
                                 |
                                 |
                                 v
                       +-------------------+
                       |Global NID registry|
                       +-------------------+
                                 |