rfc1430.txt

<VC++网络游戏建摸与实现>源代码


RFC 1430                     X.500 Strategy                February 1993


   This means that whilst we will attempt to solve a wider range of
   problems, not all potential requirements will necessarily be met.

   The technical work is done in conjunction with the RARE WG on Network
   Application Support WG (formerly RARE WG3). The IETF WGs and the RARE
   WG have a common technical mailing list. It is intended that this
   will lead to a common European and North American technical approach.

7.1   Schema

   A Directory needs to be used in the context of an Information
   Framework. The standard directory provides a number of a attributes
   and object classes to enable basic operation. It is certain that the
   Internet community will have requirements for additional attributes
   and object classes. There is a need to establish a mechanism to
   register such information.

   Pilots in the European RARE Community and the US PSI White Pages
   Pilot have based their information framework on the THORN and RARE
   Naming Architecture. This architecture should be used for the
   Internet Directory Service, in conjunction with COSINE based services
   in Europe. A revised version of the Naming Architecture, with a
   mechanism for registration of new attributes and object classes, has
   been released as RFC 1274 [BHK91a].

7.2   Use on the Internet

   It is a recognized policy on the Internet to deploy OSI Applications
   over non-OSI lower layers (such as STD 35, RFC 1006) [RC87]. This
   policy allows deployment of OSI Applications before an OSI lower
   layer infrastructure has been deployed. Thus, the Internet Directory
   Service will decouple deployment of the OSI Directory from deployment
   of the OSI lower layers. As the Internet Directory service will
   extend into the far corners of the Internet namespace, where the
   underlying technology is not always TCP/IP, the Internet Directory
   Service will not make any mandatory requirements about use of lower
   layers. When configuring the Internet Directory Services, variations
   in the lower layers must be considered. The following options are
   possible:

   - Operation on top of TCP/IP using a lightweight protocol.

   - Operation over TCP/IP using STD 35, RFC 1006. This is a practical
     requirement of deployment at very many Internet sites, and is the
     basis of the existing services. It is highly recommended that all
     participating DSAs support this stack.

   - Use of OSI Network Service (Connection Oriented or Connectionless).



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 11]

RFC 1430                     X.500 Strategy                February 1993


   - X.25(80) will probably not be used in the core infrastructure of
     the Internet Directory Service, but is the basis of some European
     activities.  It may be needed later to interconnect with US
     commercial systems not on the Internet. There will be a practical
     need to interwork with DSAs which only support this stack.

   This approach has the following implications:

   1. There is a need to represent TCP/IP addresses within OSI Network
      Addresses. This is specified in RFC 1277 [HK91a].

   2. It will be desirable to have a uniform method to present Network
      Addresses of this style. Therefore, a string representation of
      presentation addresses is specified in RFC 1278 [HK91d].

   3. This approach leads to the situation where not all DSAs can
      communicate directly due the different choice of lower layers.
      This is already a practical result of many European sites operating
      DSAs over X.25.  When the Internet Directory Service is deployed,
      the issue of which DSAs operate which stacks must be considered in
      order to achieve a coherent service.  In particular, there may be a
      need to require DSAs that serve parts higher up in the DIT to serve
      multiple stacks. This will be tackled as an operational issue.

   4. There may be a requirement to extend the distributed operations, so
      that there is no requirement for full connectivity (i.e., each DSA
      supports each stack). A solution to this problem, by defining
      "relay DSAs" is specified in RFC 1276 [HK91b].

7.3   Replication of Knowledge and Data

   There are a number of requirements on replication, both of data (the
   actual information on objects in the directory) and knowledge (the
   information on where do I find what data) information, which must be
   met before an Internet Directory can be deployed. The 1988 standard
   cannot be used as is, because it does not deal with replication or
   caching. This leads to serious problems with performance. There is a
   partial solution available in the 1992 version of the standard,
   however there are no products available yet that implement this
   solution.  These issues are discussed in more detail in RFC 1275
   [HK91c].

   As it took too long for 1992 implementations to arrive to be of any
   help to the already rapidly growing pilot that urgently needed a
   solution, an option was chosen to use a simple interim approach as
   defined in RFC 1276.  It will be clearly emphasized that this is an
   interim approach, which will be phased out as soon as the appropriate
   standards are available and stable implementations are deployed. The



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 12]

RFC 1430                     X.500 Strategy                February 1993


   interim approach is based on the approach used in the QUIPU
   Implementation and it is widely deployed in the existing pilots.

7.4   Presentation of Directory Names

   The standard does not specify a means to present directory names to
   the user. This is seen as a serious deficiency, and a standard for
   presenting directory names is required. For Distinguished Names, a
   string representation is defined in [HK92a]. However, as the
   distinguished name is not very friendly for the user, a more user
   oriented specification of a standard format for representing names,
   and procedures to resolve them is chosen on the Internet, and is
   specified in [HK92b].

