diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt | 8277 |
1 files changed, 0 insertions, 8277 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt deleted file mode 100644 index 2284c3c..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt +++ /dev/null @@ -1,8277 +0,0 @@ - -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 - - - - |
