rfc1507.txt

RFC 的详细文档！

   themselves to others, whereas verifier information in credentials
   permit principals to verify the claims of others.  Credentials
   intended primarily for use by a claimant will be referred to as
   claimant credentials in the text which follows.  Credentials intended
   primarily for use in verification will be referred to as verifier
   credentials.  A particular set of credentials may or may not contain



Kaufman                                                        [Page 19]

RFC 1507                          DASS                    September 1993


   all of the data necessary to be used in both roles.  That will depend
   on the mechanisms by which the credentials were created.

   In some contexts, but not here, the concept of representation
   and/or delegation is sometimes referred to as proxy. This term is
   used in ECMA TR/46.  We avoid use of the term because of possible
   confusion with an unrelated use of the term in the context of
   DECnet.

1.4.4 Key Distribution, Replay, Mutual Authentication and Trust

   Strong authentication uses cryptographic techniques. The
   particular mechanisms used in DASS result in the distribution of
   cryptographic keys as a side effect. These keys are suitable for
   use for providing a data origin authentication service and/or a
   data confidentiality service between a pair of authenticated
   principals.

   Replay detection is provided using timestamps on relevant
   authentication messages, combined with remembering previously
   accepted messages until they become "stale". This is in contrast
   to other techniques, such as challenge and response exchanges.

   Authentication can be one-way or mutual. One-way authentication is
   when only one party, in DASS the claimant, authenticates to the other.
   Mutual authentication provides, in addition, authentication of the
   verifier back to the claimant. In certain communications schemes, for
   example connectionless transfer, only one-way authentication is
   meaningful. DASS supports mutual authentication as a simple extension
   of one-way authentication for use in environments where it makes
   sense.

   DASS potentially can allow many different "trust relationships"
   to exist. All principals trust one or more CA's to safeguard the
   certification process. Principals use certificates as the basis
   for authenticating identities, and trust that CA's which issue
   certificates act responsibly. Users expect CA's to make sure that
   certificates (and related secrets) are only made for principals
   that the CA knows or has properly authenticated on its own.

1.5 An Authentication Walkthrough

   The OSI Authentication Framework characterizes authentication as
   occurring in six phases. This section attempts to describe DASS
   in these terms.






Kaufman                                                        [Page 20]

RFC 1507                          DASS                    September 1993


1.5.1 Installation

   In this phase, principal certificates are created, as is the
   additional information needed to create claimant and verifier
   credentials. OSI defines three sub-phases:

    - Enrollment. In DASS, this is the definition of a principal in
      terms of a key, name and UID.

    - Validation,  confirmation of identity to the satisfaction of
      the CA, after which the CA generates a certificate.

    - Confirmation.  In DASS, this is the act of providing the user
      with the certificate and with the CA's own name, key and UID,
      followed up by the user creating a  trusted authority for that
      CA. A trusted authority is a certificate for the CA signed by
      the user.

   Included in this step in DASS is the posting of the certificate so as
   to be available to principals wishing to verify the principal's
   identity. In addition, the user principal saves the trusted authority
   so as to be available when it creates credentials.

1.5.2 Distribution

   DASS distributes certificates by placing them in the name service.

1.5.3 Acquisition

   Whenever principals wish to authenticate to one another, they access
   the Name Service to obtain whatever public key certificates they need
   and create the necessary credentials. In DASS, acquisition means
   obtaining credentials.

   Claimant credentials implement the representation of a principal in a
   process, or, more accurately, provide a representation of the
   principal for use by a process. In making this representation, the
   principal delegates to a temporary delegation key. In this fashion
   the claimant's long term principal key need not remain in the system.

   Claimant credentials are made by invoking the get credentials
   primitive. Claimant credentials are a DASS specific data structure
   containing:

    - a name

    - a ticket, a data structure containing




Kaufman                                                        [Page 21]