7.5   DSA Naming and MD Structure

   There are some critical issues related to naming of DSAs and the
   structure of Directory Management Domains. The main issues are:

   - It is hard to achieve very high replication of knowledge
     information as this is very widely spread;

   - There is a need to give DSAs more reasonable names, which will
     contain an indication on the role of the DSA; This is necessary for
     DSAs high up the DIT.

   - There is too much DIT clutter in the current pilots;

   - There is no real concept of a DMD (Directory Management Domain)
     authority.

   These will be significant as the directory increases in size by
   orders of magnitude. The IETF OSI-DS WG is working to develop a
   solution in this area.

8. SECURITY

   A Directory can be an important component in the overall provision of
   security in a distributed system environment, especially when
   public-key cryptographic technology is employed. The directory can
   serve as a repository for authentication information, which, in turn,
   forms the basis of a number of OSI Authentication Services (e.g.,
   X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM). The
   directory may also use this and other stored authentication
   information to provide a wide range of security Services used by the
   Directory system itself.





Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 13]

RFC 1430                     X.500 Strategy                February 1993


8.1   Directory Provision of Authentication

   The directory will be used to provide X.509 strong authentication.
   This places minimal requirements on the directory. To use this
   infrastructure, users of authentication services must have access to
   the directory. In practice, this type of authentication can be
   deployed only on a limited scale without use of a directory, and so
   this provision is critical for applications such as Privacy Enhanced
   Mail [Lin93]. The PEM development is considering issues relating to
   deploying Certification Authorities, and this discussion is not
   duplicated here.

   PEM defines a key management architecture based on the use of
   public-key certificates, in support of the message encipherment and
   authentication procedures defined in [Lin93]. The PEM certificate
   management design [Ken93] makes use of the authentication framework
   defined by X.509. In this framework, as adopted by PEM, a
   "certification authority" representing an organization applies a
   digital signature to a collection of data consisting of a user's
   public component, various information that serves to identify the
   user, and the identity of the organization whose signature is
   affixed.  This establishes a binding between these user credentials,
   the user's public component and the organization which vouches for
   this binding. The resulting, signed, data item is called a
   certificate. The organization identified as the certifying authority
   for the certificate is the "issuer" of that certificate. The format
   of the certificate is defined in X.509.

   In signing the certificate, the certification authority vouches for
   the user's identification, in the context specified by the identity
   of the issuer. Various types of organization may issue certificates,
   including corporate, educational, professional, or governmental
   entities. Moreover, these issuers may operate under different
   certification policies, so that not all certificates may be equally
   credible (i.e., some certificates may be more trustworthy as accurate
   identifiers of users, organizations, mailing lists, etc). The PEM
   certificate management design allows for this diversity of
   certification policies, while ensuring that any certificate can be
   traced unambiguously to the policy under which it was issued.

   The digital signature is affixed on behalf of that organization and
   is in a form which can be recognized by all members of the privacy-
   enhanced electronic mail community. This ability to universally
   verify any PEM certificate results because the PEM certification
   design is a singly rooted tree, in which the Internet Society acts as
   the root. Once generated, certificates can be stored in directory
   servers, transmitted via unsecure message exchanges, or distributed
   via any other means that make certificates easily accessible to



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 14]

RFC 1430                     X.500 Strategy                February 1993


   message originators, without regard for the security of the
   transmission medium.

8.2   Directory Security

   A number of security services are possible with the directory:

   Peer Authentication at Bind
      Authentication (one or two way) between DUA/DSA and DSA/DSA,
      established during the bind operation. This authentication may be
      provided using simple passwords (not recommended), one-way hashed
      passwords (more secure), or via public key cryptography (most
      secure). The various authentication options are specified in
      X.500(88), but most existent implementations implement only simple
      password authentication.

   Per-operation Authentication and Integrity
      This is usually used to identify the DUA originating an operation
      to the Directory (e.g., to authenticate prior to data
      modification). It may also be used to verify the identity of the
      DSA which provided data in a response to the user. In both
      examples, the integrity of the data also is ensured through the
      use of digital signatures. This is specified in X.500(88), but not
      yet widely implemented.

   Single Entry Access Control
      This is used to control which users (DUAs) can access and modify
      data within an entry. This is specified in X.500(92) and most DSA
      implementations provide this function.

   Multiple Entry Access Control
      This is used to control search and list operations, in order to
      allow location of information by searching, but to deter
      "trawling" of information and organizational structure. Usually,
      these access controls are limited in their ability to prevent
      trawling because of the conflicting goal of allowing a certain
      level of legitimate browsing in support of "white pages"
      functionality.

   Service Authorization
      This allows DSAs to control service in a data independent manner,
      based on peer authentication. For example, one might prevent
      students from making non-local queries, while permitting such
      queries by faculty and staff.







Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 15]