rfc1507.txt

RFC 的详细文档！

   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
   using a sequence number, a timestamp, or a random number big enough
   that the probability of a duplicate is negligible).  In the
   timestamp-based scheme, I include the current time in my message.
   You have a rule that you will not accept messages more than - say -
   five minutes old and you keep track of all messages you've seen in
   the last five minutes.  If someone replays the message within five
   minutes, you will reject it because you will remember you've seen it
   before; if someone replays it after five minutes, you will reject it



Kaufman                                                         [Page 5]

RFC 1507                          DASS                    September 1993


   as timed out.

   The disadvantage of the challenge/response based scheme is that it
   requires extra messages.  While one-way authentication could
   otherwise be done with a single message and mutual authentication
   with one message in each direction, the challenge/response scheme
   always requires at least three messages.

   The disadvantage of the timestamp-based scheme is that it requires
   secure synchronized time.  If our clocks drift apart by more than
   five minutes, you will reject all of my attempts to authenticate.  If
   a network time service spoofer can convince you to turn back your
   clock and then subsequently replays an expired message, you will
   accept it again.  The multicast nature of existing distributed time
   services and the likelihood of detection make this an unlikely
   threat, but it must be considered in any analysis of the security of
   the scheme.  The timestamp scheme also requires the server to keep
   state about all messages seen in the clock skew interval.  To be
   secure, this must be kept on stable storage (unless rebooting takes
   longer than the permitted clock skew interval).

   DASS uses the timestamp-based scheme.  The primary motivations behind
   this decision were so that authentication messages could be
   "piggybacked" on existing connection establishment messages and so
   that DASS would fit within the same "form factor" (number and
   direction of messages) as Kerberos.

1.2.3 Delegation

   In a distributed environment, authentication alone is not enough.
   When I log onto a computer, not only do I want to prove my identity
   to that computer, I want to use that computer to access network
   resources (e.g., file systems, database systems) on my behalf.  My
   files should (normally) be protected so that I can access them
   through any node I log in through.  DASS allows them to be so
   protected without allowing all of the systems that I might ever use
   to access those files in my absence.  In the process of logging in,
   my password gives my login node access to my RSA secret.  It can use
   that secret to "impersonate" me on any requests it makes on my
   behalf.  It should forget all secrets associated with me when I log
   off.  This limits the trust placed in computer systems.  If someone
   takes control of a computer, they can impersonate all people who use
   that computer after it is taken over but no others.

   Normally when I access a network service, I want to strongly
   authenticate to it.  That is, I want to prove my identity to that
   service, but I don't want to allow that service to learn anything
   that would allow it to impersonate me.  This allows me to use a



Kaufman                                                         [Page 6]

RFC 1507                          DASS                    September 1993


   service without trusting it for more than the service it is
   delivering.  When using some services, for example remote login
   services, I may want that service to act on my behalf in calling
   additional services.  DASS provides a mechanism whereby I can pass
   secrets to such services that allow them to impersonate me.

   Future versions of this architecture may allow "limited delegation"
   so that a user may delegate to a server only those rights the server
   needs to carry out the user's wishes.  This version  can limit
   delegation only in terms of time.  The information a user gives a
   server (other than the initial login node) can be used to impersonate
   the user but only for a limited period of time.  Smart cards will
   permit that time limitation to apply to the initial login node as
   well.

1.2.4 Certification Authorities

   A flaw in the strong authentication mechanism described above is that
   it assumes that every "principal" (user and node) knows the public
   key of every other principal it wants to authenticate.  If I can fool
   a server into thinking my public key is actually your public key, I
   can impersonate you by signing a message, saying it is from you, and
   having the server verify the message with what it thinks is your
   public key.

   To avoid the need to securely install the public key of every
   principal in the database of every other principal, the concept of a
   "Certification Authority" was invented.  A certification authority is
   a principal trusted to act as an introduction service.  Each
   principal goes to the certification authority, presents its public
   key, and proves it has a particular name (the exact mechanisms for
   this vary with the type of principal and the level of security to be
   provided).  The CA then creates a "certificate" which is a message
   containing the name and public key of the principal, an expiration
   date, and bookkeeping information signed by the CA's private key.
   All "subscribers" to a particular CA can then be authenticated to one
   another by presenting their certificates and proving knowledge of the
   corresponding secret.  CAs need only act when new principals are
   being named and new private keys created, so that can be maintained
   under tight physical security.

   The two problems with the scheme as described so far are "revocation"
   and "scaleability".

1.2.4.1 Certificate Revocation

   Revocation is the process of announcing that a key has (or may have)
   fallen into the wrong hands and should no longer be accepted as proof



Kaufman                                                         [Page 7]

