rfc1507.txt

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

Network Working Group                                         C. Kaufman
Request for Comments: 1507                 Digital Equipment Corporation
                                                          September 1993


                                  DASS
              Distributed Authentication Security Service

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "Internet Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Table of Contents

    1.   Introduction ................................................ 2
         1.1  What is DASS? .......................................... 2
         1.2  Central Concepts ....................................... 4
         1.3  What This Document Won't Tell You ..................... 11
         1.4  The Relationship between DASS and ISO Standards ....... 17
         1.5  An Authentication Walkthrough ......................... 20
    2.   Services Used .............................................. 25
         2.1  Time Service .......................................... 25
         2.2  Random Numbers ........................................ 26
         2.3  Naming Service ........................................ 26
    3.   Services Provided .......................................... 37
         3.1  Certificate Contents .................................. 38
         3.2  Encrypted Private Key Structure ....................... 40
         3.3  Authentication Tokens ................................. 40
         3.4  Credentials ........................................... 43
         3.5  CA State .............................................. 47
         3.6  Data types used in the routines ....................... 47
         3.7  Error conditions ...................................... 49
         3.8  Certificate Maintenance Functions ..................... 49
         3.9  Credential Maintenance Functions ...................... 55
         3.10 Authentication Procedures ............................. 63
         3.11 DASSlessness Determination Functions .................. 87
    4.   Certificate and message formats ............................ 89
         4.1  ASN.1 encodings ....................................... 89
         4.2  Encoding Rules ........................................ 96
         4.3  Version numbers and forward compatibility ............. 96
         4.4  Cryptographic Encodings ............................... 97
    Annex A - Typical Usage ........................................ 101
         A.1  Creating a CA ........................................ 101



Kaufman                                                         [Page 1]

RFC 1507                          DASS                    September 1993


         A.2  Creating a User Principal ............................ 102
         A.3  Creating a Server Principal .......................... 103
         A.4  Booting a Server Principal ........................... 103
         A.5  A user logs on to the network ........................ 103
         A.6  An Rlogin (TCP/IP) connection is made ................ 104
         A.7  A Transport-Independent Connection ................... 104
    Annex B - Support of the GSSAPI ................................ 104
         B.1  Summary of GSSAPI .................................... 105
         B.2  Implementation of GSSAPI over DASS ................... 106
         B.3  Syntax ............................................... 110
    Annex C - Imported ASN.1 definitions ........................... 112
    Glossary ....................................................... 114
   Security Considerations ......................................... 119
   Author's Address ................................................ 119
   Figures
    Figure 1 - Authentication Exchange Overview ....................  24

1. Introduction

1.1 What is DASS?

   Authentication is a security service. The goal of authentication is
   to reliably learn the name of the originator of a message or request.
   The classic way by which people authenticate to computers (and by
   which computers authenticate to one another) is by supplying a
   password.  There are a number of problems with existing password
   based schemes which DASS attempts to solve.  The goal of DASS is to
   provide authentication services in a distributed environment which
   are both more secure (more difficult for a bad guy to impersonate a
   good guy) and easier to use than existing mechanisms.

   In a distributed environment, authentication is particularly
   challenging.  Users do not simply log on to one machine and use
   resources there.  Users start processes on one machine which may
   request services on another.  In some cases, the second system must
   request services from a third system on behalf of the user.  Further,
   given current network technology, it is fairly easy to eavesdrop on
   conversations between computers and pick up any passwords that might
   be going by.

   DASS uses cryptographic mechanisms to provide "strong, mutual"
   authentication.  Mutual authentication means that the two parties
   communicating each reliably learn the name of the other.  Strong
   authentication means that in the exchange neither obtains any
   information that it could use to impersonate the other to a third
   party.  This can't be done with passwords alone.  Mutual
   authentication can be done with passwords by having a "sign" and a
   "counter-sign" which the two parties must utter to assure one another



Kaufman                                                         [Page 2]

