rfc1510.txt

RFC 的详细文档！

   called a "session key").  The client transmits the ticket (which
   contains the client's identity and a copy of the session key, all
   encrypted in the server's key) to the server.  The session key (now
   shared by the client and server) is used to authenticate the client,
   and may optionally be used to authenticate the server.  It may also
   be used to encrypt further communication between the two parties or
   to exchange a separate sub-session key to be used to encrypt further
   communication.

   The implementation consists of one or more authentication servers
   running on physically secure hosts.  The authentication servers
   maintain a database of principals (i.e., users and servers) and their
   secret keys. Code libraries provide encryption and implement the
   Kerberos protocol.  In order to add authentication to its



Kohl & Neuman                                                   [Page 5]

RFC 1510                        Kerberos                  September 1993


   transactions, a typical network application adds one or two calls to
   the Kerberos library, which results in the transmission of the
   necessary messages to achieve authentication.

   The Kerberos protocol consists of several sub-protocols (or
   exchanges).  There are two methods by which a client can ask a
   Kerberos server for credentials.  In the first approach, the client
   sends a cleartext request for a ticket for the desired server to the
   AS. The reply is sent encrypted in the client's secret key. Usually
   this request is for a ticket-granting ticket (TGT) which can later be
   used with the ticket-granting server (TGS).  In the second method,
   the client sends a request to the TGS.  The client sends the TGT to
   the TGS in the same manner as if it were contacting any other
   application server which requires Kerberos credentials.  The reply is
   encrypted in the session key from the TGT.

   Once obtained, credentials may be used to verify the identity of the
   principals in a transaction, to ensure the integrity of messages
   exchanged between them, or to preserve privacy of the messages.  The
   application is free to choose whatever protection may be necessary.

   To verify the identities of the principals in a transaction, the
   client transmits the ticket to the server.  Since the ticket is sent
   "in the clear" (parts of it are encrypted, but this encryption
   doesn't thwart replay) and might be intercepted and reused by an
   attacker, additional information is sent to prove that the message
   was originated by the principal to whom the ticket was issued.  This
   information (called the authenticator) is encrypted in the session
   key, and includes a timestamp.  The timestamp proves that the message
   was recently generated and is not a replay.  Encrypting the
   authenticator in the session key proves that it was generated by a
   party possessing the session key.  Since no one except the requesting
   principal and the server know the session key (it is never sent over
   the network in the clear) this guarantees the identity of the client.

   The integrity of the messages exchanged between principals can also
   be guaranteed using the session key (passed in the ticket and
   contained in the credentials).  This approach provides detection of
   both replay attacks and message stream modification attacks.  It is
   accomplished by generating and transmitting a collision-proof
   checksum (elsewhere called a hash or digest function) of the client's
   message, keyed with the session key.  Privacy and integrity of the
   messages exchanged between principals can be secured by encrypting
   the data to be passed using the session key passed in the ticket, and
   contained in the credentials.

   The authentication exchanges mentioned above require read-only access
   to the Kerberos database.  Sometimes, however, the entries in the



Kohl & Neuman                                                   [Page 6]

RFC 1510                        Kerberos                  September 1993


   database must be modified, such as when adding new principals or
   changing a principal's key.  This is done using a protocol between a
   client and a third Kerberos server, the Kerberos Administration
   Server (KADM).  The administration protocol is not described in this
   document. There is also a protocol for maintaining multiple copies of
   the Kerberos database, but this can be considered an implementation
   detail and may vary to support different database technologies.

1.1.  Cross-Realm Operation

   The Kerberos protocol is designed to operate across organizational
   boundaries.  A client in one organization can be authenticated to a
   server in another.  Each organization wishing to run a Kerberos
   server establishes its own "realm".  The name of the realm in which a
   client is registered is part of the client's name, and can be used by
   the end-service to decide whether to honor a request.

   By establishing "inter-realm" keys, the administrators of two realms
   can allow a client authenticated in the local realm to use its
   authentication remotely (Of course, with appropriate permission the
   client could arrange registration of a separately-named principal in
   a remote realm, and engage in normal exchanges with that realm's
   services. However, for even small numbers of clients this becomes
   cumbersome, and more automatic methods as described here are
   necessary).  The exchange of inter-realm keys (a separate key may be
   used for each direction) registers the ticket-granting service of
   each realm as a principal in the other realm.  A client is then able
   to obtain a ticket-granting ticket for the remote realm's ticket-
   granting service from its local realm. When that ticket-granting
   ticket is used, the remote ticket-granting service uses the inter-
   realm key (which usually differs from its own normal TGS key) to
   decrypt the ticket-granting ticket, and is thus certain that it was
   issued by the client's own TGS. Tickets issued by the remote ticket-
   granting service will indicate to the end-service that the client was
   authenticated from another realm.

   A realm is said to communicate with another realm if the two realms
   share an inter-realm key, or if the local realm shares an inter-realm
   key with an intermediate realm that communicates with the remote
   realm.  An authentication path is the sequence of intermediate realms
   that are transited in communicating from one realm to another.

   Realms are typically organized hierarchically. Each realm shares a
   key with its parent and a different key with each child.  If an
   inter-realm key is not directly shared by two realms, the
   hierarchical organization allows an authentication path to be easily
   constructed.  If a hierarchical organization is not used, it may be
   necessary to consult some database in order to construct an



Kohl & Neuman                                                   [Page 7]

RFC 1510                        Kerberos                  September 1993


   authentication path between realms.

   Although realms are typically hierarchical, intermediate realms may
   be bypassed to achieve cross-realm authentication through alternate
   authentication paths (these might be established to make
   communication between two realms more efficient).  It is important
   for the end-service to know which realms were transited when deciding
   how much faith to place in the authentication process. To facilitate
   this decision, a field in each ticket contains the names of the
   realms that were involved in authenticating the client.

1.2.  Environmental assumptions

   Kerberos imposes a few assumptions on the environment in which it can
   properly function:

   +    "Denial of service" attacks are not solved with Kerberos.  There
        are places in these protocols where an intruder intruder can
        prevent an application from participating in the proper
        authentication steps.  Detection and solution of such attacks
        (some of which can appear to be not-uncommon "normal" failure
        modes for the system) is usually best left to the human
        administrators and users.

   +    Principals must keep their secret keys secret.  If an intruder
        somehow steals a principal's key, it will be able to masquerade
        as that principal or impersonate any server to the legitimate
        principal.

   +    "Password guessing" attacks are not solved by Kerberos.  If a
        user chooses a poor password, it is possible for an attacker to
        successfully mount an offline dictionary attack by repeatedly
        attempting to decrypt, with successive entries from a
        dictionary, messages obtained which are encrypted under a key
        derived from the user's password.

   +    Each host on the network must have a clock which is "loosely
        synchronized" to the time of the other hosts; this
        synchronization is used to reduce the bookkeeping needs of
        application servers when they do replay detection.  The degree
        of "looseness" can be configured on a per-server basis.  If the
        clocks are synchronized over the network, the clock
        synchronization protocol must itself be secured from network
        attackers.

   +    Principal identifiers are not recycled on a short-term basis.  A
        typical mode of access control will use access control lists
        (ACLs) to grant permissions to particular principals.  If a



Kohl & Neuman                                                   [Page 8]

RFC 1510                        Kerberos                  September 1993


        stale ACL entry remains for a deleted principal and the
        principal identifier is reused, the new principal will inherit
        rights specified in the stale ACL entry. By not re-using
        principal identifiers, the danger of inadvertent access is
        removed.

1.3.  Glossary of terms

   Below is a list of terms used throughout this document.


   Authentication      Verifying the claimed identity of a
                       principal.


   Authentication header A record containing a Ticket and an
                         Authenticator to be presented to a
                         server as part of the authentication
                         process.


   Authentication path  A sequence of intermediate realms transited
                        in the authentication process when
                        communicating from one realm to another.

   Authenticator       A record containing information that can
                       be shown to have been recently generated
                       using the session key known only by  the
                       client and server.


   Authorization       The process of determining whether a
                       client may use a service, which objects
                       the client is allowed to access, and the
                       type of access allowed for each.


   Capability          A token that grants the bearer permission
                       to access an object or service.  In
                       Kerberos, this might be a ticket whose
                       use is restricted by the contents of the
                       authorization data field, but which
                       lists no network addresses, together
                       with the session key necessary to use
                       the ticket.






Kohl & Neuman                                                   [Page 9]

RFC 1510                        Kerberos                  September 1993


   Ciphertext          The output of an encryption function.
                       Encryption transforms plaintext into
                       ciphertext.


   Client              A process that makes use of a network
                       service on behalf of a user.  Note that
                       in some cases a Server may itself be a
                       client of some other server (e.g., a
                       print server may be a client of a file
                       server).


   Credentials         A ticket plus the secret session key
                       necessary to successfully use that
                       ticket in an authentication exchange.