RFC 1507                          DASS                    September 1993


   of some particular identity.  With certificates as described above,
   someone who learns your secret and your certificate can impersonate
   you indefinitely - even after you have learned of the compromise.  It
   lacks the ability corresponding to changing your password.  DASS
   supports two independent mechanisms for revoking certificates. In the
   future, a third may be added.

   One method for revocation is using timeouts and renewals of
   certificates.  Part of the signed message which is a certificate may
   be a time after which the certificate should not be believed.
   Periodically, the CA would renew certificates by signing one with a
   later timeout.  If a key were compromised, a new key would be
   generated and a new certificate signed.  The old certificate would
   only be valid until its timeout.  Timeouts are not perfect revocation
   mechanisms because they provide only slow revocation (timeouts are
   typically measured in months for the load on the CA and communication
   with users to be kept manageable) and they depend on servers having
   an accurate source of the current time.  Someone who can trick a
   server into turning back its clock can use expired certificates.

   The second method is by listing all non-revoked certificates in the
   naming service and believing only certificates found there.  The
   advantage of this method is that it is almost immediate (the only
   delay is for name service "skulking" and caching delays).  The
   disadvantages are: (1) the availability of authentication is only as
   good as the availability of the naming service and (2) the security
   of revocation is only as good as the security of the naming service.

   A third method for revocation - not currently supported by DASS - is
   for certification authorities to periodically issue "revocation
   lists" which list certificates which should no longer be accepted.

1.2.4.2 Certification Authority Hierarchy

   While using a certification authority as an introduction service
   scales much better than having every principal learn the public key
   of every other principal by some out of band means, it has the
   problem that it creates a central point of trust.  The certification
   authority can impersonate any principal by inventing a new key and
   creating a certificate stating that the new key represents the
   principal.  In a large organization, there may be no individual who
   is sufficiently trusted to operate the CA.  Even if there were, in a
   large organization it would be impractical to have every individual
   authenticate to that single person.  Replicating the CA solves the
   availability problem but makes the trust problem worse.  When
   authentication is to be used in a global context - between companies
   - the concept of a single CA is untenable.




Kaufman                                                         [Page 8]

RFC 1507                          DASS                    September 1993


   DASS addresses this problem by creating a hierarchy of CAs.  The CA
   hierarchy is tied to the naming hierarchy.  For each directory in the
   namespace, there is a single CA responsible for certifying the public
   keys of its members.  That CA will also certify the public keys of
   the CAs of all child directories and of the CA of the parent
   directory.  With this cross-certification, it is possible knowing the
   public key of any CA to verify the public keys of a series of
   intermediate CAs and finally to verify the public key of any
   principal.

   Because the CA hierarchy is tied to the naming hierarchy, the trust
   placed in any individual CA is limited.  If a CA is compromised, it
   can impersonate any of the principals listed in its directory, but it
   cannot impersonate arbitrary principals.

   DASS provides mechanisms for every principal to know the public key
   of its "parent" CA - the CA controlling the directory in which it is
   named.  The result is the following rules for the implications of a
   compromised CA:

    a) A CA can impersonate any principal named in its directory.

    b) A CA can impersonate any principal to a server named in its
       directory.

    c) A CA can impersonate any principal named in a subdirectory to
       any server not named in the same subdirectory.

    d) A CA can impersonate to any server in a subdirectory any
       principal not named in the same subdirectory.

   The implication is that a compromise low in the naming tree will
   compromise all principals below that directory while a compromise
   high in the naming tree will compromise only the authentication of
   principals far apart in the naming hierarchy.  In particular, when
   multiple organizations share a namespace (as they do in the case of
   X.500), the compromise of a CA in one organization can not result in
   false authentication within another organization.

   DASS uses the X.500 directory hierarchy for principal naming.  At the
   top of the hierarchy are names of countries.  National authorities
   are not expected to establish certification authorities (at least
   initially), so an alternative mechanism must be used to authenticate
   entities "distant" in the naming hierarchy.  The mechanism for this
   in DASS is the "cross-certificate" where a CA certifies the public
   key for some CA or principal not its parent or child.  By limiting
   the chains of certificates they will use to parent certificates
   followed by a single "cross certificate" followed by child



Kaufman                                                         [Page 9]

RFC 1507                          DASS                    September 1993


   certificates, a DASS implementation can avoid the need to have CAs
   near the root of the tree or can avoid the requirement to trust them
   even if they do exist.  A special case can also be supported whereby
   a global authority whose name is not the root can certify the local
   roots of independent "islands".

1.2.5 User vs. Node Authentication

   In concept, DASS mechanisms support the mutual authentication of two
   principals regardless of whether those principals are people,
   computers, or applications.  Those mechanisms have been extended,
   however, to deal with a common case of a pair of principals acting
   together (a user and a node) authenticating to a single principal (a
   remote server).  This is done by having optionally in each
   credentials structure two sets of secrets - one for the user and one
   for the node.  When authentication is done using such credentials,
   both secrets sign the request so the receiving party can verify that
   both principals are present.