RFC 1507                          DASS                    September 1993


   of their identities.  But whichever party speaks first reveals
   information which can be used by the second (unauthenticated) party
   to impersonate it.  Longer sequences (often seen in spy movies)
   cannot solve the problem in general.  Further, anyone who can
   eavesdrop on the conversation can impersonate either party in a
   subsequent conversation (unless passwords are only good once).
   Cryptography provides a means whereby one can prove knowledge of a
   secret without revealing it.  People cannot execute cryptographic
   algorithms in their heads, and thus cannot strongly authenticate to
   computers directly.  DASS lays the groundwork for "smart cards":
   microcomputers sealed in credit cards which when activated by a PIN
   will strongly authenticate to a computer.  Until smart cards are
   available, the first link from a user to a DASS node remains
   vulnerable to eavesdropping.  DASS mechanisms are constructed so that
   after the initial authentication, smart card or password based
   authentication looks the same.

   Today, systems are constructed to think of user identities in terms
   of accounts on individual computers.  If I have accounts on ten
   machines, there is no way a priori to see that those ten accounts all
   belong to the same individual.  If I want to be able to access a
   resource through any of the ten machines, I must tell the resource
   about all ten accounts.  I must also tell the resource when I get an
   eleventh account.

   DASS supports the concept of global identity and network login.  A
   user is assigned a name from a global namespace and that name will be
   recognized by any node in the network.  (In some cases, a resource
   may be configured as accessible only by a particular user acting
   through a particular node.  That is an access control decision, and
   it is supported by DASS, but the user is still known by his global
   identity).  From a practical point of view, this means that a user
   can have a single password (or smart card) which can be used on all
   systems which allow him access and access control mechanisms can
   conveniently give access to a user through any computer the user
   happens to be logged into.  Because a single user secret is good on
   all systems, it should never be necessary for a user to enter a
   password other than at initial login.  Because cryptographic
   mechanisms are used, the password should never appear on the network
   beyond the initial login node.

   DASS was designed as a component of the Distributed System Security
   Architecture (DSSA) (see "The Digital Distributed System Security
   Architecture" by M. Gasser, A. Goldstein, C. Kaufman, and B. Lampson,
   1989 National Computer Security Conference).  It is a goal of DSSA
   that access control on all systems be based on users' global names
   and the concept of "accounts" on computers eventually be replaced
   with unnamed rights to execute processes on those computers.  Until



Kaufman                                                         [Page 3]

RFC 1507                          DASS                    September 1993


   this happens, computers will continue to support the concept of
   "local accounts" and access controls on resources on those systems
   will still be based on those accounts.  There is today within the
   Berkeley rtools running over the Internet Protocol suite the concept
   of a ".rhosts database" which gives access to local accounts from
   remote accounts.  We envision that those databases will be extended
   to support granting access to local accounts based on DASS global
   names as a bridge between the past and the future.  DASS should
   greatly simplify the administration of those databases for the
   (presumably common) case where a user should be granted access to an
   account ignoring his choice of intermediate systems.

1.2 Central Concepts

1.2.1 Strong Authentication with Public Keys

   DASS makes heavy use of the RSA Public Key cryptosystem.  The
   important properties of the RSA algorithms for purposes of this
   discussion are:

    - It supports the creation of a public/private key pair, where
      operations with one key of the pair reverse the operations of
      the other, but it is computationally infeasible to derive the
      private key from the public key.

    - It supports the "signing" of a message with the private key,
      after which anyone knowing the public key can "verify" the
      signature and know that it was constructed with knowledge of
      the private key and that the message was not subsequently
      altered.

    - It supports the "enciphering" of a message by anyone knowing
      the public key such that only someone with knowledge of the
      private key can recover the message.

   With access to the RSA algorithms, it is easy to see how one could
   construct a "strong" authentication mechanism.  Each "principal"
   (user or computer) would construct a public/private key pair, publish
   the public key, and keep secret the private key.  To authenticate to
   you, I would write a message, sign it with my private key, and send
   it to you.  You would verify the message using my public key and know
   the message came from me.  If mutual authentication were desired, you
   could create an acknowledgment and sign it with your private key; I
   could verify it with your public key and I would know you received my
   message.

   The authentication algorithms used by DASS are considerably more
   complex than those described in the paragraph above in order to deal



Kaufman                                                         [Page 4]

RFC 1507                          DASS                    September 1993


   with a large number of practical concerns including subtle security
   threats.  Some of these are discussed below.

1.2.2 Timestamps vs. Challenge/Response

   Cryptosystems give you the ability to sign messages so that the
   receiver has assurance that the signer of the message knew some
   cryptographic secret.  Free-standing public key based authentication
   is sufficiently expensive that it is unlikely that anyone would want
   to sign every message of an interactive communication, and even if
   they did they would still face the threat of someone rearranging the
   messages or playing them multiple times.  Authentication generally
   takes place in the context of establishing some sort of "connection,"
   where a conversation will ensue under the auspices of the single
   peer-entity authentication.  This connection might be
   cryptographically protected against modification or reordering of the
   messages, but any such protection would be largely independent of the
   authentication which occurred at the start of the connection.  DASS
   provides as a side effect of authentication the provision of a shared
   key which may be used for this purpose.

   If in our simple minded authentication above, I signed the message
   "It's really me!" with my private key and sent it to you, you could
   verify the signature and know the message came from me and give the
   connection in which this message arrived access to my resources.
   Anyone watching this message over the network, however, could replay
   it to any server (just like a password!) and impersonate me.  It is
   important that the message I send you only be accepted by you and
   only once.  I can prevent the message from being useful at any other
   server by including your name in the message.  You will only accept
   the message if you see your name in it.  Keeping you from accepting
   the message twice is harder.

   There are two "standard" ways of providing this replay protection.
   One is called challenge/response and the other is called timestamp-
   based.  In a challenge response type scheme, I tell you I want to
   authenticate, you generate a "challenge" (generally a number), and I
   include the challenge in the message I sign.  You will only accept a
   message if it contains the recently generated challenge and you will
   make sure you never issue the same challenge to me twice (either by