diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt | 6766 |
1 files changed, 6766 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt new file mode 100644 index 00000000000..06d997d48cc --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt @@ -0,0 +1,6766 @@ + + + +INTERNET-DRAFT Clifford Neuman + John Kohl + Theodore Ts'o + November 18th, 1998 + +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 ftp.ietf.org (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-03.txt, and expires May 18th, 1999. +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 provided in RFC1510. This document is intended to provide a detailed +description of the protocol, suitable for implementation, together with +descriptions of the appropriate use of protocol messages and fields within +those messages. + +This document is not intended to describe Kerberos to the end user, system +administrator, or application developer. Higher level papers describing +Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], +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 protocol. + +The motivations, goals, assumptions, and rationale behind most design +decisions are treated cursorily; they are more fully described in a paper +available in IEEE communications [NT94] and earlier in the Kerberos portion +of the Athena Technical Plan [MNSS87]. 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 [NS78] and on modifications suggested +by Denning and Sacco [DS81]. 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 +Kerberos. + +Version 5 of the Kerberos protocol (described in this document) has evolved +from Version 4 based on new requirements 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 +community. 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. Since RFC1510 was issued, extensions and revisions to the +protocol have been proposed by many individuals. Some of these proposals +are reflected in this document. Where such changes involved significant +effort, the document cites the contribution of the proposer. + +Reference implementations of both version 4 and version 5 of Kerberos are +publicly available and commercial implementations have been developed and +are widely used. Details on the differences between Kerberos Versions 4 and +5 can be found in [KNT92]. + +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 performs 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 certification +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +client transmits the ticket (which contains the client's identity and a +copy of the session key, all encrypted in the server's key) to the server. +The session key (now shared by the client and server) is used to +authenticate the client, and may optionally be used to 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 transactions, 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 authentication. + +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 protocol specification describes the AS and the TGS as separate +servers, they are implemented in practice as different protocol 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 transaction, 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, +additional information is sent to prove that the message originated 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 session key. Since no one except the +requesting principal and 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 principals 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. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +The authentication exchanges mentioned above require read-only access to +the Kerberos database. Sometimes, however, 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 +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 +transited 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 +authentication 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, intermediate realms may be +bypassed to achieve cross-realm authentication 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. + +The application server is ultimately responsible for accepting or rejecting +authentication and should check the transited field. The application server +may choose to rely on the KDC for the application server's realm to check +the transited field. The application server's KDC will set the +TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate +realms may also check the transited field as they issue + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +ticket-granting-tickets for other realms, but they are encouraged not to do +so. A client may request that the KDC's not check the transited field by +setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not +required to honor this flag. + +1.2. Authorization + +As an authentication service, Kerberos provides a means of verifying the +identity of principals on a network. Authentication 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 considered +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 [Neu93] , or on other authorization services. + +Applications should not be modified to accept the issuance of a service +ticket by the Kerberos server (even by 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 if +they interoperate with other KDCs or where other options for application +authentication (e.g. the PKTAPP proposal) 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 Kerberos. 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 nnot-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 successive 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 detection. 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 network, 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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. + +1.4. Glossary of terms + +Below is a list of terms used throughout this document. + +Authentication + Verifying the claimed identity of a principal. +Authentication header + A 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 transited 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 permission 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). +Credentials + A ticket plus the secret session key necessary to successfully use + that ticket in an authentication exchange. +KDC + Key Distribution Center, a network service that supplies tickets and + temporary session keys; or an instance of that service or the host on + which it runs. The KDC services both initial ticket and + ticket-granting ticket requests. The initial ticket portion is + sometimes referred to as the Authentication Server (or service). The + ticket-granting ticket portion is sometimes referred to as the + ticket-granting server (or service). +Kerberos + Aside from the 3-headed dog guarding Hades, the name given to Project + Athena's authentication service, the protocol used by that service, or + the code used to implement the authentication service. +Plaintext + The input to an encryption function or the output of a decryption + function. Decryption transforms ciphertext into plaintext. +Principal + A uniquely named client or server instance that participates in a + network communication. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +Principal identifier + The name used to uniquely identify each different principal. +Seal + To encipher a record containing several fields in such a way that the + fields cannot be individually replaced without either knowledge of the + encryption key or leaving evidence of tampering. +Secret key + An encryption key shared by a principal and the KDC, distributed + outside the bounds of the system, with a long lifetime. In the case of + a human user's principal, the secret key is derived from a password. +Server + A particular Principal which provides a resource to network clients. + The server is sometimes refered to as the Application 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 "session". +Sub-session key + A temporary encryption key used between two principals, selected and + exchanged by the principals using the session key, and with a lifetime + limited to the duration of a single association. +Ticket + A record that helps a client authenticate itself to a server; it + contains the client's identity, a session key, a timestamp, and other + information, all sealed using the server's secret key. It only serves + to authenticate a client when presented along with a fresh + Authenticator. + +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 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +KDC before use, by presenting them to the KDC in a TGS request with the +VALIDATE option specified. The KDC will only validate tickets after their +starttime has passed. The validation is required so that postdated tickets +which have been stolen before their starttime can be rendered permanently +invalid (through a hot-list mechanism) (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 interpreted by the +ticket-granting service (discussed below in section 3.3). It can usually be +ignored by application servers. However, some particularly careful +application servers may wish to disallow renewable tickets. + +If a renewable ticket is not renewed by its expiration time, the KDC will +not renew the ticket. The RENEWABLE flag is reset by default, but a client +may request it be set by setting the RENEWABLE option in the KRB_AS_REQ +message. If it is set, then the renew-till field in the ticket contains the +time after which the ticket may not be renewed. + +2.4. Postdated tickets + +Applications may occasionally need to obtain tickets for use much later, +e.g. a batch submission system would need tickets to be valid at the time +the batch job is serviced. However, it is dangerous to hold valid tickets +in a batch queue, since they will be on-line longer and more prone to +theft. Postdated tickets provide a way to obtain these tickets from the KDC +at job submission time, but to leave them "dormant" until they are +activated and validated by a further request of the KDC. If a ticket theft +were reported in the interim, the KDC would refuse to validate the ticket, +and the thief would be foiled. + +The MAY-POSTDATE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. This +flag must be set in a ticket-granting ticket in order to issue a postdated +ticket based on the presented ticket. It is reset by default; it may be +requested by a client by setting the ALLOW-POSTDATE option in the +KRB_AS_REQ message. This flag does not allow a client to obtain a postdated +ticket-granting ticket; postdated ticket-granting tickets can only by +obtained by requesting the postdating in the KRB_AS_REQ message. The life +(endtime-starttime) of a postdated ticket will be the remaining life of the + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 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 section to +forward a ticket granting ticket. + +The PROXIABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. When +set, this flag tells the ticket-granting server that it is OK to issue a +new ticket (but not a ticket-granting ticket) with a different network +address based on this ticket. This flag is set if requested by the client +on initial authentication. By default, the client will request that it be +set when requesting a ticket granting 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 service client can give the print +server a proxy to access the client's files on a particular file server in +order to satisfy a print request. + +In order to complicate the use of stolen credentials, Kerberos tickets are +usually valid from only those network addresses specifically included in +the ticket[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 authentication 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. + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +The FORWARDABLE flag in a ticket is normally only interpreted by the +ticket-granting service. It can be ignored by application servers. The +FORWARDABLE flag has an interpretation similar to that of the PROXIABLE +flag, except ticket-granting tickets may also be issued with different +network addresses. This flag is reset by default, but users may request +that it be set by setting the FORWARDABLE option in the AS request when +they request their initial ticket- granting ticket. + +This flag allows for authentication forwarding without requiring the user +to enter a password again. If the flag is not set, then authentication +forwarding is not permitted, but the same 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 process FORWARDED tickets +differently than non-FORWARDED tickets. + +2.7. Other KDC options + +There are two additional options which may be set in a client's request of +the KDC. The RENEWABLE-OK option indicates that the client will accept a +renewable ticket if a ticket with the requested life cannot otherwise be +provided. If a ticket with the requested life cannot be provided, then the +KDC may issue a renewable ticket with a renew-till equal to the the +requested endtime. The value of the renew-till field may still be adjusted +by site-determined limits or limits imposed by the individual principal or +server. + +The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. +It indicates that the ticket to be issued for the end server is to be +encrypted in the session key from the a additional second ticket-granting +ticket provided with the request. See section 3.3.3 for specific details. + +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 credentials for a given server but currently holds no +credentials. In its basic form, the client's secret key is used for +encryption and decryption. This exchange is typically used at the +initiation of a login session to obtain credentials for a Ticket-Granting +Server which will subsequently be used to obtain credentials for other +servers (see section 3.3) without requiring further use of the client's +secret key. This exchange is also used to request credentials for services + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 sections 5.4.1, 5.4.2, and 5.9.1. + +In the request, the client sends (in cleartext) its own identity and the +identity of the server for which it is requesting credentials. The +response, KRB_AS_REP, contains a ticket for the client to present to the +server, and a session key that will be shared by the client and the server. +The session key and additional information are encrypted in the client's +secret key. The KRB_AS_REP message contains information which can be used +to detect replays, and to associate it with the message to which it +replies. Various errors can occur; these are indicated by an error response +(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not +encrypted. The KRB_ERROR message contains information which can be used to +associate it with the message to which it replies. The lack of encryption +in the KRB_ERROR message precludes the ability to detect replays, +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 knowing or caring whether they are the same. This is +acceptable because nobody but the principal whose identity was given in the +request will be able to use the reply. Its critical information is +encrypted in that principal's key. The initial request supports an optional +field that can be used to pass additional information that might be needed +for the initial exchange. This field may be used for preauthentication as +described in section [hl<>]. + +3.1.1. Generation of KRB_AS_REQ message + +The client may specify a number of options in the initial request. Among +these options are whether 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 section 4). See +section A.1 for pseudocode. + +The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + +If all goes well, processing the KRB_AS_REQ message will result in the +creation of a ticket for the client to present to the server. The format +for the ticket is described in section 5.3.1. The contents of the ticket +are determined as follows. + +3.1.3. Generation of KRB_AS_REP message + +The authentication server looks up the client and server principals named +in the KRB_AS_REQ in its database, extracting their respective keys. If +required, the server pre-authenticates the request, and if the +pre-authentication check fails, an error message with the code + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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]. + +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 +information 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 specified, 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 certain types or +ranges of postdated tickets), and if acceptable, the ticket's start time is +set as requested and the INVALID flag is set in the new ticket. The +postdated ticket must be validated before use by presenting it to the KDC +after the start time has been reached. + +The expiration time of the ticket will be set to the minimum of the +following: + + * The expiration time (endtime) requested in the KRB_AS_REQ message. + * The ticket's start time plus the maximum allowable lifetime associated + with the client principal (the authentication server's database + includes a maximum ticket lifetime field in each principal's record; + see section 4). + * The ticket's start time plus the maximum allowable lifetime associated + with the server principal. + * The ticket's start time plus the maximum lifetime set by the policy of + the local realm. + +If the requested expiration time minus the start time (as determined above) +is less than a site-determined minimum lifetime, an error message with code +KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the +ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' +option was requested, then the 'RENEWABLE' flag is set in the new ticket, +and the renew-till value is set as if the 'RENEWABLE' option were requested +(the field and option names are described fully in section 5.4.1). + +If the RENEWABLE option has been requested or if the RENEWABLE-OK option +has been set and a renewable ticket is to be issued, then the renew-till +field is set to the minimum of: + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + + * Its requested value. + * The start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database entries. + * The start time of the ticket plus the maximum renewable lifetime set + by the policy of the local realm. + +The flags field of the new ticket will have the following options set if +they have been requested and if the policy of the local realm allows: +FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new +ticket is 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 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 sufficient 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + + 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 + +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 authenticated 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 insufficient to +authenticate a client, since tickets are passed across the network in +cleartext[DS90], 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 message +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 constructs 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[LGDSR87]. 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 collide with other sequence numbers in use. + +The client may indicate a requirement of mutual 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 additional 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 authenticator, 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 acceptable 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 indicates to the server that the ticket is +encrypted in the session 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 encryption 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 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 authenticators 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 authenticator +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. Otherwise, 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 server is assured that + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 service. + +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 randomly 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 timestamp and microsecond fields match those in the +Authenticator 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 checksum type) to the application programmer; the Kerberos protocol 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 protection 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 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 authenticates to the system, such as when a user logs in). The +message format for the TGS exchange is almost identical to that for the AS +exchange. The primary difference is that encryption 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 authentication 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 collection 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 credentials, +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 authentication header). The KRB_ERROR message contains an error code +and text explaining what went wrong. The KRB_ERROR message is not +encrypted. The KRB_TGS_REP message contains information which can be used + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +to detect replays, and to associate it with the message to which it +replies. The KRB_ERROR message also contains information which can be used +to associate 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 service, the client must +determine in which realm the application 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 message recursively). The Kerberos server may return +a TGT for the desired realm in which case one can proceed. Alternatively, +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. + +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 application 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 authentication 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 similar 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 service, 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 granting ticket for the current realm, but is for an application + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 +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 supported, 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 +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. + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 specified, 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 +different, 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 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 Authenticator, 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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). + +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 malicious 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 arrangement 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: + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + "/COM,/HP,/APOLLO, /COM/DEC". + +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 hierarchy) 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 hierarchy 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 processed in the same +manner as the KRB_AS_REP processing described above. The primary difference +is that the ciphertext part of the response must be decrypted using the +session 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 +information. 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 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 problem. + +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 protocol 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 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 checksum 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 messages 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. + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +The message is first checked by verifying that the protocol 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 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 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 message 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 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +error is generated. + +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 identifier +key Principal's secret key +p_kvno Principal's key version +max_life Maximum lifetime for Tickets +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 master 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 (endtime - 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. + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +When more than one key is active for a particular principal, 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 +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 tickets as or for the principal. (A +database may want to maintain 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 controlled by +the system-wide database service, Moira [LGDSR87]), 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 authentication, +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 modification 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 section 5.2). + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +Other frequently changing information that can be maintained 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 configurable 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 tickets 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 encryption and checksum +techniques, and the fields related to them, appear in section 6. + +Optional field in ASN.1 sequences + +For optional integer value and date fields in ASN.1 sequences where a +default value has been specified, certain default values will not be +allowed in the encoding because these values will always be represented +through defaulting by the absence of the optional field. For example, one +will not send a microsecond zero value because one must make sure that +there is only one way to encode this value. + +Additional fields in ASN.1 sequences + +Implementations receiving Kerberos messages with additional fields present +in ASN.1 sequences should carry the those fields through unmodified when +the message is forwarded. Implementation should drop such fields if the +sequence is reencoded. + +5.1. ASN.1 Distinguished Encoding Representation + +All uses of ASN.1 in Kerberos shall use the Distinguished Encoding +Representation of the data elements as described in the X.509 +specification, section 8.7 [X509-88]. + +5.3. ASN.1 Base Definitions + +The following ASN.1 base definitions are used in the rest of this section. +Note that since the underscore character (_) is not permitted in ASN.1 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 components consisting of the following +sub-fields: + +name-type + This field specifies the type of name that follows. 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-string + This field encodes a sequence of components that form a name, each + component encoded as a GeneralString. Taken together, a PrincipalName + and a Realm form a principal identifier. Most PrincipalNames will have + only a few components (typically one or two). + +KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + +The timestamps used in Kerberos are encoded as GeneralizedTimes. 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 +} + +HostAddresses ::= SEQUENCE OF HostAddress + +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 +} + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +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. + +Each sequence of type and data is refered to as an authorization element. +Elements may be application specific, however, there is a common set of +recursive elements that should be understood by all implementations. These +elements contain other elements embedded within them, and the +interpretation of the encapsulating element determines which of the +embedded elements must be interpreted, and which may be ignored. +Definitions for these common elements may be found in Appendix B. + +TicketExtensions ::= SEQUENCE OF SEQUENCE { + te-type[0] INTEGER, + te-data[1] OCTET STRING +} + + + +te-data + This field contains opaque data that must be caried with the ticket to + support extensions to the Kerberos protocol including but not limited + to some forms of inter-realm key exchange and plaintext authorization + data. See appendix C for some common uses of this field. +te-type + This field specifies the format for the te-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), + -- pre-authent(10), + -- hw-authent(11), + -- transited-policy-checked(12), + -- ok-as-delegate(13) + +KDCOptions ::= BIT STRING + -- reserved(0), + -- forwardable(1), + -- forwarded(2), + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + -- 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 number of bits needed to include +the highest order bit that is set (1), but in no case less than 32 bits. +The ASN.1 representation of the bit strings uses unnamed bits, with the +meaning of the individual bits defined by the comments in the specification +above. Implementations should accept values of bit strings of any length +and treat the value of flags corresponding to bits beyond the end of the +bit string as if the bit were reset (0). Comparison of 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]. + +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 indicate 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 + information 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). If it is + (6), then the lr-value subfield is the time when the password will + expire. +lr-value + This field contains the time of the last request. the time must be + interpreted according to the contents of the accompanying lr-type + subfield. + +See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, +EncryptionKey, EncryptionType, and KeyType. + +5.3. Tickets and Authenticators + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +This section describes the format and encryption parameters 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, + extensions[4] TicketExtensions OPTIONAL +} + +-- 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 identical. +sname + This field specifies the name part of the server's identity. +enc-part + This field holds the encrypted encoding of the EncTicketPart sequence. +extensions + This optional field contains a sequence of extentions that may be used + to carry information that must be carried with the ticket to support + several extensions, including but not limited to plaintext + authorization data, tokens for exchanging inter-realm keys, and other + information that must be associated with a ticket for use by the + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + application server. See Appendix C for definitions of some common + extensions. + + Note that some older versions of Kerberos did not support this field. + Because this is an optional field it will not break older clients, but + older clients might strip this field from the ticket before sending it + to the application server. This limits the usefulness of this ticket + field to environments where the ticket will not be parsed and + reconstructed by these older Kerberos clients. + + If it is known that the client will strip this field from the ticket, + as an interim measure the KDC may append this field to the end of the + enc-part of the ticket and append a traler indicating the lenght of + the appended extensions field. (this paragraph is open for discussion, + including the form of the traler). +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: + + 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. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + + 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. + + 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. + + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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. + + 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. + + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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. + When the names of CA's are to be embedded inthe transited field (as + specified for some extentions to the protocol), the X.500 names of the + CA's should be mapped into items in the transited field using the + mapping defined by RFC2253. +authtime + This field indicates the time of initial authentication 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 implementation of a `hot list' service at + the KDC. An end service that is particularly paranoid could refuse to + accept tickets for which the initial authentication 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 (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-till + This 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 absolute 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 suggested and default policy, however, is + that such tickets will only be issued or accepted when additional + 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 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 + service. 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 + basis 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 + additional entries when a new ticket is obtained during 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 service specific objects, and the rights to + those objects. The format for this field is described in section 5.2. + Although Kerberos is not concerned with the format of the contents of + the sub-fields, it does carry type information (ad-type). + + 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 authorization or certifying group + membership may be built using the authorization-data field. In this + case, the entity granting authorization (not the authorized 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 restrictions on its + own authority and delegates the restricted 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 [Neu93] for some suggested + uses of this field. + + The authorization-data field is optional and does not have to be + included in a ticket. + +5.3.2. Authenticators + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 +} + + +authenticator-vno + This field specifies the version number for the format of the + authenticator. This document specifies 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 + application specifies otherwise, if this field is left out the session + key from the ticket will be used. +seq-number + This optional field includes the initial sequence number to be used by + the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to + detect replays (It may also be used by application specific messages). + When included in the authenticator 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. Sequence numbers fall in the range of 0 through 2^32 - 1 and + wrap to zero following the value 2^32 - 1. + + 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. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 carried 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 + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData + -- encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +The fields in this message are: + +pvno + This field is included in each message, and specifies the protocol + version number. This document specifies protocol version 5. +msg-type + This field indicates the type of a protocol message. 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 contains 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 authentication (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 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. + + [use-specified-kvno item is here for discussion and may be removed] It + may also be used by the client to specify the version of a key that is + being used for accompanying preauthentication, and/or which should be + used to encrypt the reply from the KDC. + + PA-USE-SPECIFIED-KVNO ::= Integer + + The KDC should only accept and abide by the value of the + use-specified-kvno preauthentication data field when the specified key + is still valid and until use of a new key is confirmed. This situation + is likely to occur primarily during the period during which an updated + key is propagating to other KDC's in a realm. + + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + specified in separate documents. See [Pat92] for additional uses of + this field. +padata-type + The padata-type element of the padata field indicates 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: + + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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. + + 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- + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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. + + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 absent when the ENC-TKT-IN-SKEY option is + specified. 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 encoding 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. If this field is + omitted then the KDC should use the current time instead. +till + This field contains the expiration date requested by the client in a + ticket request. It is optional 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 generated + randomly, but if the correct time is known, it may suffice[25]. +etype + This field specifies the desired encryption algorithm 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 perform 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 subsequent (TGS) request. There is no +message type for 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 +ciphertext is encrypted in the sub-session key from the Authenticator, or +if absent, the session key from the ticket-granting ticket used in the +request. In that case, no version 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, + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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. +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 useful 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 + appearance 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 client's secret key is due to expire. The + expiration 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 expiration 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 section 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) +} + + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_AP_REQ. +ap-options + This 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 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 association session key. + +pvno and msg-type + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 session. 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 authenticator, or if also left out, the session key from the + ticket will be used. + +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 +example, 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. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +cksum + This field contains the checksum of the application data. Checksum + details are described in section 6.4. The checksum is computed over + the encoding of the KRB-SAFE sequence. First, the cksum is zeroed and + the checksum is computed over the encoding of the KRB-SAFE sequence, + then the checksum is set to the result of that computation, and + finally the KRB-SAFE sequence is encoded again. +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 recipient. +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: + +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 another. It is presented here to +encourage a common mechanism 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 +} + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +pvno and msg-type + These fields are described above in section 5.4.1. msg-type is + KRB_CRED. +tickets + These are the tickets obtained from the KDC specifically for use by + the intended recipient. Successive tickets are paired with the + corresponding 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 message 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 provide 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 message. +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 + 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 message for security-critical purposes, such as setting a +system clock or generating a fresh authenticator. The message can be +useful, however, for advising a user on the reason for some failure. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +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, + e-typed-data[14] SEQUENCE of ETypedData +OPTIONAL +} + +ETypedData ::= SEQUENCE { + e-data-type [1] INTEGER, + e-data-value [2] OCTET STRING, +} + + + +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 reasonably accurate + timestamp. +error-code + This 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 support 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + application to help it recover from or handle the error. If the + errorcode 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 containing + data for the method: + + 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 following 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. +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 message with the checksum absent. The checksum is then added + to the KRB-ERROR structure and the message is re-encoded. The Checksum + should be calculated using the session key from the ticket granting + 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 preauthentication + to prove knowledge of the secret key by the client[33]. If a checksum + can not be computed because the key to be used is not available, no + checksum will be included. +e-typed-data + [This field for discussion, may be deleted from final spec] This field + contains optional data that may be used to help the client recover + from the indicated error. [This could contain the METHOD-DATA + specified since I don't think anyone actually uses it yet. It could + also contain the PA-DATA sequence for the preauth required error if we + had a clear way to transition to the use of this field from the use of + the untype e-data field.] For example, this field may specify the key + version of the key used to verify preauthentication: + + e-data-type := 20 -- Key version number + e-data-value := Integer -- Key version number used to verify +preauthentication + +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, [DES77] in +conjunction with block chaining and checksum methods [DESM80]. Encryption +is used to prove the identities of the network entities participating 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 +confidence. 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 exchange) or a shared +session key (in the TGS exchange) to encrypt responses to ticket requests; + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 difficult. 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 confounder 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 +mapping 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. + +For an discussion of the integrity characteristics of the candidate +encryption and checksum methods considered for Kerberos, the the reader is +referred to [SG92]. + +6.1. Encryption Specifications + +The following ASN.1 definition describes all encrypted messages. The +enc-part field which appears in the unencrypted part of messages in section +5 is a sequence consisting 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +} + + + +etype + This field identifies which encryption algorithm was used to encipher + the cipher. Detailed specifications 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 dictionary 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 sufficient to hold the +appropriate item. The type and length is implicit and specified by the +particular encryption type 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; calculates 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 encryption 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 particular +encryption type to communicate with all others using that type, the + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +specification of an encryption type defines any checksum that is needed as +part of the encryption 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 additional +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 + algorithm 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 happen, 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 encryption 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). + +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 [DES77] using the cipher block chaining mode [DESM80]. +A CRC-32 checksum (described in ISO 3309 [ISO3309]) 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 confounder is used [SG92]. 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +Kerberos Version 5 Specification 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 [DES77] using the cipher block chaining mode [DESM80]. +An MD4 checksum (described in [MD492]) 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. + +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 [DES77] using the cipher block chaining mode [DESM80]. +An MD5 checksum (described in [MD5-92].) 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. + +Plaintext and DES ciphtertext are encoded as blocks of 8 octets 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 bits, ..., +and the eighth octet supplies the 8 least significant bits. + +Encryption under DES using cipher block chaining requires an additional +input in the form of an initialization 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 messages 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 hexadecimal 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.] + +String to key transformation + +To generate a DES key from a text string (password), a "salt" is +concatenated to the text string, and then padded with ASCII nulls to an 8 +byte boundary. This "salt" is normally the realm and each component of the +principal's name appended. However, sometimes different salts are used --- +for example, when a realm is renamed, or if a user changes her username, or +for compatibility with Kerberos V4 (whose string-to-key algorithm uses a +null string for the salt). This string is then fan-folded and +eXclusive-ORed with itself to form an 8 byte DES key. Before + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +eXclusive-ORing a block, every byte is shifted one bit to the left to leave +the lowest bit zero. The key is the "corrected" by correcting the parity on +the key, and if the key matches a 'weak' or 'semi-weak' key as described in +the DES specification, it is eXclusive-ORed with the constant +00000000000000F0. This key is then used to generate a DES CBC checksum on +the initial string (with the salt appended). The result of the CBC checksum +is the "corrected" as described above to form the result which is return as +the key. Pseudocode follows: + + name_to_default_salt(realm, name) { + s = realm + for(each component in name) { + s = s + component; + } + return s; + } + + key_correction(key) { + fixparity(key); + if (is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + string_to_key(string,salt) { + + odd = 1; + s = string + salt; + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + left shift every byte in 8byteblock one bit; + tempkey = tempkey XOR 8byteblock; + } + tempkey = key_correction(tempkey); + key = key_correction(DES-CBC-check(s,tempkey)); + return(key); + } + +6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key +Derivation [Horowitz] + +NOTE: This description currently refers to documents, the contents of which +might be bettered included by value in this spec. The description below was +provided by Marc Horowitz, and the form in which it will finally appear is +yet to be determined. This description is included in this version of the +draft because it does describe the implemenation ready for use with the MIT +implementation. Note also that the encryption identifier has been left +unspecified here because the value from Marc Horowitz's spec conflicted +with some other impmenentations implemented based on perevious versions of +the specification. + +This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1 +[Krawczyk96] message authentication algorithm, and key derivation for + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +Kerberos V5 [HorowitzB96]. + +The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The +hmac-sha1-des3 checksum type has been assigned the value 12. + +Encryption Type des3-cbc-hmac-sha1 + +EncryptedData using this type must be generated as described in +[Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The +keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV +must be used. If the length of the input data is not a multiple of the +block size, zero octets must be used to pad the plaintext to the next +eight-octet boundary. The counfounder must be eight random octets (one +block). + +Checksum Type hmac-sha1-des3 + +Checksums using this type must be generated as described in [Horowitz96]. +The keyed hash algorithm is HMAC-SHA1. + +Common Requirements + +The EncryptionKey value is 24 octets long. The 7 most significant bits of +each octet contain key bits, and the least significant bit is the inverse +of the xor of the key bits. + +For the purposes of key derivation, the block size is 64 bits, and the key +size is 168 bits. The 168 bits output by key derivation are converted to an +EncryptionKey value as follows. First, the 168 bits are divided into three +groups of 56 bits, which are expanded individually into 64 bits as follows: + + 1 2 3 4 5 6 7 p + 9 10 11 12 13 14 15 p +17 18 19 20 21 22 23 p +25 26 27 28 29 30 31 p +33 34 35 36 37 38 39 p +41 42 43 44 45 46 47 p +49 50 51 52 53 54 55 p +56 48 40 32 24 16 8 p + +The "p" bits are parity bits computed over the data bits. The output of the +three expansions are concatenated to form the EncryptionKey value. + +When the HMAC-SHA1 of a string is computed, the key is used in the +EncryptedKey form. + +Key Derivation + +In the Kerberos protocol, cryptographic keys are used in a number of +places. In order to minimize the effect of compromising a key, it is +desirable to use a different key for each of these places. Key derivation +[Horowitz96] can be used to construct different keys for each operation +from the keys transported on the network. For this to be possible, a small +change to the specification is necessary. + +This section specifies a profile for the use of key derivation [Horowitz96] +with Kerberos. For each place where a key is used, a ``key usage'' must is +specified for that purpose. The key, key usage, and encryption/checksum +type together describe the transformation from plaintext to ciphertext, or + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +plaintext to checksum. + +Key Usage Values + +This is a complete list of places keys are used in the kerberos protocol, +with key usage values and RFC 1510 section numbers: + + 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the + client key (section 5.4.1) + 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or + application session key), encrypted with the service key + (section 5.4.2) + 3. AS-REP encrypted part (includes tgs session key or application + session key), encrypted with the client key (section 5.4.2) + 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + session key (section 5.4.1) + 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs + authenticator subkey (section 5.4.1) + 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed + with the tgs session key (sections 5.3.2, 5.4.1) + 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs + authenticator subkey), encrypted with the tgs session key + (section 5.3.2) + 8. TGS-REP encrypted part (includes application session key), + encrypted with the tgs session key (section 5.4.2) + 9. TGS-REP encrypted part (includes application session key), + encrypted with the tgs authenticator subkey (section 5.4.2) +10. AP-REQ Authenticator cksum, keyed with the application session + key (section 5.3.2) +11. AP-REQ Authenticator (includes application authenticator + subkey), encrypted with the application session key (section + 5.3.2) +12. AP-REP encrypted part (includes application session subkey), + encrypted with the application session key (section 5.5.2) +13. KRB-PRIV encrypted part, encrypted with a key chosen by the + application (section 5.7.1) +14. KRB-CRED encrypted part, encrypted with a key chosen by the + application (section 5.6.1) +15. KRB-SAVE cksum, keyed with a key chosen by the application + (section 5.8.1) +18. KRB-ERROR checksum (e-cksum in section 5.9.1) +19. AD-KDCIssued checksum (ad-checksum in appendix B.1) +20. Checksum for Mandatory Ticket Extensions (appendix B.6) +21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) + +Key usage values between 1024 and 2047 (inclusive) are reserved for +application use. Applications should use even values for encryption and odd +values for checksums within this range. + +A few of these key usages need a little clarification. A service which +receives an AP-REQ has no way to know if the enclosed Ticket was part of an +AS-REP or TGS-REP. Therefore, key usage 2 must always be used for +generating a Ticket, whether it is in response to an AS- REQ or TGS-REQ. + +There might exist other documents which define protocols in terms of the +RFC1510 encryption types or checksum types. Such documents would not know +about key usages. In order that these documents continue to be meaningful +until they are updated, key usages 1024 and 1025 must be used to derive +keys for encryption and checksums, respectively. New protocols defined in + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +terms of the Kerberos encryption and checksum types should use their own +key usages. Key usages may be registered with IANA to avoid conflicts. Key +usages must be unsigned 32 bit integers. Zero is not permitted. + +Defining Cryptosystems Using Key Derivation + +Kerberos requires that the ciphertext component of EncryptedData be +tamper-resistant as well as confidential. This implies encryption and +integrity functions, which must each use their own separate keys. So, for +each key usage, two keys must be generated, one for encryption (Ke), and +one for integrity (Ki): + + Ke = DK(protocol key, key usage | 0xAA) + Ki = DK(protocol key, key usage | 0x55) + +where the protocol key is from the EncryptionKey from the wire protocol, +and the key usage is represented as a 32 bit integer in network byte order. +The ciphertest must be generated from the plaintext as follows: + + ciphertext = E(Ke, confounder | plaintext | padding) | + H(Ki, confounder | plaintext | padding) + +The confounder and padding are specific to the encryption algorithm E. + +When generating a checksum only, there is no need for a confounder or +padding. Again, a new key (Kc) must be used. Checksums must be generated +from the plaintext as follows: + + Kc = DK(protocol key, key usage | 0x99) + + MAC = H(Kc, plaintext) + +Note that each enctype is described by an encryption algorithm E and a +keyed hash algorithm H, and each checksum type is described by a keyed hash +algorithm H. HMAC, with an appropriate hash, is recommended for use as H. + +Key Derivation from Passwords + +The well-known constant for password key derivation must be the byte string +{0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the +ASCII encoding for the string "kerberos". + +6.4. Checksums + +The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + +cksumtype + This field indicates the algorithm used to generate 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. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 subsequently 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 message. In such cases, the composition of +the checksum and 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 [ISO3309]. 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 probabilistic +chosen-plaintext attack as described in [SG92] 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 +[MD4-92]. 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 'semi-weak keys'; those +keys shall not be used for generating 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) | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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. +[MD5-92]. 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 hexadecimal +constant F0F0F0F0F0F0F0F0. 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 'semi-weak keys'; +those keys shall not be used for encrypting RSA-MD5 checksums for use in +Kerberos. + +The format for the checksum is described in the following 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 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 hexadecimal +constant F0F0F0F0F0F0F0F0. The initialization 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 following diagram: + ++--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +| 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 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 vector +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 generating 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) + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 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 organization 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 administrator 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 different). The following name types are +defined: + + name-type value meaning + + 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 + NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +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 NT-X500-PRINCIPAL should be used when a name from an X.509 +certificiate is translated into a Kerberos name. The encoding of the X.509 +name as a Kerberos principal shall conform to the encoding rules specified +in RFC 2253. + +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 UNKNOWN. + +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 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +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 interpretations. + +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 with symbolic names AF_xxx (where xxx is an +abbreviation of the address family name). + +Internet (IPv4) Addresses + +Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB +order. The type of IPv4 addresses is two (2). + +Internet (IPv6) Addresses [Westerlund] + +IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The +type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The +following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: + + * the Unspecified Address + * the Loopback Address + * Link-Local addresses + +IPv4-mapped IPv6 addresses MUST be represented as addresses of type 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). + +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 network 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). + +Netbios addresses + +Netbios addresses are 16-octet addresses typically composed of 1 to 15 +characters, trailing blank (ascii char 20) filled, with a 16th octet of +0x0. The type of Netbios addresses is 20 (0x14). + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +8.2. KDC messages + +8.2.1. UDP/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). The response to a request made +through UDP/IP transport must also use UDP/IP transport. + +8.2.2. TCP/IP transport [Westerlund,Danielsson] + +Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) +and clients should support the sending of TCP requests on port 88 +(decimal). When the KRB_KDC_REQ message is sent to the KDC over a TCP +stream, a new connection will be established for each authentication +exchange (request and response). The KRB_KDC_REP or KRB_ERROR message will +be returned to the client on the same TCP stream that was established for +the request. The response to a request made through TCP/IP transport must +also use TCP/IP transport. Implementors should note that some extentions to +the Kerberos protocol will not work if any implementation not supporting +the TCP transport is involved (client or KDC). Implementors are strongly +urged to support the TCP transport on both the client and server and are +advised that the current notation of "should" support will likely change in +the future to must support. The KDC may close the TCP stream after sending +a response, but may leave the stream open if it expects a followup - in +which case it may close the stream at any time if resource constratints or +other factors make it desirable to do so. 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. If +multiple exchanges with the KDC are needed for certain forms of +preauthentication, multiple TCP connections may be required. A client may +close the stream after receiving response, and should close the stream if +it does not expect to send followup messages. The client must be prepared +to have the stream closed by the KDC at anytime, in which case it must +simply connect again when it is ready to send subsequent messages. + +The first four octets of the TCP stream used to transmit the request +request will encode in network byte order the length of the request +(KRB_KDC_REQ), and the length will be followed by the request itself. The +response will similarly be preceeded by a 4 octet encoding in network byte +order of the length of the KRB_KDC_REP or the KRB_ERROR message and will be +followed by the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is +set on integer represented by the first 4 octets, then the next 4 octets +will be read, extending the length of the field by another 4 octets (less 1 +bit). + +8.2.3. 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 mechanism will +be: + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 (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. Ranges are specified in the "specification" section that limit +the values of constants for which values are defined here. This allows +implementations to make assumptions about the maximum values that will be +received for these constants. Implementation receiving values outside the +range specified in the "specification" section may reject the request, but +they must recover cleanly. + +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 + 4 +des3-cbc-md5 5 8 0 8 + 6 +des3-cbc-sha1 7 8 0 8 +sign-dsa-generate 8 (pkinit) +encrypt-rsa-priv 9 (pkinit) +encrypt-rsa-pub 10 (pkinit) +rsa-pub-md5 11 (pkinit) +rsa-pub-sha1 12 (pkinit) +des3kd-cbc-sha1 ?? 8 0 8 +ENCTYPE_PK_CROSS 48 (reserved for pkcross) + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +rsa-md5-des3 9 24 +hmac-sha1-des3 12 20 (I had this as 10, is it +12) + +padata type padata-type value + +PA-TGS-REQ 1 +PA-ENC-TIMESTAMP 2 +PA-PW-SALT 3 + 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) +PA-USE-SPECIFIED-KVNO 20 + +authorization data type ad-type value +AD-KDC-ISSUED 1 +AD-INTENDED-FOR-SERVER 2 +AD-INTENDED-FOR-APPLICATION-CLASS 3 +AD-IF-RELEVANT 4 +AD-OR 5 +AD-MANDATORY-TICKET-EXTENSIONS 6 +AD-IN-TICKET-EXTENSIONS 7 +reserved values 8-63 +OSF-DCE 64 +SESAME 65 + +Ticket Extension Types + +TE-TYPE-NULL 0 Null ticket extension +TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data + 2 TE-TYPE-PKCROSS-KDC (I have reservations) +TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket +TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp + 5 TE-TYPE-DEST-HOST (I have reservations) + +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +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 + +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 +KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] + +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 +[40] +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 +KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in +message +KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path +KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP +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) +KDC_ERR_CERTIFICATE_MISMATCH 66 (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 authentication, user to user authentication, support for proxies, +forwarding, 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 configuration 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 2 + +This section defines the second specification of these options. +Implementations which are configured in this way can be said to support +Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may +be found in RFC1510. + +Transport + +TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance +to specification 2. Kerberos clients claiming conformance to specification +2 must support UDP/IP transport for messages with the KDC and should +support TCP/IP transport. + +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +also support them: This list is to be determined. + +Encryption: DES-CBC-MD5 +Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 + +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 preauthentication 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 derivative 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. Individual realms and +application servers can set their own policy on when such tickets will be +accepted. + +All implementations must recognize renewable and postdated 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 implementations +shall make the presence of the postdated flag 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. + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 definition 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 authorization 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. + +Constant ranges + +All protocol constants are constrained to 32 bit (signed) values unless +further constrained by the protocol definition. This limit is provided to +allow implementations to make assumptions about the maximum values that +will be received for these constants. Implementation receiving values +outside this range may reject the request, but they must recover cleanly. + +9.2. Recommended KDC values + +Following is a list of recommended values for a KDC implementation, based +on the list of suggested configuration constants (see section 4.4). + +minimum lifetime 5 minutes +maximum renewable lifetime 1 week +maximum ticket lifetime 1 day +empty addresses only when suitable restrictions appear + in authorization data +proxiable, etc. Allowed. + +10. REFERENCES + +[NT94] 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). + +[MNSS87] 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). + +[SNS88] 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). + +[NS78] 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). + +[DS81] 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). + +[KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + "The Evolution of the Kerberos Authentication Service," + in an IEEE Computer Society Text soon to be published + (June 1992). + +[Neu93] 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). + +[DS90] Don Davis and Ralph Swick, "Workstation Services and + Kerberos Authentication at Project Athena," Technical + Memorandum TM-424, MIT Laboratory for Computer Science + (February 1990). + +[LGDSR87] 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). + +[X509-88] CCITT, Recommendation X.509: The Directory Authentica- + tion Framework, December 1988. + +[Pat92]. J. Pato, Using Pre-Authentication to Avoid Password + Guessing Attacks, Open Software Foundation DCE Request + for Comments 26 (December 1992). + +[DES77] National Bureau of Standards, U.S. Department of Com- + merce, "Data Encryption Standard," Federal Information + Processing Standards Publication 46, Washington, DC + (1977). + +[DESM80] National Bureau of Standards, U.S. Department of Com- + merce, "DES Modes of Operation," Federal Information + Processing Standards Publication 81, Springfield, VA + (December 1980). + +[SG92] 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). + +[IS3309] 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. + +[MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC + 1320, MIT Laboratory for Computer Science (April + 1992). + +[MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC + 1321, MIT Laboratory for Computer Science (April + 1992). + +[KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication," Working Draft + draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). + +[Horowitz96] Horowitz, M., "Key Derivation for Authentication, + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, + August 1998. + +[HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- + horowitz-kerb-key-derivation-01.txt, September 1998. + +[Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- + md5-01.txt, August, 1996. + +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 + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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); + + 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; + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + endif + + 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; + new_tkt.renew-till := min(rtime, + +new_tkt.starttime+client.max_rlife, + +new_tkt.starttime+server.max_rlife, + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +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); + +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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; + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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; + 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)); + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 + + 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(req.sname)) then + server := best_intermediate_tgs(req.sname); + else + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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; + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 + + 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, + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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, + +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) + /* Don't check tranited field if TGT for foreign realm, + * or requested not to check */ + if (is_not_foreign_tgt_name(new_tkt.server) + && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + /* Check it, so end-server does not have to + * but don't fail, end-server may still accept it */ + if (check_transited_field(new_tkt.transited) == OK) + set new_tkt.flags.TRANSITED-POLICY-CHECKED; + endif + endif + 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; + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + + 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); + +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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + + 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}; + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 + if (decr_ticket.transited) then + /* caller may ignore the TRANSITED-POLICY-CHECKED and do + * check anyway */ + if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then + if (check_transited_field(decr_ticket.transited) then + error_out(KDC_AP_PATH_NOT_ACCPETED); + endif + endif + 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 */ + + 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 + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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; + 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); + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 + + 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; + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + 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 + 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; + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + + 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 + 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 + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +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 + 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 + +B. Definition of common authorization data elements + +This appendix contains the definitions of common authorization data +elements. These common authorization data elements are recursivly defined, +meaning the ad-data for these types will itself contain a sequence of +authorization data whose interpretation is affected by the encapsulating +element. Depending on the meaning of the encapsulating element, the +encapsulated elements may be ignored, might be interpreted as issued +directly by the KDC, or they might be stored in a separate plaintext part +of the ticket. The types of the encapsulating elements are specified as +part of the Kerberos specification because the behavior based on these +values should be understood across implementations whereas other elements +need only be understood by the applications which they affect. + +In the definitions that follow, the value of the ad-type for the element +will be specified in the subsection number, and the value of the ad-data +will be as shown in the ASN.1 structure that follows the subsection +heading. + +B.1. KDC Issued + +AD-KDCIssued SEQUENCE { + ad-checksum[0] Checksum, + i-realm[1] Realm OPTIONAL, + i-sname[2] PrincipalName OPTIONAL, + elements[3] AuthorizationData. +} + +ad-checksum + A checksum over the elements field using a cryptographic checksum + method that is identical to the checksum used to protect the ticket + itself (i.e. using the same hash function and the same encryption + algorithm used to encrypt the ticket) and using a key derived from the + same key used to protect the ticket. +i-realm, i-sname + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + The name of the issuing principal if different from the KDC itself. + This field would be used when the KDC can verify the authenticity of + elements signed by the issuing principal and it allows this KDC to + notify the application server of the validity of those elements. +elements + A sequence of authorization data elements issued by the KDC. + +The KDC-issued ad-data field is intended to provide a means for Kerberos +principal credentials to embed within themselves privilege attributes and +other mechanisms for positive authorization, amplifying the priveleges of +the principal beyond what can be done using a credentials without such an +a-data element. + +This can not be provided without this element because the definition of the +authorization-data field allows elements to be added at will by the bearer +of a TGT at the time that they request service tickets and elements may +also be added to a delegated ticket by inclusion in the authenticator. + +For KDC-issued elements this is prevented because the elements are signed +by the KDC by including a checksum encrypted using the server's key (the +same key used to encrypt the ticket - or a key derived from that key). +Elements encapsulated with in the KDC-issued element will be ignored by the +application server if this "signature" is not present. Further, elements +encapsulated within this element from a ticket granting ticket may be +interpreted by the KDC, and used as a basis according to policy for +including new signed elements within derivative tickets, but they will not +be copied to a derivative ticket directly. If they are copied directly to a +derivative ticket by a KDC that is not aware of this element, the signature +will not be correct for the application ticket elements, and the field will +be ignored by the application server. + +This element and the elements it encapulates may be safely ignored by +applications, application servers, and KDCs that do not implement this +element. + +B.2. Intended for server + +AD-INTENDED-FOR-SERVER SEQUENCE { + intended-server[0] SEQUENCE OF PrincipalName + elements[1] AuthorizationData +} + +AD elements encapsulated within the intended-for-server element may be +ignored if the application server is not in the list of principal names of +intended servers. Further, a KDC issuing a ticket for an application server +can remove this element if the application server is not in the list of +intended servers. + +Application servers should check for their principal name in the +intended-server field of this element. If their principal name is not +found, this element should be ignored. If found, then the encapsulated +elements should be evaluated in the same manner as if they were present in +the top level authorization data field. Applications and application +servers that do not implement this element should reject tickets that +contain authorization data elements of this type. + +B.3. Intended for application class + +AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements +encapsulated within the intended-for-application-class element may be +ignored if the application server is not in one of the named classes of +application servers. Examples of application server classes include +"FILESYSTEM", and other kinds of servers. + +This element and the elements it encapulates may be safely ignored by +applications, application servers, and KDCs that do not implement this +element. + +B.4. If relevant + +AD-IF-RELEVANT AuthorizationData + +AD elements encapsulated within the if-relevant element are intended for +interpretation only by application servers that understand the particular +ad-type of the embedded element. Application servers that do not understand +the type of an element embedded within the if-relevant element may ignore +the uninterpretable element. This element promotes interoperability across +implementations which may have local extensions for authorization. + +B.5. And-Or + +AD-AND-OR SEQUENCE { + condition-count[0] INTEGER, + elements[1] AuthorizationData +} + +When restrictive AD elements encapsulated within the and-or element are +encountered, only the number specified in condition-count of the +encapsulated conditions must be met in order to satisfy this element. This +element may be used to implement an "or" operation by setting the +condition-count field to 1, and it may specify an "and" operation by +setting the condition count to the number of embedded elements. Application +servers that do not implement this element must reject tickets that contain +authorization data elements of this type. + +B.6. Mandatory ticket extensions + +AD-Mandatory-Ticket-Extensions Checksum + +An authorization data element of type mandatory-ticket-extensions specifies +a collision-proof checksum using the same hash algorithm used to protect +the integrity of the ticket itself. This checksum will be calculated over +an individual extension field. If there are more than one extension, +multiple Mandatory-Ticket-Extensions authorization data elements may be +present, each with a checksum for a different extension field. This +restriction indicates that the ticket should not be accepted if a ticket +extension is not present in the ticket for which the checksum does not +match that checksum specified in the authorization data element. +Application servers that do not implement this element must reject tickets +that contain authorization data elements of this type. + +B.7. Authorization Data in ticket extensions + +AD-IN-Ticket-Extensions Checksum + +An authorization data element of type in-ticket-extensions specifies a +collision-proof checksum using the same hash algorithm used to protect the + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +integrity of the ticket itself. This checksum is calculated over a separate +external AuthorizationData field carried in the ticket extensions. +Application servers that do not implement this element must reject tickets +that contain authorization data elements of this type. Application servers +that do implement this element will search the ticket extensions for +authorization data fields, calculate the specified checksum over each +authorization data field and look for one matching the checksum in this +in-ticket-extensions element. If not found, then the ticket must be +rejected. If found, the corresponding authorization data elements will be +interpreted in the same manner as if they were contained in the top level +authorization data field. + +Note that if multiple external authorization data fields are present in a +ticket, each will have a corresponding element of type in-ticket-extensions +in the top level authorization data field, and the external entries will be +linked to the corresponding element by their checksums. + +C. Definition of common ticket extensions + +This appendix contains the definitions of common ticket extensions. Support +for these extensions is optional. However, certain extensions have +associated authorization data elements that may require rejection of a +ticket containing an extension by application servers that do not implement +the particular extension. Other extensions have been defined beyond those +described in this specification. Such extensions are described elswhere and +for some of those extensions the reserved number may be found in the list +of constants. + +It is known that older versions of Kerberos did not support this field, and +that some clients will strip this field from a ticket when they parse and +then reassemble a ticket as it is passed to the application servers. The +presence of the extension will not break such clients, but any functionaly +dependent on the extensions will not work when such tickets are handled by +old clients. In such situations, some implementation may use alternate +methods to transmit the information in the extensions field. + +C.1. Null ticket extension + +TE-NullExtension OctetString -- The empty Octet String + +The te-data field in the null ticket extension is an octet string of lenght +zero. This extension may be included in a ticket granting ticket so that +the KDC can determine on presentation of the ticket granting ticket whether +the client software will strip the extensions field. + +C.2. External Authorization Data + +TE-ExternalAuthorizationData AuthorizationData + +The te-data field in the external authorization data ticket extension is +field of type AuthorizationData containing one or more authorization data +elements. If present, a corresponding authorization data element will be +present in the primary authorization data for the ticket and that element +will contain a checksum of the external authorization data ticket +extension. + ------------------------------------------------------------------------ +[TM] 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. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +[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. + +[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. + +[4] Though it is permissible to request or issue tick- ets with no network +addresses specified. + +[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 system, the credentials +obtained in the AS exchange may first be used in a TGS exchange to obtain +credentials for a local server. Those credentials must then be verified by +a local server through successful completion of the Client/Server exchange. + +[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 desirable to use a truly random number +generator, such as one based on measurements of random physical phenomena. + +[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 unreliable 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. + +[10] This is used for user-to-user authentication as described in [8]. + +[11] Note that the rejection here is restricted to authenticators from the +same principal to the same server. Other client principals communicating +with the same server principal should not be have their authenticators +rejected if the time and microsecond fields happen to match some other +client's authenticator. + +[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 messages are formatted in such a way that it is not possible to + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + +create the reply by judicious message surgery (even in encrypted form) +without knowledge of the appropriate 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. + +[14] Implementations of the protocol may wish to provide 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. + +[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 application server to the client. + +[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 random number and XOR it with the session key from the +ticket-granting ticket. + +[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. + +[18] For the purpose of appending, the realm preceding the first listed +realm is considered to be the null realm (""). + +[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 considered to follow them. + +[20] This means that a client and server running on the same host and +communicating with one another using the KRB_SAFE messages should not share +a common replay cache to detect KRB_SAFE replays. + +[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. + +[22] See the discussion of the padata field in section 5.4.2 for details on +why this can be useful. + +[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. + +[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 actually came from the proper KDC in a timely manner. + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + + +INTERNET-DRAFT draft-ietf-cat-kerberos-r-03 November 18 1998 + + + +[25] Note, however, that if the time is used as the 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. + +[27] An application code in the encrypted part of a message provides an +additional check that the message was decrypted properly. + +[29] An application code in the encrypted part of a message provides an +additional check that the message was decrypted properly. + +[31] An application code in the encrypted part of a 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 message, 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 algorithm +will be used. + +[33] This prevents an attacker who generates an incorrect AS request from +obtaining verifiable plaintext for use in an off-line password guessing +attack. + +[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 because +they are specified by the encryption type. [36] The ordering of the fields +in the CipherText is important. Additionally, messages encoded in this +format 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 +message which could be truncated, while leaving the checksum 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. + +[37] In some cases, it may be necessary to use a different "mix-in" string +for compatibility reasons; see the discussion of padata in section 5.4.2. + +[38] In some cases, it may be necessary to use a different "mix-in" string +for compatibility reasons; see the discussion of padata in section 5.4.2. + +[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 performed 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 purpose in +the Message Integrity Check in the Privacy Enhanced Mail standard. + +[40] 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. + + +Neuman, Ts'o, Kohl Expires: 18 May 1999 + |