rfc1510.txt

RFC 的详细文档！

   Authentication forwarding is an instance of the proxy case where the
   service is granted complete use of the client's identity.  An example
   where it might be used is when a user logs in to a remote system and
   wants authentication to work from that system as if the login were
   local.

   The FORWARDABLE flag in a ticket is normally only interpreted by the
   ticket-granting service.  It can be ignored by application servers.
   The FORWARDABLE flag has an interpretation similar to that of the
   PROXIABLE flag, except ticket-granting tickets may also be issued
   with different network addresses.  This flag is reset by default, but
   users may request that it be set by setting the FORWARDABLE option in
   the AS request when they request their initial ticket-granting
   ticket.

   This flag allows for authentication forwarding without requiring the
   user to enter a password again.  If the flag is not set, then
   authentication forwarding is not permitted, but the same end result
   can still be achieved if the user engages in the AS exchange with the
   requested network addresses and supplies a password.

   The FORWARDED flag is set by the TGS when a client presents a ticket
   with the FORWARDABLE flag set and requests it be set by specifying
   the FORWARDED KDC option and supplying a set of addresses for the new
   ticket.  It is also set in all tickets issued based on tickets with
   the FORWARDED flag set.  Application servers may wish to process
   FORWARDED tickets differently than non-FORWARDED tickets.

2.7.  Other KDC options

   There are two additional options which may be set in a client's
   request of the KDC.  The RENEWABLE-OK option indicates that the
   client will accept a renewable ticket if a ticket with the requested
   life cannot otherwise be provided.  If a ticket with the requested
   life cannot be provided, then the KDC may issue a renewable ticket
   with a renew-till equal to the the requested endtime.  The value of
   the renew-till field may still be adjusted by site-determined limits
   or limits imposed by the individual principal or server.

   The ENC-TKT-IN-SKEY option is honored only by the ticket-granting
   service.  It indicates that the to-be-issued ticket for the end
   server is to be encrypted in the session key from the additional
   ticket-granting ticket provided with the request.  See section 3.3.3
   for specific details.





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


3.  Message Exchanges

   The following sections describe the interactions between network
   clients and servers and the messages involved in those exchanges.