RFC 1507                          DASS                    September 1993


      .  a validity interval,

      .  UID, and

      .  (temporary) delegation public key, along with a

      .  digital signature on the above made with the principal
         private key

    - the delegation private key

   Optionally in addition, there may be credential information relating
   to the node on which the user is logged in and the account on that
   node.  A detailed description of all the information found in
   credentials can be found in section 3.  Verifier credentials are made
   with initialize_server. Verifier credentials consist of a principal
   (long term) private key. The rationale is that these credentials are
   usually needed by servers that must be able to run indefinitely
   without re-entry of any long term key.

   In addition, claimants and verifiers have a trusted authority, which
   consists of information about a trusted CA.  That information is its:

    - name (this will appear in the "issuer" field in principal
      certificates),

    - public key (to use in verifying certificates issued by that
      CA), and

    - UID.

   Trusted authorities are used by principals to verify certificates for
   other principals' public keys.  CAs are arranged in a hierarchy
   corresponding to the naming hierarchy, where each directory in the
   naming hierarchy is controlled by a single CA.  Each CA certifies the
   CA of its parent directory, the CAs of each of its child directories,
   and optionally CAs elsewhere in the naming hierarchy (mainly to deal
   with the case where the directories up to a common ancestor lack
   CAs).  Even though a principal has only a single CA as a trusted
   authority, it can securely obtain the public key of any principal in
   the namespace by "walking the CA hierarchy".

1.5.4 Transfer

   The DASS exchange of authentication information is illustrated in
   Figure 1-1. During the transfer phase, the DASS claimant sends an
   authentication token  to the verifier. Authentication tokens are made
   by invoking the create_token primitive. The authentication token is



Kaufman                                                        [Page 22]

RFC 1507                          DASS                    September 1993


   cryptographically protected and specified as a DASS data structure in
   ASN.1. The authentication token includes:

    - a ticket,

    - a DES authenticating key encrypted using the intended
      verifier's public key

    - one of the following:

      . if delegation is not being performed, a digital signature on
        the encrypted DES key using the delegation private key, or

      . if delegation is being performed, sending the delegation
        private key, DES encrypted using the DES authenticating key

    - an authenticator, which is a cryptographic checksum made using
      the DES authenticating key over a buffer containing

      . a timestamp

      . any application supplied "channel bindings". For example,
        addresses or other context information. The purpose of this
        field is to thwart substitution and replay attacks.

    - additional optional information concerning node authentication
      and context.

   As a side effect, after init_authentication_context, the caller
   receives a local authentication context, a data structure containing:

    - the DES key, and

    - if mutual authentication is being requested, the expected
      response.

   In order to construct an authentication token, the claimant needs to
   access the verifier's public key certificate from the Name Service
   (labeled CDC, for Certificate Distribution Center, in the figure).

   Note that while an authenticator can only be used once, it is
   permissible to re-establish the same local authentication context
   multiple times. That is, the ticket and DES key establishment
   components of the authentication token may have a relatively long
   lifetime. This permits a performance improvement in that repeated
   applications of public key operations can be alleviated if one caches
   authentication contexts, along with other components from a
   successfully used authentication token and the associated verified



Kaufman                                                        [Page 23]

RFC 1507                          DASS                    September 1993


   principal public key value. It is a relatively inexpensive operation
   to create (and verify) "fresh" authenticators based on cached
   authentication context.

      Claimant Actions      | Communications |  Verifier Actions
                            |                |
           verifier name    |                |
                   |        |                |
                   |        |           +---+|
                   \------------------->|   ||
     trusted                |           |   ||
   authorities              |           |CDC||
        |    +-----------+  |certificate|   ||
        |    |  Verify   |<-------------|   ||
        \--->|Certificate|  |           +---+|
             +-----------+  |                |
     Claimant        |      |                |
   credentials    Verifier  |                |   Verifier
        |       Public Key  |                | Credentials
        |            |      |                |       |
        |            V      |                |       V
        |    +-----------+  | Authentication | +-----------+
        |    |   Make    |  |     Token      | |   Check   |   Replay
        \--->|  Token    |-------------------->|   Token   |<-->Cache
             +-----------+  |