rfc1507.txt

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

   DASS mechanisms generally deal with authentication between principals
   each knowing a private key.  For principals who are people, special
   mechanisms are provided for maintaining that private key.  In
   particular, it many cases it will be most convenient to keep
   passwords as secrets rather than private keys.  This architecture
   specifies a means of storing private keys encrypted under passwords.
   This would provide security as good as hiding a private key were it
   not that people tend to choose passwords from a small space (like
   words in a dictionary) such that a password can be more easily
   guessed than a private key.  To address this potential weakness, DASS
   specifies a protocol between a login node and a login agent whereby
   the login agent can audit and limit the rate of password guesses.
   Use of these features is optional.  A user with a smart card could
   store a private key directly and bypass all of these mechanisms.  If
   users can be forced to choose "good" passwords, the login agent could
   be eliminated and encrypted credentials could be stored directly in
   the naming service.




Kaufman                                                        [Page 10]

RFC 1507                          DASS                    September 1993


   Another way in which user keys are protected is that the architecture
   does not require that they be available except briefly at login.
   This reduces the threat of a user walking away from a logged on
   workstation and having someone take over the workstation and extract
   his key.  It also makes the use of RSA based smart cards practical;
   the card could keep the user's private key and execute one signature
   operation at login time to authenticate an entire session.

1.3 What This Document Won't Tell You

   Architecture documents are by their nature difficult to read.  This
   one is no exception. The reason is that an architecture document
   contains the details sufficient to build interoperable
   implementations, but it is not a design specification. It goes out of
   its way to leave out any details which an implementation could choose
   without affecting interoperability. It also does not specify all the
   uses of the services provided because these services are properly
   regarded as general purpose tools.

   The remainder of this section includes information which is not
   properly part of the authentication architecture, but which may be
   useful in understanding why the architecture is the way it is.

1.3.1 How DASS is Embedded in an Operating System

   While architecturally DASS does not require any operating system
   support in order to be used by an application (other than the
   services listed in Section 2), it is expected that actual
   implementations of DASS will be closely tied to the operating systems
   of host computers.  This is done both for security and for
   convenience.

   In particular, it is expected that when a user logs into a node, a
   set of credentials will be created for that user and then associated
   by the operating system with all processes initiated by or on behalf
   of the user.  When a user delegates to a service, the remote
   operating system is expected to accept the delegation and start up
   the remote process with the delegated credentials.  Most nodes are
   expected to have credentials of their own and support the concept of
   user accounts.  When user credentials are created, the node is
   expected to verify them in its own context, determine the appropriate
   user account, and add node credentials to the created credentials
   set.

1.3.2 Forms of Credentials

   In the DASS architecture, there is a single data structure called
   "Credentials" with a large number of optional parts.  In an



Kaufman                                                        [Page 11]

RFC 1507                          DASS                    September 1993


   implementation, it is possible that not all of the architecturally
   allowed subsets will be supported and credentials structures with
   different subsets of the data may be implemented quite differently.

   The major categories of credentials likely to be supported in an
   implementation are:

    - Claimant credentials  - these are the credentials which would
      normally be associated with a user process in order that it be
      able to create authentication tokens.  It would contain the
      user's name, login ticket, session private key, and (at least
      logically) local node credentials and cached outgoing
      contexts.

    - Verifier credentials -  these are the credentials which would
      normally be associated with a server which must verify tokens
      and produce mutual authentication response tokens.  Since
      servers may be started by a node on demand, some
      representation of verifier credentials must exist independent
      of a process.  If an operating system wishes to authenticate a
      request before starting a server process, the credentials must
      exist in usable form.  An implementation may choose to have
      all services on a "node" share a verifier credentials
      structure, or it may choose to have each service have its own.

    - Combined credentials - architecturally, a server may have a
      structure which is both claimant credentials and verifier
      credentials combined so that the server may act in either role
      using a single structure.  There is some overlap in the
      contents.  There is no requirement, however, that an
      implementation support such a structure.

    - Stub credentials - In the architecture, a credentials
      structure is created whenever a token is accepted.  If delegation
      took place, these are claimant credentials usable by their
      possessor to create additional tokens.  If no delegation took
      place, this structure exists as an architectural place holder
      against which an implementation may attempt to authenticate
      user and node names.  An implementation might choose to
      implement  stub credentials  with a different mechanism than
      claimant or verifier credentials.  In particular, it might do
      whatever user and node authentication is useful itself and not
      support this structure at all.








Kaufman                                                        [Page 12]

RFC 1507                          DASS                    September 1993