3.1.  The Authentication Service Exchange

                             Summary

         Message direction       Message type    Section
         1. Client to Kerberos   KRB_AS_REQ      5.4.1
         2. Kerberos to client   KRB_AS_REP or   5.4.2
                                 KRB_ERROR       5.9.1

   The Authentication Service (AS) Exchange between the client and the
   Kerberos Authentication Server is usually initiated by a client when
   it wishes to obtain authentication credentials for a given server but
   currently holds no credentials.  The client's secret key is used for
   encryption and decryption.  This exchange is typically used at the
   initiation of a login session, to obtain credentials for a Ticket-
   Granting Server, which will subsequently be used to obtain
   credentials for other servers (see section 3.3) without requiring
   further use of the client's secret key.  This exchange is also used
   to request credentials for services which must not be mediated
   through the Ticket-Granting Service, but rather require a principal's
   secret key, such as the password-changing service.  (The password-
   changing request must not be honored unless the requester can provide
   the old password (the user's current secret key).  Otherwise, it
   would be possible for someone to walk up to an unattended session and
   change another user's password.)  This exchange does not by itself
   provide any assurance of the the identity of the user.  (To
   authenticate a user logging on to a local system, the credentials
   obtained in the AS exchange may first be used in a TGS exchange to
   obtain credentials for a local server.  Those credentials must then
   be verified by the local server through successful completion of the
   Client/Server exchange.)

   The exchange consists of two messages: KRB_AS_REQ from the client to
   Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
   messages are described in sections 5.4.1, 5.4.2, and 5.9.1.

   In the request, the client sends (in cleartext) its own identity and
   the identity of the server for which it is requesting credentials.
   The response, KRB_AS_REP, contains a ticket for the client to present
   to the server, and a session key that will be shared by the client
   and the server.  The session key and additional information are
   encrypted in the client's secret key.  The KRB_AS_REP message
   contains information which can be used to detect replays, and to



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


   associate it with the message to which it replies.  Various errors
   can occur; these are indicated by an error response (KRB_ERROR)
   instead of the KRB_AS_REP response.  The error message is not
   encrypted.  The KRB_ERROR message also contains information which can
   be used to associate it with the message to which it replies.  The
   lack of encryption in the KRB_ERROR message precludes the ability to
   detect replays or fabrications of such messages.

   In the normal case the authentication server does not know whether
   the client is actually the principal named in the request.  It simply
   sends a reply without knowing or caring whether they are the same.
   This is acceptable because nobody but the principal whose identity
   was given in the request will be able to use the reply. Its critical
   information is encrypted in that principal's key.  The initial
   request supports an optional field that can be used to pass
   additional information that might be needed for the initial exchange.
   This field may be used for preauthentication if desired, but the
   mechanism is not currently specified.

3.1.1. Generation of KRB_AS_REQ message

   The client may specify a number of options in the initial request.
   Among these options are whether preauthentication is to be performed;
   whether the requested ticket is to be renewable, proxiable, or
   forwardable; whether it should be postdated or allow postdating of
   derivative tickets; and whether a renewable ticket will be accepted
   in lieu of a non-renewable ticket if the requested ticket expiration
   date cannot be satisfied by a nonrenewable ticket (due to
   configuration constraints; see section 4).  See section A.1 for
   pseudocode.

   The client prepares the KRB_AS_REQ message and sends it to the KDC.

3.1.2. Receipt of KRB_AS_REQ message

   If all goes well, processing the KRB_AS_REQ message will result in
   the creation of a ticket for the client to present to the server.
   The format for the ticket is described in section 5.3.1.  The
   contents of the ticket are determined as follows.

3.1.3. Generation of KRB_AS_REP message

   The authentication server looks up the client and server principals
   named in the KRB_AS_REQ in its database, extracting their respective
   keys.  If required, the server pre-authenticates the request, and if
   the pre-authentication check fails, an error message with the code
   KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate
   the requested encryption type, an error message with code



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


   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
   session key ("Random" means that, among other things, it should be
   impossible to guess the next session key based on knowledge of past
   session keys.  This can only be achieved in a pseudo-random number
   generator if it is based on cryptographic principles.  It would be
   more desirable to use a truly random number generator, such as one
   based on measurements of random physical phenomena.).

   If the requested start time is absent or indicates a time in the
   past, then the start time of the ticket is set to the authentication
   server's current time. If it indicates a time in the future, but the
   POSTDATED option has not been specified, then the error
   KDC_ERR_CANNOT_POSTDATE is returned.  Otherwise the requested start
   time is checked against the policy of the local realm (the
   administrator might decide to prohibit certain types or ranges of
   postdated tickets), and if acceptable, the ticket's start time is set
   as requested and the INVALID flag is set in the new ticket. The
   postdated ticket must be validated before use by presenting it to the
   KDC after the start time has been reached.

   The expiration time of the ticket will be set to the minimum of the
   following:

   +The expiration time (endtime) requested in the KRB_AS_REQ
    message.

   +The ticket's start time plus the maximum allowable lifetime
    associated with the client principal (the authentication
    server's database includes a maximum ticket lifetime field
    in each principal's record; see section 4).

   +The ticket's start time plus the maximum allowable lifetime
    associated with the server principal.

   +The ticket's start time plus the maximum lifetime set by
    the policy of the local realm.

   If the requested expiration time minus the start time (as determined
   above) is less than a site-determined minimum lifetime, an error
   message with code KDC_ERR_NEVER_VALID is returned.  If the requested
   expiration time for the ticket exceeds what was determined as above,
   and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE"
   flag is set in the new ticket, and the renew-till value is set as if
   the "RENEWABLE" option were requested (the field and option names are
   described fully in section 5.4.1).  If the RENEWABLE option has been
   requested or if the RENEWABLE-OK option has been set and a renewable
   ticket is to be issued, then the renew-till field is set to the
   minimum of:



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


   +Its requested value.

   +The start time of the ticket plus the minimum of the two
    maximum renewable lifetimes associated with the principals'
    database entries.

   +The start time of the ticket plus the maximum renewable
    lifetime set by the policy of the local realm.

   The flags field of the new ticket will have the following options set
   if they have been requested and if the policy of the local realm
   allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
   If the new ticket is postdated (the start time is in the future), its
   INVALID flag will also be set.

   If all of the above succeed, the server formats a KRB_AS_REP message
   (see section 5.4.2), copying the addresses in the request into the
   caddr of the response, placing any required pre-authentication data
   into the padata of the response, and encrypts the ciphertext part in
   the client's key using the requested encryption method, and sends it
   to the client.  See section A.2 for pseudocode.

3.1.4. Generation of KRB_ERROR message

   Several errors can occur, and the Authentication Server responds by
   returning an error message, KRB_ERROR, to the client, with the
   error-code and e-text fields set to appropriate values.  The error
   message contents and details are described in Section 5.9.1.

3.1.5. Receipt of KRB_AS_REP message

   If the reply message type is KRB_AS_REP, then the client verifies
   that the cname and crealm fields in the cleartext portion of the
   reply match what it requested.  If any padata fields are present,
   they may be used to derive the proper secret key to decrypt the
   message.  The client decrypts the encrypted part of the response
   using its secret key, verifies that the nonce in the encrypted part
   matches the nonce it supplied in its request (to detect replays).  It
   also verifies that the sname and srealm in the response match those
   in the request, and that the host address field is also correct.  It
   then stores the ticket, session key, start and expiration times, and
   other information for later use.  The key-expiration field from the