rfc1507.txt

RFC 的详细文档！

   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
   architecturally reserved for this purpose in the standard, this
   specification allows for the possibility of different forms of
   certificate stores.  The SPX implementation of DASS implements its
   own certificate distribution service because we did not want to
   introduce a dependency on an X.500 naming service.

1.3.6 Key Hiding - Credentials

   The abstract interfaces described in section 3 specify that
   "credentials" and "keys" are the inputs and outputs of various
   routines.  Credentials structures in particular contain secret
   information which should not be made available to the calling
   application.  In most cases, keeping this information from
   applications is simply a matter of prudence - a misbehaving
   application can do nearly as much damage using the credentials as it
   can by using the secrets directly.  Having access to the keys
   themselves may allow an application to bypass auditing or leak a key
   to an accomplice who can use it on another node where a large amount
   of activity is less likely to be noticed.  In some cases, most
   dramatically where a "node key" is present in user credentials, it is
   vital that the contents of the credentials be kept out of the hands
   of applications.

   To accomplish this, a concrete interface is expected to create
   "credentials handles" that are passed in and out of DASS routines.
   The credentials themselves would be kept in some portion of memory
   where unprivileged code can't get at them.




Kaufman                                                        [Page 15]

RFC 1507                          DASS                    September 1993


   There is another aspect of the way credentials are used which is
   important to the design of real implementations.  In normal use, a
   user will create a set of credentials in the process of logging on to
   a system and then use them from many processes or jobs.  When many
   processes share a set of credentials, it is important for the sake of
   performance that they share one set of credentials rather than having
   a copy of the credentials made for each.  This is because information
   is cached in credentials as a side effect of some requests and for
   good performance those caches should be shared.

   As an example, consider a system executing a series of copy commands
   moving files from one system to another.  The credentials of the user
   will have been established when the user logged on.  The first time a
   copy is requested, a new process will start up, open a connection to
   the destination system, and create a token to authenticate itself.
   Creating that token will be an expensive operation, but information
   will be computed and "cached" in the credentials structure which will
   allow any subsequent tokens on behalf of that user to that server to
   be computed cheaply.  After the copy completes, the connection is
   closed and the process terminates.  In response to a second copy
   request, another new process will be created and a new token
   computed.  For this operation to get a performance benefit from the
   caching, the information computed by the first process must somehow
   make it to the second.

   A model for how this caching might work can be seen in the way
   Kerberos caches credentials.  Kerberos keeps credentials in a file
   whose name can be computed from the name of the local user.  This
   file is initialized as part of the login process and its protection
   is set so that only processes running under the UID of the user may
   read and write the file.  Processes cache information there; all
   processes running on behalf of the user share the file.

   There are two problems with this scheme: first, on a diskless node
   putting information in a file exposes it to eavesdroppers on the
   network; second, it does not accomplish the "key hiding" function
   described earlier in this section.  In a more secure implementation,
   the kernel or a privileged process would manage some "pool" of
   credentials for all processes on a node and would grant access to
   them only through the DASS calls.  Credentials structures are complex
   and varying length; DASS may organize them as a set of pools rather
   than as contiguous blocks of data.  All such design issues are
   "beyond the scope of the architecture".  Implementations must decide
   how to control access to credentials.  They could copy the Kerberos
   scheme of having credentials available to processes with the UID of
   the login session which created them and to privileged processes or
   there may be a more elaborate mechanism for "passing" credentials
   handles from process to process.  This design should probably follow



Kaufman                                                        [Page 16]

RFC 1507                          DASS                    September 1993


   the operating system mechanisms for passing around local privileges.

1.3.7 Key Hiding - Contexts

   The "GSSAPI" has a concept of a security context which has some of
   the same key hiding problems as a credentials structure.  Security
   contexts are used in calls to cryptographically protect user data
   (from modification or from disclosure and modification) using keys
   established during authentication.  The "services provided"
   specification says that create_ and accept_token return a "shared
   key" and "instance identifier".  The GSSAPI says that a context
   handle is returned which is an integer.  A secure implementation
   would keep the key and instance identifier in protected memory and
   only allow access to them through provided interfaces.

   Unlike credentials, there is probably no need to provide mechanisms
   for contexts to be shared between processes.  Contexts will normally
   be associated with some notion of a communications "connection" and
   ends of a connection are not normally shared.  If an implementation
   chooses to provide additional services to applications like message
   sequencing or duplicate detection, contexts will have to contain
   additional fields.  These can be created and maintained without any
   additional authentication services.