1.3.3 Support for Alternative Certification Authority
      Implementations

   A motivating factor in much of the design of DASS is the need to
   protect certification authorities from compromise. CAs are only used
   to create certificates for new principals and to renew them on
   expiration (expiration intervals are likely to be measured in
   months). They therefore do not need to be highly available. For
   maximum security, CAs could be implemented on standalone PCs where
   the hardware, software, and keys can be locked in a safe when the CA
   is not in use. The certificates the CA generates must be delivered to
   the naming service to be registered, and a possible mechanism for
   this is for the CA to have an RS232 line to an on-line component
   which can pass certificates and related information but not login
   sessions. The intent would be to make it implausible to mount a
   network attack against the CA.  Alternatively, certificates could be
   carried to the network on a floppy disk.

   For CAs to be secure, a whole host of design details must be done
   right. The most important of these is the design of user and system
   manager interfaces that make it difficult to "trick" a user or system
   manager into doing the wrong thing and certifying an impostor or
   revealing a key. Mechanisms for generating keys must also be
   carefully protected to assure that the generated key cannot be
   guessed (because of lack of randomness) and is not recorded where a
   penetrator can get it. Because a certificate contains relatively
   little human intelligible information (its most important components
   are UIDs and public keys), it will be a challenge to design a user
   interface that assures the human operator only authorizes the signing
   of intented certificates. Such considerations are beyond the scope of
   the architecture (since they do not affect interoperability), but
   they did affect the design in subtle ways.  In particular, it does
   not assume uniform security throughout the CA hierarchy and is
   designed to assure that the compromise of a CA in one part of the
   hierarchy does not have global implications.

   The architecture does not require that CAs be off-line. The CA could
   be software that can run on any node when the proper secret is
   installed.  Administrative convenience can be gained by integrating
   the CA with account registration utilities and naming service
   maintenance. As such, the CA would have to be on-line when in use in
   order to register certificates in the naming service.  The CA key
   could be unlocked with a password and the password could be entered
   on each use both to authenticate the CA operator and to assure that
   compromise of the host node while the CA is not in use will not
   compromise the CA.  This design would be subject to attacks based on
   planting Trojan horses in the CA software, but is entirely
   interoperable with a more secure implementation.  Realistic tradeoffs



Kaufman                                                        [Page 13]

RFC 1507                          DASS                    September 1993


   must be made between security, cost, and administrative convenience
   bearing in mind that a system is only as secure as its weakest link
   and that there is no benefit in making the CA substantially more
   secure than the other components of the system.

1.3.4 Services Provided vs. Application Program Interface

   Section 3 of this document specifies "abstract interfaces" to the
   services provided by DASS. This means it tells what services are
   provided, what parameters are supplied by the caller, and what data
   is returned. It does not specify the calling interfaces.  Calling
   interfaces may be platform, operating system, and language dependent.
   They do not affect interoperability; different implementations which
   implement completely different calling interfaces can still
   interoperate over a network. They do, however, affect portability. A
   program which runs on one platform can only run on another which
   implements an identical API.

   In order to support portability of applications - not just between
   implementations of DASS but between implementations of DASS and
   implementations of Kerberos - a "Generic Security Service API" has
   been designed and is outlined in Annex B. This API could be the only
   "published" interface to DASS services.  This interface does not,
   however, give access to all the functions provided by DASS and it
   provides some non-DASS services. It does not give access to the
   "login" service, for example, so the login function cannot be
   implemented in a portable way. Clearly an implementation must provide
   some implementation of the login function, though perhaps only to one
   system program and the implementation need not be portable.
   Similarly, the Generic API provides no access to node authentication
   information, so applications which use these services may not be
   portable.

   The Generic API provides services for encryption of user data for
   integrity and possibly privacy. These services are not specified as a
   part of the DASS architecture. This is because we envisioned that
   such services would be provided by the communications network and not
   in applications. These services are provided by the Generic API
   because these services are provided by Kerberos, there exist
   applications which use these services, and they are desired in the
   context of the IETF-CAT work. The DASS architecture includes a Key
   Distribution service so that the encryption functions of the Generic
   API can be supported and integrated. Annex B specifies how those
   services can be implemented using DASS services.

   The Services Provided also differ from the GSSAPI because there are
   important extensions envisioned to the API for future applications
   and it was important to assure that architecturally those services



Kaufman                                                        [Page 14]

RFC 1507                          DASS                    September 1993


   were available.  In particular, DASS provides the ability for a
   principal to have multiple aliases and for the receiver of an
   authentication token to verify any one of them.  We want DASS to
   support the case where a server only learns the name it is trying to
   validate in the course of evaluating an ACL.  This may be long after
   a connection is accepted.  The Services Provided section therefore
   separates the Accept_token function from the Verify Principal Name.
   The other motivation behind a different interface is that DASS
   provides node authentication - the ability to authenticate the node
   from which a request originates as well as the user.  Because
   Kerberos provides no such mechanism, the capability is missing from
   the GSSAPI, but we expect some applications will want to make use of
   it.

1.3.5 Use of a Naming Service

   With the exception of the syntactical representation of names, which
   is tied to X.500, the DASS architecture is designed to be independent
   of the particular underlying naming service.  While the intention is
   that certificates be stored in an X.500 naming service in the fields