Network Working Group Jennifer Steiner Request for Comments: DRAFT 1 Project Athena MIT 28 Mar 1989 The Kerberos Network Authentication Service Overview DRAFT STATUS OF THIS MEMO This DRAFT document gives an overview and specification of the Version 4 protocol of Kerberos, a network authentica- tion system in production use at MIT's Project Athena. Dis- tribution of this memo is unlimited. OVERVIEW This DRAFT RFC describes the concepts and model upon which the Kerberos network authentication system is based. It also provides a specification of the protocols employed. The motivations, goals, assumptions, and rationale behind design decisions are treated cursorily; they are fully described elsewhere [refs]. The discussion is based on the Version 4 implementation of Kerberos, currently in use at Project Athena. The protocols are under review, and are not proposed as an Internet standard. Comments are encouraged. Requests for additions to a mail list on Ker- beros discussions, kerberos@athena.mit.edu, may be addressed to kerberos-request@athena.mit.edu. Requests for further information, including documents and code availability, may be sent to info-kerberos@athena.mit.edu. ACKNOWLEDGEMENTS The Kerberos model is based on Needham and Schroeder's trusted third-party authentication scheme [ref]. The origi- nal design and implementation of Kerberos are due to two former Project Athena members, Steve Miller of Digital Equipment Corporation and Clifford Neuman of the University of Washington; along with Jerome Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, Head of Athena Operations and MIT Telecommunications. Many other members of Project Athena have also contributed to the work on Ker- beros. April 5, 1989 - 2 - INTRODUCTION Kerberos provides a means of verifying the identities of two principals, for example, a workstation user and a network server, to one another in the context of an open network computing system. This must be accomplished without relying on authentication by the workstation operating sys- tem or host addresses, without requiring physical security of all the hosts on the system, and under the assumption that packets travelling along the network can be read and inserted at will. Kerberos performs authentication under these conditions as a trusted third-party authentication service using private key encryption. [ref] The authentication process works roughly as follows. A Client sends a request to the Kerberos Authentication Ser- vice (AS) asking for Credentials for a given Server. The Credentials consist of two parts: 1) a Ticket for the Server and 2) a temporary encryption key (Session Key). The Client forwards the Ticket, which contains the Client's identity along with a copy of the Session Key, to the Server. The Session Key can then be used to authenticate the Server to the Client, to encrypt communication between the two, or whatever. The protocols that implement this authentication model are the subject of XXX. The implementation consists of one or more authentica- tion servers running on physically secure hosts housing a database of principals (i.e., users and servers) and their private keys. Libraries provide encryption routines and routines implementing the various protocols. An existing network application typically adds one or two calls to Ker- beros library routines in order to add authentication to its Client/Server transactions. Protocols are run on UDP/IP. The IP address in received UDP packets is used as part of the authentication process. Several protocols are involved. There are two dif- ferent protocols in which a Client can ask a Kerberos server for Credentials. In the first protocol, the Client sends a request in the clear to the Authentication Server (AS) for a Ticket for a given Server. The reply is sent encrypted in the Client's private key. Usually this request is for a Ticket for the Ticket-Granting Service (TGS). In the second protocol, the Client sends a request to the TGS. This is actually an example of the Client/Server authentication pro- tocol. The Client sends its TGS Ticket to the Ticket- Granting Service, asking for a Ticket for some other Service (for example, file service). The reply is encrypted in the Session Key of the Client and TGS. Once a Client has obtained Credentials for a Server (using either of the two protocols above), it is up to the specific Client/Server application how the Credentials are April 5, 1989 - 3 - to be used. We have implemented several protocols for Client/Server authentication. In the first, the Client for- wards the Ticket to the Server, along with information (including a timestamp) which helps to detect replay. Since the Ticket is sent in the clear, and may be reused for a limited period of time, there must be some way for the Server to know not only to whom the Ticket was issued, but also that the principal using the Ticket is the same as the principal to whom it was issued. This can be done using the Session Key, since no one except the requesting principal knows it - it is never sent over the network in the clear. The second Client/Server authentication protocol affords detection not only of replay, but also of message stream modification (MSM). This is done by including a cryptographic checksum of the Client's message. The check- sum is computed using the Session Key. A third protocol provides not only Client/Server authentication, but also data encryption, again using the Session Key. Finally, ... [John's prot.] TCP vs UDP etc. [Describe in a separate document?] The authentication protocols described above require read-only access to the Kerberos database. Sometimes, how- ever, the data in the database must be modified, such as when adding new principals or changing a password. This is done using the protocol between a Client and a third Ker- beros server, the Kerberos Administration Server (KADM). [Describe in a separate document?] Interrealm Operation [Describe in separate document?] _N_O_T_A_T_I_O_N Numbers are given in decimal unless otherwise indicated. We assume 8-bit bytes. The words "byte" and "octet" are used synonymously. An octet is represented as follows: 01234567 +--------+ | | +--------+ <-8 bits-> The most significant bit (msb) is bit 0; the least signifi- cant bit is bit 7. Successions of octets are shown in ???- April 5, 1989 - 4 - endian order: MSB LSB +--------+--------+--------+--------+ | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +--------+--------+--------+--------+ <-------------32 bits---------------> The most significant byte (MSB) is Byte 0; the least signi- ficant byte (LSB) in this diagram is Byte 3. _B_Y_T_E _O_R_D_E_R_I_N_G The byte ordering of values comprised of more than one octet is determined by the sender (receiver-makes-right). The least significant bit of the message type field is used to indicate the sender's byte order. Only two byte orders are recognized: big and little endian. We are considering changing to net byte order in version 5 of the protocols. _F_I_E_L_D _T_Y_P_E_S Each packet is described in terms of a table of its fields and a picture. The table gives the length, "type", label, and meaning of each field, for example: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local byte order 4 octets ui_4 error error code <= 40 octets string err_text error text The "Size" column gives the number of octets in the field. The "Type" column refers to a type described in this sec- tion. The "Label" refers to the field's label in the pic- ture. The "Value" gives the meaning of the field. A picture for the table above is: +-------+-------+-------+-------+-------+-------+ | pvno |type B| error | +-------+-------+-------+-------+-------+-------+---------------+ | "err_text" | +---------------------------------------------------------------+ April 5, 1989 - 5 - Since many fields in the Kerberos protocols are of variable length, the layout of the corresponding picture is somewhat arbitrary. For example, the "err_text" field above is a variable-length string, so the table above could also be depicted as: +-------+-------+-------+-------+-------+-------+---------------+ | pvno |type B| error | "err_text" | +-------+-------+-------+-------+-------+-------+---------------+ _Z_E_R_O_S _N_U_L_L A null octet, or NULL, is an octet with 8 zero bits: +--------+ |00000000| +--------+ <--NULL--> It is used to indicate the end of a variable-length string. _P_A_D Some messages include variable-length fields. DES encryp- tion requires that its input and output be multiples of 8 octets. In these cases, a field of NULL octets is used to fill up sections of messages to be encrypted to the next 8- octet multiple. This type of field is called a PAD and is anywhere from 0 to 7 octets in length for obvious reasons. In the picture representation, its label is placed in brack- ets to indicate that it may be of 0 length. +-----------------------------------------------+---------------+ | "sinstance" | [PAD] | +-----------------------------------------------+---------------+ _S_T_R_I_N_G_S A "string" means 0 or more 1-octet ASCII characters, ter- minated by a null octet, for example, the string "SNAIL": Byte 0 Byte 5 +--------+--------+--------+--------+--------+--------+ | S + N + A + I + L + NULL | +--------+--------+--------+--------+--------+--------+ <-----------------------48 bits-----------------------> April 5, 1989 - 6 - A string of unspecified length is represented as: +-----------------------------------+ | "string" | +-----------------------------------+ <-------------? octets--------------> where "string" is a descriptive label. Note that the label is placed in quotation marks, and the octet delimiters '+' are missing. Strings are used to represent the name, instance, or realm of a Kerberos principal, or an error mes- sage text. Strings are currently 40 octets or less; at least some strings will be longer in the next protocol ver- sion. _U_N_S_I_G_N_E_D _I_N_T_E_G_E_R_S Fields of unsigned integers of length 1, 2, and 4 octets are used. _u_i__1 A ui_1 field consists of one octet representing an unsigned integer: +-------+ | ui_1 | +-------+ This type of field is used for some protocol version numbers, key version numbers, and for the millisecond field of a timestamp. _l_i_f_e The "life" field, a special case of a ui_1 field, gives the length of time a Ticket is valid. The time interval unit is 5 minutes; the longest Ticket lifetime is therefore 255*5 minutes. This is not long enough, and the "life" field will be lengthened or reinterpreted in the next protocol version. +-------+ | life | +-------+ April 5, 1989 - 7 - _u_i__2 The length of some data is given by two octets representing an unsigned integer: +-------+-------+ | ui_2 | +-------+-------+ The ui_2 field is used, for example, in the AS protocol to indicate the length of a CREDENTIALS field. _u_i__4 Some fields require an unsigned integer of 4 octets: +-------+-------+-------+-------+ | ui_4 | +-------+-------+-------+-------+ This type of field is used in the KRB_PRIV protocol to indi- cate the length of an encrypted data field. It is also used to indicate IP addresses. A third use is as an error code, in the KRB_AS_ERR message. _t_i_m_e_s_t_a_m_p A "timestamp" is a special case of a ui_4 field, used to indicate the date and time. The time is represented as the number of seconds since 00:00:00 GMT, Jan. 1, 1970. This will probably be changed to Internet time in the next ver- sion. (Internet time is the number of seconds since 00:00:00 GMT, Jan. 1, 1900. The offset from UNIX time to Internet time is about 2208988800 seconds.) +-------+-------+-------+-------+ | timestamp | +-------+-------+-------+-------+ _t_y_p_e+_B The message type and local byte order are represented in a single unsigned octet, "type+B". The least significant bit of the "type+B" contains the local byte order - 0 for ?- endian; 1 for ?-endian. The message types are therefore multiples of two. The next version of the protocol will probably be in net order, and this hack will go away. April 5, 1989 - 8 - +-------+ |type+B | +-------+ _f_l_a_g_s+_B A one-octet bit field is used in a Ticket to communicate information from the Kerberos server to the application server. Currently, the least significant bit is the only one used, and it indicates the Kerberos server's byte order (and therefore the byte order of the information in the Ticket). +-------+ |flags+B| +-------+ _D+_t_i_m_e_s_t_a_m_p Some protocols use the most significant bit of a timestamp field to indicate the direction of a message. The direction is calculated by comparing the sender's address to the receiver's address. If the sender's address is less, the direction bit (i.e., the most significant bit of a "time- stamp" field) is set to 1 ???. (Anyway, the time is set to -time). If it's greater, the direction bit is set to 0 ???. If they are the same, the ports are used for comparisons. +-------+-------+-------+-------+ |D timestamp | +-------+-------+-------+-------+ _U_N_I_N_T_E_R_P_R_E_T_E_D _D_A_T_A _F_I_E_L_D_S Some fields contain data which are interpreted word by word, rather than as a string or integer, etc. _K_e_y A DES encryption key is 8 octets of data. This is used both for session keys and private keys. April 5, 1989 - 9 - +-------+-------+-------+-------+-------+-------+-------+-------+ | key | +-------+-------+-------+-------+-------+-------+-------+-------+ _C_h_e_c_k_s_u_m The checksum computed by the KRB_SAFE protocol contains 16 octets of data: +-------+-------+-------+-------+-------+-------+-------+-------+ | checksum | | (16 octets) | +-------+-------+-------+-------+-------+-------+-------+-------+ _e_d_a_t_a [This should go before CREDENTIALS, etc.] Some fields con- sist of encrypted data. These are interpreted octet by octet. An example is a Ticket field, which contains data encrypted in a server's key (see T+A.ms). Encrypted data are always 8-octet multiples. +-------+-------+-------+-------+-------+-------+-------+-------+ | | / edata / / (8 octet multiple) / | | +-------+-------+-------+-------+-------+-------+-------+-------+ _d_a_t_a Some fields consist of unspecified user data. These are interpreted octet by octet. An example is the DATA field of a KRB_SAFE message. (see KRB_SAFE.ms). User data are vari- able length. +-------+-------+-------+-------+-------+-------+-------+-------+ | | / data / / (variable length) / | | +-------+-------+-------+-------+-------+-------+-------+-------+ April 5, 1989 - 10 - _T_i_c_k_e_t_s, _A_u_t_h_e_n_t_i_c_a_t_o_r_s, _a_n_d _C_r_e_d_e_n_t_i_a_l_s This section describes the format and enciphering of Tickets, Authenticators, and Credentials. _T_i_c_k_e_t_s A Ticket contains the following information, encrypted in the Server's private key: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet flags+B flags bit field (only lsb used) 1 bit -- B local byte order <= 40 octets string cname client's name <= 40 octets string cinstance client's instance <= 40 octets string crealm client's realm 4 octets ui_4 caddr client's address 8 octets key session session key 1 octet ui_1 life ticket lifetime 4 octets ui_4 timestamp AS timestamp in seconds <= 40 octets string sname service's name <= 40 octets string sinstance service's instance <= 7 octets PAD PAD null pad to 8-octet multiple +-------+-------------------------------------------------------+ |flags B| "cname" | +-------+-------------------------------------------------------+ | "cinstance" | +-----------------------+-------+-------+-------+-------+-------+ | "crealm" | caddr | +-------+-------+-------+-------+-------+-------+-------+-------+ | session | +-------+-------+-------+-------+-------+-------+-------+-------+ | life | timestamp | "sname" | +-------+-------+-------+-------+-------+---------------+-------+ | "sinstance" | [PAD] | +-------------------------------------------------------+-------+ The "flags" field is used to communicate information from the Kerberos athentication server to the server. Currently, it is only used to indicate the byte order of the Ticket (i.e., the authentication server's byte order), in the least significant bit. The following picture is a shorthand for a Ticket: April 5, 1989 - 11 - +-------+-------+-------+---------------------------------------+ | | / TICKET / / (8 octet multiple) / | | +-------+-------+-------+-------+-------------------------------+ _A_u_t_h_e_n_t_i_c_a_t_o_r_s An Authenticator contains the following, encrypted in the Session Key of the Client and Server: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e <= 40 octets string cname client's name <= 40 octets string cinstance client's instance <= 40 octets string crealm client's realm 4 octets data checksum client checksum 1 octet ui_1 t_usec timestamp (milliseconds) 4 octets ui_4 timestamp timestamp in seconds <= 7 octets PAD PAD null pad to 8-octet multiple +---------------------------------------------------------------+ | "cname" | +---------------------------------------------------------------+ | "cinstance" | +---------------------------------------------------------------+ | "crealm" | +-------+-------+-------+-------+-------+-----------------------+ | checksum | usec | +-------+-------+-------+-------+-------+-----------------------+ | timestamp | [PAD] | +-------+-------+-------+-------+-------------------------------+ The following picture is a shorthand for the above: +---------------------------------------------------------------+ | | / AUTHENTICATOR / / (8 octet multiple) / | | +---------------------------------------------------------------+ April 5, 1989 - 12 - _C_R_E_D_E_N_T_I_A_L_S The CREDENTIALS data include a Ticket and Session Key. If returned using the AS Protocol, they are encrypted in the Client's private key. If returned using the TGS Protocol, they are encrypted in the Session Key of the Client and TGS. _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 8 octets key session session key for C and S <= 40 octets string sname service name <= 40 octets string sinstance server instance <= 40 octets string srealm server's realm 1 octet ui_1 life ticket lifetime 1 octet ui_1 kvno server key version 1 octet ui_1 len length of TICKET len octets edata TICKET Ticket for C to use S 4 octets ui_4 timestamp AS or TGS timestamp (seconds) +-------+-------+-------+-------+-------+-------+-------+-------+ | session | +-------+-------+-------+-------+-------+-------+-------+-------+ | "sname" | +---------------------------------------------------------------+ | "sinstance" | +---------------------------------------------------------------+ | "srealm" | +-------+-------+-------+---------------------------------------+ | life | kvno | len | +-------+-------+-------+---------------------------------------+ | | / TICKET / / (8 octet multiple) / | | +-------+-------+-------+-------+-------------------------------+ | timestamp | +-------+-------+-------+-------+ The following picture is used as a shorthand for the above: +-------+-------+-------+-------+-------+-------+-------+-------+ | | / CREDENTIALS / / (8 octet multiple) / | | +-------+-------+-------+-------+-------+-------+-------+-------+ April 5, 1989 - 13 - _M_o_r_e _N_o_t_a_t_i_o_n/_T_y_p_e_s The following are shorthand notation for complex fields or message types described in detail elsewhere. _C_R_E_D_E_N_T_I_A_L_S [Use caps for variable length or just encryption?] Encrypted data are set off by capitalized labels, such as the CREDEN- TIALS data, which are encrypted in the Client's private key in the case of the Authentication Service protocol, or encrypted in the Session Key shared by the Client and Ticket-Granting Server in a TGS Request. The length of the CREDENTIALS data is a multiple of 8 octets: +-------+-------+-------+-------+-------+-------+-------+-------+ | | / CREDENTIALS / / (8 octet multiple) / | | +-------+-------+-------+-------+-------+-------+-------+-------+ _K_R_B__A_P__R_E_Q The KRB_AP_REQ contains authentication information which can be the first message, or the first part of a message, in an authenticated transaction. It contains the Kerberos proto- col version number, the message type KRB_AP_REQ, the local byte order, the version number of the server's key (used to encrypt the Ticket), the server's Kerberos realm, the lengths of the Ticket and Authenticator, and the Ticket and Authenticator themselves. (See AP.ms for exact format.) It is represented as: +---------------------------------------------------------------+ | | / KRB_AP_REQ / / (variable length) / | | +---------------------------------------------------------------+ _K_R_B__P_R_I_V The KRB_PRIV message contains, among other fields, some user data encrypted in the Session Key of a client and server. (See PRIV.ms for exact format.) It is represented as: April 5, 1989 - 14 - +-------+-------+-------+-------+-------------------------------+ | | / KRB_PRIV / / (variable length) / | | +---------------------------------------------------------------+ _K_R_B__S_A_F_E The KRB_SAFE message contains, among other fields, a check- sum of user data generated using the Session Key of a client and server. (See KRB_SAFE.ms for exact format.) It is represented as: +-------+-------+-------+-------+-------------------------------+ | | / KRB_SAFE / / (variable length) / | | +---------------------------------------------------------------+ _T_h_e _A_u_t_h_e_n_t_i_c_a_t_i_o_n _S_e_r_v_i_c_e (_A_S) _P_r_o_t_o_c_o_l This section describes the interaction between a client and the Kerberos Authentication Server when the client requests authentication credentials for a given server. _O_v_e_r_v_i_e_w This protocol is initiated by a client when it wishes to obtain authentication credentials for a given server. The client's private key (for example, a key derived from a user's password) is used for encryption/decryption. This protocol is typically used at the initiation of a login ses- sion, to obtain credentials for a Ticket-Granting Server, which will subsequently be used obtain credentials for other servers (see TGS.ms) without requiring a private key. More generally, this protocol is used to request credentials for services which must not be mediated through the Ticket- Granting Service; but rather require a principal's private key, for example, the password-changing service.* The transaction consists of two messages: a KRB_AS_REQ __________________________ *The password-changing request must not be honored un- less the requester can provide the old password (the user's current private key). Otherwise, it would be possible for someone to walk up to an unattended ses- sion and change another user's password. April 5, 1989 - 15 - message from the client to the Kerberos Authentication Ser- vice, and a KRB_AS_REP or KRB_AS_ERR message in the opposite direction. In the KRB_AS_REQ message, the client sends (in cleartext) its own identity and the identity of the server for which it requires credentials. The KRB_AS_REP message contains a Ticket for the client to forward to the server, and a Session Key for the client and server to use in their communication. These are encrypted in the client's private key. Various errors can occur; these are indicated in the KRB_AS_ERR message. The KRB_AS_ERR is not encrypted. Both the KRB_AS_REP and KRB_AS_ERR messages contain information (such as the KRB_AS_REQ timestamp) which can be used to determine to which KRB_AS_REQ message they are replying. No authentication takes place; the Authentication Server simply sends a reply without knowing or caring whether the client is the same as the principal whose iden- tity was given in the request. (But no one except the prin- cipal whose identity was given in the request will be able to use the reply, since it is encrypted in that principal's key.) Similarly, the client does not know whether the KRB_AS_REP really originated from the Authentication Server. [Is this really true?] It is possible, for example, for a KRB_AS_REP not originating from the Authentication Server to be received, and successfully decrypted in a key other than the principal whose identity was given in the KRB_AS_REQ. (But the contents of the decrypted message will not be use- ful since only the real Authentication Server can create a Ticket acceptable to the desired server.) _T_h_e _K_R_B__A_S__R_E_Q _M_e_s_s_a_g_e The KRB_AS_REQ message from the client to the Authenti- cation Server contains the Kerberos protocol version number, the KRB_AS_REQ message type, the local host's byte ordering, the identity of the client for which the credentials are requested, the identity of the server to which the creden- tials will be presented, the local host's timestamp, and the requested lifetime of the Ticket portion of the desired credentials. The message fields are: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local (client) byte order <= 40 octets string cname client's name <= 40 octets string cinstance client's instance <= 40 octets string crealm client's realm April 5, 1989 - 16 - 4 octets ui_4 ctime client's timestamp in seconds 1 octet life life desired lifetime <= 40 octets string sname service's name <= 40 octets string sinstance service's instance and the packet format is: +-------+-------+-----------------------------------------------+ | pvno |type B| "cname" | +-------+-------+-----------------------------------------------+ | "cinstance" | +---------------------------------------------------------------+ | "crealm" | +-------+-------+-------+-------+-------+-----------------------+ | ctime | life | "sname" | +-------+-------+-------+-------+-------+-----------------------+ | "sinstance" | +---------------------------------------------------------------+ where "pvno" is currently 4 and "type" is KRB_AS_REQ (in code, AUTH_MSG_KDC_REQUEST, 2). _T_h_e _K_R_B__A_S__R_E_P _M_e_s_s_a_g_e A successful request is serviced as follows. The Authentication Server looks up the client and server princi- pals in its database, extracting their respective keys. It generates a "random" Session Key. A Ticket is created for the client to use the server (see TAC.ms for the Ticket for- mat). The Ticket is encrypted in the server's private key. The lifetime of the Ticket will be set to the minimum of the following: the requested lifetime ("life" in the KRB_AS_REQ message), the maximum lifetime associated with the client principal, and the maximum lifetime associated with the server principal. (See DB.ms for details of database.) The Credentials data, which include both the Ticket and the Ses- sion Key, are created and encrypted in the client's key (see TAC.ms for the Credentials format). The KRB_AS_REP message contains the following fields: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local (AS) byte order <= 40 octets string cname client's name <= 40 octets string cinstance client's instance <= 40 octets string crealm client's realm 4 octets ui_4 timestamp client's timestamp in seconds April 5, 1989 - 17 - 1 octet ui_1 n number of tickets 4 octets ui_4 exp ticket expiration date 1 octet ui_1 kvno server key version 2 octets ui_2 len_C credentials length len_C CREDENTIALS CREDENTIALS credentials data in the following format: +-------+-------+-----------------------------------------------+ | pvno |type B| "cname" | +-------+-------+-----------------------------------------------+ | "cinstance" | +---------------------------------------------------------------+ | "crealm" | +-------------------------------+-------+-----------------------+ | timestamp | n | +-------+-------+-------+-------+-------+-------+-------+ | exp | kvno | len_C | +-------+-------+-------+-------+-------+-------+-------+-------+ | | / CREDENTIALS / / (8 octet multiple) / | | +-------+-------+-------+-------+-------+-------+-------+-------+ where "pvno" is currently 4 and "type" is KRB_AS_REP (in code, AUTH_MSG_KDC_REPLY, 4), and "n" is 0.* __________________________ *"n" is leftover from protocol version 3, where multi- ple tickets could be requested and returned. Only one ticket is ever returned in version 4. This field will be removed in version 5. When the KRB_AS_REP message is received by the client, the client checks the Kerberos protocol version number and mes- sage type. It checks the byte order against its own and byte-swaps fields if necessary. All other cleartext fields are ignored (the client's name, instance, and realm, the timestamp, the number of tickets, the client's expiration date, and the client's key version number). The client decrypts the Credentials using its private key. It extracts the session key, server's name, instance and realm, and the ticket lifetime, the server's key version, and the ticket length. It then compares the server name, instance and realm to what it asked for. [If tickets are cached, the ticket, key, key version number, ???, are cached with it.] Some (which???) fields (e.g., server key version number) are returned to the client so that the client can in turn for- April 5, 1989 - 18 - _T_h_e _K_R_B__A_S__E_R_R _M_e_s_s_a_g_e Several errors can occur, and the Authentication Server responds by returning an error message to the client. The error message contains the protocol version number, message type and byte order, the client's identity and timestamp, the error code, and text associated with it. The errors which can occur are as follows. KERB_ERR_PKT_VER If the Kerberos protocol ver- sion number is not one the authentication server knows how to deal with. KERB_ERR_PRINCIPAL_UNKNOWN If there is no entry in the Kerberos database for the client principal. KERB_ERR_PRINCIPAL_UNKNOWN If there is no entry in the Kerberos database for the server principal. KERB_ERR_PRINCIPAL_NOT_UNIQUE If there is more than one entry in the Kerberos database for either the client or server principal. KERB_ERR_NULL_KEY If the client or server prin- cipal has a NULL key. KERB_ERR_NAME_MAST_KEY_VER If the version of the Kerberos master key under which the client or server key is stored, is not one the server can deal with (e.g., it's old, and the authentication server doesn't have a copy of the old key). KERB_ERR_NAME_EXP If the expiration date for the client or server principal's database entry has passed. The KRB_AS_ERR message consists of the following fields: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number __________________________ ward them to the server. April 5, 1989 - 19 - 1 octet type+B type message type 1 bit -- B local (AS) byte order <= 40 octets string cname client's name <= 40 octets string cinstance client's instance <= 40 octets string crealm client's realm 4 octets ui_4 timestamp client's timestamp in seconds 4 octets ui_4 error error code <= 40 octets string e_text error text in the following format: +-------+-------+-----------------------------------------------+ | pvno |type B| "cname" | +-------+-------+-----------------------------------------------+ | "cinstance" | +---------------------------------------------------------------+ | "crealm" | +-------------------------------+-------+-------+-------+-------+ | timestamp | error | +-------+-------+-------+-------+-------+-------+-------+-------+ | "e_text" | +---------------------------------------------------------------+ where "type" is KRB_AS_ERR (in code, AUTH_MSG_ERR_REPLY, 32). Error codes are defined as: * KERB_ERR_OK 0 KERB_ERR_NAME_EXP 1 * KERB_ERR_SERVICE_EXP 2 * KERB_ERR_AUTH_EXP 3 KERB_ERR_PKT_VER 4 KERB_ERR_NAME_MAST_KEY_VER 5 * KERB_ERR_SERV_MAST_KEY_VER 6 * KERB_ERR_BYTE_ORDER 7 KERB_ERR_PRINCIPAL_UNKNOWN 8 KERB_ERR_PRINCIPAL_NOT_UNIQUE 9 KERB_ERR_NULL_KEY 10 The error codes preceded by asterisks are currently not in use. _T_h_e _C_l_i_e_n_t/_S_e_r_v_e_r (_C_S) _A_u_t_h_e_n_t_i_c_a_t_i_o_n _P_r_o_t_o_c_o_l This protocol is used by a network application to authenticate the client and server sides to one another. It is assumed that the client has already acquired Credentials for the server using the AS or TGS protocol. April 5, 1989 - 20 - _T_h_e _K_R_B__A_P__R_E_Q _M_e_s_s_a_g_e The KRB_AP_REQ contains authentication information which can be the first message, or the first part of a mes- sage, in an authenticated transaction. It contains the Ker- beros protocol version number, the message type KRB_AP_REQ, the local byte order, the version number of the server's key (used to encrypt the Ticket), the server's Kerberos realm, the lengths of the Ticket and Authenticator, and the Ticket and Authenticator themselves. _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local byte order 1 octet ui_1 kvno server key version number <= 40 octets string srealm server's realm 1 octet ui_1 len_T length of Ticket 1 octet ui_1 len_A length of Authenticator len_T edata TICKET Ticket len_A edata AUTHENTICATOR Authenticator The message format is: +-------+-------+-------+---------------------------------------+ | pvno |type B| kvno | "srealm" | +-------+-------+-------+---------------------------------------+ | len_T | len_A | +-------+-------+-----------------------------------------------+ | | / TICKET / / (8 octet multiple) / | | +---------------------------------------------------------------+ | | / AUTHENTICATOR / / (8 octet multiple) / | | +---------------------------------------------------------------+ where "type" is KRB_AP_REQ (8). _T_h_e _K_R_B__A_P__R_E_P _M_e_s_s_a_g_e Doesn't exist. Typically, a client's request will include both the authentication information and its initial request in the same message. If mutual authentication (not April 5, 1989 - 21 - only authenticating the client to the server, but also the server to the client) is being performed, a reply is required. [See Kohl authentication for an example.???] _T_h_e _K_R_B__A_P__E_R_R _M_e_s_s_a_g_e (_f_r_o_m _r_d__r_e_q._c, _m_k__e_r_r._c) This message is returned by the server if the client's authentication failed. Authentication is based on informa- tion in the received UDP packet, the server's time (so clocks must be somewhat synchronized), the Authenticator, and the Ticket. Several different error codes can result. The algorithm for verifying authentication information is as follows. The server checks the protocol version number in the KRB_AP_REQ and if it doesn't know how to deal with it, returns the RD_AP_VERSION error. If the message type is neither KRB_AP_REQ nor KRB_AP_REQ_MUT, returns the RD_AP_MSG_TYPE error. If the key version in the KRB_AP_REQ is not one the server can deal with (e.g., it's old, and the server doesn't have a copy of the old key), the RD_AP_UNDEC error is returned (there should be a different error code for this). The "realm" field in the KRB_AP_REQ is ignored. It should be used to determine the private key a server should use to decrypt the ticket, since it is possible for the server to be registered in multiple realms, with dif- ferent keys in each. An error code RD_AP_RLM should be returned if the service doesn't have its key for that realm. The Ticket is decrypted using the given version of the server's key. If the client's name, instance, or realm inside the decrypted ticket is bigger than their maximum allowed sized, RD_AP_UNDEC is returned (chances are good that different keys were used to encrypt and decrypt). If the client's realm is null, the server's realm is assumed in the checks below. Using the Session Key extracted from the decrypted Ticket, the Authenticator is decrypted. The milliseconds time field is ignored. The name, instance, and realm of the client in the Ticket are compared against the same fields in the Authenticator. If they don't match, RD_AP_INCON is returned. The address in the Ticket and the received (IP) KRB_AP_REQ address are compared, and if they differ, RD_AP_BADD is returned. If the local (server) time and the client time in the Authenticator are off by too much (e.g., 5 minutes), RD_AP_TIME is returned. The age of the ticket is computed: local (server) time minus the issue time inside the Ticket. If the issue time is later than the current time (by more than the clock skew, e.g., 5 minutes), RD_AP_NYV is returned. Otherwise, if the local time (in seconds) minus the issue time is more than 5 (minutes) times 60 (seconds) April 5, 1989 - 22 - times the lifetime of the ticket, RD_AP_EXP is returned. The returned KRB_AP_ERR message contains the following fields. _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local (server) byte order 4 octets ui_4 error error code <= 40 octets string err_text error text +-------+-------+-------+-------+-------+-------+ | pvno |type B| error | +-------+-------+-------+-------+-------+-------+---------------+ | "err_text" | +---------------------------------------------------------------+ where "type" is KRB_AP_ERR (8<<1). A better error message is needed: one containing information for determining which KRB_AP_REQ the KRB_AP_ERR is replying to. The error codes are as follows. _L_a_b_e_l _V_a_l_u_e _M_e_a_n_i_n_g RD_AP_UNDEC 31 Can't decode authenticator RD_AP_EXP 32 Ticket expired RD_AP_NYV 33 Ticket not yet valid RD_AP_REPEAT 34 Repeated request RD_AP_NOT_US 35 The ticket isn't for us RD_AP_INCON 36 Request is inconsistent RD_AP_TIME 37 delta_t too big RD_AP_BADD 38 Incorrect net address RD_AP_VERSION 39 protocol version mismatch RD_AP_MSG_TYPE 40 invalid msg type RD_AP_MODIFIED 41 message stream modified RD_AP_ORDER 42 message out of order RD_AP_UNAUTHOR 43 unauthorized request _T_h_e _T_i_c_k_e_t-_G_r_a_n_t_i_n_g _S_e_r_v_i_c_e (_T_G_S) _P_r_o_t_o_c_o_l This section describes the interaction between a client and the Kerberos Ticket-Granting Server when the client requests authentication credentials for a given server. April 5, 1989 - 23 - _O_v_e_r_v_i_e_w This protocol is initiated by a client when it wishes to obtain authentication credentials for a given server. The client must already have acquired a ticket for the Ticket Granting Service using the AS protocol. (Usually the TGS ticket is obtained at login.) The Session Key of the Client and TGS is used for encryption/decryption. Unlike the AS protocol, the TGS does not use the client's private key. However, the TGS ticket expires after set time (8 hours at Athena), at which time a new TGS ticket must be obtained using the AS protocol. The transaction consists of two messages: a KRB_TGS_REQ message from the client to the Kerberos Ticket-Granting Server, and a KRB_TGS_REP or KRB_TGS_ERR message in the opposite direction. In the KRB_TGS_REQ message, the client sends information authenticating itself, plus its request for Credentials. The authentication information consists of a KRB_AP_REQ message (which includes the TGS ticket it obtained earlier). The KRB_TGS_REP message contains the requested Credentials, encrypted in the Session Key of the client and TGS. The KRB_TGS_ERR message contains an error code and text explaining what went wrong, in the clear. _K_R_B__T_G_S__R_E_Q The KRB_TGS_REQ consists of a KRB_AP_REQ header, con- taining authentication information, and additional fields containing information about the specific request. The latter are: the client's timestamp, the desired lifetime of the Credentials to be obtained, and the name and instance of the server for which Credentials are to be obtained. (See CS.ms for the KRB_AP_REQ format.) _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e variable KRB_AP_REQ KRB_AP_REQ KRB_AP_REQ header 4 octets ui_4 ctime client's timestamp (0) 1 octet ui_1 life requested Ticket lifetime <= 40 octets string sname name of service <= 40 octets string sinstance server instance The packet format is: April 5, 1989 - 24 - +---------------------------------------------------------------+ | | / KRB_AP_REQ / / (variable length) / | | +-------+-------+-------+-------+-------+-----------------------+ | ctime | life | "sname" | +-------+-------+-------+-------+-------+-----------------------+ | "sinstance" | +---------------------------------------------------------------+ The message type "KRB_TGS_REQ" is not used; the message type KRB_AP_REQ (3<<1) is part of the KRB_AP_REQ header informa- tion. [The TGS protocol should probably be separated from the KRB_AP_REQ message: it should have its own protocol ver- sion number, message type, etc.] The successful KRB_TGS_REQ is serviced as follows: [...] It doesn't honor authentication requests for certain servers, e.g., the password-changing server, which requires authenti- cation through the Authentciation Server. _K_R_B__T_G_S__R_E_P Does not exist. KRB_AS_REP (AUTH_MSG_KDC_REPLY) is used. (See the AS protocol specification.) Two differences between the KRB_AS_REP as used by the AS and TGS are: the client's expiration date is set to NULL, as is the client's key version number, when KRB_AS_REP is sent by the TGS. The client's key version number is not needed because the ses- sion key of the client and TGS is used to encrypt the reply, not the client's key. [Is the exp not used because the db is not accessed at all?] When the KRB_TGS_REP is received by the client, the Kerberos protocol version numbers are checked, as is the message type. The rest of the cleartext fields are ignored. _K_R_B__T_G_S__E_R_R Does not exist. KRB_AS_ERR (AUTH_MSG_KDC_ERR) is used. (See the AS protocol specification.) Some additional error codes may be returned since the request is authenticated. (See CS.ms.) _T_h_e _K_R_B__P_R_I_V _M_e_s_s_a_g_e The KRB_PRIV message contains user data encrypted in the Session Key. The message fields are: April 5, 1989 - 25 - _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local byte order 4 octets ui_4 len_E length of encrypted data len_E edata EMSG encrypted data and the packet format is: +-------+-------+-------+-------+-------+-------+ | pvno |type B| len_E | +-------+-------+-------+-------+-------+-------+---------------+ | | / EMSG / / (8 octet multiple) / | | +---------------------------------------------------------------+ where "type" is KRB_PRIV (6<<1). The EMSG is encrypted in the Session Key, and contains the following before encryption: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 4 octets ui_4 len_D length of user data len data DATA user data 1 octet ui_1 usec timestamp milliseconds 4 octets ui_4 address sender's IP address 4 octets D+timestamp timestamp timestamp 1 bit -- D direction in sign bit <= 7 octets PAD PAD null pad to 8-octet multiple +-------+-------+-------+-------+ | len_D | +-------+-------+-------+-------+-------------------------------+ | | / DATA / / (len_D octets) / | | +-------+-------+-------+-------+-------+-----------------------+ | usec | address | +-------+-------+-------+-------+-------+-----------------------+ |D timestamp | [PAD] | +-------+-------+-------+-------+-------------------------------+ April 5, 1989 - 26 - _R_e_c_e_i_p_t _o_f _K_R_B__P_R_I_V _M_e_s_s_a_g_e [Describe verification of this message.] _K_R_B__S_A_F_E The KRB_SAFE message includes a checksum of the user data. The checksum is generated using the Session Key. The message fields are: _S_i_z_e _T_y_p_e _L_a_b_e_l _V_a_l_u_e 1 octet ui_1 pvno protocol version number 1 octet type+B type message type 1 bit -- B local byte order ======== 4 octets ui_4 len_D length of user data len data DATA user data 1 octet ui_1 usec timestamp milliseconds 4 octets ui_4 address sender's IP address 4 octets D+timestamp timestamp (WHOSE?) timestamp 1 bit -- D direction in sign bit ======== 16 octets checksum checksum quadratic checksum The data between dashed lines above is computed into the checksum. The packet format is: +-------+-------+-------+-------+-------+-------+ | pvno |type B| len_D | +-------+-------+-------+-------+-------+-------+---------------+ | | / DATA / / (len_D octets) / | | +-------+-------+-------+-------+-------+-----------------------+ | usec | address | +-------+-------+-------+-------+-------+ |D timestamp | +-------+-------+-------+-------+-------+-------+-------+-------+ | checksum | | (16 octets) | +-------+-------+-------+-------+-------+-------+-------+-------+ where "type" is KRB_SAFE (7<<1). _T_h_e _K_e_r_b_e_r_o_s _D_a_t_a_b_a_s_e The Kerberos server must have access to a database contain- ing the names and private keys of principals to be April 5, 1989 - 27 - authenticated. A database entry should contain at least the following fields: _F_i_e_l_d _V_a_l_u_e name Principal's name instance Principal's instance key Principal's private key P_kvno Principal's key version max_life Maximum lifetime for Tickets The first two fields are strings representing the principal's name and instance. The second field contains an 8-octet key. This key is the principal's key. (The key can be encrypted in a Kerberos master key to protect it in case the database is compromised but the master key is not. In that case, an extra field must be added for the master key version, see below.) The P_kvno field is the key version number of the principal's private key. The maximum lifetime for any Ticket issued for this principal is also needed. (See AS.ms for a description of how this lifetime is used in determining the lifetime of a given Ticket.) Additional fields used at Athena: _F_i_e_l_d _V_a_l_u_e K_kvno Kerberos' key version expiration Expiration date for entry attributes Bit field of attributes mod_date Timestamp of last modification mod_name Modifying principal's name mod_instance Modifying principal's instance The K_kvno field indicates the key version of the Kerberos master key in which the principal's private key is encrypted. After an entry's expiration date has passed, ??? One bit of the attributes field is used to indicate that a principal name has been assigned, but no password has been allocated yet. This is for use in conjunction with Athena's registration server [ref]. Information about the last time the entry was modified is also kept, namely, the name and instance of the principal who modified the entry, and the date and time the modification took place. _E_n_c_r_y_p_t_i_o_n [Describe how encryption relates to this protocol.] Label Value Meaning or MIT code pvno 4 current Kerberos protocol version number message types April 5, 1989 - 28 - KRB_AS_REQ 2 AUTH_MSG_KDC_REQUEST KRB_AS_ERR 32 AUTH_MSG_ERR_REPLY KRB_AP_REQ 3<<1 AUTH_MSG_APPL_REQUEST KRB_AP_ERR 8<<1 AUTH_MSG_APPL_ERR KRB_PRIV 6<<1 AUTH_MSG_PRIVATE KRB_SAFE 7<<1 AUTH_MSG_SAFE KRB_AS_ERR codes KERB_ERR_OK 0 KERB_ERR_NAME_EXP 1 KERB_ERR_SERVICE_EXP 2 KERB_ERR_AUTH_EXP 3 KERB_ERR_PKT_VER 4 KERB_ERR_NAME_MAST_KEY_VER 5 KERB_ERR_SERV_MAST_KEY_VER 6 KERB_ERR_BYTE_ORDER 7 KERB_ERR_PRINCIPAL_UNKNOWN 8 KERB_ERR_PRINCIPAL_NOT_UNIQUE 9 KERB_ERR_NULL_KEY 10 April 5, 1989