1.4 The Relationship between DASS and ISO Standards

   This section provides an introduction to DASS authentication in terms
   of the ISO Authentication Framework (DP10181-2).   The purpose of
   this introduction is to give the reader an intuitive understanding of
   the way DASS works and how its mechanisms and terminology relate to
   standards.  Important details have been omitted here but are spelled
   out in section 3.

1.4.1 Concepts

   The primary goal of authentication is to prevent impersonation, that
   is, the pretense to a false identity. Authentication always involves
   identification in some form. Without authentication, anyone could
   claim to be whomever they wished and get away with it.

   If it didn't matter with whom one was communicating, elaborate
   procedures for authentication would be unnecessary. However, in most
   systems, and in timesharing and distributed processing environments
   in particular, the rights of individuals are often circumscribed by
   security policy. In particular, authorization (identity based access
   control) and accountability (audit) provisions could be circumvented
   if masquerading attempts were impossible to prevent or detect.




Kaufman                                                        [Page 17]

RFC 1507                          DASS                    September 1993


   Almost all practical authentication mechanisms suitable for use in
   distributed environments rely on knowledge of some secret
   information. Most differences lie in how one presents evidence that
   they know the secret. Some schemes, in particular the familiar simple
   use of passwords, are quite susceptible to attack. Generally, the
   threats to authentication may be classified as:

    - forgery, attempting to guess or otherwise fabricate evidence;

    - replay, where one can eavesdrop upon another's authentication
      exchange and learn enough to impersonate them; and

    - interception, where one slips between the communicants and is
      able to modify the communications channel unnoticed.

   Most such attacks can be countered by using what is known as strong
   authentication. Strong authentication refers to techniques that
   permit one to provide evidence that they know a particular secret
   without revealing even a hint about the secret. Thus neither the
   entity to whom one is authenticating, nor an eavesdropper on the
   conversation can further their ability to impersonate the
   authenticating principal at some future time as the result of an
   authentication exchange.

   Strong authentication mechanisms, in particular those used here, rely
   on cryptographic techniques. In particular, DASS uses public key
   cryptography. Note that interception attacks cannot be countered by
   strong authentication alone, but generally need additional security
   mechanisms to secure the communication channel, such as data
   encryption.

1.4.2 Principals and Their Roles

   All authentication is on behalf of principals. In DASS the following
   types of principals are recognized:

    - user principals, normally people with accounts who are
      responsible for performing particular tasks. Generally it is
      users that are authorized to do things by virtue of having
      been granted access rights, or who are to be held accountable
      for specific actions subject to being audited.

    - server principals, which are accessed by users.

    - node principals,  corresponding to locations where users and
      servers, or more accurately, processes acting on behalf of
      principals can reside.




Kaufman                                                        [Page 18]

RFC 1507                          DASS                    September 1993


   Principals can act in one of two capacities:

    - the claimant is the active entity seeking to authenticate
      itself, and

    - the verifier is the passive entity to whom the claimant is
      authenticating.

   Users normally are claimants, whereas servers are usually verifiers,
   although sometimes servers can also be claimants.

   There is another kind of principal:

    - certification authorities (CA's) issue certificates which
      attest to another principal's public key.

1.4.3 Representation, Delegation and Representation Transfer

   Of course, although it is users that are responsible for what the
   computer does, human beings are physically unable to directly do
   anything within a computer system. In point of fact, it is a
   process executing on behalf of a user that actually performs
   useful work. From the point of view of performing security
   controlled functions, the process is the agent, or
   representative, of the user, and is authorized by that user to do
   things on his behalf. In the terms used in the ISO Authentication
   Framework, the user is said to have a representation in the
   process.

   The representation has to come into existence somehow.  Delegation
   refers to the act of creating a representation. A user is said to
   create a representation for themselves by delegating to a process. If
   the user creates another process, say by doing an rlogin on a
   different computer, a representation may be needed there as well. This
   may be accomplished automatically by a process known as representation
   transfer.  DASS uses the term delegation to also mean the act of
   creating additional representations on a remote systems.

   A representation is instantiated in DASS as credentials.  Credentials
   include the identity of the principal as well as the cryptographic
   "state" needed to engage in strong authentication procedures. Claimant
   information in credentials enable principals to authenticate