rfc1510.txt

RFC 的详细文档！

   KDC                 Key Distribution Center, a network service
                       that supplies tickets and temporary
                       session keys; or an instance of that
                       service or the host on which it runs.
                       The KDC services both initial ticket and
                       ticket-granting ticket requests.  The
                       initial ticket portion is sometimes
                       referred to as the Authentication Server
                       (or service).  The ticket-granting
                       ticket portion is sometimes referred to
                       as the ticket-granting server (or service).

   Kerberos            Aside from the 3-headed dog guarding
                       Hades, the name given to Project
                       Athena's authentication service, the
                       protocol used by that service, or the
                       code used to implement the authentication
                       service.


   Plaintext           The input to an encryption function  or
                       the output of a decryption function.
                       Decryption transforms ciphertext into
                       plaintext.


   Principal           A uniquely named client or server
                       instance that participates in a network
                       communication.




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


   Principal identifier The name used to uniquely identify each
                        different principal.


   Seal                To encipher a record containing several
                       fields in such a way that the fields
                       cannot be individually replaced without
                       either knowledge of the encryption key
                       or leaving evidence of tampering.


   Secret key          An encryption key shared by a principal
                       and the KDC, distributed outside the
                       bounds of the system, with a long lifetime.
                       In the case of a human user's
                       principal, the secret key is derived
                       from a password.


   Server              A particular Principal which provides a
                       resource to network clients.


   Service             A resource provided to network clients;
                       often provided by more than one server
                       (for example, remote file service).


   Session key         A temporary encryption key used between
                       two principals, with a lifetime limited
                       to the duration of a single login "session".


   Sub-session key     A temporary encryption key used between
                       two principals, selected and exchanged
                       by the principals using the session key,
                       and with a lifetime limited to the duration
                       of a single association.


   Ticket              A record that helps a client authenticate
                       itself to a server; it contains the
                       client's identity, a session key, a
                       timestamp, and other information, all
                       sealed using the server's secret key.
                       It only serves to authenticate a client
                       when presented along with a fresh
                       Authenticator.



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


2.  Ticket flag uses and requests

   Each Kerberos ticket contains a set of flags which are used to
   indicate various attributes of that ticket.  Most flags may be
   requested by a client when the ticket is obtained; some are
   automatically turned on and off by a Kerberos server as required.
   The following sections explain what the various flags mean, and gives
   examples of reasons to use such a flag.

2.1.  Initial and pre-authenticated tickets

   The INITIAL flag indicates that a ticket was issued using the AS
   protocol and not issued based on a ticket-granting ticket.
   Application servers that want to require the knowledge of a client's
   secret key (e.g., a passwordchanging program) can insist that this
   flag be set in any tickets they accept, and thus be assured that the
   client's key was recently presented to the application client.

   The PRE-AUTHENT and HW-AUTHENT flags provide addition information
   about the initial authentication, regardless of whether the current
   ticket was issued directly (in which case INITIAL will also be set)
   or issued on the basis of a ticket-granting ticket (in which case the
   INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
   carried forward from the ticket-granting ticket).

2.2.  Invalid tickets

   The INVALID flag indicates that a ticket is invalid.  Application
   servers must reject tickets which have this flag set.  A postdated
   ticket will usually be issued in this form. Invalid tickets must be
   validated by the KDC before use, by presenting them to the KDC in a
   TGS request with the VALIDATE option specified.  The KDC will only
   validate tickets after their starttime has passed.  The validation is
   required so that postdated tickets which have been stolen before
   their starttime can be rendered permanently invalid (through a hot-
   list mechanism).

