diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt | 8277 |
1 files changed, 8277 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt new file mode 100644 index 00000000000..2284c3c6b57 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt @@ -0,0 +1,8277 @@ + +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + 11 July 1997 + + + + The Kerberos Network Authentication Service (V5) + + +STATUS OF THIS MEMO + + This document is an Internet-Draft. Internet-Drafts +are working documents of the Internet Engineering Task Force +(IETF), its areas, and its working groups. Note that other +groups may also distribute working documents as Internet- +Drafts. + + Internet-Drafts are draft documents valid for a maximum +of six months and may be updated, replaced, or obsoleted by +other documents at any time. It is inappropriate to use +Internet-Drafts as reference material or to cite them other +than as "work in progress." + + To learn the current status of any Internet-Draft, +please check the "1id-abstracts.txt" listing contained in +the Internet-Drafts Shadow Directories on ds.internic.net +(US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US +West Coast), or munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is +filed as draft-ietf-cat-kerberos-revisions-00.txt, and expires +11 January 1998. Please send comments to: + + krb-protocol@MIT.EDU + +ABSTRACT + + + This document provides an overview and specification of +Version 5 of the Kerberos protocol, and updates RFC1510 to +clarify aspects of the protocol and its intended use that +require more detailed or clearer explanation than was pro- +vided in RFC1510. This document is intended to provide a +detailed description of the protocol, suitable for implemen- +tation, together with descriptions of the appropriate use of +protocol messages and fields within those messages. + + This document is not intended to describe Kerberos to +__________________________ +Project Athena, Athena, and Kerberos are trademarks of +the Massachusetts Institute of Technology (MIT). No +commercial use of these trademarks may be made without +prior written permission of MIT. + + + +Overview - 1 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +the end user, system administrator, or application +developer. Higher level papers describing Version 5 of the +Kerberos system [1] and documenting version 4 [23], are +available elsewhere. + +OVERVIEW + + This INTERNET-DRAFT describes the concepts and model +upon which the Kerberos network authentication system is +based. It also specifies Version 5 of the Kerberos proto- +col. + + The motivations, goals, assumptions, and rationale +behind most design decisions are treated cursorily; they are +more fully described in a paper available in IEEE communica- +tions [1] and earlier in the Kerberos portion of the Athena +Technical Plan [2]. The protocols have been a proposed +standard and are being considered for advancement for draft +standard through the IETF standard process. Comments are +encouraged on the presentation, but only minor refinements +to the protocol as implemented or extensions that fit within +current protocol framework will be considered at this time. + + Requests for addition to an electronic mailing list for +discussion of Kerberos, kerberos@MIT.EDU, may be addressed +to kerberos-request@MIT.EDU. This mailing list is gatewayed +onto the Usenet as the group comp.protocols.kerberos. +Requests for further information, including documents and +code availability, may be sent to info-kerberos@MIT.EDU. + +BACKGROUND + + The Kerberos model is based in part on Needham and +Schroeder's trusted third-party authentication protocol [4] +and on modifications suggested by Denning and Sacco [5]. +The original design and implementation of Kerberos Versions +1 through 4 was the work of two former Project Athena staff +members, Steve Miller of Digital Equipment Corporation and +Clifford Neuman (now at the Information Sciences Institute +of the University of Southern California), along with Jerome +Saltzer, Technical Director of Project Athena, and Jeffrey +Schiller, MIT Campus Network Manager. Many other members of +Project Athena have also contributed to the work on Ker- +beros. + + Version 5 of the Kerberos protocol (described in this +document) has evolved from Version 4 based on new require- +ments and desires for features not available in Version 4. +The design of Version 5 of the Kerberos protocol was led by +Clifford Neuman and John Kohl with much input from the com- +munity. The development of the MIT reference implementation +was led at MIT by John Kohl and Theodore T'so, with help and +contributed code from many others. Reference implementa- +tions of both version 4 and version 5 of Kerberos are pub- +licly available and commercial implementations have been + +Overview - 2 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +developed and are widely used. + + Details on the differences between Kerberos Versions 4 +and 5 can be found in [6]. + +1. Introduction + + Kerberos provides a means of verifying the identities +of principals, (e.g. a workstation user or a network server) +on an open (unprotected) network. This is accomplished +without relying on assertions by the host operating system, +without basing trust on host addresses, without requiring +physical security of all the hosts on the network, and under +the assumption that packets traveling along the network can +be read, modified, and inserted at will[1]. Kerberos per- +forms authentication under these conditions as a trusted +third-party authentication service by using conventional +(shared secret key[2]) cryptography. Kerberos extensions +have been proposed and implemented that provide for the use +of public key cryptography during certain phases of the +authentication protocol. These extensions provide for +authentication of users registered with public key certifi- +cation authorities, and allow the system to provide certain +benefits of public key cryptography in situations where they +are needed. + + The basic Kerberos authentication process proceeds as +follows: A client sends a request to the authentication +server (AS) requesting "credentials" for a given server. +The AS responds with these credentials, encrypted in the +client's key. The credentials consist of 1) a "ticket" for +the server and 2) a temporary encryption key (often called a +"session key"). The client transmits the ticket (which con- +tains the client's identity and a copy of the session key, +all encrypted in the server's key) to the server. The ses- +sion key (now shared by the client and server) is used to +authenticate the client, and may optionally be used to +__________________________ +[1] Note, however, that many applications use Kerberos' +functions only upon the initiation of a stream-based +network connection. Unless an application subsequently +provides integrity protection for the data stream, the +identity verification applies only to the initiation of +the connection, and does not guarantee that subsequent +messages on the connection originate from the same +principal. +[2] Secret and private are often used interchangeably +in the literature. In our usage, it takes two (or +more) to share a secret, thus a shared DES key is a +secret key. Something is only private when no one but +its owner knows it. Thus, in public key cryptosystems, +one has a public and a private key. + + + +Section 1. - 3 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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. + + Implementation of the basic protocol 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 transac- +tions, a typical network application adds one or two calls +to the Kerberos library directly or through the Generic +Security Services Application Programming Interface, GSSAPI, +described in separate document. These calls result in the +transmission of the necessary messages to achieve authenti- +cation. + + The Kerberos protocol consists of several sub-protocols +(or exchanges). There are two basic 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 +uses the TGT to authenticate itself to the TGS in the same +manner as if it were contacting any other application server +that requires Kerberos authentication. The reply is +encrypted in the session key from the TGT. Though the pro- +tocol specification describes the AS and the TGS as separate +servers, they are implemented in practice as different pro- +tocol entry points within a single Kerberos server. + + 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 tran- +saction, the client transmits the ticket to the application +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, addi- +tional information is sent to prove that the message ori- +ginated with 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 ses- +sion key. Since no one except the requesting principal and + + +Section 1. - 4 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 princi- +pals 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 contained in the +ticket or the subsession key found in the authenticator. + + The authentication exchanges mentioned above require +read-only access to the Kerberos database. Sometimes, how- +ever, the entries in the 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). +There is also a protocol for maintaining multiple copies of +the Kerberos database. Neither of these protocols are +described in this document. + +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 prove its identity to servers in other realms[3]. +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 +__________________________ +[3] Of course, with appropriate permission the client +could arrange registration of a separately-named prin- +cipal 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. + + +Section 1.1. - 5 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 tran- +sited 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 authen- +tication path to be easily constructed. If a hierarchical +organization is not used, it may be necessary to consult a +database in order to construct an authentication path +between realms. + + Although realms are typically hierarchical, intermedi- +ate realms may be bypassed to achieve cross-realm authenti- +cation 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. Authorization + +As an authentication service, Kerberos provides a means of +verifying the identity of principals on a network. Authen- +tication is usually useful primarily as a first step in the +process of authorization, determining whether a client may +use a service, which objects the client is allowed to +access, and the type of access allowed for each. Kerberos +does not, by itself, provide authorization. Possession of a +client ticket for a service provides only for authentication +of the client to that service, and in the absence of a +separate authorization procedure, it should not be con- +sidered by an application as authorizing the use of that +service. + + Such separate authorization methods may be implemented +as application specific access control functions and may be +based on files such as the application server, or on +separately issued authorization credentials such as those +based on proxies [7] , or on other authorization services. + + Applications should not be modified to accept the +issuance of a service ticket by the Kerberos server (even by + +Section 1.2. - 6 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +an modified Kerberos server) as granting authority to use +the service, since such applications may become vulnerable +to the bypass of this authorization check in an environment +where they interoperate with other KDCs or where other +options for application authentication (e.g. the PKTAPP pro- +posal) are provided. + +1.3. Environmental assumptions + +Kerberos imposes a few assumptions on the environment in +which it can properly function: + ++ "Denial of service" attacks are not solved with Ker- + beros. There are places in these protocols where an + 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 suc- + cessive 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 detec- + tion. The degree of "looseness" can be configured on a + per-server basis, but is typically on the order of 5 + minutes. If the clocks are synchronized over the net- + work, 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 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. + + + +Section 1.3. - 7 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +1.4. Glossary of terms + +Below is a list of terms used throughout this document. + + +Authentication Verifying the claimed identity of a + principal. + + +Authentication headerA 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 tran- + sited 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 permis- + sion 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. + + +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). + + + +Section 1.4. - 8 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +Credentials A ticket plus the secret session key + necessary to successfully use that + ticket in an authentication exchange. + + +KDC Key Distribution Center, a network ser- + vice 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 ser- + vice). + + +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 authentica- + tion 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. + + +Principal identifierThe 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 life- + time. In the case of a human user's + principal, the secret key is derived + + +Section 1.4. - 9 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + from a password. + + +Server A particular Principal which provides a + resource to network clients. The server + is sometimes refered to as the Applica- + tion Server. + + +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 "ses- + sion". + + +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 dura- + tion of a single association. + + +Ticket A record that helps a client authenti- + cate 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. + +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 demonstrated knowledge of a client's secret key (e.g. a +password-changing program) can insist that this flag be set +in any tickets they accept, and thus be assured that the + + +Section 2.1. - 10 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 tick- +ets 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) (see section 3.3.3.1). + +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 short- +lived 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 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 inter- +preted by the ticket-granting service (discussed below in +section 3.3). It can usually be ignored by application +servers. However, some particularly careful application + + +Section 2.3. - 11 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 ser- +viced. 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; post- +dated 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-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 + + +Section 2.5. - 12 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 process of granting a proxy using the proxy and +proxiable flags is used to provide credentials for use with +specific services. Though conceptually also a proxy, user's +wishing to delegate their identity for ANY purpose must use +the ticket forwarding mechanism described in the next sec- +tion to forward a ticket granting ticket. + + The PROXIABLE flag in a ticket is normally only inter- +preted 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 if requested by the +client on initial authentication. By default, the client +will request that it be set when requesting a ticket grant- +ing ticket, and reset when requesting any other ticket. + + This flag allows a client to pass a proxy to a server +to perform a remote request on its behalf, e.g. a print ser- +vice 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[4]. When +granting a proxy, the client must specify the new network +address from which the proxy is to be used, or indicate that +the proxy is to be issued for use from any address. + + The PROXY flag is set in a ticket by the TGS when it +issues a proxy ticket. Application servers may check this +flag and at their option they may require additional authen- +tication from the agent presenting the proxy in order to +provide an audit trail. + +2.6. Forwardable tickets + + Authentication forwarding is an instance of a proxy +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 +__________________________ +[4] Though it is permissible to request or issue tick- +ets with no network addresses specified. + + +Section 2.6. - 13 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 result can still be achieved if the user +engages in the AS exchange specifying 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 +a forwarded ticket 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 choose to pro- +cess FORWARDED tickets differently than non-FORWARDED tick- +ets. + +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 indi- +cates 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 ticket to be +issued for the end server is to be encrypted in the session +key from the a additional second ticket-granting ticket pro- +vided with the request. See section 3.3.3 for specific +details. + +__________________________ +[5] 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 ses- +sion and change another user's password. +[6] To authenticate a user logging on to a local sys- +tem, the credentials obtained in the AS exchange may +first be used in a TGS exchange to obtain credentials + + +Section 3.1. - 14 - Expires 11 January 1998 + + + + + + + Version 5 - Specification Revision 6 + + + +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 initiated +by a client when it wishes to obtain authentication creden- +tials for a given server but currently holds no credentials. +In its basic form, the client's secret key is used for en- +cryption 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 ser- +vices which must not be mediated through the Ticket-Granting +Service, but rather require a principal's secret key, such +as the password-changing service[5]. This exchange does not +by itself provide any assurance of the the identity of the +user[6]. + + 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 sec- +tions 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 ses- +sion 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 +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 +__________________________ +for a local server. Those credentials must then be +verified by a local server through successful comple- +tion of the Client/Server exchange. + + + +Section 3.1. - 15 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +message is not encrypted. The KRB_ERROR message contains +information which can be used to associate it with the mes- +sage to which it replies. The lack of encryption in the +KRB_ERROR message precludes the ability to detect replays, +fabrications, or modifications of such messages. + + Without preautentication, the authentication server +does not know whether the client is actually the principal +named in the request. It simply sends a reply without know- +ing 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 ini- +tial 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 pre- +authentication as described in section <<sec preauth>>. + +3.1.1. Generation of KRB_AS_REQ message + + The client may specify a number of options in the ini- +tial request. Among these options are whether pre- +authentication 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 non- +renewable ticket (due to configuration constraints; see sec- +tion 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 KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it +generates a "random" session key[7]. +__________________________ + + +Section 3.1.3. - 16 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + If there are multiple encryption keys registered for a +client in the Kerberos database (or if the key registered +supports multiple encryption types; e.g. DES-CBC-CRC and +DES-CBC-MD5), then the etype field from the AS request is +used by the KDC to select the encryption method to be used +for encrypting the response to the client. If there is more +than one supported, strong encryption type in the etype +list, the first valid etype for which an encryption key is +available is used. The encryption method used to respond to +a TGS request is taken from the keytype of the session key +found in the ticket granting ticket. + + When the etype field is present in a KDC request, +whether an AS or TGS request, the KDC will attempt to assign +the type of the random session key from the list of methods +in the etype field. The KDC will select the appropriate +type using the list of methods provided together with infor- +mation from the Kerberos database indicating acceptable +encryption methods for the application server. The KDC will +not issue tickets with a weak session key encryption type. + + If the requested start time is absent, indicates a time +in the past, or is within the window of acceptable clock +skew for the KDC and the POSTDATE option has not been speci- +fied, then the start time of the ticket is set to the +authentication server's current time. If it indicates a +time in the future beyond the acceptable clock skew, 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 cer- +tain types or ranges of postdated tickets), and if accept- +able, 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. + + + + + + + + + +__________________________ +[7] "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 is more desir- +able to use a truly random number generator, such as +one based on measurements of random physical phenomena. + + + +Section 3.1.3. - 17 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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: + ++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 follow- +ing options set if they have been requested and if the pol- +icy of the local realm allows: FORWARDABLE, MAY-POSTDATE, +POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is post- +dated (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 + + +Section 3.1.3. - 18 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +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 (or are otherwise expected +values), 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 encrypted part of the response may +be checked to notify the user of impending key expiration +(the client program could then suggest remedial action, such +as a password change). See section A.3 for pseudocode. + + Proper decryption of the KRB_AS_REP message is not suf- +ficient to verify the identity of the user; the user and an +attacker could cooperate to generate a KRB_AS_REP format +message which decrypts properly but is not from the proper +KDC. If the host wishes to verify the identity of the user, +it must require the user to present application credentials +which can be verified using a securely-stored secret key for +the host. If those credentials can be verified, then the +identity of the user can be assured. + +3.1.6. Receipt of KRB_ERROR message + + If the reply message type is KRB_ERROR, then the client +interprets it as an error and performs whatever +application-specific tasks are necessary to recover. + +3.2. The Client/Server Authentication Exchange + + Summary +Message direction Message type Section +Client to Application server KRB_AP_REQ 5.5.1 +[optional] Application server to client KRB_AP_REP or 5.5.2 + KRB_ERROR 5.9.1 + + + +Section 3.2. - 19 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + The client/server authentication (CS) exchange is used +by network applications to authenticate the client to the +server and vice versa. The client must have already +acquired credentials for the server using the AS or TGS +exchange. + +3.2.1. The KRB_AP_REQ message + + The KRB_AP_REQ contains authentication information +which should be part of the first message in an authenti- +cated transaction. It contains a ticket, an authenticator, +and some additional bookkeeping information (see section +5.5.1 for the exact format). The ticket by itself is insuf- +ficient to authenticate a client, since tickets are passed +across the network in cleartext[8], so the authenticator is +used to prevent invalid replay of tickets by proving to the +server that the client knows the session key of the ticket +and thus is entitled to use the ticket. The KRB_AP_REQ mes- +sage is referred to elsewhere as the "authentication +header." + +3.2.2. Generation of a KRB_AP_REQ message + + When a client wishes to initiate authentication to a +server, it obtains (either through a credentials cache, the +AS exchange, or the TGS exchange) a ticket and session key +for the desired service. The client may re-use any tickets +it holds until they expire. To use a ticket the client con- +structs a new Authenticator from the the system time, its +name, and optionally an application specific checksum, an +initial sequence number to be used in KRB_SAFE or KRB_PRIV +messages, and/or a session subkey to be used in negotiations +for a session key unique to this particular session. +Authenticators may not be re-used and will be rejected if +replayed to a server[9]. If a sequence number is to be +included, it should be randomly chosen so that even after +many messages have been exchanged it is not likely to col- +lide with other sequence numbers in use. + + The client may indicate a requirement of mutual +__________________________ +[8] Tickets contain both an encrypted and unencrypted +portion, so cleartext here refers to the entire unit, +which can be copied from one message and replayed in +another without any cryptographic skill. +[9] Note that this can make applications based on un- +reliable transports difficult to code correctly. If the +transport might deliver duplicated messages, either a +new authenticator must be generated for each retry, or +the application server must match requests and replies +and replay the first reply in response to a detected +duplicate. + + + +Section 3.2.2. - 20 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +authentication or the use of a session-key based ticket by +setting the appropriate flag(s) in the ap-options field of +the message. + + The Authenticator is encrypted in the session key and +combined with the ticket to form the KRB_AP_REQ message +which is then sent to the end server along with any addi- +tional application-specific information. See section A.9 +for pseudocode. + +3.2.3. Receipt of KRB_AP_REQ message + + Authentication is based on the server's current time of +day (clocks must be loosely synchronized), the authentica- +tor, and the ticket. Several errors are possible. If an +error occurs, the server is expected to reply to the client +with a KRB_ERROR message. This message may be encapsulated +in the application protocol if its "raw" form is not accept- +able to the protocol. The format of error messages is +described in section 5.9.1. + + The algorithm for verifying authentication information +is as follows. If the message type is not KRB_AP_REQ, the +server returns the KRB_AP_ERR_MSG_TYPE error. If the key +version indicated by the Ticket in the KRB_AP_REQ is not one +the server can use (e.g., it indicates an old key, and the +server no longer possesses a copy of the old key), the +KRB_AP_ERR_BADKEYVER error is returned. If the USE- +SESSION-KEY flag is set in the ap-options field, it indi- +cates to the server that the ticket is encrypted in the ses- +sion key from the server's ticket-granting ticket rather +than its secret key[10]. Since it is possible for the +server to be registered in multiple realms, with different +keys in each, the srealm field in the unencrypted portion of +the ticket in the KRB_AP_REQ is used to specify which secret +key the server should use to decrypt that ticket. The +KRB_AP_ERR_NOKEY error code is returned if the server +doesn't have the proper key to decipher the ticket. + + The ticket is decrypted using the version of the +server's key specified by the ticket. If the decryption +routines detect a modification of the ticket (each encryp- +tion system must provide safeguards to detect modified +ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY +error is returned (chances are good that different keys were +used to encrypt and decrypt). + + The authenticator is decrypted using the session key +extracted from the decrypted ticket. If decryption shows it +to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is +__________________________ +[10] This is used for user-to-user authentication as +described in [8]. + + +Section 3.2.3. - 21 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +returned. The name and realm of the client from the ticket +are compared against the same fields in the authenticator. +If they don't match, the KRB_AP_ERR_BADMATCH error is +returned (they might not match, for example, if the wrong +session key was used to encrypt the authenticator). The +addresses in the ticket (if any) are then searched for an +address matching the operating-system reported address of +the client. If no match is found or the server insists on +ticket addresses but none are present in the ticket, the +KRB_AP_ERR_BADADDR error is returned. + + If the local (server) time and the client time in the +authenticator differ by more than the allowable clock skew +(e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned. +If the server name, along with the client name, time and +microsecond fields from the Authenticator match any +recently-seen such tuples, the KRB_AP_ERR_REPEAT error is +returned[11]. The server must remember any authenticator +presented within the allowable clock skew, so that a replay +attempt is guaranteed to fail. If a server loses track of +any authenticator presented within the allowable clock skew, +it must reject all requests until the clock skew interval +has passed. This assures that any lost or re-played authen- +ticators will fall outside the allowable clock skew and can +no longer be successfully replayed (If this is not done, an +attacker could conceivably record the ticket and authentica- +tor sent over the network to a server, then disable the +client's host, pose as the disabled host, and replay the +ticket and authenticator to subvert the authentication.). +If a sequence number is provided in the authenticator, the +server saves it for later use in processing KRB_SAFE and/or +KRB_PRIV messages. If a subkey is present, the server +either saves it for later use or uses it to help generate +its own choice for a subkey to be returned in a KRB_AP_REP +message. + + The server computes the age of the ticket: local +(server) time minus the start time inside the Ticket. If +the start time is later than the current time by more than +the allowable clock skew or if the INVALID flag is set in +the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Oth- +erwise, if the current time is later than end time by more +than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED +error is returned. + + If all these checks succeed without an error, the +__________________________ +[11] Note that the rejection here is restricted to au- +thenticators from the same principal to the same +server. Other client principals communicating with the +same server principal should not be have their authen- +ticators rejected if the time and microsecond fields +happen to match some other client's authenticator. + + +Section 3.2.3. - 22 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +server is assured that the client possesses the credentials +of the principal named in the ticket and thus, the client +has been authenticated to the server. See section A.10 for +pseudocode. + + Passing these checks provides only authentication of +the named principal; it does not imply authorization to use +the named service. Applications must make a separate +authorization decisions based upon the authenticated name of +the user, the requested operation, local acces control +information such as that contained in a .k5login or .k5users +file, and possibly a separate distributed authorization ser- +vice. + +3.2.4. Generation of a KRB_AP_REP message + + Typically, a client's request will include both the +authentication information and its initial request in the +same message, and the server need not explicitly reply to +the KRB_AP_REQ. However, if mutual authentication (not only +authenticating the client to the server, but also the server +to the client) is being performed, the KRB_AP_REQ message +will have MUTUAL-REQUIRED set in its ap-options field, and a +KRB_AP_REP message is required in response. As with the +error message, this message may be encapsulated in the +application protocol if its "raw" form is not acceptable to +the application's protocol. The timestamp and microsecond +field used in the reply must be the client's timestamp and +microsecond field (as provided in the authenticator)[12]. +If a sequence number is to be included, it should be ran- +domly chosen as described above for the authenticator. A +subkey may be included if the server desires to negotiate a +different subkey. The KRB_AP_REP message is encrypted in +the session key extracted from the ticket. See section A.11 +for pseudocode. + +3.2.5. Receipt of KRB_AP_REP message + + + If a KRB_AP_REP message is returned, the client uses +the session key from the credentials obtained for the +server[13] to decrypt the message, and verifies that the +__________________________ +[12] In the Kerberos version 4 protocol, the timestamp +in the reply was the client's timestamp plus one. This +is not necessary in version 5 because version 5 mes- +sages are formatted in such a way that it is not possi- +ble to create the reply by judicious message surgery +(even in encrypted form) without knowledge of the ap- +propriate encryption keys. +[13] Note that for encrypting the KRB_AP_REP message, +the sub-session key is not used, even if present in the +Authenticator. + + +Section 3.2.5. - 23 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +timestamp and microsecond fields match those in the Authen- +ticator it sent to the server. If they match, then the +client is assured that the server is genuine. The sequence +number and subkey (if present) are retained for later use. +See section A.12 for pseudocode. + + +3.2.6. Using the encryption key + + After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, +the client and server share an encryption key which can be +used by the application. The "true session key" to be used +for KRB_PRIV, KRB_SAFE, or other application-specific uses +may be chosen by the application based on the subkeys in the +KRB_AP_REP message and the authenticator[14]. In some +cases, the use of this session key will be implicit in the +protocol; in others the method of use must be chosen from +several alternatives. We leave the protocol negotiations of +how to use the key (e.g. selecting an encryption or check- +sum type) to the application programmer; the Kerberos proto- +col does not constrain the implementation options, but an +example of how this might be done follows. + + One way that an application may choose to negotiate a +key to be used for subequent integrity and privacy protec- +tion is for the client to propose a key in the subkey field +of the authenticator. The server can then choose a key +using the proposed key from the client as input, returning +the new subkey in the subkey field of the application reply. +This key could then be used for subsequent communication. +To make this example more concrete, if the encryption method +in use required a 56 bit key, and for whatever reason, one +of the parties was prevented from using a key with more than +40 unknown bits, this method would allow the the party which +is prevented from using more than 40 bits to either propose +(if the client) an initial key with a known quantity for 16 +of those bits, or to mask 16 of the bits (if the server) +with the known quantity. The application implementor is +warned, however, that this is only an example, and that an +analysis of the particular crytosystem to be used, and the +reasons for limiting the key length, must be made before +deciding whether it is acceptable to mask bits of the key. + + With both the one-way and mutual authentication +exchanges, the peers should take care not to send sensitive +information to each other without proper assurances. In +particular, applications that require privacy or integrity +should use the KRB_AP_REP response from the server to client +__________________________ +[14] Implementations of the protocol may wish to pro- +vide routines to choose subkeys based on session keys +and random numbers and to generate a negotiated key to +be returned in the KRB_AP_REP message. + + +Section 3.2.6. - 24 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +to assure both client and server of their peer's identity. +If an application protocol requires privacy of its messages, +it can use the KRB_PRIV message (section 3.5). The KRB_SAFE +message (section 3.4) can be used to assure integrity. + + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + + The TGS exchange between a client and the Kerberos +Ticket-Granting Server is initiated by a client when it +wishes to obtain authentication credentials for a given +server (which might be registered in a remote realm), when +it wishes to renew or validate an existing ticket, or when +it wishes to obtain a proxy ticket. In the first case, the +client must already have acquired a ticket for the Ticket- +Granting Service using the AS exchange (the ticket-granting +ticket is usually obtained when a client initially authenti- +cates to the system, such as when a user logs in). The mes- +sage format for the TGS exchange is almost identical to that +for the AS exchange. The primary difference is that encryp- +tion and decryption in the TGS exchange does not take place +under the client's key. Instead, the session key from the +ticket-granting ticket or renewable ticket, or sub-session +key from an Authenticator is used. As is the case for all +application servers, expired tickets are not accepted by the +TGS, so once a renewable or ticket-granting ticket expires, +the client must use a separate exchange to obtain valid +tickets. + + The TGS exchange consists of two messages: A request +(KRB_TGS_REQ) from the client to the Kerberos Ticket- +Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR). +The KRB_TGS_REQ message includes information authenticating +the client plus a request for credentials. The authentica- +tion information consists of the authentication header +(KRB_AP_REQ) which includes the client's previously obtained +ticket-granting, renewable, or invalid ticket. In the +ticket-granting ticket and proxy cases, the request may +include one or more of: a list of network addresses, a col- +lection of typed authorization data to be sealed in the +ticket for authorization use by the application server, or +additional tickets (the use of which are described later). +The TGS reply (KRB_TGS_REP) contains the requested creden- +tials, encrypted in the session key from the ticket-granting +ticket or renewable ticket, or if present, in the sub- +session key from the Authenticator (part of the authentica- +tion header). The KRB_ERROR message contains an error code + + +Section 3.3. - 25 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +and text explaining what went wrong. The KRB_ERROR message +is not encrypted. The KRB_TGS_REP message contains informa- +tion which can be used to detect replays, and to associate +it with the message to which it replies. The KRB_ERROR mes- +sage also contains information which can be used to associ- +ate it with the message to which it replies, but the lack of +encryption in the KRB_ERROR message precludes the ability to +detect replays or fabrications of such messages. + +3.3.1. Generation of KRB_TGS_REQ message + + Before sending a request to the ticket-granting ser- +vice, the client must determine in which realm the applica- +tion server is registered[15]. If the client does not +already possess a ticket-granting ticket for the appropriate +realm, then one must be obtained. This is first attempted +by requesting a ticket-granting ticket for the destination +realm from a Kerberos server for which the client does +posess a ticket-granting ticket (using the KRB_TGS_REQ mes- +sage recursively). The Kerberos server may return a TGT for +the desired realm in which case one can proceed. Alterna- +tively, the Kerberos server may return a TGT for a realm +which is "closer" to the desired realm (further along the +standard hierarchical path), in which case this step must be +repeated with a Kerberos server in the realm specified in +the returned TGT. If neither are returned, then the request +must be retried with a Kerberos server for a realm higher in +the hierarchy. This request will itself require a ticket- +granting ticket for the higher realm which must be obtained +by recursively applying these directions. + + + Once the client obtains a ticket-granting ticket for +the appropriate realm, it determines which Kerberos servers +serve that realm, and contacts one. The list might be +obtained through a configuration file or network service or +it may be generated from the name of the realm; as long as +the secret keys exchanged by realms are kept secret, only +denial of service results from using a false Kerberos +server. +__________________________ +[15] This can be accomplished in several ways. It +might be known beforehand (since the realm is part of +the principal identifier), it might be stored in a +nameserver, or it might be obtained from a configura- +tion file. If the realm to be used is obtained from a +nameserver, there is a danger of being spoofed if the +nameservice providing the realm name is not authenti- +cated. This might result in the use of a realm which +has been compromised, and would result in an attacker's +ability to compromise the authentication of the appli- +cation server to the client. + + + +Section 3.3.1. - 26 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + As in the AS exchange, the client may specify a number +of options in the KRB_TGS_REQ message. The client prepares +the KRB_TGS_REQ message, providing an authentication header +as an element of the padata field, and including the same +fields as used in the KRB_AS_REQ message along with several +optional fields: the enc-authorization-data field for appli- +cation server use and additional tickets required by some +options. + + In preparing the authentication header, the client can +select a sub-session key under which the response from the +Kerberos server will be encrypted[16]. If the sub-session +key is not specified, the session key from the ticket- +granting ticket will be used. If the enc-authorization-data +is present, it must be encrypted in the sub-session key, if +present, from the authenticator portion of the authentica- +tion header, or if not present, using the session key from +the ticket-granting ticket. + + Once prepared, the message is sent to a Kerberos server +for the destination realm. See section A.5 for pseudocode. + +3.3.2. Receipt of KRB_TGS_REQ message + + The KRB_TGS_REQ message is processed in a manner simi- +lar to the KRB_AS_REQ message, but there are many additional +checks to be performed. First, the Kerberos server must +determine which server the accompanying ticket is for and it +must select the appropriate key to decrypt it. For a normal +KRB_TGS_REQ message, it will be for the ticket granting ser- +vice, and the TGS's key will be used. If the TGT was issued +by another realm, then the appropriate inter-realm key must +be used. If the accompanying ticket is not a ticket grant- +ing ticket for the current realm, but is for an application +server in the current realm, the RENEW, VALIDATE, or PROXY +options are specified in the request, and the server for +which a ticket is requested is the server named in the +accompanying ticket, then the KDC will decrypt the ticket in +the authentication header using the key of the server for +which it was issued. If no ticket can be found in the +padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is +returned. + + Once the accompanying ticket has been decrypted, the +user-supplied checksum in the Authenticator must be verified +against the contents of the request, and the message +rejected if the checksums do not match (with an error code +__________________________ +[16] If the client selects a sub-session key, care must +be taken to ensure the randomness of the selected sub- +session key. One approach would be to generate a ran- +dom number and XOR it with the session key from the +ticket-granting ticket. + + +Section 3.3.2. - 27 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or +not collision-proof (with an error code of +KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not sup- +ported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If +the authorization-data are present, they are decrypted using +the sub-session key from the Authenticator. + + If any of the decryptions indicate failed integrity +checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned. + +3.3.3. Generation of KRB_TGS_REP message + + The KRB_TGS_REP message shares its format with the +KRB_AS_REP (KRB_KDC_REP), but with its type field set to +KRB_TGS_REP. The detailed specification is in section +5.4.2. + + The response will include a ticket for the requested +server. The Kerberos database is queried to retrieve the +record for the requested server (including the key with +which the ticket will be encrypted). If the request is for +a ticket granting ticket for a remote realm, and if no key +is shared with the requested realm, then the Kerberos server +will select the realm "closest" to the requested realm with +which it does share a key, and use that realm instead. This +is the only case where the response from the KDC will be for +a different server than that requested by the client. + + By default, the address field, the client's name and +realm, the list of transited realms, the time of initial +authentication, the expiration time, and the authorization +data of the newly-issued ticket will be copied from the +ticket-granting ticket (TGT) or renewable ticket. If the +transited field needs to be updated, but the transited type +is not supported, the KDC_ERR_TRTYPE_NOSUPP error is +returned. + + If the request specifies an endtime, then the endtime +of the new ticket is set to the minimum of (a) that request, +(b) the endtime from the TGT, and (c) the starttime of the +TGT plus the minimum of the maximum life for the application +server and the maximum life for the local realm (the maximum +life for the requesting principal was already applied when +the TGT was issued). If the new ticket is to be a renewal, +then the endtime above is replaced by the minimum of (a) the +value of the renew_till field of the ticket and (b) the +starttime for the new ticket plus the life (endtime- +starttime) of the old ticket. + + If the FORWARDED option has been requested, then the +resulting ticket will contain the addresses specified by the +client. This option will only be honored if the FORWARDABLE +flag is set in the TGT. The PROXY option is similar; the +resulting ticket will contain the addresses specified by the + + +Section 3.3.3. - 28 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +client. It will be honored only if the PROXIABLE flag in +the TGT is set. The PROXY option will not be honored on +requests for additional ticket-granting tickets. + + If the requested start time is absent, indicates a time +in the past, or is within the window of acceptable clock +skew for the KDC and the POSTDATE option has not been speci- +fied, then the start time of the ticket is set to the +authentication server's current time. If it indicates a +time in the future beyond the acceptable clock skew, but the +POSTDATED option has not been specified or the MAY-POSTDATE +flag is not set in the TGT, then the error +KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the +ticket-granting ticket has the MAY-POSTDATE flag set, then +the resulting ticket will be postdated and the requested +starttime is checked against the policy of the local realm. +If acceptable, the ticket's start time is set as requested, +and the INVALID flag is set. The postdated ticket must be +validated before use by presenting it to the KDC after the +starttime has been reached. However, in no case may the +starttime, endtime, or renew-till time of a newly-issued +postdated ticket extend beyond the renew-till time of the +ticket-granting ticket. + + If the ENC-TKT-IN-SKEY option has been specified and an +additional ticket has been included in the request, the KDC +will decrypt the additional ticket using the key for the +server to which the additional ticket was issued and verify +that it is a ticket-granting ticket. If the name of the +requested server is missing from the request, the name of +the client in the additional ticket will be used. Otherwise +the name of the requested server will be compared to the +name of the client in the additional ticket and if dif- +ferent, the request will be rejected. If the request +succeeds, the session key from the additional ticket will be +used to encrypt the new ticket that is issued instead of +using the key of the server for which the new ticket will be +used[17]. + + If the name of the server in the ticket that is +presented to the KDC as part of the authentication header is +not that of the ticket-granting server itself, the server is +registered in the realm of the KDC, and the RENEW option is +requested, then the KDC will verify that the RENEWABLE flag +is set in the ticket, that the INVALID flag is not set in +the ticket, and that the renew_till time is still in the +future. If the VALIDATE option is rqeuested, the KDC will +__________________________ +[17] This allows easy implementation of user-to-user +authentication [8], which uses ticket-granting ticket +session keys in lieu of secret server keys in situa- +tions where such secret keys could be easily comprom- +ised. + + +Section 3.3.3. - 29 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +check that the starttime has passed and the INVALID flag is +set. If the PROXY option is requested, then the KDC will +check that the PROXIABLE flag is set in the ticket. If the +tests succeed, and the ticket passes the hotlist check +described in the next paragraph, the KDC will issue the +appropriate new ticket. + + +3.3.3.1. Checking for revoked tickets + + Whenever a request is made to the ticket-granting +server, the presented ticket(s) is(are) checked against a +hot-list of tickets which have been canceled. This hot-list +might be implemented by storing a range of issue timestamps +for "suspect tickets"; if a presented ticket had an authtime +in that range, it would be rejected. In this way, a stolen +ticket-granting ticket or renewable ticket cannot be used to +gain additional tickets (renewals or otherwise) once the +theft has been reported. Any normal ticket obtained before +it was reported stolen will still be valid (because they +require no interaction with the KDC), but only until their +normal expiration time. + + The ciphertext part of the response in the KRB_TGS_REP +message is encrypted in the sub-session key from the Authen- +ticator, if present, or the session key key from the +ticket-granting ticket. It is not encrypted using the +client's secret key. Furthermore, the client's key's +expiration date and the key version number fields are left +out since these values are stored along with the client's +database record, and that record is not needed to satisfy a +request based on a ticket-granting ticket. See section A.6 +for pseudocode. + +3.3.3.2. Encoding the transited field + + If the identity of the server in the TGT that is +presented to the KDC as part of the authentication header is +that of the ticket-granting service, but the TGT was issued +from another realm, the KDC will look up the inter-realm key +shared with that realm and use that key to decrypt the +ticket. If the ticket is valid, then the KDC will honor the +request, subject to the constraints outlined above in the +section describing the AS exchange. The realm part of the +client's identity will be taken from the ticket-granting +ticket. The name of the realm that issued the ticket- +granting ticket will be added to the transited field of the +ticket to be issued. This is accomplished by reading the +transited field from the ticket-granting ticket (which is +treated as an unordered set of realm names), adding the new +realm to the set, then constructing and writing out its +encoded (shorthand) form (this may involve a rearrangement +of the existing encoding). + + + +Section 3.3.3.2. - 30 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + Note that the ticket-granting service does not add the +name of its own realm. Instead, its responsibility is to +add the name of the previous realm. This prevents a mali- +cious Kerberos server from intentionally leaving out its own +name (it could, however, omit other realms' names). + + The names of neither the local realm nor the +principal's realm are to be included in the transited field. +They appear elsewhere in the ticket and both are known to +have taken part in authenticating the principal. Since the +endpoints are not included, both local and single-hop +inter-realm authentication result in a transited field that +is empty. + + Because the name of each realm transited is added to +this field, it might potentially be very long. To decrease +the length of this field, its contents are encoded. The +initially supported encoding is optimized for the normal +case of inter-realm communication: a hierarchical arrange- +ment of realms using either domain or X.500 style realm +names. This encoding (called DOMAIN-X500-COMPRESS) is now +described. + + Realm names in the transited field are separated by a +",". The ",", "\", trailing "."s, and leading spaces (" ") +are special characters, and if they are part of a realm +name, they must be quoted in the transited field by preced- +ing them with a "\". + + A realm name ending with a "." is interpreted as being +prepended to the previous realm. For example, we can encode +traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, +and CS.WASHINGTON.EDU as: + + "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". + +Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end- +points, that they would not be included in this field, and +we would have: + + "EDU,MIT.,WASHINGTON.EDU" + +A realm name beginning with a "/" is interpreted as being +appended to the previous realm[18]. If it is to stand by +itself, then it should be preceded by a space (" "). For +example, we can encode traversal of /COM/HP/APOLLO, /COM/HP, +/COM, and /COM/DEC as: + + "/COM,/HP,/APOLLO, /COM/DEC". +__________________________ +[18] For the purpose of appending, the realm preceding +the first listed realm is considered to be the null +realm (""). + + +Section 3.3.3.2. - 31 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +Like the example above, if /COM/HP/APOLLO and /COM/DEC are +endpoints, they they would not be included in this field, +and we would have: + + "/COM,/HP" + + + A null subfield preceding or following a "," indicates +that all realms between the previous realm and the next +realm have been traversed[19]. Thus, "," means that all +realms along the path between the client and the server have +been traversed. ",EDU, /COM," means that that all realms +from the client's realm up to EDU (in a domain style hierar- +chy) have been traversed, and that everything from /COM down +to the server's realm in an X.500 style has also been +traversed. This could occur if the EDU realm in one hierar- +chy shares an inter-realm key directly with the /COM realm +in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + +When the KRB_TGS_REP is received by the client, it is pro- +cessed in the same manner as the KRB_AS_REP processing +described above. The primary difference is that the cipher- +text part of the response must be decrypted using the ses- +sion key from the ticket-granting ticket rather than the +client's secret key. See section A.7 for pseudocode. + + +3.4. The KRB_SAFE Exchange + + The KRB_SAFE message may be used by clients requiring +the ability to detect modifications of messages they +exchange. It achieves this by including a keyed collision- +proof checksum of the user data and some control informa- +tion. The checksum is keyed with an encryption key (usually +the last key negotiated via subkeys, or the session key if +no negotiation has occured). + +3.4.1. Generation of a KRB_SAFE message + +When an application wishes to send a KRB_SAFE message, it +collects its data and the appropriate control information +and computes a checksum over them. The checksum algorithm +should be a keyed one-way hash function (such as the RSA- +MD5-DES checksum algorithm specified in section 6.4.5, or +the DES MAC), generated using the sub-session key if +present, or the session key. Different algorithms may be +__________________________ +[19] For the purpose of interpreting null subfields, +the client's realm is considered to precede those in +the transited field, and the server's realm is con- +sidered to follow them. + + +Section 3.4.1. - 32 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +selected by changing the checksum type in the message. +Unkeyed or non-collision-proof checksums are not suitable +for this use. + + The control information for the KRB_SAFE message +includes both a timestamp and a sequence number. The +designer of an application using the KRB_SAFE message must +choose at least one of the two mechanisms. This choice +should be based on the needs of the application protocol. + + Sequence numbers are useful when all messages sent will +be received by one's peer. Connection state is presently +required to maintain the session key, so maintaining the +next sequence number should not present an additional prob- +lem. + + If the application protocol is expected to tolerate +lost messages without them being resent, the use of the +timestamp is the appropriate replay detection mechanism. +Using timestamps is also the appropriate mechanism for +multi-cast protocols where all of one's peers share a common +sub-session key, but some messages will be sent to a subset +of one's peers. + + After computing the checksum, the client then transmits +the information and checksum to the recipient in the message +format specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + +When an application receives a KRB_SAFE message, it verifies +it as follows. If any error occurs, an error code is +reported for use by the application. + + The message is first checked by verifying that the pro- +tocol version and type fields match the current version and +KRB_SAFE, respectively. A mismatch generates a +KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application verifies that the checksum used is a collision- +proof keyed checksum, and if it is not, a +KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient +verifies that the operating system's report of the sender's +address matches the sender's address in the message, and (if +a recipient address is specified or the recipient requires +an address) that one of the recipient's addresses appears as +the recipient's address in the message. A failed match for +either case generates a KRB_AP_ERR_BADADDR error. Then the +timestamp and usec and/or the sequence number fields are +checked. If timestamp and usec are expected and not +present, or they are present but not current, the +KRB_AP_ERR_SKEW error is generated. If the server name, +along with the client name, time and microsecond fields from +the Authenticator match any recently-seen (sent or +received[20] ) such tuples, the KRB_AP_ERR_REPEAT error is +__________________________ +[20] This means that a client and server running on the + + + + + + + Version 5 - Specification Revision 6 + + +generated. If an incorrect sequence number is included, or +a sequence number is expected but not present, the +KRB_AP_ERR_BADORDER error is generated. If neither a time- +stamp and usec or a sequence number is present, a +KRB_AP_ERR_MODIFIED error is generated. Finally, the check- +sum is computed over the data and control information, and +if it doesn't match the received checksum, a +KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application is assured +that the message was generated by its peer and was not modi- +fied in transit. + +3.5. The KRB_PRIV Exchange + + The KRB_PRIV message may be used by clients requiring +confidentiality and the ability to detect modifications of +exchanged messages. It achieves this by encrypting the mes- +sages and adding control information. + +3.5.1. Generation of a KRB_PRIV message + +When an application wishes to send a KRB_PRIV message, it +collects its data and the appropriate control information +(specified in section 5.7.1) and encrypts them under an +encryption key (usually the last key negotiated via subkeys, +or the session key if no negotiation has occured). As part +of the control information, the client must choose to use +either a timestamp or a sequence number (or both); see the +discussion in section 3.4.1 for guidelines on which to use. +After the user data and control information are encrypted, +the client transmits the ciphertext and some "envelope" +information to the recipient. + +3.5.2. Receipt of KRB_PRIV message + +When an application receives a KRB_PRIV message, it verifies +it as follows. If any error occurs, an error code is +reported for use by the application. + + The message is first checked by verifying that the pro- +tocol version and type fields match the current version and +KRB_PRIV, respectively. A mismatch generates a +KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application then decrypts the ciphertext and processes the +resultant plaintext. If decryption shows the data to have +been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- +erated. The recipient verifies that the operating system's +report of the sender's address matches the sender's address +__________________________ +same host and communicating with one another using the +KRB_SAFE messages should not share a common replay +cache to detect KRB_SAFE replays. + + + +Section 3.5.2. - 34 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +in the message, and (if a recipient address is specified or +the recipient requires an address) that one of the +recipient's addresses appears as the recipient's address in +the message. A failed match for either case generates a +KRB_AP_ERR_BADADDR error. Then the timestamp and usec +and/or the sequence number fields are checked. If timestamp +and usec are expected and not present, or they are present +but not current, the KRB_AP_ERR_SKEW error is generated. If +the server name, along with the client name, time and +microsecond fields from the Authenticator match any +recently-seen such tuples, the KRB_AP_ERR_REPEAT error is +generated. If an incorrect sequence number is included, or +a sequence number is expected but not present, the +KRB_AP_ERR_BADORDER error is generated. If neither a time- +stamp and usec or a sequence number is present, a +KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application can assume +the message was generated by its peer, and was securely +transmitted (without intruders able to see the unencrypted +contents). + +3.6. The KRB_CRED Exchange + + The KRB_CRED message may be used by clients requiring +the ability to send Kerberos credentials from one host to +another. It achieves this by sending the tickets together +with encrypted data containing the session keys and other +information associated with the tickets. + +3.6.1. Generation of a KRB_CRED message + +When an application wishes to send a KRB_CRED message it +first (using the KRB_TGS exchange) obtains credentials to be +sent to the remote host. It then constructs a KRB_CRED mes- +sage using the ticket or tickets so obtained, placing the +session key needed to use each ticket in the key field of +the corresponding KrbCredInfo sequence of the encrypted part +of the the KRB_CRED message. + + Other information associated with each ticket and +obtained during the KRB_TGS exchange is also placed in the +corresponding KrbCredInfo sequence in the encrypted part of +the KRB_CRED message. The current time and, if specifically +required by the application the nonce, s-address, and r- +address fields, are placed in the encrypted part of the +KRB_CRED message which is then encrypted under an encryption +key previosuly exchanged in the KRB_AP exchange (usually the +last key negotiated via subkeys, or the session key if no +negotiation has occured). + +3.6.2. Receipt of KRB_CRED message + +When an application receives a KRB_CRED message, it verifies + + +Section 3.6.2. - 35 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +it. If any error occurs, an error code is reported for use +by the application. The message is verified by checking +that the protocol version and type fields match the current +version and KRB_CRED, respectively. A mismatch generates a +KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The +application then decrypts the ciphertext and processes the +resultant plaintext. If decryption shows the data to have +been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- +erated. + + If present or required, the recipient verifies that the +operating system's report of the sender's address matches +the sender's address in the message, and that one of the +recipient's addresses appears as the recipient's address in +the message. A failed match for either case generates a +KRB_AP_ERR_BADADDR error. The timestamp and usec fields +(and the nonce field if required) are checked next. If the +timestamp and usec are not present, or they are present but +not current, the KRB_AP_ERR_SKEW error is generated. + + If all the checks succeed, the application stores each +of the new tickets in its ticket cache together with the +session key and other information in the corresponding +KrbCredInfo sequence from the encrypted part of the KRB_CRED +message. + +4. The Kerberos Database + +The Kerberos server must have access to a database contain- +ing the principal identifiers and secret keys of principals +to be authenticated[21]. + +4.1. Database contents + +A database entry should contain at least the following +fields: + +Field Value + +name Principal's identif- +ier +key Principal's secret key +p_kvno Principal's key version +max_life Maximum lifetime for Tickets +__________________________ +[21] The implementation of the Kerberos server need not +combine the database and the server on the same +machine; it is feasible to store the principal database +in, say, a network name service, as long as the entries +stored therein are protected from disclosure to and +modification by unauthorized parties. However, we +recommend against such strategies, as they can make +system management and threat analysis quite complex. + + +Section 4.1. - 36 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +max_renewable_life Maximum total lifetime for renewable Tickets + +The name field is an encoding of the principal's identifier. +The key field contains an encryption key. This key is the +principal's secret key. (The key can be encrypted before +storage under 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 to indicate the mas- +ter key version used, see below.) The p_kvno field is the +key version number of the principal's secret key. The +max_life field contains the maximum allowable lifetime (end- +time - starttime) for any Ticket issued for this principal. +The max_renewable_life field contains the maximum allowable +total lifetime for any renewable Ticket issued for this +principal. (See section 3.1 for a description of how these +lifetimes are used in determining the lifetime of a given +Ticket.) + + A server may provide KDC service to several realms, as +long as the database representation provides a mechanism to +distinguish between principal records with identifiers which +differ only in the realm name. + + When an application server's key changes, if the change +is routine (i.e. not the result of disclosure of the old +key), the old key should be retained by the server until all +tickets that had been issued using that key have expired. +Because of this, it is possible for several keys to be +active for a single principal. Ciphertext encrypted in a +principal's key is always tagged with the version of the key +that was used for encryption, to help the recipient find the +proper key for decryption. + + When more than one key is active for a particular prin- +cipal, the principal will have more than one record in the +Kerberos database. The keys and key version numbers will +differ between the records (the rest of the fields may or +may not be the same). Whenever Kerberos issues a ticket, or +responds to a request for initial authentication, the most +recent key (known by the Kerberos server) will be used for +encryption. This is the key with the highest key version +number. + +4.2. Additional fields + +Project Athena's KDC implementation uses additional fields +in its database: + +Field Value + +K_kvno Kerberos' key version +expiration Expiration date for entry +attributes Bit field of attributes +mod_date Timestamp of last modification + + +Section 4.2. - 37 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +mod_name Modifying principal's identifier + + +The K_kvno field indicates the key version of the Kerberos +master key under which the principal's secret key is +encrypted. + + After an entry's expiration date has passed, the KDC +will return an error to any client attempting to gain tick- +ets as or for the principal. (A database may want to main- +tain two expiration dates: one for the principal, and one +for the principal's current key. This allows password aging +to work independently of the principal's expiration date. +However, due to the limited space in the responses, the KDC +must combine the key expiration and principal expiration +date into a single value called "key_exp", which is used as +a hint to the user to take administrative action.) + + The attributes field is a bitfield used to govern the +operations involving the principal. This field might be +useful in conjunction with user registration procedures, for +site-specific policy implementations (Project Athena +currently uses it for their user registration process con- +trolled by the system-wide database service, Moira [9]), to +identify whether a principal can play the role of a client +or server or both, to note whether a server is appropriate +trusted to recieve credentials delegated by a client, or to +identify the "string to key" conversion algorithm used for a +principal's key[22]. Other bits are used to indicate that +certain ticket options should not be allowed in tickets +encrypted under a principal's key (one bit each): Disallow +issuing postdated tickets, disallow issuing forwardable +tickets, disallow issuing tickets based on TGT authentica- +tion, disallow issuing renewable tickets, disallow issuing +proxiable tickets, and disallow issuing tickets for which +the principal is the server. + + The mod_date field contains the time of last modifica- +tion of the entry, and the mod_name field contains the name +of the principal which last modified the entry. + +4.3. Frequently Changing Fields + + Some KDC implementations may wish to maintain the last +time that a request was made by a particular principal. +Information that might be maintained includes the time of +the last request, the time of the last request for a +ticket-granting ticket, the time of the last use of a +ticket-granting ticket, or other times. This information +can then be returned to the user in the last-req field (see +__________________________ +[22] See the discussion of the padata field in section +5.4.2 for details on why this can be useful. + + +Section 4.3. - 38 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +section 5.2). + + Other frequently changing information that can be main- +tained is the latest expiration time for any tickets that +have been issued using each key. This field would be used +to indicate how long old keys must remain valid to allow the +continued use of outstanding tickets. + +4.4. Site Constants + + The KDC implementation should have the following confi- +gurable constants or options, to allow an administrator to +make and enforce policy decisions: + ++ The minimum supported lifetime (used to determine whether + the KDC_ERR_NEVER_VALID error should be returned). This + constant should reflect reasonable expectations of + round-trip time to the KDC, encryption/decryption time, + and processing time by the client and target server, and + it should allow for a minimum "useful" lifetime. + ++ The maximum allowable total (renewable) lifetime of a + ticket (renew_till - starttime). + ++ The maximum allowable lifetime of a ticket (endtime - + starttime). + ++ Whether to allow the issue of tickets with empty address + fields (including the ability to specify that such tick- + ets may only be issued if the request specifies some + authorization_data). + ++ Whether proxiable, forwardable, renewable or post-datable + tickets are to be issued. + + +5. Message Specifications + + The following sections describe the exact contents and +encoding of protocol messages and objects. The ASN.1 base +definitions are presented in the first subsection. The +remaining subsections specify the protocol objects (tickets +and authenticators) and messages. Specification of encryp- +tion and checksum techniques, and the fields related to +them, appear in section 6. + +5.1. ASN.1 Distinguished Encoding Representation + + All uses of ASN.1 in Kerberos shall use the Dis- +tinguished Encoding Representation of the data elements as +described in the X.509 specification, section 8.7 [10]. + + + + + +Section 5.1. - 39 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +5.2. ASN.1 Base Definitions + + The following ASN.1 base definitions are used in the +rest of this section. Note that since the underscore char- +acter (_) is not permitted in ASN.1 names, the hyphen (-) is +used in its place for the purposes of ASN.1 names. + +Realm ::= GeneralString +PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString +} + + +Kerberos realms are encoded as GeneralStrings. Realms shall +not contain a character with the code 0 (the ASCII NUL). +Most realms will usually consist of several components +separated by periods (.), in the style of Internet Domain +Names, or separated by slashes (/) in the style of X.500 +names. Acceptable forms for realm names are specified in +section 7. A PrincipalName is a typed sequence of com- +ponents consisting of the following sub-fields: + +name-type This field specifies the type of name that fol- + lows. Pre-defined values for this field are + specified in section 7.2. The name-type should be + treated as a hint. Ignoring the name type, no two + names can be the same (i.e. at least one of the + components, or the realm, must be different). + This constraint may be eliminated in the future. + +name-stringThis field encodes a sequence of components that + form a name, each component encoded as a General- + String. Taken together, a PrincipalName and a + Realm form a principal identifier. Most Princi- + palNames will have only a few components (typi- + cally one or two). + + + + KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + + + The timestamps used in Kerberos are encoded as General- +izedTimes. An encoding shall specify the UTC time zone (Z) +and shall not include any fractional portions of the +seconds. It further shall not include any separators. +Example: The only valid format for UTC time 6 minutes, 27 +seconds after 9 pm on 6 November 1985 is 19851106210627Z. + + HostAddress ::= SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING + + +Section 5.2. - 40 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + } + + HostAddresses ::= SEQUENCE OF SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING + } + + + The host adddress encodings consists of two fields: + +addr-type This field specifies the type of address that + follows. Pre-defined values for this field are + specified in section 8.1. + + +address This field encodes a single address of type addr- + type. + +The two forms differ slightly. HostAddress contains exactly +one address; HostAddresses contains a sequence of possibly +many addresses. + +AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type[0] INTEGER, + ad-data[1] OCTET STRING +} + + +ad-data This field contains authorization data to be + interpreted according to the value of the + corresponding ad-type field. + +ad-type This field specifies the format for the ad-data + subfield. All negative values are reserved for + local use. Non-negative values are reserved for + registered use. + + APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) + } + + + TicketFlags ::= BIT STRING { + reserved(0), + forwardable(1), + forwarded(2), + proxiable(3), + proxy(4), + may-postdate(5), + postdated(6), + invalid(7), + renewable(8), + initial(9), + + +Section 5.2. - 41 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + pre-authent(10), + hw-authent(11), + transited-policy-checked(12), + ok-as-delegate(13) + } + + + KDCOptions ::= BIT STRING { + reserved(0), + forwardable(1), + forwarded(2), + proxiable(3), + proxy(4), + allow-postdate(5), + postdated(6), + unused7(7), + renewable(8), + unused9(9), + unused10(10), + unused11(11), + unused12(12), + unused13(13), + disable-transited-check(26), + renewable-ok(27), + enc-tkt-in-skey(28), + renew(30), + validate(31) + } + + ASN.1 Bit strings have a length and a value. When + used in Kerberos for the APOptions, TicketFlags, + and KDCOptions, the length of the bit string on + generated values should be the smallest multiple + of 32 bits needed to include the highest order bit + that is set (1), but in no case less than 32 bits. + Implementations should accept values of bit + strings of any length and treat the value of flags + cooresponding to bits beyond the end of the bit + string as if the bit were reset (0). Comparisonof + bit strings of different length should treat the + smaller string as if it were padded with zeros + beyond the high order bits to the length of the + longer string[23]. + +__________________________ +[23] Warning for implementations that unpack and repack +data structures during the generation and verification +of embedded checksums: Because any checksums applied to +data structures must be checked against the original +data the length of bit strings must be preserved within +a data structure between the time that a checksum is +generated through transmission to the time that the +checksum is verified. + + + +Section 5.2. - 42 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type[0] INTEGER, + lr-value[1] KerberosTime + } + + +lr-type This field indicates how the following lr-value + field is to be interpreted. Negative values indi- + cate that the information pertains only to the + responding server. Non-negative values pertain to + all servers for the realm. + + If the lr-type field is zero (0), then no informa- + tion is conveyed by the lr-value subfield. If the + absolute value of the lr-type field is one (1), + then the lr-value subfield is the time of last + initial request for a TGT. If it is two (2), then + the lr-value subfield is the time of last initial + request. If it is three (3), then the lr-value + subfield is the time of issue for the newest + ticket-granting ticket used. If it is four (4), + then the lr-value subfield is the time of the last + renewal. If it is five (5), then the lr-value + subfield is the time of last request (of any + type). + + +lr-value This field contains the time of the last request. + The time must be interpreted according to the con- + tents of the accompanying lr-type subfield. + + See section 6 for the definitions of Checksum, Check- +sumType, EncryptedData, EncryptionKey, EncryptionType, and +KeyType. + + +5.3. Tickets and Authenticators + + This section describes the format and encryption param- +eters for tickets and authenticators. When a ticket or +authenticator is included in a protocol message it is +treated as an opaque object. + +5.3.1. Tickets + + A ticket is a record that helps a client authenticate +to a service. A Ticket contains the following information: + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno[0] INTEGER, + realm[1] Realm, + sname[2] PrincipalName, + enc-part[3] EncryptedData +} + + +Section 5.3.1. - 43 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +-- Encrypted part of ticket +EncTicketPart ::= [APPLICATION 3] SEQUENCE { + flags[0] TicketFlags, + key[1] EncryptionKey, + crealm[2] Realm, + cname[3] PrincipalName, + transited[4] TransitedEncoding, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + caddr[9] HostAddresses OPTIONAL, + authorization-data[10] AuthorizationData OPTIONAL +} +-- encoded Transited field +TransitedEncoding ::= SEQUENCE { + tr-type[0] INTEGER, -- must be registered + contents[1] OCTET STRING +} + +The encoding of EncTicketPart is encrypted in the key shared +by Kerberos and the end server (the server's secret key). +See section 6 for the format of the ciphertext. + +tkt-vno This field specifies the version number for the + ticket format. This document describes version + number 5. + + +realm This field specifies the realm that issued a + ticket. It also serves to identify the realm part + of the server's principal identifier. Since a + Kerberos server can only issue tickets for servers + within its realm, the two will always be identi- + cal. + + +sname This field specifies the name part of the server's + identity. + + +enc-part This field holds the encrypted encoding of the + EncTicketPart sequence. + + +flags This field indicates which of various options were + used or requested when the ticket was issued. It + is a bit-field, where the selected options are + indicated by the bit being set (1), and the + unselected options and reserved fields being reset + (0). Bit 0 is the most significant bit. The + encoding of the bits is specified in section 5.2. + The flags are described in more detail above in + section 2. The meanings of the flags are: + + +Section 5.3.1. - 44 - Expires 11 January 1998 + + + + + + Version 5 - Specification Revision 6 + + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, this + flag tells the ticket-granting server + that it is OK to issue a new ticket- + granting ticket with a different network + address based on the presented ticket. + + 2 FORWARDED + When set, this flag indicates that the + ticket has either been forwarded or was + issued based on authentication involving + a forwarded ticket-granting ticket. + + 3 PROXIABLE + The PROXIABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. The PROXIABLE + flag has an interpretation identical to + that of the FORWARDABLE flag, except + that the PROXIABLE flag tells the + ticket-granting server that only non- + ticket-granting tickets may be issued + with different network addresses. + + 4 PROXY + When set, this flag indicates that a + ticket is a proxy. + + 5 MAY-POSTDATE + The MAY-POSTDATE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. This flag tells + the ticket-granting server that a post- + dated ticket may be issued based on this + ticket-granting ticket. + + 6 POSTDATED + This flag indicates that this ticket has + been postdated. The end-service can + check the authtime field to see when the + original authentication occurred. + + 7 INVALID + This flag indicates that a ticket is + invalid, and it must be validated by the + KDC before use. Application servers + must reject tickets which have this flag + set. + + + + + + + + +Section 5.3.1. - 45 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + 8 RENEWABLE + The RENEWABLE flag is normally only + interpreted by the TGS, and can usually + be ignored by end servers (some particu- + larly careful servers may wish to disal- + low renewable tickets). A renewable + ticket can be used to obtain a replace- + ment ticket that expires at a later + date. + + 9 INITIAL + This flag indicates that this ticket was + issued using the AS protocol, and not + issued based on a ticket-granting + ticket. + + 10 PRE-AUTHENT + This flag indicates that during initial + authentication, the client was authenti- + cated by the KDC before a ticket was + issued. The strength of the pre- + authentication method is not indicated, + but is acceptable to the KDC. + + 11 HW-AUTHENT + This flag indicates that the protocol + employed for initial authentication + required the use of hardware expected to + be possessed solely by the named client. + The hardware authentication method is + selected by the KDC and the strength of + the method is not indicated. + + + + +Section 5.3.1. - 46 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + 12 TRANSITED This flag indicates that the KDC for the + POLICY-CHECKED realm has checked the transited field + against a realm defined policy for + trusted certifiers. If this flag is + reset (0), then the application server + must check the transited field itself, + and if unable to do so it must reject + the authentication. If the flag is set + (1) then the application server may skip + its own validation of the transited + field, relying on the validation + performed by the KDC. At its option the + application server may still apply its + own validation based on a separate + policy for acceptance. + +Section 5.3.1. - 47 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + 13 OK-AS-DELEGATE This flag indicates that the server (not + the client) specified in the ticket has + been determined by policy of the realm + to be a suitable recipient of + delegation. A client can use the + presence of this flag to help it make a + decision whether to delegate credentials + (either grant a proxy or a forwarded + ticket granting ticket) to this server. + The client is free to ignore the value + of this flag. When setting this flag, + an administrator should consider the + security and placement of the server on + which the service will run, as well as + whether the service requires the use of + delegated credentials. + + + + +Section 5.3.1. - 48 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + 14 ANONYMOUS + This flag indicates that the principal + named in the ticket is a generic princi- + pal for the realm and does not identify + the individual using the ticket. The + purpose of the ticket is only to + securely distribute a session key, and + not to identify the user. Subsequent + requests using the same ticket and ses- + sion may be considered as originating + from the same user, but requests with + the same username but a different ticket + are likely to originate from different + users. + + 15-31 RESERVED + Reserved for future use. + + + +key This field exists in the ticket and the KDC + response and is used to pass the session key from + Kerberos to the application server and the client. + The field's encoding is described in section 6.2. + +crealm This field contains the name of the realm in which + the client is registered and in which initial + authentication took place. + + +cname This field contains the name part of the client's + principal identifier. + + +transited This field lists the names of the Kerberos realms + that took part in authenticating the user to whom + this ticket was issued. It does not specify the + order in which the realms were transited. See + section 3.3.3.2 for details on how this field + encodes the traversed realms. + + +authtime This field indicates the time of initial authenti- + cation for the named principal. It is the time of + issue for the original ticket on which this ticket + is based. It is included in the ticket to provide + additional information to the end service, and to + provide the necessary information for implementa- + tion of a `hot list' service at the KDC. An end + service that is particularly paranoid could refuse + to accept tickets for which the initial authenti- + cation occurred "too far" in the past. + + This field is also returned as part of the + response from the KDC. When returned as part of + the response to initial authentication + + +Section 5.3.1. - 49 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + (KRB_AS_REP), this is the current time on the Ker- + beros server[24]. + + +starttime This field in the ticket specifies the time after + which the ticket is valid. Together with endtime, + this field specifies the life of the ticket. If + it is absent from the ticket, its value should be + treated as that of the authtime field. + + +endtime This field contains the time after which the + ticket will not be honored (its expiration time). + Note that individual services may place their own + limits on the life of a ticket and may reject + tickets which have not yet expired. As such, this + is really an upper bound on the expiration time + for the ticket. + + +renew-tillThis field is only present in tickets that have + the RENEWABLE flag set in the flags field. It + indicates the maximum endtime that may be included + in a renewal. It can be thought of as the abso- + lute expiration time for the ticket, including all + renewals. + + +caddr This field in a ticket contains zero (if omitted) + or more (if present) host addresses. These are + the addresses from which the ticket can be used. + If there are no addresses, the ticket can be used + from any location. The decision by the KDC to + issue or by the end server to accept zero-address + tickets is a policy decision and is left to the + Kerberos and end-service administrators; they may + refuse to issue or accept such tickets. The sug- + gested and default policy, however, is that such + tickets will only be issued or accepted when addi- + tional information that can be used to restrict + the use of the ticket is included in the + authorization_data field. Such a ticket is a + capability. + + Network addresses are included in the ticket to + make it harder for an attacker to use stolen + credentials. Because the session key is not sent + over the network in cleartext, credentials can't +__________________________ +[24] It is NOT recommended that this time value be used +to adjust the workstation's clock since the workstation +cannot reliably determine that such a KRB_AS_REP actu- +ally came from the proper KDC in a timely manner. + + +Section 5.3.1. - 50 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + be stolen simply by listening to the network; an + attacker has to gain access to the session key + (perhaps through operating system security + breaches or a careless user's unattended session) + to make use of stolen tickets. + + It is important to note that the network address + from which a connection is received cannot be + reliably determined. Even if it could be, an + attacker who has compromised the client's worksta- + tion could use the credentials from there. + Including the network addresses only makes it more + difficult, not impossible, for an attacker to walk + off with stolen credentials and then use them from + a "safe" location. + + +authorization-data + The authorization-data field is used to pass + authorization data from the principal on whose + behalf a ticket was issued to the application ser- + vice. If no authorization data is included, this + field will be left out. Experience has shown that + the name of this field is confusing, and that a + better name for this field would be restrictions. + Unfortunately, it is not possible to change the + name of this field at this time. + + This field contains restrictions on any authority + obtained on the bases of authentication using the + ticket. It is possible for any principal in + posession of credentials to add entries to the + authorization data field since these entries + further restrict what can be done with the ticket. + Such additions can be made by specifying the addi- + tional entries when a new ticket is obtained dur- + ing the TGS exchange, or they may be added during + chained delegation using the authorization data + field of the authenticator. + + Because entries may be added to this field by the + holder of credentials, it is not allowable for the + presence of an entry in the authorization data + field of a ticket to amplify the priveleges one + would obtain from using a ticket. + + The data in this field may be specific to the end + service; the field will contain the names of ser- + vice specific objects, and the rights to those + objects. The format for this field is described + in section 5.2. Although Kerberos is not con- + cerned with the format of the contents of the sub- + fields, it does carry type information (ad-type). + + + +Section 5.3.1. - 51 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + By using the authorization_data field, a principal + is able to issue a proxy that is valid for a + specific purpose. For example, a client wishing + to print a file can obtain a file server proxy to + be passed to the print server. By specifying the + name of the file in the authorization_data field, + the file server knows that the print server can + only use the client's rights when accessing the + particular file to be printed. + + A separate service providing providing authoriza- + tion or certifying group membership may be built + using the authorization-data field. In this case, + the entity granting authorization (not the author- + ized entity), obtains a ticket in its own name + (e.g. the ticket is issued in the name of a + privelege server), and this entity adds restric- + tions on its own authority and delegates the res- + tricted authority through a proxy to the client. + The client would then present this authorization + credential to the application server separately + from the authentication exchange. + + Similarly, if one specifies the authorization-data + field of a proxy and leaves the host addresses + blank, the resulting ticket and session key can be + treated as a capability. See [7] for some sug- + gested uses of this field. + + The authorization-data field is optional and does + not have to be included in a ticket. + + +5.3.2. Authenticators + + An authenticator is a record sent with a ticket to a +server to certify the client's knowledge of the encryption +key in the ticket, to help the server detect replays, and to +help choose a "true session key" to use with the particular +session. The encoding is encrypted in the ticket's session +key shared by the client and the server: + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno[0] INTEGER, + crealm[1] Realm, + cname[2] PrincipalName, + cksum[3] Checksum OPTIONAL, + cusec[4] INTEGER, + ctime[5] KerberosTime, + subkey[6] EncryptionKey OPTIONAL, + seq-number[7] INTEGER OPTIONAL, + authorization-data[8] AuthorizationData OPTIONAL +} + + + +Section 5.3.2. - 52 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +authenticator-vno + This field specifies the version number for the + format of the authenticator. This document speci- + fies version 5. + + +crealm and cname + These fields are the same as those described for + the ticket in section 5.3.1. + + +cksum This field contains a checksum of the the applica- + tion data that accompanies the KRB_AP_REQ. + + +cusec This field contains the microsecond part of the + client's timestamp. Its value (before encryption) + ranges from 0 to 999999. It often appears along + with ctime. The two fields are used together to + specify a reasonably accurate timestamp. + + +ctime This field contains the current time on the + client's host. + + +subkey This field contains the client's choice for an + encryption key which is to be used to protect this + specific application session. Unless an applica- + tion specifies otherwise, if this field is left + out the session key from the ticket will be used. + +seq-numberThis optional field includes the initial sequence + number to be used by the KRB_PRIV or KRB_SAFE mes- + sages when sequence numbers are used to detect + replays (It may also be used by application + specific messages). When included in the authen- + ticator this field specifies the initial sequence + number for messages from the client to the server. + When included in the AP-REP message, the initial + sequence number is that for messages from the + server to the client. When used in KRB_PRIV or + KRB_SAFE messages, it is incremented by one after + each message is sent. + + For sequence numbers to adequately support the + detection of replays they should be non-repeating, + even across connection boundaries. The initial + sequence number should be random and uniformly + distributed across the full space of possible + sequence numbers, so that it cannot be guessed by + an attacker and so that it and the successive + sequence numbers do not repeat other sequences. + + + +Section 5.3.2. - 53 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +authorization-data + This field is the same as described for the ticket + in section 5.3.1. It is optional and will only + appear when additional restrictions are to be + placed on the use of a ticket, beyond those car- + ried in the ticket itself. + +5.4. Specifications for the AS and TGS exchanges + + This section specifies the format of the messages used +in the exchange between the client and the Kerberos server. +The format of possible error messages appears in section +5.9.1. + +5.4.1. KRB_KDC_REQ definition + + The KRB_KDC_REQ message has no type of its own. +Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ +depending on whether the request is for an initial ticket or +an additional ticket. In either case, the message is sent +from the client to the Authentication Server to request +credentials for a service. + + The message fields are: + +AS-REQ ::= [APPLICATION 10] KDC-REQ +TGS-REQ ::= [APPLICATION 12] KDC-REQ + +KDC-REQ ::= SEQUENCE { + pvno[1] INTEGER, + msg-type[2] INTEGER, + padata[3] SEQUENCE OF PA-DATA OPTIONAL, + req-body[4] KDC-REQ-BODY +} + +PA-DATA ::= SEQUENCE { + padata-type[1] INTEGER, + padata-value[2] OCTET STRING, + -- might be encoded AP-REQ +} + +KDC-REQ-BODY ::= SEQUENCE { + kdc-options[0] KDCOptions, + cname[1] PrincipalName OPTIONAL, + -- Used only in AS-REQ + realm[2] Realm, -- Server's realm + -- Also client's in AS-REQ + sname[3] PrincipalName OPTIONAL, + from[4] KerberosTime OPTIONAL, + till[5] KerberosTime OPTIONAL, + rtime[6] KerberosTime OPTIONAL, + nonce[7] INTEGER, + etype[8] SEQUENCE OF INTEGER, + -- EncryptionType, + -- in preference order + + +Section 5.4.1. - 54 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData + -- encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + +The fields in this message are: + + +pvno This field is included in each message, and speci- + fies the protocol version number. This document + specifies protocol version 5. + + +msg-type This field indicates the type of a protocol mes- + sage. It will almost always be the same as the + application identifier associated with a message. + It is included to make the identifier more readily + accessible to the application. For the KDC-REQ + message, this type will be KRB_AS_REQ or + KRB_TGS_REQ. + + +padata The padata (pre-authentication data) field con- + tains a sequence of authentication information + which may be needed before credentials can be + issued or decrypted. In the case of requests for + additional tickets (KRB_TGS_REQ), this field will + include an element with padata-type of PA-TGS-REQ + and data of an authentication header (ticket- + granting ticket and authenticator). The checksum + in the authenticator (which must be collision- + proof) is to be computed over the KDC-REQ-BODY + encoding. In most requests for initial authenti- + cation (KRB_AS_REQ) and most replies (KDC-REP), + the padata field will be left out. + + This field may also contain information needed by + certain extensions to the Kerberos protocol. For + example, it might be used to initially verify the + identity of a client before any response is + returned. This is accomplished with a padata + field with padata-type equal to PA-ENC-TIMESTAMP + and padata-value defined as follows: + +padata-type ::= PA-ENC-TIMESTAMP +padata-value ::= EncryptedData -- PA-ENC-TS-ENC + +PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp[0] KerberosTime, -- client's time + pausec[1] INTEGER OPTIONAL +} + + with patimestamp containing the client's time and + + +Section 5.4.1. - 55 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + pausec containing the microseconds which may be + omitted if a client will not generate more than + one request per second. The ciphertext (padata- + value) consists of the PA-ENC-TS-ENC sequence, + encrypted using the client's secret key. + + The padata field can also contain information + needed to help the KDC or the client select the + key needed for generating or decrypting the + response. This form of the padata is useful for + supporting the use of certain token cards with + Kerberos. The details of such extensions are + specified in separate documents. See [11] for + additional uses of this field. + +padata-type + The padata-type element of the padata field indi- + cates the way that the padata-value element is to + be interpreted. Negative values of padata-type + are reserved for unregistered use; non-negative + values are used for a registered interpretation of + the element type. + + +req-body This field is a placeholder delimiting the extent + of the remaining fields. If a checksum is to be + calculated over the request, it is calculated over + an encoding of the KDC-REQ-BODY sequence which is + enclosed within the req-body field. + + +kdc-options + This field appears in the KRB_AS_REQ and + KRB_TGS_REQ requests to the KDC and indicates the + flags that the client wants set on the tickets as + well as other information that is to modify the + behavior of the KDC. Where appropriate, the name + of an option may be the same as the flag that is + set by that option. Although in most case, the + bit in the options field will be the same as that + in the flags field, this is not guaranteed, so it + is not acceptable to simply copy the options field + to the flags field. There are various checks that + must be made before honoring an option anyway. + + The kdc_options field is a bit-field, where the + selected options are indicated by the bit being + set (1), and the unselected options and reserved + fields being reset (0). The encoding of the bits + is specified in section 5.2. The options are + described in more detail above in section 2. The + meanings of the options are: + + + + +Section 5.4.1. - 56 - Expires 11 January 1998 + + + + + Version 5 - Specification Revision 6 + + + Bit(s) Name Description + 0 RESERVED + Reserved for future expansion of this + field. + + 1 FORWARDABLE + The FORWARDABLE option indicates that + the ticket to be issued is to have its + forwardable flag set. It may only be + set on the initial request, or in a sub- + sequent request if the ticket-granting + ticket on which it is based is also for- + wardable. + + 2 FORWARDED + The FORWARDED option is only specified + in a request to the ticket-granting + server and will only be honored if the + ticket-granting ticket in the request + has its FORWARDABLE bit set. This + option indicates that this is a request + for forwarding. The address(es) of the + host from which the resulting ticket is + to be valid are included in the + addresses field of the request. + + 3 PROXIABLE + The PROXIABLE option indicates that the + ticket to be issued is to have its prox- + iable flag set. It may only be set on + the initial request, or in a subsequent + request if the ticket-granting ticket on + which it is based is also proxiable. + + 4 PROXY + The PROXY option indicates that this is + a request for a proxy. This option will + only be honored if the ticket-granting + ticket in the request has its PROXIABLE + bit set. The address(es) of the host + from which the resulting ticket is to be + valid are included in the addresses + field of the request. + + 5 ALLOW-POSTDATE + The ALLOW-POSTDATE option indicates that + the ticket to be issued is to have its + MAY-POSTDATE flag set. It may only be + set on the initial request, or in a sub- + sequent request if the ticket-granting + ticket on which it is based also has its + MAY-POSTDATE flag set. + + + + + + + +Section 5.4.1. - 57 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + 6 POSTDATED + The POSTDATED option indicates that this + is a request for a postdated ticket. + This option will only be honored if the + ticket-granting ticket on which it is + based has its MAY-POSTDATE flag set. + The resulting ticket will also have its + INVALID flag set, and that flag may be + reset by a subsequent request to the KDC + after the starttime in the ticket has + been reached. + + 7 UNUSED + This option is presently unused. + + 8 RENEWABLE + The RENEWABLE option indicates that the + ticket to be issued is to have its + RENEWABLE flag set. It may only be set + on the initial request, or when the + ticket-granting ticket on which the + request is based is also renewable. If + this option is requested, then the rtime + field in the request contains the + desired absolute expiration time for the + ticket. + + 9-13 UNUSED + These options are presently unused. + + 14 REQUEST-ANONYMOUS + The REQUEST-ANONYMOUS option indicates + that the ticket to be issued is not to + identify the user to which it was + issued. Instead, the principal identif- + ier is to be generic, as specified by + the policy of the realm (e.g. usually + anonymous@realm). The purpose of the + ticket is only to securely distribute a + session key, and not to identify the + user. The ANONYMOUS flag on the ticket + to be returned should be set. If the + local realms policy does not permit + anonymous credentials, the request is to + be rejected. + + 15-25 RESERVED + Reserved for future use. + + 26 DISABLE-TRANSITED-CHECK + By default the KDC will check the + transited field of a ticket-granting- + ticket against the policy of the local + realm before it will issue derivative + tickets based on the ticket granting + ticket. If this flag is set in the + request, checking of the transited field + is disabled. Tickets issued without the + performance of this check will be noted + by the reset (0) value of the + TRANSITED-POLICY-CHECKED flag, + indicating to the application server + that the tranisted field must be checked + locally. KDC's are encouraged but not + required to honor the + DISABLE-TRANSITED-CHECK option. + + + +Section 5.4.1. - 58 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + 27 RENEWABLE-OK + The RENEWABLE-OK option indicates that a + renewable ticket will be acceptable if a + ticket with the requested life cannot + otherwise be provided. If a ticket with + the requested life cannot be provided, + then a renewable ticket may be issued + with a renew-till equal to the the + requested endtime. The value of the + renew-till field may still be limited by + local limits, or limits selected by the + individual principal or server. + + 28 ENC-TKT-IN-SKEY + This option is used only by the ticket- + granting service. The ENC-TKT-IN-SKEY + option indicates that the ticket for the + end server is to be encrypted in the + session key from the additional ticket- + granting ticket provided. + + 29 RESERVED + Reserved for future use. + + 30 RENEW + This option is used only by the ticket- + granting service. The RENEW option + indicates that the present request is + for a renewal. The ticket provided is + encrypted in the secret key for the + server on which it is valid. This + option will only be honored if the + ticket to be renewed has its RENEWABLE + flag set and if the time in its renew- + till field has not passed. The ticket + to be renewed is passed in the padata + field as part of the authentication + header. + + 31 VALIDATE + This option is used only by the ticket- + granting service. The VALIDATE option + indicates that the request is to vali- + date a postdated ticket. It will only + be honored if the ticket presented is + postdated, presently has its INVALID + flag set, and would be otherwise usable + at this time. A ticket cannot be vali- + dated before its starttime. The ticket + presented for validation is encrypted in + the key of the server for which it is + valid and is passed in the padata field + as part of the authentication header. + +cname and sname + These fields are the same as those described for + the ticket in section 5.3.1. sname may only be + + +Section 5.4.1. - 59 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + absent when the ENC-TKT-IN-SKEY option is speci- + fied. If absent, the name of the server is taken + from the name of the client in the ticket passed + as additional-tickets. + + +enc-authorization-data + The enc-authorization-data, if present (and it can + only be present in the TGS_REQ form), is an encod- + ing of the desired authorization-data encrypted + under the sub-session key if present in the + Authenticator, or alternatively from the session + key in the ticket-granting ticket, both from the + padata field in the KRB_AP_REQ. + + +realm This field specifies the realm part of the + server's principal identifier. In the AS + exchange, this is also the realm part of the + client's principal identifier. + + +from This field is included in the KRB_AS_REQ and + KRB_TGS_REQ ticket requests when the requested + ticket is to be postdated. It specifies the + desired start time for the requested ticket. + + + +till This field contains the expiration date requested + by the client in a ticket request. It is option + and if omitted the requested ticket is to have the + maximum endtime permitted according to KDC policy + for the parties to the authentication exchange as + limited by expiration date of the ticket granting + ticket or other preauthentication credentials. + + +rtime This field is the requested renew-till time sent + from a client to the KDC in a ticket request. It + is optional. + + +nonce This field is part of the KDC request and + response. It it intended to hold a random number + generated by the client. If the same number is + included in the encrypted response from the KDC, + it provides evidence that the response is fresh + and has not been replayed by an attacker. Nonces + must never be re-used. Ideally, it should be gen- + erated randomly, but if the correct time is known, + it may suffice[25]. +__________________________ +[25] Note, however, that if the time is used as the + +Section 5.4.1. - 60 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +etype This field specifies the desired encryption algo- + rithm to be used in the response. + + +addresses This field is included in the initial request for + tickets, and optionally included in requests for + additional tickets from the ticket-granting + server. It specifies the addresses from which the + requested ticket is to be valid. Normally it + includes the addresses for the client's host. If + a proxy is requested, this field will contain + other addresses. The contents of this field are + usually copied by the KDC into the caddr field of + the resulting ticket. + + +additional-tickets + Additional tickets may be optionally included in a + request to the ticket-granting server. If the + ENC-TKT-IN-SKEY option has been specified, then + the session key from the additional ticket will be + used in place of the server's key to encrypt the + new ticket. If more than one option which + requires additional tickets has been specified, + then the additional tickets are used in the order + specified by the ordering of the options bits (see + kdc-options, above). + + + The application code will be either ten (10) or twelve +(12) depending on whether the request is for an initial +ticket (AS-REQ) or for an additional ticket (TGS-REQ). + + The optional fields (addresses, authorization-data and +additional-tickets) are only included if necessary to per- +form the operation specified in the kdc-options field. + + It should be noted that in KRB_TGS_REQ, the protocol +version number appears twice and two different message types +appear: the KRB_TGS_REQ message contains these fields as +does the authentication header (KRB_AP_REQ) that is passed +in the padata field. + +5.4.2. KRB_KDC_REP definition + + The KRB_KDC_REP message format is used for the reply +from the KDC for either an initial (AS) request or a subse- +quent (TGS) request. There is no message type for +__________________________ +nonce, one must make sure that the workstation time is +monotonically increasing. If the time is ever reset +backwards, there is a small, but finite, probability +that a nonce will be reused. + + + +Section 5.4.2. - 61 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or +KRB_TGS_REP. The key used to encrypt the ciphertext part of +the reply depends on the message type. For KRB_AS_REP, the +ciphertext is encrypted in the client's secret key, and the +client's key version number is included in the key version +number for the encrypted data. For KRB_TGS_REP, the cipher- +text is encrypted in the sub-session key from the Authenti- +cator, or if absent, the session key from the ticket- +granting ticket used in the request. In that case, no ver- +sion number will be present in the EncryptedData sequence. + + The KRB_KDC_REP message contains the following fields: + +AS-REP ::= [APPLICATION 11] KDC-REP +TGS-REP ::= [APPLICATION 13] KDC-REP + +KDC-REP ::= SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + padata[2] SEQUENCE OF PA-DATA OPTIONAL, + crealm[3] Realm, + cname[4] PrincipalName, + ticket[5] Ticket, + enc-part[6] EncryptedData +} + + +EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart +EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + + + +EncKDCRepPart ::= SEQUENCE { + key[0] EncryptionKey, + last-req[1] LastReq, + nonce[2] INTEGER, + key-expiration[3] KerberosTime OPTIONAL, + flags[4] TicketFlags, + authtime[5] KerberosTime, + starttime[6] KerberosTime OPTIONAL, + endtime[7] KerberosTime, + renew-till[8] KerberosTime OPTIONAL, + srealm[9] Realm, + sname[10] PrincipalName, + caddr[11] HostAddresses OPTIONAL +} + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is either KRB_AS_REP or KRB_TGS_REP. +__________________________ +[27] An application code in the encrypted part of a +message provides an additional check that the message +was decrypted properly. + + +Section 5.4.2. - 62 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +padata This field is described in detail in section + 5.4.1. One possible use for this field is to + encode an alternate "mix-in" string to be used + with a string-to-key algorithm (such as is + described in section 6.3.2). This ability is use- + ful to ease transitions if a realm name needs to + change (e.g. when a company is acquired); in such + a case all existing password-derived entries in + the KDC database would be flagged as needing a + special mix-in string until the next password + change. + + +crealm, cname, srealm and sname + These fields are the same as those described for + the ticket in section 5.3.1. + + +ticket The newly-issued ticket, from section 5.3.1. + + +enc-part This field is a place holder for the ciphertext + and related information that forms the encrypted + part of a message. The description of the + encrypted part of the message follows each appear- + ance of this field. The encrypted part is encoded + as described in section 6.1. + + +key This field is the same as described for the ticket + in section 5.3.1. + + +last-req This field is returned by the KDC and specifies + the time(s) of the last request by a principal. + Depending on what information is available, this + might be the last time that a request for a + ticket-granting ticket was made, or the last time + that a request based on a ticket-granting ticket + was successful. It also might cover all servers + for a realm, or just the particular server. Some + implementations may display this information to + the user to aid in discovering unauthorized use of + one's identity. It is similar in spirit to the + last login time displayed when logging into + timesharing systems. + + +nonce This field is described above in section 5.4.1. + + +key-expiration + The key-expiration field is part of the response + from the KDC and specifies the time that the + + +Section 5.4.2. - 63 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + client's secret key is due to expire. The expira- + tion might be the result of password aging or an + account expiration. This field will usually be + left out of the TGS reply since the response to + the TGS request is encrypted in a session key and + no client information need be retrieved from the + KDC database. It is up to the application client + (usually the login program) to take appropriate + action (such as notifying the user) if the expira- + tion time is imminent. + + +flags, authtime, starttime, endtime, renew-till and caddr + These fields are duplicates of those found in the + encrypted portion of the attached ticket (see sec- + tion 5.3.1), provided so the client may verify + they match the intended request and to assist in + proper ticket caching. If the message is of type + KRB_TGS_REP, the caddr field will only be filled + in if the request was for a proxy or forwarded + ticket, or if the user is substituting a subset of + the addresses from the ticket granting ticket. If + the client-requested addresses are not present or + not used, then the addresses contained in the + ticket will be the same as those included in the + ticket-granting ticket. + + +5.5. Client/Server (CS) message specifications + + This section specifies the format of the messages used +for the authentication of the client to the application +server. + +5.5.1. KRB_AP_REQ definition + + The KRB_AP_REQ message contains the Kerberos protocol +version number, the message type KRB_AP_REQ, an options +field to indicate any options in use, and the ticket and +authenticator themselves. The KRB_AP_REQ message is often +referred to as the "authentication header". + +AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ap-options[2] APOptions, + ticket[3] Ticket, + authenticator[4] EncryptedData +} + +APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) + + +Section 5.5.1. - 64 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +} + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is KRB_AP_REQ. + + +ap-optionsThis field appears in the application request + (KRB_AP_REQ) and affects the way the request is + processed. It is a bit-field, where the selected + options are indicated by the bit being set (1), + and the unselected options and reserved fields + being reset (0). The encoding of the bits is + specified in section 5.2. The meanings of the + options are: + + Bit(s) Name Description + + 0 RESERVED + Reserved for future expansion of this + field. + + 1 USE-SESSION-KEY + The USE-SESSION-KEY option indicates + that the ticket the client is presenting + to a server is encrypted in the session + key from the server's ticket-granting + ticket. When this option is not speci- + fied, the ticket is encrypted in the + server's secret key. + + 2 MUTUAL-REQUIRED + The MUTUAL-REQUIRED option tells the + server that the client requires mutual + authentication, and that it must respond + with a KRB_AP_REP message. + + 3-31 RESERVED + Reserved for future use. + + + +ticket This field is a ticket authenticating the client + to the server. + + +authenticator + This contains the authenticator, which includes + the client's choice of a subkey. Its encoding is + described in section 5.3.2. + +5.5.2. KRB_AP_REP definition + + The KRB_AP_REP message contains the Kerberos protocol +version number, the message type, and an encrypted time- +stamp. The message is sent in in response to an application +request (KRB_AP_REQ) where the mutual authentication option + + +Section 5.5.2. - 65 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +has been selected in the ap-options field. + +AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[2] EncryptedData +} + +EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { + ctime[0] KerberosTime, + cusec[1] INTEGER, + subkey[2] EncryptionKey OPTIONAL, + seq-number[3] INTEGER OPTIONAL +} + +The encoded EncAPRepPart is encrypted in the shared session +key of the ticket. The optional subkey field can be used in +an application-arranged negotiation to choose a per associa- +tion session key. + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is KRB_AP_REP. + + +enc-part This field is described above in section 5.4.2. + + +ctime This field contains the current time on the + client's host. + + +cusec This field contains the microsecond part of the + client's timestamp. + + +subkey This field contains an encryption key which is to + be used to protect this specific application ses- + sion. See section 3.2.6 for specifics on how this + field is used to negotiate a key. Unless an + application specifies otherwise, if this field is + left out, the sub-session key from the authentica- + tor, or if also left out, the session key from the + ticket will be used. + + + +__________________________ +[29] An application code in the encrypted part of a +message provides an additional check that the message +was decrypted properly. + + + +Section 5.5.2. - 66 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +5.5.3. Error message reply + + If an error occurs while processing the application +request, the KRB_ERROR message will be sent in response. +See section 5.9.1 for the format of the error message. The +cname and crealm fields may be left out if the server cannot +determine their appropriate values from the corresponding +KRB_AP_REQ message. If the authenticator was decipherable, +the ctime and cusec fields will contain the values from it. + +5.6. KRB_SAFE message specification + + This section specifies the format of a message that can +be used by either side (client or server) of an application +to send a tamper-proof message to its peer. It presumes +that a session key has previously been exchanged (for exam- +ple, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.6.1. KRB_SAFE definition + + The KRB_SAFE message contains user data along with a +collision-proof checksum keyed with the last encryption key +negotiated via subkeys, or the session key if no negotiation +has occured. The message fields are: + +KRB-SAFE ::= [APPLICATION 20] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + safe-body[2] KRB-SAFE-BODY, + cksum[3] Checksum +} + +KRB-SAFE-BODY ::= SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + + + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is KRB_SAFE. + + +safe-body This field is a placeholder for the body of the + KRB-SAFE message. It is to be encoded separately + and then have the checksum computed over it, for + use in the cksum field. + + + +Section 5.6.1. - 67 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +cksum This field contains the checksum of the applica- + tion data. Checksum details are described in sec- + tion 6.4. The checksum is computed over the + encoding of the KRB-SAFE-BODY sequence. + + +user-data This field is part of the KRB_SAFE and KRB_PRIV + messages and contain the application specific data + that is being passed from the sender to the reci- + pient. + + +timestamp This field is part of the KRB_SAFE and KRB_PRIV + messages. Its contents are the current time as + known by the sender of the message. By checking + the timestamp, the recipient of the message is + able to make sure that it was recently generated, + and is not a replay. + + +usec This field is part of the KRB_SAFE and KRB_PRIV + headers. It contains the microsecond part of the + timestamp. + + +seq-number + This field is described above in section 5.3.2. + + +s-address This field specifies the address in use by the + sender of the message. + + +r-address This field specifies the address in use by the + recipient of the message. It may be omitted for + some uses (such as broadcast protocols), but the + recipient may arbitrarily reject such messages. + This field along with s-address can be used to + help detect messages which have been incorrectly + or maliciously delivered to the wrong recipient. + +5.7. KRB_PRIV message specification + + This section specifies the format of a message that can +be used by either side (client or server) of an application +to securely and privately send a message to its peer. It +presumes that a session key has previously been exchanged +(for example, by using the KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + + The KRB_PRIV message contains user data encrypted in +the Session Key. The message fields are: + +__________________________ +[31] An application code in the encrypted part of a + + + + + + + Version 5 - Specification Revision 6 + + + +KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[3] EncryptedData +} + +EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, -- sender's addr + r-address[5] HostAddress OPTIONAL -- recip's addr +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is KRB_PRIV. + + +enc-part This field holds an encoding of the EncKrbPrivPart + sequence encrypted under the session key[32]. + This encrypted encoding is used for the enc-part + field of the KRB-PRIV message. See section 6 for + the format of the ciphertext. + + +user-data, timestamp, usec, s-address and r-address + These fields are described above in section 5.6.1. + + +seq-number + This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + + This section specifies the format of a message that can +be used to send Kerberos credentials from one principal to +__________________________ +message provides an additional check that the message +was decrypted properly. +[32] If supported by the encryption method in use, an +initialization vector may be passed to the encryption +procedure, in order to achieve proper cipher chaining. +The initialization vector might come from the last +block of the ciphertext from the previous KRB_PRIV mes- +sage, but it is the application's choice whether or not +to use such an initialization vector. If left out, the +default initialization vector for the encryption algo- +rithm will be used. + + +Section 5.8. - 69 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +another. It is presented here to encourage a common mechan- +ism to be used by applications when forwarding tickets or +providing proxies to subordinate servers. It presumes that +a session key has already been exchanged perhaps by using +the KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + + The KRB_CRED message contains a sequence of tickets to +be sent and information needed to use the tickets, including +the session key from each. The information needed to use +the tickets is encrypted under an encryption key previously +exchanged or transferred alongside the KRB_CRED message. +The message fields are: + +KRB-CRED ::= [APPLICATION 22] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, -- KRB_CRED + tickets[2] SEQUENCE OF Ticket, + enc-part[3] EncryptedData +} + +EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info[0] SEQUENCE OF KrbCredInfo, + nonce[1] INTEGER OPTIONAL, + timestamp[2] KerberosTime OPTIONAL, + usec[3] INTEGER OPTIONAL, + s-address[4] HostAddress OPTIONAL, + r-address[5] HostAddress OPTIONAL +} + +KrbCredInfo ::= SEQUENCE { + key[0] EncryptionKey, + prealm[1] Realm OPTIONAL, + pname[2] PrincipalName OPTIONAL, + flags[3] TicketFlags OPTIONAL, + authtime[4] KerberosTime OPTIONAL, + starttime[5] KerberosTime OPTIONAL, + endtime[6] KerberosTime OPTIONAL + renew-till[7] KerberosTime OPTIONAL, + srealm[8] Realm OPTIONAL, + sname[9] PrincipalName OPTIONAL, + caddr[10] HostAddresses OPTIONAL +} + + + + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is KRB_CRED. + + + + +Section 5.8.1. - 70 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +tickets + These are the tickets obtained from the KDC + specifically for use by the intended recipient. + Successive tickets are paired with the correspond- + ing KrbCredInfo sequence from the enc-part of the + KRB-CRED message. + + +enc-part This field holds an encoding of the EncKrbCredPart + sequence encrypted under the session key shared + between the sender and the intended recipient. + This encrypted encoding is used for the enc-part + field of the KRB-CRED message. See section 6 for + the format of the ciphertext. + + +nonce If practical, an application may require the + inclusion of a nonce generated by the recipient of + the message. If the same value is included as the + nonce in the message, it provides evidence that + the message is fresh and has not been replayed by + an attacker. A nonce must never be re-used; it + should be generated randomly by the recipient of + the message and provided to the sender of the mes- + sage in an application specific manner. + + +timestamp and usec + + These fields specify the time that the KRB-CRED + message was generated. The time is used to pro- + vide assurance that the message is fresh. + + +s-address and r-address + These fields are described above in section 5.6.1. + They are used optionally to provide additional + assurance of the integrity of the KRB-CRED mes- + sage. + + +key This field exists in the corresponding ticket + passed by the KRB-CRED message and is used to pass + the session key from the sender to the intended + recipient. The field's encoding is described in + section 6.2. + + The following fields are optional. If present, they +can be associated with the credentials in the remote ticket +file. If left out, then it is assumed that the recipient of +the credentials already knows their value. + + +prealm and pname + + +Section 5.8.1. - 71 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + The name and realm of the delegated principal + identity. + + +flags, authtime, starttime, endtime, renew-till, srealm, + sname, and caddr + These fields contain the values of the correspond- + ing fields from the ticket found in the ticket + field. Descriptions of the fields are identical + to the descriptions in the KDC-REP message. + +5.9. Error message specification + + This section specifies the format for the KRB_ERROR +message. The fields included in the message are intended to +return as much information as possible about an error. It +is not expected that all the information required by the +fields will be available for all types of errors. If the +appropriate information is not available when the message is +composed, the corresponding field will be left out of the +message. + + Note that since the KRB_ERROR message is not protected +by any encryption, it is quite possible for an intruder to +synthesize or modify such a message. In particular, this +means that the client should not use any fields in this mes- +sage for security-critical purposes, such as setting a sys- +tem clock or generating a fresh authenticator. The message +can be useful, however, for advising a user on the reason +for some failure. + +5.9.1. KRB_ERROR definition + + The KRB_ERROR message consists of the following fields: + +KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ctime[2] KerberosTime OPTIONAL, + cusec[3] INTEGER OPTIONAL, + stime[4] KerberosTime, + susec[5] INTEGER, + error-code[6] INTEGER, + crealm[7] Realm OPTIONAL, + cname[8] PrincipalName OPTIONAL, + realm[9] Realm, -- Correct realm + sname[10] PrincipalName, -- Correct name + e-text[11] GeneralString OPTIONAL, + e-data[12] OCTET STRING OPTIONAL, + e-cksum[13] Checksum OPTIONAL +} + + + + + +Section 5.9.1. - 72 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +pvno and msg-type + These fields are described above in section 5.4.1. + msg-type is KRB_ERROR. + + +ctime This field is described above in section 5.4.1. + + + +cusec This field is described above in section 5.5.2. + + +stime This field contains the current time on the + server. It is of type KerberosTime. + + +susec This field contains the microsecond part of the + server's timestamp. Its value ranges from 0 to + 999999. It appears along with stime. The two + fields are used in conjunction to specify a rea- + sonably accurate timestamp. + + +error-codeThis field contains the error code returned by + Kerberos or the server when a request fails. To + interpret the value of this field see the list of + error codes in section 8. Implementations are + encouraged to provide for national language sup- + port in the display of error messages. + + +crealm, cname, srealm and sname + These fields are described above in section 5.3.1. + + +e-text This field contains additional text to help + explain the error code associated with the failed + request (for example, it might include a principal + name which was unknown). + + +e-data This field contains additional data about the + error for use by the application to help it + recover from or handle the error. If the error- + code is KDC_ERR_PREAUTH_REQUIRED, then the e-data + field will contain an encoding of a sequence of + padata fields, each corresponding to an acceptable + pre-authentication method and optionally contain- + ing data for the method: + + +e-cksum This field contains an optional checksum for the + KRB-ERROR message. The checksum is calculated + over the Kerberos ASN.1 encoding of the KRB-ERROR + + +Section 5.9.1. - 73 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + message with the checksum absent. The checksum is + then added to the KRB-ERROR structure and the mes- + sage is re-encoded. The Checksum should be calcu- + lated using the session key from the ticket grant- + ing ticket or service ticket, where available. If + the error is in response to a TGS or AP request, + the checksum should be calculated uing the the + session key from the client's ticket. If the + error is in response to an AS request, then the + checksum should be calulated using the client's + secret key ONLY if there has been suitable preau- + thentication to prove knowledge of the secret key + by the client[33]. If a checksum can not be com- + puted because the key to be used is not available, + no checksum will be included. + + METHOD-DATA ::= SEQUENCE of PA-DATA + + + If the error-code is KRB_AP_ERR_METHOD, then the + e-data field will contain an encoding of the fol- + lowing sequence: + + METHOD-DATA ::= SEQUENCE { + method-type[0] INTEGER, + method-data[1] OCTET STRING OPTIONAL + } + + method-type will indicate the required alternate + method; method-data will contain any required + additional information. + + + +6. Encryption and Checksum Specifications + +The Kerberos protocols described in this document are +designed to use stream encryption ciphers, which can be +simulated using commonly available block encryption ciphers, +such as the Data Encryption Standard, [12] in conjunction +with block chaining and checksum methods [13]. Encryption +is used to prove the identities of the network entities par- +ticipating in message exchanges. The Key Distribution +Center for each realm is trusted by all principals +registered in that realm to store a secret key in confi- +dence. Proof of knowledge of this secret key is used to +verify the authenticity of a principal. + + The KDC uses the principal's secret key (in the AS +__________________________ +[33] This prevents an attacker who generates an in- +correct AS request from obtaining verifiable plaintext +for use in an off-line password guessing attack. + + +Section 6. - 74 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +exchange) or a shared session key (in the TGS exchange) to +encrypt responses to ticket requests; the ability to obtain +the secret key or session key implies the knowledge of the +appropriate keys and the identity of the KDC. The ability +of a principal to decrypt the KDC response and present a +Ticket and a properly formed Authenticator (generated with +the session key from the KDC response) to a service verifies +the identity of the principal; likewise the ability of the +service to extract the session key from the Ticket and prove +its knowledge thereof in a response verifies the identity of +the service. + + The Kerberos protocols generally assume that the +encryption used is secure from cryptanalysis; however, in +some cases, the order of fields in the encrypted portions of +messages are arranged to minimize the effects of poorly +chosen keys. It is still important to choose good keys. If +keys are derived from user-typed passwords, those passwords +need to be well chosen to make brute force attacks more dif- +ficult. Poorly chosen keys still make easy targets for +intruders. + + The following sections specify the encryption and +checksum mechanisms currently defined for Kerberos. The +encodings, chaining, and padding requirements for each are +described. For encryption methods, it is often desirable to +place random information (often referred to as a confounder) +at the start of the message. The requirements for a con- +founder are specified with each encryption mechanism. + + Some encryption systems use a block-chaining method to +improve the the security characteristics of the ciphertext. +However, these chaining methods often don't provide an +integrity check upon decryption. Such systems (such as DES +in CBC mode) must be augmented with a checksum of the plain- +text which can be verified at decryption and used to detect +any tampering or damage. Such checksums should be good at +detecting burst errors in the input. If any damage is +detected, the decryption routine is expected to return an +error indicating the failure of an integrity check. Each +encryption type is expected to provide and verify an +appropriate checksum. The specification of each encryption +method sets out its checksum requirements. + + Finally, where a key is to be derived from a user's +password, an algorithm for converting the password to a key +of the appropriate type is included. It is desirable for +the string to key function to be one-way, and for the map- +ping to be different in different realms. This is important +because users who are registered in more than one realm will +often use the same password in each, and it is desirable +that an attacker compromising the Kerberos server in one +realm not obtain or derive the user's key in another. + + + +Section 6. - 75 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + For an discussion of the integrity characteristics of +the candidate encryption and checksum methods considered for +Kerberos, the the reader is referred to [14]. + +6.1. Encryption Specifications + + The following ASN.1 definition describes all encrypted +messages. The enc-part field which appears in the unen- +crypted part of messages in section 5 is a sequence consist- +ing of an encryption type, an optional key version number, +and the ciphertext. + + +EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext +} + + +etype This field identifies which encryption algorithm + was used to encipher the cipher. Detailed specif- + ications for selected encryption types appear + later in this section. + + +kvno This field contains the version number of the key + under which data is encrypted. It is only present + in messages encrypted under long lasting keys, + such as principals' secret keys. + + +cipher This field contains the enciphered text, encoded + as an OCTET STRING. + + + The cipher field is generated by applying the specified +encryption algorithm to data composed of the message and +algorithm-specific inputs. Encryption mechanisms defined +for use with Kerberos must take sufficient measures to +guarantee the integrity of the plaintext, and we recommend +they also take measures to protect against precomputed dic- +tionary attacks. If the encryption algorithm is not itself +capable of doing so, the protections can often be enhanced +by adding a checksum and a confounder. + + The suggested format for the data to be encrypted +includes a confounder, a checksum, the encoded plaintext, +and any necessary padding. The msg-seq field contains the +part of the protocol message described in section 5 which is +to be encrypted. The confounder, checksum, and padding are +all untagged and untyped, and their length is exactly suffi- +cient to hold the appropriate item. The type and length is +implicit and specified by the particular encryption type + + +Section 6.1. - 76 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +being used (etype). The format for the data to be encrypted +is described in the following diagram: + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + +The format cannot be described in ASN.1, but for those who +prefer an ASN.1-like notation: + +CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL +} + + + One generates a random confounder of the appropriate +length, placing it in confounder; zeroes out check; calcu- +lates the appropriate checksum over confounder, check, and +msg-seq, placing the result in check; adds the necessary +padding; then encrypts using the specified encryption type +and the appropriate key. + + Unless otherwise specified, a definition of an encryp- +tion algorithm that specifies a checksum, a length for the +confounder field, or an octet boundary for padding uses this +ciphertext format[36]. Those fields which are not specified +will be omitted. + + In the interest of allowing all implementations using a +__________________________ +[35] In the above specification, UNTAGGED OCTET +STRING(length) is the notation for an octet string with +its tag and length removed. It is not a valid ASN.1 +type. The tag bits and length must be removed from the +confounder since the purpose of the confounder is so +that the message starts with random data, but the tag +and its length are fixed. For other fields, the length +and tag would be redundant if they were included be- +cause they are specified by the encryption type. +[36] The ordering of the fields in the CipherText is +important. Additionally, messages encoded in this for- +mat must include a length as part of the msg-seq field. +This allows the recipient to verify that the message +has not been truncated. Without a length, an attacker +could use a chosen plaintext attack to generate a mes- +sage which could be truncated, while leaving the check- +sum intact. Note that if the msg-seq is an encoding of +an ASN.1 SEQUENCE or OCTET STRING, then the length is +part of that encoding. + + + +Section 6.1. - 77 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +particular encryption type to communicate with all others +using that type, the specification of an encryption type +defines any checksum that is needed as part of the encryp- +tion process. If an alternative checksum is to be used, a +new encryption type must be defined. + + Some cryptosystems require additional information +beyond the key and the data to be encrypted. For example, +DES, when used in cipher-block-chaining mode, requires an +initialization vector. If required, the description for +each encryption type must specify the source of such addi- +tional information. + +6.2. Encryption Keys + + The sequence below shows the encoding of an encryption +key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + +keytype This field specifies the type of encryption key + that follows in the keyvalue field. It will + almost always correspond to the encryption algo- + rithm used to generate the EncryptedData, though + more than one algorithm may use the same type of + key (the mapping is many to one). This might hap- + pen, for example, if the encryption algorithm uses + an alternate checksum algorithm for an integrity + check, or a different chaining mechanism. + + +keyvalue This field contains the key itself, encoded as an + octet string. + + All negative values for the encryption key type are +reserved for local use. All non-negative values are +reserved for officially assigned type fields and interpreta- +tions. + +6.3. Encryption Systems + +6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is +said to be the NULL encryption system. In the NULL encryp- +tion system there is no checksum, confounder or padding. +The ciphertext is simply the plaintext. The NULL Key is +used by the null encryption system and is zero octets in +length, with keytype zero (0). + + + +Section 6.3.1. - 78 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information +under the Data Encryption Standard [12] using the cipher +block chaining mode [13]. A CRC-32 checksum (described in +ISO 3309 [15]) is applied to the confounder and message +sequence (msg-seq) and placed in the cksum field. DES +blocks are 8 bytes. As a result, the data to be encrypted +(the concatenation of confounder, checksum, and message) +must be padded to an 8 byte boundary before encryption. The +details of the encryption of this data are identical to +those for the des-cbc-md5 encryption mode. + + Note that, since the CRC-32 checksum is not collision- +proof, an attacker could use a probabilistic chosen- +plaintext attack to generate a valid message even if a con- +founder is used [14]. The use of collision-proof checksums +is recommended for environments where such attacks represent +a significant threat. The use of the CRC-32 as the checksum +for ticket or authenticator is no longer mandated as an +interoperability requirement for Kerberos Version 5 Specifi- +cation 1 (See section 9.1 for specific details). + + +6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + The des-cbc-md4 encryption mode encrypts information +under the Data Encryption Standard [12] using the cipher +block chaining mode [13]. An MD4 checksum (described in +[16]) is applied to the confounder and message sequence +(msg-seq) and placed in the cksum field. DES blocks are 8 +bytes. As a result, the data to be encrypted (the concate- +nation of confounder, checksum, and message) must be padded +to an 8 byte boundary before encryption. The details of the +encryption of this data are identical to those for the des- +cbc-md5 encryption mode. + + +6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) + + The des-cbc-md5 encryption mode encrypts information +under the Data Encryption Standard [12] using the cipher +block chaining mode [13]. An MD5 checksum (described in +[17].) is applied to the confounder and message sequence +(msg-seq) and placed in the cksum field. DES blocks are 8 +bytes. As a result, the data to be encrypted (the concate- +nation of confounder, checksum, and message) must be padded +to an 8 byte boundary before encryption. + + Plaintext and DES ciphtertext are encoded as 8-octet +blocks which are concatenated to make the 64-bit inputs for +the DES algorithms. The first octet supplies the 8 most +significant bits (with the octet's MSbit used as the DES +input block's MSbit, etc.), the second octet the next 8 + + +Section 6.3.4. - 79 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +bits, ..., and the eighth octet supplies the 8 least signi- +ficant bits. + + Encryption under DES using cipher block chaining +requires an additional input in the form of an initializa- +tion vector. Unless otherwise specified, zero should be +used as the initialization vector. Kerberos' use of DES +requires an 8-octet confounder. + + The DES specifications identify some "weak" and "semi- +weak" keys; those keys shall not be used for encrypting mes- +sages for use in Kerberos. Additionally, because of the way +that keys are derived for the encryption of checksums, keys +shall not be used that yield "weak" or "semi-weak" keys when +eXclusive-ORed with the constant F0F0F0F0F0F0F0F0. + + A DES key is 8 octets of data, with keytype one (1). +This consists of 56 bits of key, and 8 parity bits (one per +octet). The key is encoded as a series of 8 octets written +in MSB-first order. The bits within the key are also +encoded in MSB order. For example, if the encryption key is +(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) +where B1,B2,...,B56 are the key bits in MSB order, and +P1,P2,...,P8 are the parity bits, the first octet of the key +would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the +FIPS 81 introduction for reference.] + + To generate a DES key from a text string (password), +the text string normally must have the realm and each com- +ponent of the principal's name appended[37], then padded +with ASCII nulls to an 8 byte boundary. This string is then +fan-folded and eXclusive-ORed with itself to form an 8 byte +DES key. The parity is corrected on the key, and it is used +to generate a DES CBC checksum on the initial string (with +the realm and name appended). Next, parity is corrected on +the CBC checksum. If the result matches a "weak" or "semi- +weak" key as described in the DES specification, it is +eXclusive-ORed with the constant 00000000000000F0. Finally, +the result is returned as the key. Pseudocode follows: + + string_to_key(string,realm,name) { + odd = 1; + s = string + realm; + for(each component in name) { + s = s + component; + } + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { +__________________________ +[37] In some cases, it may be necessary to use a dif- +ferent "mix-in" string for compatibility reasons; see +the discussion of padata in section 5.4.2. + + +Section 6.3.4. - 80 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + tempkey = tempkey XOR 8byteblock; + } + fixparity(tempkey); + key = DES-CBC-check(s,tempkey); + fixparity(key); + if(is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + +6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check- +sum (des3-cbc-sha1) + + The des3-cbc-sha1 encryption encodes information using +three Data Encryption Standard transformations with three +DES keys. The first key is used to perform a DES ECB +encryption on an eight-octet data block using the first DES +key, followed by a DES ECB decryption of the result using +the second DES key, and a DES ECB encryption of the result +using the third DES key. Because DES blocks are 8 bytes, +the data to be encrypted (the concatenation of confounder, +checksum, and message) must first be padded to an 8 byte +boundary before encryption. To support the outer CBC mode, +the input is padded an eight-octet boundary. The first 8 +octets of the data to be encrypted (the confounder) is +exclusive-ored with an initialization vector of zero and +then ECB encrypted using triple DES as described above. +Subsequent blocks of 8 octets are exclusive-ored with the +ciphertext produced by the encryption on the previous block +before ECB encryption. + + An HMAC-SHA1 checksum (described in [18].) is applied +to the confounder and message sequence (msg-seq) and placed +in the cksum field. + + Plaintext are encoded as 8-octet blocks which are con- +catenated to make the 64-bit inputs for the DES algorithms. +The first octet supplies the 8 most significant bits (with +the octet's MSbit used as the DES input block's MSbit, +etc.), the second octet the next 8 bits, ..., and the eighth +octet supplies the 8 least significant bits. + + Encryption under Triple DES using cipher block chaining +requires an additional input in the form of an initializa- +tion vector. Unless otherwise specified, zero should be +used as the initialization vector. Kerberos' use of DES +requires an 8-octet confounder. + + The DES specifications identify some "weak" and "semi- + + +Section 6.3.5. - 81 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +weak" keys; those keys shall not be used for encrypting mes- +sages for use in Kerberos. Additionally, because of the way +that keys are derived for the encryption of checksums, keys +shall not be used that yield "weak" or "semi-weak" keys when +eXclusive-ORed with the constant F0F0F0F0F0F0F0F0. + + A Triple DES key is 24 octets of data, with keytype +seven (7). This consists of 168 bits of key, and 24 parity +bits (one per octet). The key is encoded as a series of 24 +octets written in MSB-first order, with the first 8 octets +treated as the first DES key, the second 8 octets as the +second key, and the third 8 octets the third DES key. The +bits within each key are also encoded in MSB order. For +example, if the encryption key is +(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) +where B1,B2,...,B56 are the key bits in MSB order, and +P1,P2,...,P8 are the parity bits, the first octet of the key +would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the +FIPS 81 introduction for reference.] + + To generate a DES key from a text string (password), +the text string normally must have the realm and each com- +ponent of the principal's name appended[38], + + The input string (with any salt data appended to it) is +n-folded into a 24 octet (192 bit) string. To n-fold a +number X, replicate the input value to a length that is the +least common multiple of n and the length of X. Before each +repetition, the input X is rotated to the right by 13 bit +positions. The successive n-bit chunks are added together +using 1's-complement addition (addition with end-around +carry) to yield a n-bit result. (This transformation was +proposed by Richard Basch) + + Each successive set of 8 octets is taken as a DES key, +and its parity is adjusted in the same manner as previously +described. If any of the three sets of 8 octets match a +"weak" or "semi-weak" key as described in the DES specifica- +tion, that chunk is eXclusive-ORed with the constant +00000000000000F0. The resulting DES keys are then used in +sequence to perform a Triple-DES CBC encryption of the n- +folded input string (appended with any salt data), using a +zero initial vector. Parity, weak, and semi-weak keys are +once again corrected and the result is returned as the 24 +octet key. + + Pseudocode follows: + + string_to_key(string,realm,name) { +__________________________ +[38] In some cases, it may be necessary to use a dif- +ferent "mix-in" string for compatibility reasons; see +the discussion of padata in section 5.4.2. + + +Section 6.3.5. - 82 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + s = string + realm; + for(each component in name) { + s = s + component; + } + tkey[24] = fold(s); + fixparity(tkey); + if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0; + if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0; + if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0; + key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0); + fixparity(key); + if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0; + if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0; + if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0; + return(key); + } + +6.4. Checksums + + The following is the ASN.1 definition used for a check- +sum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + + +cksumtype This field indicates the algorithm used to gen- + erate the accompanying checksum. + +checksum This field contains the checksum itself, encoded + as an octet string. + + Detailed specification of selected checksum types +appear later in this section. Negative values for the +checksum type are reserved for local use. All non-negative +values are reserved for officially assigned type fields and +interpretations. + + Checksums used by Kerberos can be classified by two +properties: whether they are collision-proof, and whether +they are keyed. It is infeasible to find two plaintexts +which generate the same checksum value for a collision-proof +checksum. A key is required to perturb or initialize the +algorithm in a keyed checksum. To prevent message-stream +modification by an active attacker, unkeyed checksums should +only be used when the checksum and message will be subse- +quently encrypted (e.g. the checksums defined as part of the +encryption algorithms covered earlier in this section). + + Collision-proof checksums can be made tamper-proof if +the checksum value is encrypted before inclusion in a mes- +sage. In such cases, the composition of the checksum and + + +Section 6.4. - 83 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +the encryption algorithm must be considered a separate +checksum algorithm (e.g. RSA-MD5 encrypted using DES is a +new checksum algorithm of type RSA-MD5-DES). For most keyed +checksums, as well as for the encrypted forms of unkeyed +collision-proof checksums, Kerberos prepends a confounder +before the checksum is calculated. + +6.4.1. The CRC-32 Checksum (crc32) + + The CRC-32 checksum calculates a checksum based on a +cyclic redundancy check as described in ISO 3309 [15]. The +resulting checksum is four (4) octets in length. The CRC-32 +is neither keyed nor collision-proof. The use of this +checksum is not recommended. An attacker using a proba- +bilistic chosen-plaintext attack as described in [14] might +be able to generate an alternative message that satisfies +the checksum. The use of collision-proof checksums is +recommended for environments where such attacks represent a +significant threat. + +6.4.2. The RSA MD4 Checksum (rsa-md4) + + The RSA-MD4 checksum calculates a checksum using the +RSA MD4 algorithm [16]. The algorithm takes as input an +input message of arbitrary length and produces as output a +128-bit (16 octet) checksum. RSA-MD4 is believed to be +collision-proof. + +6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4- +des) + + The RSA-MD4-DES checksum calculates a keyed collision- +proof checksum by prepending an 8 octet confounder before +the text, applying the RSA MD4 checksum algorithm, and +encrypting the confounder and the checksum using DES in +cipher-block-chaining (CBC) mode using a variant of the key, +where the variant is computed by eXclusive-ORing the key +with the constant F0F0F0F0F0F0F0F0[39]. The initialization +vector should be zero. The resulting checksum is 24 octets +long (8 octets of which are redundant). This checksum is +tamper-proof and believed to be collision-proof. + + The DES specifications identify some "weak keys" and +__________________________ +[39] A variant of the key is used to limit the use of a +key to a particular function, separating the functions +of generating a checksum from other encryption per- +formed using the session key. The constant +F0F0F0F0F0F0F0F0 was chosen because it maintains key +parity. The properties of DES precluded the use of the +complement. The same constant is used for similar pur- +pose in the Message Integrity Check in the Privacy +Enhanced Mail standard. + + +Section 6.4.3. - 84 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +"semi-weak keys"; those keys shall not be used for generat- +ing RSA-MD4 checksums for use in Kerberos. + + The format for the checksum is described in the follow- +ing diagram: + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +The format cannot be described in ASN.1, but for those who +prefer an ASN.1-like notation: + +rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) +} + + + +6.4.4. The RSA MD5 Checksum (rsa-md5) + + The RSA-MD5 checksum calculates a checksum using the +RSA MD5 algorithm. [17]. The algorithm takes as input an +input message of arbitrary length and produces as output a +128-bit (16 octet) checksum. RSA-MD5 is believed to be +collision-proof. + +6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5- +des) + + The RSA-MD5-DES checksum calculates a keyed collision- +proof checksum by prepending an 8 octet confounder before +the text, applying the RSA MD5 checksum algorithm, and +encrypting the confounder and the checksum using DES in +cipher-block-chaining (CBC) mode using a variant of the key, +where the variant is computed by eXclusive-ORing the key +with the constant F0F0F0F0F0F0F0F0. The initialization vec- +tor should be zero. The resulting checksum is 24 octets +long (8 octets of which are redundant). This checksum is +tamper-proof and believed to be collision-proof. + + The DES specifications identify some "weak keys" and +"semi-weak keys"; those keys shall not be used for encrypt- +ing RSA-MD5 checksums for use in Kerberos. + + The format for the checksum is described in the follow- +ing diagram: + ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + +The format cannot be described in ASN.1, but for those who + + +Section 6.4.5. - 85 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +prefer an ASN.1-like notation: + +rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) +} + + +6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 +octet confounder to the plaintext, performing a DES CBC-mode +encryption on the result using the key and an initialization +vector of zero, taking the last block of the ciphertext, +prepending the same confounder and encrypting the pair using +DES in cipher-block-chaining (CBC) mode using a a variant of +the key, where the variant is computed by eXclusive-ORing +the key with the constant F0F0F0F0F0F0F0F0. The initializa- +tion vector should be zero. The resulting checksum is 128 +bits (16 octets) long, 64 bits of which are redundant. This +checksum is tamper-proof and collision-proof. + + The format for the checksum is described in the follow- +ing diagram: + ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ +| des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + +The format cannot be described in ASN.1, but for those who +prefer an ASN.1-like notation: + +des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) +} + + + The DES specifications identify some "weak" and "semi- +weak" keys; those keys shall not be used for generating +DES-MAC checksums for use in Kerberos, nor shall a key be +used whose variant is "weak" or "semi-weak". + +6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative +(rsa-md4-des-k) + + The RSA-MD4-DES-K checksum calculates a keyed +collision-proof checksum by applying the RSA MD4 checksum +algorithm and encrypting the results using DES in cipher- +block-chaining (CBC) mode using a DES key as both key and +initialization vector. The resulting checksum is 16 octets +long. This checksum is tamper-proof and believed to be +collision-proof. Note that this checksum type is the old +method for encoding the RSA-MD4-DES checksum and it is no + + +Section 6.4.7. - 86 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +longer recommended. + +6.4.8. DES cipher-block chained checksum alternative (des- +mac-k) + + The DES-MAC-K checksum is computed by performing a DES +CBC-mode encryption of the plaintext, and using the last +block of the ciphertext as the checksum value. It is keyed +with an encryption key and an initialization vector; any +uses which do not specify an additional initialization vec- +tor will use the key as both key and initialization vector. +The resulting checksum is 64 bits (8 octets) long. This +checksum is tamper-proof and collision-proof. Note that +this checksum type is the old method for encoding the DES- +MAC checksum and it is no longer recommended. + + The DES specifications identify some "weak keys" and +"semi-weak keys"; those keys shall not be used for generat- +ing DES-MAC checksums for use in Kerberos. + +7. Naming Constraints + + +7.1. Realm Names + + Although realm names are encoded as GeneralStrings and +although a realm can technically select any name it chooses, +interoperability across realm boundaries requires agreement +on how realm names are to be assigned, and what information +they imply. + + To enforce these conventions, each realm must conform +to the conventions itself, and it must require that any +realms with which inter-realm keys are shared also conform +to the conventions and require the same from its neighbors. + + Kerberos realm names are case sensitive. Realm names +that differ only in the case of the characters are not +equivalent. There are presently four styles of realm names: +domain, X500, other, and reserved. Examples of each style +follow: + + domain: ATHENA.MIT.EDU (example) + X500: C=US/O=OSF (example) + other: NAMETYPE:rest/of.name=without-restrictions (example) + reserved: reserved, but will not conflict with above + + +Domain names must look like domain names: they consist of +components separated by periods (.) and they contain neither +colons (:) nor slashes (/). Domain names must be converted +to upper case when used as realm names. + + X.500 names contain an equal (=) and cannot contain a + + +Section 7.1. - 87 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +colon (:) before the equal. The realm names for X.500 names +will be string representations of the names with components +separated by slashes. Leading and trailing slashes will not +be included. + + Names that fall into the other category must begin with +a prefix that contains no equal (=) or period (.) and the +prefix must be followed by a colon (:) and the rest of the +name. All prefixes must be assigned before they may be +used. Presently none are assigned. + + The reserved category includes strings which do not +fall into the first three categories. All names in this +category are reserved. It is unlikely that names will be +assigned to this category unless there is a very strong +argument for not using the "other" category. + + These rules guarantee that there will be no conflicts +between the various name styles. The following additional +constraints apply to the assignment of realm names in the +domain and X.500 categories: the name of a realm for the +domain or X.500 formats must either be used by the organiza- +tion owning (to whom it was assigned) an Internet domain +name or X.500 name, or in the case that no such names are +registered, authority to use a realm name may be derived +from the authority of the parent realm. For example, if +there is no domain name for E40.MIT.EDU, then the adminis- +trator of the MIT.EDU realm can authorize the creation of a +realm with that name. + + This is acceptable because the organization to which +the parent is assigned is presumably the organization +authorized to assign names to its children in the X.500 and +domain name systems as well. If the parent assigns a realm +name without also registering it in the domain name or X.500 +hierarchy, it is the parent's responsibility to make sure +that there will not in the future exists a name identical to +the realm name of the child unless it is assigned to the +same entity as the realm name. + + +7.2. Principal Names + + As was the case for realm names, conventions are needed +to ensure that all agree on what information is implied by a +principal name. The name-type field that is part of the +principal name indicates the kind of information implied by +the name. The name-type should be treated as a hint. +Ignoring the name type, no two names can be the same (i.e. +at least one of the components, or the realm, must be dif- +ferent). This constraint may be eliminated in the future. +The following name types are defined: + + name-type value meaning + + +Section 7.2. - 88 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) + NT-SRV-INST 2 Service and other unique instance (krbtgt) + NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) + NT-SRV-XHST 4 Service with slash-separated host name components + NT-UID 5 Unique ID + + +When a name implies no information other than its uniqueness +at a particular time the name type PRINCIPAL should be used. +The principal name type should be used for users, and it +might also be used for a unique server. If the name is a +unique machine generated ID that is guaranteed never to be +reassigned then the name type of UID should be used (note +that it is generally a bad idea to reassign names of any +type since stale entries might remain in access control +lists). + + If the first component of a name identifies a service +and the remaining components identify an instance of the +service in a server specified manner, then the name type of +SRV-INST should be used. An example of this name type is +the Kerberos ticket-granting service whose name has a first +component of krbtgt and a second component identifying the +realm for which the ticket is valid. + + If instance is a single component following the service +name and the instance identifies the host on which the +server is running, then the name type SRV-HST should be +used. This type is typically used for Internet services +such as telnet and the Berkeley R commands. If the separate +components of the host name appear as successive components +following the name of the service, then the name type SRV- +XHST should be used. This type might be used to identify +servers on hosts with X.500 names where the slash (/) might +otherwise be ambiguous. + + A name type of UNKNOWN should be used when the form of +the name is not known. When comparing names, a name of type +UNKNOWN will match principals authenticated with names of +any type. A principal authenticated with a name of type +UNKNOWN, however, will only match other names of type UNK- +NOWN. + + Names of any type with an initial component of "krbtgt" +are reserved for the Kerberos ticket granting service. See +section 8.2.3 for the form of such names. + +7.2.1. Name of server principals + + The principal identifier for a server on a host will +generally be composed of two parts: (1) the realm of the KDC +with which the server is registered, and (2) a two-component + + +Section 7.2.1. - 89 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +name of type NT-SRV-HST if the host name is an Internet +domain name or a multi-component name of type NT-SRV-XHST if +the name of the host is of a form such as X.500 that allows +slash (/) separators. The first component of the two- or +multi-component name will identify the service and the +latter components will identify the host. Where the name of +the host is not case sensitive (for example, with Internet +domain names) the name of the host must be lower case. If +specified by the application protocol for services such as +telnet and the Berkeley R commands which run with system +privileges, the first component may be the string "host" +instead of a service specific identifier. When a host has +an official name and one or more aliases, the official name +of the host must be used when constructing the name of the +server principal. + +8. Constants and other defined values + + +8.1. Host address types + + All negative values for the host address type are +reserved for local use. All non-negative values are +reserved for officially assigned type fields and interpreta- +tions. + + The values of the types for the following addresses are +chosen to match the defined address family constants in the +Berkeley Standard Distributions of Unix. They can be found +in <sys/socket.h> with symbolic names AF_xxx (where xxx is +an abbreviation of the address family name). + + +Internet addresses + + Internet addresses are 32-bit (4-octet) quantities, +encoded in MSB order. The type of internet addresses is two +(2). + +CHAOSnet addresses + + CHAOSnet addresses are 16-bit (2-octet) quantities, +encoded in MSB order. The type of CHAOSnet addresses is +five (5). + +ISO addresses + + ISO addresses are variable-length. The type of ISO +addresses is seven (7). + +Xerox Network Services (XNS) addresses + + XNS addresses are 48-bit (6-octet) quantities, encoded +in MSB order. The type of XNS addresses is six (6). + + +Section 8.1. - 90 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number +and a 16-bit network number. The first octet of the address +is the node number; the remaining two octets encode the net- +work number in MSB order. The type of AppleTalk DDP +addresses is sixteen (16). + +DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded +in LSB order. The type of DECnet Phase IV addresses is +twelve (12). + +8.2. KDC messages + +8.2.1. IP transport + + When contacting a Kerberos server (KDC) for a +KRB_KDC_REQ request using UDP IP transport, the client shall +send a UDP datagram containing only an encoding of the +request to port 88 (decimal) at the KDC's IP address; the +KDC will respond with a reply datagram containing only an +encoding of the reply message (either a KRB_ERROR or a +KRB_KDC_REP) to the sending port at the sender's IP address. + + Kerberos servers supporting IP transport must accept +UDP requests on port 88 (decimal). Servers may also accept +TCP requests on port 88 (decimal). When the KRB_KDC_REQ +message is sent to the KDC by TCP, a new connection will be +established for each authentication exchange and the +KRB_KDC_REP or KRB_ERROR message will be returned to the +client on the TCP stream that was established for the +request. The connection will be broken after the reply has +been received (or upon time-out). Care must be taken in +managing TCP/IP connections with the KDC to prevent denial +of service attacks based on the number of TCP/IP connections +with the KDC that remain open. + +8.2.2. OSI transport + + During authentication of an OSI client to an OSI +server, the mutual authentication of an OSI server to an OSI +client, the transfer of credentials from an OSI client to an +OSI server, or during exchange of private or integrity +checked messages, Kerberos protocol messages may be treated +as opaque objects and the type of the authentication mechan- +ism will be: + +OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5), + kerberosv5(2)} + +Depending on the situation, the opaque object will be an +authentication header (KRB_AP_REQ), an authentication reply +(KRB_AP_REP), a safe message (KRB_SAFE), a private message + + +Section 8.2.2. - 91 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +(KRB_PRIV), or a credentials message (KRB_CRED). The opaque +data contains an application code as specified in the ASN.1 +description for each message. The application code may be +used by Kerberos to determine the message type. + +8.2.3. Name of the TGS + + The principal identifier of the ticket-granting service +shall be composed of three parts: (1) the realm of the KDC +issuing the TGS ticket (2) a two-part name of type NT-SRV- +INST, with the first part "krbtgt" and the second part the +name of the realm which will accept the ticket-granting +ticket. For example, a ticket-granting ticket issued by the +ATHENA.MIT.EDU realm to be used to get tickets from the +ATHENA.MIT.EDU KDC has a principal identifier of +"ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") +(name). A ticket-granting ticket issued by the +ATHENA.MIT.EDU realm to be used to get tickets from the +MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" +(realm), ("krbtgt", "MIT.EDU") (name). + + +8.3. Protocol constants and associated values + +The following tables list constants used in the protocol and defines their +meanings. + +Encryption type etype value block size minimum pad size confounder size +NULL 0 1 0 0 +des-cbc-crc 1 8 4 8 +des-cbc-md4 2 8 0 8 +des-cbc-md5 3 8 0 8 +<reserved> 4 +des3-cbc-md5 5 8 0 8 +<reserved> 6 +des3-cbc-sha1 7 8 0 8 +sign-dsa-generate 8 (pkinit) +encrypt-rsa-priv 9 (pkinit) +encrypt-rsa-pub 10 (pkinit) +ENCTYPE_PK_CROSS 48 (reserved for pkcross) +<reserved> 0x8003 + +Checksum type sumtype value checksum size +CRC32 1 4 +rsa-md4 2 16 +rsa-md4-des 3 24 +des-mac 4 16 +des-mac-k 5 8 +rsa-md4-des-k 6 16 +rsa-md5 7 16 +rsa-md5-des 8 24 +rsa-md5-des3 9 24 +hmac-sha1-des3 10 20 (I had this as 10, is it 12) + + +Section 8.3. - 92 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +padata type padata-type value + +PA-TGS-REQ 1 +PA-ENC-TIMESTAMP 2 +PA-PW-SALT 3 +<reserved> 4 +PA-ENC-UNIX-TIME 5 +PA-SANDIA-SECUREID 6 +PA-SESAME 7 +PA-OSF-DCE 8 +PA-CYBERSAFE-SECUREID 9 +PA-AFS3-SALT 10 +PA-ETYPE-INFO 11 +SAM-CHALLENGE 12 (sam/otp) +SAM-RESPONSE 13 (sam/otp) +PA-PK-AS-REQ 14 (pkinit) +PA-PK-AS-REP 15 (pkinit) +PA-PK-AS-SIGN 16 (pkinit) +PA-PK-KEY-REQ 17 (pkinit) +PA-PK-KEY-REP 18 (pkinit) + +authorization data type ad-type value +reserved values 0-63 +OSF-DCE 64 +SESAME 65 + +alternate authentication type method-type value +reserved values 0-63 +ATT-CHALLENGE-RESPONSE 64 + +transited encoding type tr-type value +DOMAIN-X500-COMPRESS 1 +reserved values all others + + + +Label Value Meaning or MIT code + +pvno 5 current Kerberos protocol version number + +message types + +KRB_AS_REQ 10 Request for initial authentication +KRB_AS_REP 11 Response to KRB_AS_REQ request +KRB_TGS_REQ 12 Request for authentication based on TGT +KRB_TGS_REP 13 Response to KRB_TGS_REQ request +KRB_AP_REQ 14 application request to server +KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL +KRB_SAFE 20 Safe (checksummed) application message +KRB_PRIV 21 Private (encrypted) application message +KRB_CRED 22 Private (encrypted) message to forward credentials +KRB_ERROR 30 Error response + + +Section 8.3. - 93 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +name types + +KRB_NT_UNKNOWN 0 Name type not known +KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users +KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) +KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) +KRB_NT_SRV_XHST 4 Service with host as remaining components +KRB_NT_UID 5 Unique ID + +error codes + +KDC_ERR_NONE 0 No error +KDC_ERR_NAME_EXP 1 Client's entry in database has expired +KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired +KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported +KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key +KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key +KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database +KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database +KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database +KDC_ERR_NULL_KEY 9 The client or server has a null key +KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating +KDC_ERR_NEVER_VALID 11 Requested start time is later than end time +KDC_ERR_POLICY 12 KDC policy rejects request +KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option +KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type +KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type +KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type +KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type +KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked +KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked +KDC_ERR_TGT_REVOKED 20 TGT has been revoked +KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later +KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later +KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset +KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid +KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired- +KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match +KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only +KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path +KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed +KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired +KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid +KRB_AP_ERR_REPEAT 34 Request is a replay +KRB_AP_ERR_NOT_US 35 The ticket isn't for us +KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match +KRB_AP_ERR_SKEW 37 Clock skew too great +KRB_AP_ERR_BADADDR 38 Incorrect net address +KRB_AP_ERR_BADVERSION 39 Protocol version mismatch +KRB_AP_ERR_MSG_TYPE 40 Invalid msg type +KRB_AP_ERR_MODIFIED 41 Message stream modified +KRB_AP_ERR_BADORDER 42 Message out of order +KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available +KRB_AP_ERR_NOKEY 45 Service key not available +KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed +KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction +KRB_AP_ERR_METHOD 48 Alternative authentication method required +KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message + + + +Section 8.3. - 94 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message +KRB_ERR_GENERIC 60 Generic error (description in e-text) +KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation +KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) +KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) +KDC_ERROR_INVALID_SIG 64 (pkinit) +KDC_ERR_KEY_TOO_WEAK 65 (pkinit) + + +9. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of +options. Among these are multiple encryption and checksum +types, alternative encoding schemes for the transited field, +optional mechanisms for pre-authentication, the handling of +tickets with no addresses, options for mutual authentica- +tion, user to user authentication, support for proxies, for- +warding, postdating, and renewing tickets, the format of +realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it +is necessary to define a minimal configuration which must be +supported by all implementations. This minimal configura- +tion is subject to change as technology does. For example, +if at some later date it is discovered that one of the +required encryption or checksum algorithms is not secure, it +will be replaced. + +9.1. Specification 1 + + This section defines the first specification of these +options. Implementations which are configured in this way +can be said to support Kerberos Version 5 Specification 1 +(5.1). + +Encryption and checksum methods + +The following encryption and checksum mechanisms must be +supported. Implementations may support other mechanisms as +well, but the additional mechanisms may only be used when +communicating with principals known to also support them: +This list is to be determined. +Encryption: DES-CBC-MD5 +Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 + + +__________________________ +- This error carries additional information in the e- +data field. The contents of the e-data field for this +message is described in section 5.9.1. + + + +Section 9.1. - 95 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +Realm Names + +All implementations must understand hierarchical realms in +both the Internet Domain and the X.500 style. When a ticket +granting ticket for an unknown realm is requested, the KDC +must be able to determine the names of the intermediate +realms between the KDCs realm and the requested realm. + +Transited field encoding + +DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be +supported. Alternative encodings may be supported, but they +may be used only when that encoding is supported by ALL +intermediate realms. + +Pre-authentication methods + +The TGS-REQ method must be supported. The TGS-REQ method is +not used on the initial request. The PA-ENC-TIMESTAMP +method must be supported by clients but whether it is +enabled by default may be determined on a realm by realm +basis. If not used in the initial request and the error +KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC- +TIMESTAMP as an acceptable method, the client should retry +the initial request using the PA-ENC-TIMESTAMP pre- +authentication method. Servers need not support the PA- +ENC-TIMESTAMP method, but if not supported the server should +ignore the presence of PA-ENC-TIMESTAMP pre-authentication +in a request. + +Mutual authentication + +Mutual authentication (via the KRB_AP_REP message) must be +supported. + + +Ticket addresses and flags + +All KDC's must pass on tickets that carry no addresses (i.e. +if a TGT contains no addresses, the KDC will return deriva- +tive tickets), but each realm may set its own policy for +issuing such tickets, and each application server will set +its own policy with respect to accepting them. + + Proxies and forwarded tickets must be supported. Indi- +vidual realms and application servers can set their own pol- +icy on when such tickets will be accepted. + + All implementations must recognize renewable and post- +dated tickets, but need not actually implement them. If +these options are not supported, the starttime and endtime +in the ticket shall specify a ticket's entire useful life. +When a postdated ticket is decoded by a server, all imple- +mentations shall make the presence of the postdated flag + + +Section 9.1. - 96 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +visible to the calling server. + +User-to-user authentication + +Support for user to user authentication (via the ENC-TKT- +IN-SKEY KDC option) must be provided by implementations, but +individual realms may decide as a matter of policy to reject +such requests on a per-principal or realm-wide basis. + +Authorization data + +Implementations must pass all authorization data subfields +from ticket-granting tickets to any derivative tickets +unless directed to suppress a subfield as part of the defin- +ition of that registered subfield type (it is never +incorrect to pass on a subfield, and no registered subfield +types presently specify suppression at the KDC). + + Implementations must make the contents of any authori- +zation data subfields available to the server when a ticket +is used. Implementations are not required to allow clients +to specify the contents of the authorization data fields. + +9.2. Recommended KDC values + +Following is a list of recommended values for a KDC imple- +mentation, based on the list of suggested configuration con- +stants (see section 4.4). + +minimum lifetime 5 minutes + +maximum renewable lifetime1 week + +maximum ticket lifetime1 day + +empty addresses only when suitable restrictions appear + in authorization data + +proxiable, etc. Allowed. + + + + + + + + + + + + + + + + + +Section 9.2. - 97 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +10. REFERENCES + + + +1. B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- + cation Service for Computer Networks," IEEE Communica- + tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). + +2. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. + Saltzer, Section E.2.1: Kerberos Authentication and + Authorization System, M.I.T. Project Athena, Cambridge, + Massachusetts (December 21, 1987). + +3. J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- + beros: An Authentication Service for Open Network Sys- + tems," pp. 191-202 in Usenix Conference Proceedings, + Dallas, Texas (February, 1988). + +4. Roger M. Needham and Michael D. Schroeder, "Using + Encryption for Authentication in Large Networks of Com- + puters," Communications of the ACM, Vol. 21(12), + pp. 993-999 (December, 1978). + +5. Dorothy E. Denning and Giovanni Maria Sacco, "Time- + stamps in Key Distribution Protocols," Communications + of the ACM, Vol. 24(8), pp. 533-536 (August 1981). + +6. John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + +7. B. Clifford Neuman, "Proxy-Based Authorization and + Accounting for Distributed Systems," in Proceedings of + the 13th International Conference on Distributed Com- + puting Systems, Pittsburgh, PA (May, 1993). + +8. Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + +9. P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- + merfeld, and K. Raeburn, Section E.1: Service Manage- + ment System, M.I.T. Project Athena, Cambridge, Mas- + sachusetts (1987). + +10. CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + +11. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + + + +Section 10. - 98 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +12. National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + +13. National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + +14. Stuart G. Stubblebine and Virgil D. Gligor, "On Message + Integrity in Cryptographic Protocols," in Proceedings + of the IEEE Symposium on Research in Security and + Privacy, Oakland, California (May 1992). + +15. International Organization for Standardization, "ISO + Information Processing Systems - Data Communication - + High-Level Data Link Control Procedure - Frame Struc- + ture," IS 3309 (October 1984). 3rd Edition. + +16. R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + +17. R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + +18. H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + + + + + + + + + + + + + + + + + + + + + + + + + +Section 10. - 99 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +A. Pseudo-code for protocol processing + + This appendix provides pseudo-code describing how the +messages are to be constructed and interpreted by clients +and servers. + +A.1. KRB_AS_REQ generation + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_AS_REQ */ + + if(pa_enc_timestamp_required) then + request.padata.padata-type = PA-ENC-TIMESTAMP; + get system_time; + padata-body.patimestamp,pausec = system_time; + encrypt padata-body into request.padata.padata-value + using client.key; /* derived from password */ + endif + + body.kdc-options := users's preferences; + body.cname := user's name; + body.realm := user's realm; + body.sname := service's name; /* usually "krbtgt", "localrealm" */ + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + endif + omit body.enc-authorization-data; + request.req-body := body; + + kerberos := lookup(name of local kerberos server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + +A.2. KRB_AS_REQ verification and KRB_AS_REP generation + decode message into req; + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + + +Section A.2. - 100 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable skew) then + error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + if (req.kdc-options.FORWARDABLE is set) then + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.PROXIABLE is set) then + set new_tkt.flags.PROXIABLE; + endif + + +Section A.2. - 101 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + if (req.kdc-options.ALLOW-POSTDATE is set) then + set new_tkt.flags.MAY-POSTDATE; + endif + if ((req.kdc-options.RENEW is set) or + (req.kdc-options.VALIDATE is set) or + (req.kdc-options.PROXY is set) or + (req.kdc-options.FORWARDED is set) or + (req.kdc-options.ENC-TKT-IN-SKEY is set)) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.session := random_session_key(); + new_tkt.cname := req.cname; + new_tkt.crealm := req.crealm; + new_tkt.transited := empty_transited_field(); + + new_tkt.authtime := kdc_time; + + if (req.kdc-options.POSTDATED is set) then + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + new_tkt.starttime := req.from; + else + omit new_tkt.starttime; /* treated as authtime when omitted */ + endif + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till)) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := req.till; + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if (req.kdc-options.RENEWABLE is set) then + set new_tkt.flags.RENEWABLE; + + +Section A.2. - 102 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm); + else + omit new_tkt.renew-till; /* only present if RENEWABLE */ + endif + + if (req.addresses) then + new_tkt.caddr := req.addresses; + else + omit new_tkt.caddr; + endif + + new_tkt.authorization_data := empty_authorization_data(); + + encode to-be-encrypted part of ticket into OCTET STRING; + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, server.p_kvno; + + + /* Start processing the response */ + + resp.pvno := 5; + resp.msg-type := KRB_AS_REP; + resp.cname := req.cname; + resp.crealm := req.realm; + resp.ticket := new_tkt; + + resp.key := new_tkt.session; + resp.last-req := fetch_last_request_info(client); + resp.nonce := req.nonce; + resp.key-expiration := client.expiration; + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + resp.realm := new_tkt.realm; + resp.sname := new_tkt.sname; + + resp.caddr := new_tkt.caddr; + + encode body of reply into OCTET STRING; + + resp.enc-part := encrypt OCTET STRING + using use_etype, client.key, client.p_kvno; + send(resp); + + + +Section A.2. - 103 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +A.3. KRB_AS_REP verification + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then + set pa_enc_timestamp_required; + goto KRB_AS_REQ; + endif + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key */ + /* from the response immediately */ + + key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, + resp.padata); + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and key; + zero(key); + + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + if near(resp.princ_exp) then + print(warning message); + endif + save_for_later(ticket,session,client,server,times,flags); + +A.4. KRB_AS_REP and KRB_TGS_REP common checks + if (decryption_error() or + (req.cname != resp.cname) or + (req.realm != resp.crealm) or + (req.sname != resp.sname) or + (req.realm != resp.realm) or + (req.nonce != resp.nonce) or + (req.addresses != resp.caddr)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + /* make sure no flags are set that shouldn't be, and that all that */ + /* should be are set */ + if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.from = 0) and + (resp.starttime is not within allowable skew)) then + destroy resp.key; + return KRB_AP_ERR_SKEW; + + +Section A.4. - 104 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + endif + if ((req.from != 0) and (req.from != resp.starttime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.till != 0) and (resp.endtime > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (req.rtime != 0) and (resp.renew-till > req.rtime)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + if ((req.kdc-options.RENEWABLE-OK is set) and + (resp.flags.RENEWABLE) and + (req.till != 0) and + (resp.renew-till > req.till)) then + destroy resp.key; + return KRB_AP_ERR_MODIFIED; + endif + +A.5. KRB_TGS_REQ generation + /* Note that make_application_request might have to recursivly */ + /* call this routine to get the appropriate ticket-granting ticket */ + + request.pvno := protocol version; /* pvno = 5 */ + request.msg-type := message type; /* type = KRB_TGS_REQ */ + + body.kdc-options := users's preferences; + /* If the TGT is not for the realm of the end-server */ + /* then the sname will be for a TGT for the end-realm */ + /* and the realm of the requested ticket (body.realm) */ + /* will be that of the TGS to which the TGT we are */ + /* sending applies */ + body.sname := service's name; + body.realm := service's realm; + + if (body.kdc-options.POSTDATED is set) then + body.from := requested starting time; + else + omit body.from; + endif + body.till := requested end time; + if (body.kdc-options.RENEWABLE is set) then + body.rtime := requested final renewal time; + endif + body.nonce := random_nonce(); + body.etype := requested etypes; + if (user supplied addresses) then + body.addresses := user's addresses; + else + omit body.addresses; + + +Section A.5. - 105 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + endif + + body.enc-authorization-data := user-supplied data; + if (body.kdc-options.ENC-TKT-IN-SKEY) then + body.additional-tickets_ticket := second TGT; + endif + + request.req-body := body; + check := generate_checksum (req.body,checksumtype); + + request.padata[0].padata-type := PA-TGS-REQ; + request.padata[0].padata-value := create a KRB_AP_REQ using + the TGT and checksum + + /* add in any other padata as required/supplied */ + + kerberos := lookup(name of local kerberose server (or servers)); + send(packet,kerberos); + + wait(for response); + if (timed_out) then + retry or use alternate server; + endif + +A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation + /* note that reading the application request requires first + determining the server for which a ticket was issued, and choosing the + correct key for decryption. The name of the server appears in the + plaintext part of the ticket. */ + + if (no KRB_AP_REQ in req.padata) then + error_out(KDC_ERR_PADATA_TYPE_NOSUPP); + endif + verify KRB_AP_REQ in req.padata; + + /* Note that the realm in which the Kerberos server is operating is + determined by the instance from the ticket-granting ticket. The realm + in the ticket-granting ticket is the realm under which the ticket + granting ticket was issued. It is possible for a single Kerberos + server to support more than one realm. */ + + auth_hdr := KRB_AP_REQ; + tgt := auth_hdr.ticket; + + if (tgt.sname is not a TGT for local realm and is not req.sname) then + error_out(KRB_AP_ERR_NOT_US); + + realm := realm_tgt_is_for(tgt); + + decode remainder of request; + + if (auth_hdr.authenticator.cksum is missing) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + +Section A.6. - 106 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + if (auth_hdr.authenticator.cksum type is not supported) then + error_out(KDC_ERR_SUMTYPE_NOSUPP); + endif + if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + + set computed_checksum := checksum(req); + if (computed_checksum != auth_hdr.authenticatory.cksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + server := lookup(req.sname,realm); + + if (!server) then + if (is_foreign_tgt_name(server)) then + server := best_intermediate_tgs(server); + else + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + endif + + session := generate_random_session_key(); + + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := realm; + reset all flags in new_tkt.flags; + + /* It should be noted that local policy may affect the */ + /* processing of any of these flags. For example, some */ + /* realms may refuse to issue renewable tickets */ + + new_tkt.caddr := tgt.caddr; + resp.caddr := NULL; /* We only include this if they change */ + if (req.kdc-options.FORWARDABLE is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDABLE; + endif + if (req.kdc-options.FORWARDED is set) then + if (tgt.flags.FORWARDABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.FORWARDED; + + +Section A.6. - 107 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + if (tgt.flags.FORWARDED is set) then + set new_tkt.flags.FORWARDED; + endif + + if (req.kdc-options.PROXIABLE is set) then + if (tgt.flags.PROXIABLE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXIABLE; + endif + if (req.kdc-options.PROXY is set) then + if (tgt.flags.PROXIABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.PROXY; + new_tkt.caddr := req.addresses; + resp.caddr := req.addresses; + endif + + if (req.kdc-options.ALLOW-POSTDATE is set) then + if (tgt.flags.MAY-POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.MAY-POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.MAY-POSTDATE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATED; + set new_tkt.flags.INVALID; + if (against_postdate_policy(req.from)) then + error_out(KDC_ERR_POLICY); + endif + new_tkt.starttime := req.from; + endif + + + if (req.kdc-options.VALIDATE is set) then + if (tgt.flags.INVALID is reset) then + error_out(KDC_ERR_POLICY); + endif + if (tgt.starttime > kdc_time) then + error_out(KRB_AP_ERR_NYV); + endif + if (check_hot_list(tgt)) then + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + +Section A.6. - 108 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket would */ + /* have been rejected in the initial authentication stage, so */ + /* there is no need to check again here */ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till >= kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm, + tgt.endtime); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + + +Section A.6. - 109 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; /* leave the renew-till field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data into decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited := compress_transited(tgt.transited + tgt.realm) + endif + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + + + +Section A.6. - 110 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + req.padata.authenticator.subkey; + else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; + + send(resp); + +A.7. KRB_TGS_REP verification + decode response into resp; + + if (resp.msg-type = KRB_ERROR) then + process_error(resp); + return; + endif + + /* On error, discard the response, and zero the session key from + the response immediately */ + + if (req.padata.authenticator.subkey) + unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and subkey; + else unencrypted part of resp := decode of decrypt of resp.enc-part + using resp.enc-part.etype and tgt's session key; + if (common_as_rep_tgs_rep_checks fail) then + destroy resp.key; + return error; + endif + + check authorization_data as necessary; + save_for_later(ticket,session,client,server,times,flags); + + + +Section A.7. - 111 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +A.8. Authenticator generation + body.authenticator-vno := authenticator vno; /* = 5 */ + body.cname, body.crealm := client name; + if (supplying checksum) then + body.cksum := checksum; + endif + get system_time; + body.ctime, body.cusec := system_time; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + +A.9. KRB_AP_REQ generation + obtain ticket and session_key from cache; + + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REQ */ + + if (desired(MUTUAL_AUTHENTICATION)) then + set packet.ap-options.MUTUAL-REQUIRED; + else + reset packet.ap-options.MUTUAL-REQUIRED; + endif + if (using session key for ticket) then + set packet.ap-options.USE-SESSION-KEY; + else + reset packet.ap-options.USE-SESSION-KEY; + endif + packet.ticket := ticket; /* ticket */ + generate authenticator; + encode authenticator into OCTET STRING; + encrypt OCTET STRING into packet.authenticator using session_key; + +A.10. KRB_AP_REQ verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REQ) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.ticket.tkt_vno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.ap_options.USE-SESSION-KEY is set) then + retrieve session key from ticket-granting ticket for + packet.ticket.{sname,srealm,enc-part.etype}; + + +Section A.10. - 112 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + else + retrieve service key for + packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; + endif + if (no_key_available) then + if (cannot_find_specified_skvno) then + error_out(KRB_AP_ERR_BADKEYVER); + else + error_out(KRB_AP_ERR_NOKEY); + endif + endif + decrypt packet.ticket.enc-part into decr_ticket using retrieved key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + decrypt packet.authenticator into decr_authenticator + using decr_ticket.key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (decr_authenticator.{cname,crealm} != + decr_ticket.{cname,crealm}) then + error_out(KRB_AP_ERR_BADMATCH); + endif + if (decr_ticket.caddr is present) then + if (sender_address(packet) is not in decr_ticket.caddr) then + error_out(KRB_AP_ERR_BADADDR); + endif + elseif (application requires addresses) then + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(decr_authenticator.ctime, + decr_authenticator.cusec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then + error_out(KRB_AP_ERR_REPEAT); + endif + save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); + get system_time; + if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or + (decr_ticket.flags.INVALID is set)) then + /* it hasn't yet become valid */ + error_out(KRB_AP_ERR_TKT_NYV); + endif + if (system_time-decr_ticket.endtime > CLOCK_SKEW) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + /* caller must check decr_ticket.flags for any pertinent details */ + return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); + +A.11. KRB_AP_REP generation + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_AP_REP */ + + +Section A.11. - 113 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + body.ctime := packet.ctime; + body.cusec := packet.cusec; + if (selecting sub-session key) then + select sub-session key; + body.subkey := sub-session key; + endif + if (using sequence numbers) then + select initial sequence number; + body.seq-number := initial sequence; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part; + +A.12. KRB_AP_REP verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_AP_REP) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + cleartext := decrypt(packet.enc-part) using ticket's session key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if (cleartext.ctime != authenticator.ctime) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.cusec != authenticator.cusec) then + error_out(KRB_AP_ERR_MUT_FAIL); + endif + if (cleartext.subkey is present) then + save cleartext.subkey for future use; + endif + if (cleartext.seq-number is present) then + save cleartext.seq-number for future verifications; + endif + return(AUTHENTICATION_SUCCEEDED); + +A.13. KRB_SAFE generation + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_SAFE */ + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + + +Section A.13. - 114 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + +A.14. KRB_SAFE verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_SAFE) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + if (packet.checksum.cksumtype is not both collision-proof and keyed) then + error_out(KRB_AP_ERR_INAPP_CKSUM); + endif + if (safe_priv_common_checks_ok(packet)) then + set computed_checksum := checksum(packet.body); + if (computed_checksum != packet.checksum) then + error_out(KRB_AP_ERR_MODIFIED); + endif + return (packet, PACKET_IS_GENUINE); + else + return common_checks_error; + endif + +A.15. KRB_SAFE and KRB_PRIV common checks + if (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + + +Section A.15. - 115 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) then + error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and packet.seq-number not present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + +A.16. KRB_PRIV generation + collect user data in buffer; + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_PRIV */ + + packet.enc-part.etype := encryption type; + + body.user-data := buffer; + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + + +A.17. KRB_PRIV verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + + +Section A.17. - 116 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + +A.18. KRB_CRED generation + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_CRED */ + + for (tickets[n] in tickets to be forwarded) do + packet.tickets[n] = tickets[n].ticket; + done + + packet.enc-part.etype := encryption type; + + for (ticket[n] in tickets to be forwarded) do + body.ticket-info[n].key = tickets[n].session; + body.ticket-info[n].prealm = tickets[n].crealm; + body.ticket-info[n].pname = tickets[n].cname; + body.ticket-info[n].flags = tickets[n].flags; + body.ticket-info[n].authtime = tickets[n].authtime; + body.ticket-info[n].starttime = tickets[n].starttime; + body.ticket-info[n].endtime = tickets[n].endtime; + body.ticket-info[n].renew-till = tickets[n].renew-till; + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + + +Section A.18. - 117 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + using negotiated encryption key; + + +A.19. KRB_CRED verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + if ((packet.r-address is present or required) and + (packet.s-address != O/S_sender(packet)) then + /* O/S report of sender not who claims to have sent it */ + error_out(KRB_AP_ERR_BADADDR); + endif + if ((packet.r-address is present) and + (packet.r-address != local_host_address)) then + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) then + error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + +A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + + +Section A.20. - 118 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 119 - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - cxx - Expires 11 January 1998 + + + + + + + + + + + Table of Contents + + + + +Overview .............................................. 2 + +Background ............................................ 2 + +1. Introduction ....................................... 3 + +1.1. Cross-Realm Operation ............................ 5 + +1.2. Authorization .................................... 6 + +1.3. Environmental assumptions ........................ 7 + +1.4. Glossary of terms ................................ 8 + +2. Ticket flag uses and requests ...................... 10 + +2.1. Initial and pre-authenticated tickets ............ 10 + +2.2. Invalid tickets .................................. 11 + +2.3. Renewable tickets ................................ 11 + +2.4. Postdated tickets ................................ 12 + +2.5. Proxiable and proxy tickets ...................... 12 + +2.6. Forwardable tickets .............................. 13 + +2.7. Other KDC options ................................ 14 + +3. Message Exchanges .................................. 14 + +3.1. The Authentication Service Exchange .............. 14 + +3.1.1. Generation of KRB_AS_REQ message ............... 16 + +3.1.2. Receipt of KRB_AS_REQ message .................. 16 + +3.1.3. Generation of KRB_AS_REP message ............... 16 + +3.1.4. Generation of KRB_ERROR message ................ 19 + +3.1.5. Receipt of KRB_AS_REP message .................. 19 + +3.1.6. Receipt of KRB_ERROR message ................... 19 + +3.2. The Client/Server Authentication Exchange ........ 19 + +3.2.1. The KRB_AP_REQ message ......................... 20 + + + - i - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +3.2.2. Generation of a KRB_AP_REQ message ............. 20 + +3.2.3. Receipt of KRB_AP_REQ message .................. 21 + +3.2.4. Generation of a KRB_AP_REP message ............. 23 + +3.2.5. Receipt of KRB_AP_REP message .................. 23 + +3.2.6. Using the encryption key ....................... 24 + +3.3. The Ticket-Granting Service (TGS) Exchange ....... 25 + +3.3.1. Generation of KRB_TGS_REQ message .............. 26 + +3.3.2. Receipt of KRB_TGS_REQ message ................. 27 + +3.3.3. Generation of KRB_TGS_REP message .............. 28 + +3.3.3.1. Checking for revoked tickets ................. 30 + +3.3.3.2. Encoding the transited field ................. 30 + +3.3.4. Receipt of KRB_TGS_REP message ................. 32 + +3.4. The KRB_SAFE Exchange ............................ 32 + +3.4.1. Generation of a KRB_SAFE message ............... 32 + +3.4.2. Receipt of KRB_SAFE message .................... 33 + +3.5. The KRB_PRIV Exchange ............................ 34 + +3.5.1. Generation of a KRB_PRIV message ............... 34 + +3.5.2. Receipt of KRB_PRIV message .................... 34 + +3.6. The KRB_CRED Exchange ............................ 35 + +3.6.1. Generation of a KRB_CRED message ............... 35 + +3.6.2. Receipt of KRB_CRED message .................... 35 + +4. The Kerberos Database .............................. 36 + +4.1. Database contents ................................ 36 + +4.2. Additional fields ................................ 37 + +4.3. Frequently Changing Fields ....................... 38 + +4.4. Site Constants ................................... 39 + +5. Message Specifications ............................. 39 + + + + - ii - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +5.1. ASN.1 Distinguished Encoding Representation ...... 39 + +5.2. ASN.1 Base Definitions ........................... 40 + +5.3. Tickets and Authenticators ....................... 43 + +5.3.1. Tickets ........................................ 43 + +5.3.2. Authenticators ................................. 52 + +5.4. Specifications for the AS and TGS exchanges ...... 54 + +5.4.1. KRB_KDC_REQ definition ......................... 54 + +5.4.2. KRB_KDC_REP definition ......................... 61 + +5.5. Client/Server (CS) message specifications ........ 64 + +5.5.1. KRB_AP_REQ definition .......................... 64 + +5.5.2. KRB_AP_REP definition .......................... 65 + +5.5.3. Error message reply ............................ 67 + +5.6. KRB_SAFE message specification ................... 67 + +5.6.1. KRB_SAFE definition ............................ 67 + +5.7. KRB_PRIV message specification ................... 68 + +5.7.1. KRB_PRIV definition ............................ 68 + +5.8. KRB_CRED message specification ................... 69 + +5.8.1. KRB_CRED definition ............................ 70 + +5.9. Error message specification ...................... 72 + +5.9.1. KRB_ERROR definition ........................... 72 + +6. Encryption and Checksum Specifications ............. 74 + +6.1. Encryption Specifications ........................ 76 + +6.2. Encryption Keys .................................. 78 + +6.3. Encryption Systems ............................... 78 + +6.3.1. The NULL Encryption System (null) .............. 78 + +6.3.2. DES in CBC mode with a CRC-32 checksum (des- +cbc-crc) .............................................. 79 + +6.3.3. DES in CBC mode with an MD4 checksum (des- + + + - iii - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +cbc-md4) .............................................. 79 + +6.3.4. DES in CBC mode with an MD5 checksum (des- +cbc-md5) .............................................. 79 + +6.3.5. Triple DES EDE in outer CBC mode with an SHA1 +checksum (des3-cbc-sha1) .............................. 81 + +6.4. Checksums ........................................ 83 + +6.4.1. The CRC-32 Checksum (crc32) .................... 84 + +6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 84 + +6.4.3. RSA MD4 Cryptographic Checksum Using DES +(rsa-md4-des) ......................................... 84 + +6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 85 + +6.4.5. RSA MD5 Cryptographic Checksum Using DES +(rsa-md5-des) ......................................... 85 + +6.4.6. DES cipher-block chained checksum (des-mac) + +6.4.7. RSA MD4 Cryptographic Checksum Using DES +alternative (rsa-md4-des-k) ........................... 86 + +6.4.8. DES cipher-block chained checksum alternative +(des-mac-k) ........................................... 87 + +7. Naming Constraints ................................. 87 + +7.1. Realm Names ...................................... 87 + +7.2. Principal Names .................................. 88 + +7.2.1. Name of server principals ...................... 89 + +8. Constants and other defined values ................. 90 + +8.1. Host address types ............................... 90 + +8.2. KDC messages ..................................... 91 + +8.2.1. IP transport ................................... 91 + +8.2.2. OSI transport .................................. 91 + +8.2.3. Name of the TGS ................................ 92 + +8.3. Protocol constants and associated values ......... 92 + +9. Interoperability requirements ...................... 95 + + + + - iv - Expires 11 January 1998 + + + + + + + + Version 5 - Specification Revision 6 + + +9.1. Specification 1 .................................. 95 + +9.2. Recommended KDC values ........................... 97 + +10. REFERENCES ........................................ 98 + +A. Pseudo-code for protocol processing ................ 100 + +A.1. KRB_AS_REQ generation ............................ 100 + +A.2. KRB_AS_REQ verification and KRB_AS_REP genera- +tion .................................................. 100 + +A.3. KRB_AS_REP verification .......................... 104 + +A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 104 + +A.5. KRB_TGS_REQ generation ........................... 105 + +A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen- +eration ............................................... 106 + +A.7. KRB_TGS_REP verification ......................... 111 + +A.8. Authenticator generation ......................... 112 + +A.9. KRB_AP_REQ generation ............................ 112 + +A.10. KRB_AP_REQ verification ......................... 112 + +A.11. KRB_AP_REP generation ........................... 113 + +A.12. KRB_AP_REP verification ......................... 114 + +A.13. KRB_SAFE generation ............................. 114 + +A.14. KRB_SAFE verification ........................... 115 + +A.15. KRB_SAFE and KRB_PRIV common checks ............. 115 + +A.16. KRB_PRIV generation ............................. 116 + +A.17. KRB_PRIV verification ........................... 116 + +A.18. KRB_CRED generation ............................. 117 + +A.19. KRB_CRED verification ........................... 118 + +A.20. KRB_ERROR generation ............................ 118 + + + + + + + + - v - Expires 11 January 1998 + + + + |