2.3.  Renewable tickets

   Applications may desire to hold tickets which can be valid for long
   periods of time.  However, this can expose their credentials to
   potential theft for equally long periods, and those stolen
   credentials would be valid until the expiration time of the
   ticket(s).  Simply using shortlived tickets and obtaining new ones
   periodically would require the client to have long-term access to its
   secret key, an even greater risk.  Renewable tickets can be used to
   mitigate the consequences of theft.  Renewable tickets have two
   "expiration times": the first is when the current instance of the



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


   ticket expires, and the second is the latest permissible value for an
   individual expiration time.  An application client must periodically
   (i.e., before it expires) present a renewable ticket to the KDC, with
   the RENEW option set in the KDC request.  The KDC will issue a new
   ticket with a new session key and a later expiration time.  All other
   fields of the ticket are left unmodified by the renewal process.
   When the latest permissible expiration time arrives, the ticket
   expires permanently.  At each renewal, the KDC may consult a hot-list
   to determine if the ticket had been reported stolen since its last
   renewal; it will refuse to renew such stolen tickets, and thus the
   usable lifetime of stolen tickets is reduced.

   The RENEWABLE flag in a ticket is normally only interpreted by the
   ticket-granting service (discussed below in section 3.3).  It can
   usually be ignored by application servers.  However, some
   particularly careful application servers may wish to disallow
   renewable tickets.

   If a renewable ticket is not renewed by its  expiration time, the KDC
   will not renew the ticket.  The RENEWABLE flag is reset by default,
   but a client may request it be  set  by setting  the RENEWABLE option
   in the KRB_AS_REQ message.  If it is set, then the renew-till field
   in the ticket  contains the time after which the ticket may not be
   renewed.

2.4.  Postdated tickets

   Applications may occasionally need to obtain tickets for use much
   later, e.g., a batch submission system would need tickets to be valid
   at the time the batch job is serviced.  However, it is dangerous to
   hold valid tickets in a batch queue, since they will be on-line
   longer and more prone to theft.  Postdated tickets provide a way to
   obtain these tickets from the KDC at job submission time, but to
   leave them "dormant" until they are activated and validated by a
   further request of the KDC.  If a ticket theft were reported in the
   interim, the KDC would refuse to validate the ticket, and the thief
   would be foiled.

   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
   ticket-granting service.  It can be ignored by application servers.
   This flag must be set in a ticket-granting ticket in order to issue a
   postdated ticket based on the presented ticket. It is reset by
   default; it may be requested by a client by setting the ALLOW-
   POSTDATE option in the KRB_AS_REQ message.  This flag does not allow
   a client to obtain a postdated ticket-granting ticket; postdated
   ticket-granting tickets can only by obtained by requesting the
   postdating in the KRB_AS_REQ message.  The life (endtime-starttime)
   of a postdated ticket will be the remaining life of the ticket-



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


   granting ticket at the time of the request, unless the RENEWABLE
   option is also set, in which case it can be the full life (endtime-
   starttime) of the ticket-granting ticket.  The KDC may limit how far
   in the future a ticket may be postdated.

   The POSTDATED flag indicates that a ticket has been postdated.  The
   application server can check the authtime field in the ticket to see
   when the original authentication occurred.  Some services may choose
   to reject postdated tickets, or they may only accept them within a
   certain period after the original authentication. When the KDC issues
   a POSTDATED ticket, it will also be marked as INVALID, so that the
   application client must present the ticket to the KDC to be validated
   before use.

2.5.  Proxiable and proxy tickets

   At times it may be necessary for a principal to allow a service  to
   perform an operation on its behalf.  The service must be able to take
   on the identity of the client, but only for  a particular purpose.  A
   principal can allow a service to take on the principal's identity for
   a particular purpose by granting it a proxy.

   The PROXIABLE flag in a ticket is normally only interpreted by the
   ticket-granting service. It can be ignored by application servers.
   When set, this flag tells the ticket-granting server that it is OK to
   issue a new ticket (but not a ticket-granting ticket) with a
   different network address based on this ticket.  This flag is set by
   default.

   This flag allows a client to pass a proxy to a server to perform a
   remote request on its behalf, e.g., a print service client can give
   the print server a proxy to access the client's files on a particular
   file server in order to satisfy a print request.

   In order to complicate the use of stolen credentials, Kerberos
   tickets are usually valid from only those network addresses
   specifically included in the ticket (It is permissible to request or
   issue tickets with no network addresses specified, but we do not
   recommend it).  For this reason, a client wishing to grant a proxy
   must request a new ticket valid for the network address of the
   service to be granted the proxy.

   The PROXY flag is set in a ticket by the  TGS  when  it issues a
   proxy ticket.  Application servers may check this flag and require
   additional authentication  from  the  agent presenting the proxy in
   order to provide an audit trail.





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


2.6.  Forwardable tickets