1 2INTERNET-DRAFT Clifford Neuman 3 John Kohl 4 Theodore Ts'o 5 21 November 1997 6 7The Kerberos Network Authentication Service (V5) 8 9STATUS OF THIS MEMO 10 11This document is an Internet-Draft. Internet-Drafts are working documents of 12the Internet Engineering Task Force (IETF), its areas, and its working 13groups. Note that other groups may also distribute working documents as 14Internet-Drafts. 15 16Internet-Drafts are draft documents valid for a maximum of six months and 17may be updated, replaced, or obsoleted by other documents at any time. It is 18inappropriate to use Internet-Drafts as reference material or to cite them 19other than as 'work in progress.' 20 21To learn the current status of any Internet-Draft, please check the 22'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow 23Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 26The distribution of this memo is unlimited. It is filed as 27draft-ietf-cat-kerberos-r-01.txt, and expires 21 May 1998. Please send 28comments to: krb-protocol@MIT.EDU 29 30ABSTRACT 31 32This document provides an overview and specification of Version 5 of the 33Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 34and its intended use that require more detailed or clearer explanation than 35was provided in RFC1510. This document is intended to provide a detailed 36description of the protocol, suitable for implementation, together with 37descriptions of the appropriate use of protocol messages and fields within 38those messages. 39 40This document is not intended to describe Kerberos to the end user, system 41administrator, or application developer. Higher level papers describing 42Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 43are available elsewhere. 44 45OVERVIEW 46 47This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 48network authentication system is based. It also specifies Version 5 of the 49Kerberos protocol. 50 51The motivations, goals, assumptions, and rationale behind most design 52decisions are treated cursorily; they are more fully described in a paper 53available in IEEE communications [NT94] and earlier in the Kerberos portion 54of the Athena Technical Plan [MNSS87]. The protocols have been a proposed 55 56 57draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 58 59standard and are being considered for advancement for draft standard through 60the IETF standard process. Comments are encouraged on the presentation, but 61only minor refinements to the protocol as implemented or extensions that fit 62within current protocol framework will be considered at this time. 63 64Requests for addition to an electronic mailing list for discussion of 65Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. 66This mailing list is gatewayed onto the Usenet as the group 67comp.protocols.kerberos. Requests for further information, including 68documents and code availability, may be sent to info-kerberos@MIT.EDU. 69 70BACKGROUND 71 72The Kerberos model is based in part on Needham and Schroeder's trusted 73third-party authentication protocol [NS78] and on modifications suggested by 74Denning and Sacco [DS81]. The original design and implementation of Kerberos 75Versions 1 through 4 was the work of two former Project Athena staff 76members, Steve Miller of Digital Equipment Corporation and Clifford Neuman 77(now at the Information Sciences Institute of the University of Southern 78California), along with Jerome Saltzer, Technical Director of Project 79Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members 80of Project Athena have also contributed to the work on Kerberos. 81 82Version 5 of the Kerberos protocol (described in this document) has evolved 83from Version 4 based on new requirements and desires for features not 84available in Version 4. The design of Version 5 of the Kerberos protocol was 85led by Clifford Neuman and John Kohl with much input from the community. The 86development of the MIT reference implementation was led at MIT by John Kohl 87and Theodore T'so, with help and contributed code from many others. 88Reference implementations of both version 4 and version 5 of Kerberos are 89publicly available and commercial implementations have been developed and 90are widely used. 91 92Details on the differences between Kerberos Versions 4 and 5 can be found in 93[KNT92]. 94 951. Introduction 96 97Kerberos provides a means of verifying the identities of principals, (e.g. a 98workstation user or a network server) on an open (unprotected) network. This 99is accomplished without relying on assertions by the host operating system, 100without basing trust on host addresses, without requiring physical security 101of all the hosts on the network, and under the assumption that packets 102traveling along the network can be read, modified, and inserted at will[1]. 103Kerberos performs authentication under these conditions as a trusted 104third-party authentication service by using conventional (shared secret key 105[2] cryptography. Kerberos extensions have been proposed and implemented 106that provide for the use of public key cryptography during certain phases of 107the authentication protocol. These extensions provide for authentication of 108users registered with public key certification authorities, and allow the 109system to provide certain benefits of public key cryptography in situations 110where they are needed. 111 112The basic Kerberos authentication process proceeds as follows: A client 113 114 115draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 116 117sends a request to the authentication server (AS) requesting 'credentials' 118for a given server. The AS responds with these credentials, encrypted in the 119client's key. The credentials consist of 1) a 'ticket' for the server and 2) 120a temporary encryption key (often called a "session key"). The client 121transmits the ticket (which contains the client's identity and a copy of the 122session key, all encrypted in the server's key) to the server. The session 123key (now shared by the client and server) is used to authenticate the 124client, and may optionally be used to authenticate the server. It may also 125be used to encrypt further communication between the two parties or to 126exchange a separate sub-session key to be used to encrypt further 127communication. 128 129Implementation of the basic protocol consists of one or more authentication 130servers running on physically secure hosts. The authentication servers 131maintain a database of principals (i.e., users and servers) and their secret 132keys. Code libraries provide encryption and implement the Kerberos protocol. 133In order to add authentication to its transactions, a typical network 134application adds one or two calls to the Kerberos library directly or 135through the Generic Security Services Application Programming Interface, 136GSSAPI, described in separate document. These calls result in the 137transmission of the necessary messages to achieve authentication. 138 139The Kerberos protocol consists of several sub-protocols (or exchanges). 140There are two basic methods by which a client can ask a Kerberos server for 141credentials. In the first approach, the client sends a cleartext request for 142a ticket for the desired server to the AS. The reply is sent encrypted in 143the client's secret key. Usually this request is for a ticket-granting 144ticket (TGT) which can later be used with the ticket-granting server (TGS). 145In the second method, the client sends a request to the TGS. The client uses 146the TGT to authenticate itself to the TGS in the same manner as if it were 147contacting any other application server that requires Kerberos 148authentication. The reply is encrypted in the session key from the TGT. 149Though the protocol specification describes the AS and the TGS as separate 150servers, they are implemented in practice as different protocol entry points 151within a single Kerberos server. 152 153Once obtained, credentials may be used to verify the identity of the 154principals in a transaction, to ensure the integrity of messages exchanged 155between them, or to preserve privacy of the messages. The application is 156free to choose whatever protection may be necessary. 157 158To verify the identities of the principals in a transaction, the client 159transmits the ticket to the application server. Since the ticket is sent "in 160the clear" (parts of it are encrypted, but this encryption doesn't thwart 161replay) and might be intercepted and reused by an attacker, additional 162information is sent to prove that the message originated with the principal 163to whom the ticket was issued. This information (called the authenticator) 164is encrypted in the session key, and includes a timestamp. The timestamp 165proves that the message was recently generated and is not a replay. 166Encrypting the authenticator in the session key proves that it was generated 167by a party possessing the session key. Since no one except the requesting 168principal and the server know the session key (it is never sent over the 169network in the clear) this guarantees the identity of the client. 170 171 172 173draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 174 175The integrity of the messages exchanged between principals can also be 176guaranteed using the session key (passed in the ticket and contained in the 177credentials). This approach provides detection of both replay attacks and 178message stream modification attacks. It is accomplished by generating and 179transmitting a collision-proof checksum (elsewhere called a hash or digest 180function) of the client's message, keyed with the session key. Privacy and 181integrity of the messages exchanged between principals can be secured by 182encrypting the data to be passed using the session key contained in the 183ticket or the subsession key found in the authenticator. 184 185The authentication exchanges mentioned above require read-only access to the 186Kerberos database. Sometimes, however, the entries in the database must be 187modified, such as when adding new principals or changing a principal's key. 188This is done using a protocol between a client and a third Kerberos server, 189the Kerberos Administration Server (KADM). There is also a protocol for 190maintaining multiple copies of the Kerberos database. Neither of these 191protocols are described in this document. 192 1931.1. Cross-Realm Operation 194 195The Kerberos protocol is designed to operate across organizational 196boundaries. A client in one organization can be authenticated to a server in 197another. Each organization wishing to run a Kerberos server establishes its 198own 'realm'. The name of the realm in which a client is registered is part 199of the client's name, and can be used by the end-service to decide whether 200to honor a request. 201 202By establishing 'inter-realm' keys, the administrators of two realms can 203allow a client authenticated in the local realm to prove its identity to 204servers in other realms[3]. The exchange of inter-realm keys (a separate key 205may be used for each direction) registers the ticket-granting service of 206each realm as a principal in the other realm. A client is then able to 207obtain a ticket-granting ticket for the remote realm's ticket-granting 208service from its local realm. When that ticket-granting ticket is used, the 209remote ticket-granting service uses the inter-realm key (which usually 210differs from its own normal TGS key) to decrypt the ticket-granting ticket, 211and is thus certain that it was issued by the client's own TGS. Tickets 212issued by the remote ticket-granting service will indicate to the 213end-service that the client was authenticated from another realm. 214 215A realm is said to communicate with another realm if the two realms share an 216inter-realm key, or if the local realm shares an inter-realm key with an 217intermediate realm that communicates with the remote realm. An 218authentication path is the sequence of intermediate realms that are 219transited in communicating from one realm to another. 220 221Realms are typically organized hierarchically. Each realm shares a key with 222its parent and a different key with each child. If an inter-realm key is not 223directly shared by two realms, the hierarchical organization allows an 224authentication path to be easily constructed. If a hierarchical organization 225is not used, it may be necessary to consult a database in order to construct 226an authentication path between realms. 227 228Although realms are typically hierarchical, intermediate realms may be 229 230 231draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 232 233bypassed to achieve cross-realm authentication through alternate 234authentication paths (these might be established to make communication 235between two realms more efficient). It is important for the end-service to 236know which realms were transited when deciding how much faith to place in 237the authentication process. To facilitate this decision, a field in each 238ticket contains the names of the realms that were involved in authenticating 239the client. 240 241The application server is ultimately responsible for accepting or rejecting 242authentication and should check the transited field. The application server 243may choose to rely on the KDC for the application server's realm to check 244the transited field. The application server's KDC will set the 245TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 246realms may also check the transited field as they issue 247ticket-granting-tickets for other realms, but they are encouraged not to do 248so. A client may request that the KDC's not check the transited field by 249setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 250required to honor this flag. 251 2521.2. Authorization 253 254As an authentication service, Kerberos provides a means of verifying the 255identity of principals on a network. Authentication is usually useful 256primarily as a first step in the process of authorization, determining 257whether a client may use a service, which objects the client is allowed to 258access, and the type of access allowed for each. Kerberos does not, by 259itself, provide authorization. Possession of a client ticket for a service 260provides only for authentication of the client to that service, and in the 261absence of a separate authorization procedure, it should not be considered 262by an application as authorizing the use of that service. 263 264Such separate authorization methods may be implemented as application 265specific access control functions and may be based on files such as the 266application server, or on separately issued authorization credentials such 267as those based on proxies [Neu93] , or on other authorization services. 268 269Applications should not be modified to accept the issuance of a service 270ticket by the Kerberos server (even by an modified Kerberos server) as 271granting authority to use the service, since such applications may become 272vulnerable to the bypass of this authorization check in an environment if 273they interoperate with other KDCs or where other options for application 274authentication (e.g. the PKTAPP proposal) are provided. 275 2761.3. Environmental assumptions 277 278Kerberos imposes a few assumptions on the environment in which it can 279properly function: 280 281 * 'Denial of service' attacks are not solved with Kerberos. There are 282 places in these protocols where an intruder can prevent an application 283 from participating in the proper authentication steps. Detection and 284 solution of such attacks (some of which can appear to be nnot-uncommon 285 'normal' failure modes for the system) is usually best left to the 286 human administrators and users. 287 288 289draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 290 291 * Principals must keep their secret keys secret. If an intruder somehow 292 steals a principal's key, it will be able to masquerade as that 293 principal or impersonate any server to the legitimate principal. 294 * 'Password guessing' attacks are not solved by Kerberos. If a user 295 chooses a poor password, it is possible for an attacker to successfully 296 mount an offline dictionary attack by repeatedly attempting to decrypt, 297 with successive entries from a dictionary, messages obtained which are 298 encrypted under a key derived from the user's password. 299 * Each host on the network must have a clock which is 'loosely 300 synchronized' to the time of the other hosts; this synchronization is 301 used to reduce the bookkeeping needs of application servers when they 302 do replay detection. The degree of "looseness" can be configured on a 303 per-server basis, but is typically on the order of 5 minutes. If the 304 clocks are synchronized over the network, the clock synchronization 305 protocol must itself be secured from network attackers. 306 * Principal identifiers are not recycled on a short-term basis. A typical 307 mode of access control will use access control lists (ACLs) to grant 308 permissions to particular principals. If a stale ACL entry remains for 309 a deleted principal and the principal identifier is reused, the new 310 principal will inherit rights specified in the stale ACL entry. By not 311 re-using principal identifiers, the danger of inadvertent access is 312 removed. 313 3141.4. Glossary of terms 315 316Below is a list of terms used throughout this document. 317 318Authentication 319 Verifying the claimed identity of a principal. 320Authentication header 321 A record containing a Ticket and an Authenticator to be presented to a 322 server as part of the authentication process. 323Authentication path 324 A sequence of intermediate realms transited in the authentication 325 process when communicating from one realm to another. 326Authenticator 327 A record containing information that can be shown to have been recently 328 generated using the session key known only by the client and server. 329Authorization 330 The process of determining whether a client may use a service, which 331 objects the client is allowed to access, and the type of access allowed 332 for each. 333Capability 334 A token that grants the bearer permission to access an object or 335 service. In Kerberos, this might be a ticket whose use is restricted by 336 the contents of the authorization data field, but which lists no 337 network addresses, together with the session key necessary to use the 338 ticket. 339Ciphertext 340 The output of an encryption function. Encryption transforms plaintext 341 into ciphertext. 342Client 343 A process that makes use of a network service on behalf of a user. Note 344 that in some cases a Server may itself be a client of some other server 345 346 347draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 348 349 (e.g. a print server may be a client of a file server). 350Credentials 351 A ticket plus the secret session key necessary to successfully use that 352 ticket in an authentication exchange. 353KDC 354 Key Distribution Center, a network service that supplies tickets and 355 temporary session keys; or an instance of that service or the host on 356 which it runs. The KDC services both initial ticket and ticket-granting 357 ticket requests. The initial ticket portion is sometimes referred to as 358 the Authentication Server (or service). The ticket-granting ticket 359 portion is sometimes referred to as the ticket-granting server (or 360 service). 361Kerberos 362 Aside from the 3-headed dog guarding Hades, the name given to Project 363 Athena's authentication service, the protocol used by that service, or 364 the code used to implement the authentication service. 365Plaintext 366 The input to an encryption function or the output of a decryption 367 function. Decryption transforms ciphertext into plaintext. 368Principal 369 A uniquely named client or server instance that participates in a 370 network communication. 371Principal identifier 372 The name used to uniquely identify each different principal. 373Seal 374 To encipher a record containing several fields in such a way that the 375 fields cannot be individually replaced without either knowledge of the 376 encryption key or leaving evidence of tampering. 377Secret key 378 An encryption key shared by a principal and the KDC, distributed 379 outside the bounds of the system, with a long lifetime. In the case of 380 a human user's principal, the secret key is derived from a password. 381Server 382 A particular Principal which provides a resource to network clients. 383 The server is sometimes refered to as the Application Server. 384Service 385 A resource provided to network clients; often provided by more than one 386 server (for example, remote file service). 387Session key 388 A temporary encryption key used between two principals, with a lifetime 389 limited to the duration of a single login "session". 390Sub-session key 391 A temporary encryption key used between two principals, selected and 392 exchanged by the principals using the session key, and with a lifetime 393 limited to the duration of a single association. 394Ticket 395 A record that helps a client authenticate itself to a server; it 396 contains the client's identity, a session key, a timestamp, and other 397 information, all sealed using the server's secret key. It only serves 398 to authenticate a client when presented along with a fresh 399 Authenticator. 400 4012. Ticket flag uses and requests 402 403 404 405draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 406 407Each Kerberos ticket contains a set of flags which are used to indicate 408various attributes of that ticket. Most flags may be requested by a client 409when the ticket is obtained; some are automatically turned on and off by a 410Kerberos server as required. The following sections explain what the various 411flags mean, and gives examples of reasons to use such a flag. 412 4132.1. Initial and pre-authenticated tickets 414 415The INITIAL flag indicates that a ticket was issued using the AS protocol 416and not issued based on a ticket-granting ticket. Application servers that 417want to require the demonstrated knowledge of a client's secret key (e.g. a 418password-changing program) can insist that this flag be set in any tickets 419they accept, and thus be assured that the client's key was recently 420presented to the application client. 421 422The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the 423initial authentication, regardless of whether the current ticket was issued 424directly (in which case INITIAL will also be set) or issued on the basis of 425a ticket-granting ticket (in which case the INITIAL flag is clear, but the 426PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 427ticket-granting ticket). 428 4292.2. Invalid tickets 430 431The INVALID flag indicates that a ticket is invalid. Application servers 432must reject tickets which have this flag set. A postdated ticket will 433usually be issued in this form. Invalid tickets must be validated by the KDC 434before use, by presenting them to the KDC in a TGS request with the VALIDATE 435option specified. The KDC will only validate tickets after their starttime 436has passed. The validation is required so that postdated tickets which have 437been stolen before their starttime can be rendered permanently invalid 438(through a hot-list mechanism) (see section 3.3.3.1). 439 4402.3. Renewable tickets 441 442Applications may desire to hold tickets which can be valid for long periods 443of time. However, this can expose their credentials to potential theft for 444equally long periods, and those stolen credentials would be valid until the 445expiration time of the ticket(s). Simply using short-lived tickets and 446obtaining new ones periodically would require the client to have long-term 447access to its secret key, an even greater risk. Renewable tickets can be 448used to mitigate the consequences of theft. Renewable tickets have two 449"expiration times": the first is when the current instance of the ticket 450expires, and the second is the latest permissible value for an individual 451expiration time. An application client must periodically (i.e. before it 452expires) present a renewable ticket to the KDC, with the RENEW option set in 453the KDC request. The KDC will issue a new ticket with a new session key and 454a later expiration time. All other fields of the ticket are left unmodified 455by the renewal process. When the latest permissible expiration time arrives, 456the ticket expires permanently. At each renewal, the KDC may consult a 457hot-list to determine if the ticket had been reported stolen since its last 458renewal; it will refuse to renew such stolen tickets, and thus the usable 459lifetime of stolen tickets is reduced. 460 461 462 463draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 464 465The RENEWABLE flag in a ticket is normally only interpreted by the 466ticket-granting service (discussed below in section 3.3). It can usually be 467ignored by application servers. However, some particularly careful 468application servers may wish to disallow renewable tickets. 469 470If a renewable ticket is not renewed by its expiration time, the KDC will 471not renew the ticket. The RENEWABLE flag is reset by default, but a client 472may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 473message. If it is set, then the renew-till field in the ticket contains the 474time after which the ticket may not be renewed. 475 4762.4. Postdated tickets 477 478Applications may occasionally need to obtain tickets for use much later, 479e.g. a batch submission system would need tickets to be valid at the time 480the batch job is serviced. However, it is dangerous to hold valid tickets in 481a batch queue, since they will be on-line longer and more prone to theft. 482Postdated tickets provide a way to obtain these tickets from the KDC at job 483submission time, but to leave them "dormant" until they are activated and 484validated by a further request of the KDC. If a ticket theft were reported 485in the interim, the KDC would refuse to validate the ticket, and the thief 486would be foiled. 487 488The MAY-POSTDATE flag in a ticket is normally only interpreted by the 489ticket-granting service. It can be ignored by application servers. This flag 490must be set in a ticket-granting ticket in order to issue a postdated ticket 491based on the presented ticket. It is reset by default; it may be requested 492by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 493This flag does not allow a client to obtain a postdated ticket-granting 494ticket; postdated ticket-granting tickets can only by obtained by requesting 495the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 496postdated ticket will be the remaining life of the ticket-granting ticket at 497the time of the request, unless the RENEWABLE option is also set, in which 498case it can be the full life (endtime-starttime) of the ticket-granting 499ticket. The KDC may limit how far in the future a ticket may be postdated. 500 501The POSTDATED flag indicates that a ticket has been postdated. The 502application server can check the authtime field in the ticket to see when 503the original authentication occurred. Some services may choose to reject 504postdated tickets, or they may only accept them within a certain period 505after the original authentication. When the KDC issues a POSTDATED ticket, 506it will also be marked as INVALID, so that the application client must 507present the ticket to the KDC to be validated before use. 508 5092.5. Proxiable and proxy tickets 510 511At times it may be necessary for a principal to allow a service to perform 512an operation on its behalf. The service must be able to take on the identity 513of the client, but only for a particular purpose. A principal can allow a 514service to take on the principal's identity for a particular purpose by 515granting it a proxy. 516 517The process of granting a proxy using the proxy and proxiable flags is used 518to provide credentials for use with specific services. Though conceptually 519 520 521draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 522 523also a proxy, user's wishing to delegate their identity for ANY purpose must 524use the ticket forwarding mechanism described in the next section to forward 525a ticket granting ticket. 526 527The PROXIABLE flag in a ticket is normally only interpreted by the 528ticket-granting service. It can be ignored by application servers. When set, 529this flag tells the ticket-granting server that it is OK to issue a new 530ticket (but not a ticket-granting ticket) with a different network address 531based on this ticket. This flag is set if requested by the client on initial 532authentication. By default, the client will request that it be set when 533requesting a ticket granting ticket, and reset when requesting any other 534ticket. 535 536This flag allows a client to pass a proxy to a server to perform a remote 537request on its behalf, e.g. a print service client can give the print server 538a proxy to access the client's files on a particular file server in order to 539satisfy a print request. 540 541In order to complicate the use of stolen credentials, Kerberos tickets are 542usually valid from only those network addresses specifically included in the 543ticket[4]. When granting a proxy, the client must specify the new network 544address from which the proxy is to be used, or indicate that the proxy is to 545be issued for use from any address. 546 547The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 548Application servers may check this flag and at their option they may require 549additional authentication from the agent presenting the proxy in order to 550provide an audit trail. 551 5522.6. Forwardable tickets 553 554Authentication forwarding is an instance of a proxy where the service is 555granted complete use of the client's identity. An example where it might be 556used is when a user logs in to a remote system and wants authentication to 557work from that system as if the login were local. 558 559The FORWARDABLE flag in a ticket is normally only interpreted by the 560ticket-granting service. It can be ignored by application servers. The 561FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 562flag, except ticket-granting tickets may also be issued with different 563network addresses. This flag is reset by default, but users may request that 564it be set by setting the FORWARDABLE option in the AS request when they 565request their initial ticket- granting ticket. 566 567This flag allows for authentication forwarding without requiring the user to 568enter a password again. If the flag is not set, then authentication 569forwarding is not permitted, but the same result can still be achieved if 570the user engages in the AS exchange specifying the requested network 571addresses and supplies a password. 572 573The FORWARDED flag is set by the TGS when a client presents a ticket with 574the FORWARDABLE flag set and requests a forwarded ticket by specifying the 575FORWARDED KDC option and supplying a set of addresses for the new ticket. It 576is also set in all tickets issued based on tickets with the FORWARDED flag 577 578 579draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 580 581set. Application servers may choose to process FORWARDED tickets differently 582than non-FORWARDED tickets. 583 5842.7. Other KDC options 585 586There are two additional options which may be set in a client's request of 587the KDC. The RENEWABLE-OK option indicates that the client will accept a 588renewable ticket if a ticket with the requested life cannot otherwise be 589provided. If a ticket with the requested life cannot be provided, then the 590KDC may issue a renewable ticket with a renew-till equal to the the 591requested endtime. The value of the renew-till field may still be adjusted 592by site-determined limits or limits imposed by the individual principal or 593server. 594 595The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. 596It indicates that the ticket to be issued for the end server is to be 597encrypted in the session key from the a additional second ticket-granting 598ticket provided with the request. See section 3.3.3 for specific details. 599 6003. Message Exchanges 601 602The following sections describe the interactions between network clients and 603servers and the messages involved in those exchanges. 604 6053.1. The Authentication Service Exchange 606 607 Summary 608 Message direction Message type Section 609 1. Client to Kerberos KRB_AS_REQ 5.4.1 610 2. Kerberos to client KRB_AS_REP or 5.4.2 611 KRB_ERROR 5.9.1 612 613The Authentication Service (AS) Exchange between the client and the Kerberos 614Authentication Server is initiated by a client when it wishes to obtain 615authentication credentials for a given server but currently holds no 616credentials. In its basic form, the client's secret key is used for 617encryption and decryption. This exchange is typically used at the initiation 618of a login session to obtain credentials for a Ticket-Granting Server which 619will subsequently be used to obtain credentials for other servers (see 620section 3.3) without requiring further use of the client's secret key. This 621exchange is also used to request credentials for services which must not be 622mediated through the Ticket-Granting Service, but rather require a 623principal's secret key, such as the password-changing service[5]. This 624exchange does not by itself provide any assurance of the the identity of the 625user[6]. 626 627The exchange consists of two messages: KRB_AS_REQ from the client to 628Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 629messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 630 631In the request, the client sends (in cleartext) its own identity and the 632identity of the server for which it is requesting credentials. The response, 633KRB_AS_REP, contains a ticket for the client to present to the server, and a 634session key that will be shared by the client and the server. The session 635 636 637draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 638 639key and additional information are encrypted in the client's secret key. The 640KRB_AS_REP message contains information which can be used to detect replays, 641and to associate it with the message to which it replies. Various errors can 642occur; these are indicated by an error response (KRB_ERROR) instead of the 643KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR 644message contains information which can be used to associate it with the 645message to which it replies. The lack of encryption in the KRB_ERROR message 646precludes the ability to detect replays, fabrications, or modifications of 647such messages. 648 649Without preautentication, the authentication server does not know whether 650the client is actually the principal named in the request. It simply sends a 651reply without knowing or caring whether they are the same. This is 652acceptable because nobody but the principal whose identity was given in the 653request will be able to use the reply. Its critical information is encrypted 654in that principal's key. The initial request supports an optional field that 655can be used to pass additional information that might be needed for the 656initial exchange. This field may be used for preauthentication as described 657in section [hl<>]. 658 6593.1.1. Generation of KRB_AS_REQ message 660 661The client may specify a number of options in the initial request. Among 662these options are whether pre-authentication is to be performed; whether the 663requested ticket is to be renewable, proxiable, or forwardable; whether it 664should be postdated or allow postdating of derivative tickets; and whether a 665renewable ticket will be accepted in lieu of a non-renewable ticket if the 666requested ticket expiration date cannot be satisfied by a non-renewable 667ticket (due to configuration constraints; see section 4). See section A.1 668for pseudocode. 669 670The client prepares the KRB_AS_REQ message and sends it to the KDC. 671 6723.1.2. Receipt of KRB_AS_REQ message 673 674If all goes well, processing the KRB_AS_REQ message will result in the 675creation of a ticket for the client to present to the server. The format for 676the ticket is described in section 5.3.1. The contents of the ticket are 677determined as follows. 678 6793.1.3. Generation of KRB_AS_REP message 680 681The authentication server looks up the client and server principals named in 682the KRB_AS_REQ in its database, extracting their respective keys. If 683required, the server pre-authenticates the request, and if the 684pre-authentication check fails, an error message with the code 685KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the 686requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP 687is returned. Otherwise it generates a 'random' session key[7]. 688 689If there are multiple encryption keys registered for a client in the 690Kerberos database (or if the key registered supports multiple encryption 691types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS 692request is used by the KDC to select the encryption method to be used for 693 694 695draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 696 697encrypting the response to the client. If there is more than one supported, 698strong encryption type in the etype list, the first valid etype for which an 699encryption key is available is used. The encryption method used to respond 700to a TGS request is taken from the keytype of the session key found in the 701ticket granting ticket. 702 703When the etype field is present in a KDC request, whether an AS or TGS 704request, the KDC will attempt to assign the type of the random session key 705from the list of methods in the etype field. The KDC will select the 706appropriate type using the list of methods provided together with 707information from the Kerberos database indicating acceptable encryption 708methods for the application server. The KDC will not issue tickets with a 709weak session key encryption type. 710 711If the requested start time is absent, indicates a time in the past, or is 712within the window of acceptable clock skew for the KDC and the POSTDATE 713option has not been specified, then the start time of the ticket is set to 714the authentication server's current time. If it indicates a time in the 715future beyond the acceptable clock skew, but the POSTDATED option has not 716been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise 717the requested start time is checked against the policy of the local realm 718(the administrator might decide to prohibit certain types or ranges of 719postdated tickets), and if acceptable, the ticket's start time is set as 720requested and the INVALID flag is set in the new ticket. The postdated 721ticket must be validated before use by presenting it to the KDC after the 722start time has been reached. 723 724The expiration time of the ticket will be set to the minimum of the 725following: 726 727 * The expiration time (endtime) requested in the KRB_AS_REQ message. 728 * The ticket's start time plus the maximum allowable lifetime associated 729 with the client principal (the authentication server's database 730 includes a maximum ticket lifetime field in each principal's record; 731 see section 4). 732 * The ticket's start time plus the maximum allowable lifetime associated 733 with the server principal. 734 * The ticket's start time plus the maximum lifetime set by the policy of 735 the local realm. 736 737If the requested expiration time minus the start time (as determined above) 738is less than a site-determined minimum lifetime, an error message with code 739KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the 740ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' 741option was requested, then the 'RENEWABLE' flag is set in the new ticket, 742and the renew-till value is set as if the 'RENEWABLE' option were requested 743(the field and option names are described fully in section 5.4.1). 744 745If the RENEWABLE option has been requested or if the RENEWABLE-OK option has 746been set and a renewable ticket is to be issued, then the renew-till field 747is set to the minimum of: 748 749 * Its requested value. 750 * The start time of the ticket plus the minimum of the two maximum 751 752 753draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 754 755 renewable lifetimes associated with the principals' database entries. 756 * The start time of the ticket plus the maximum renewable lifetime set by 757 the policy of the local realm. 758 759The flags field of the new ticket will have the following options set if 760they have been requested and if the policy of the local realm allows: 761FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new 762ticket is post-dated (the start time is in the future), its INVALID flag 763will also be set. 764 765If all of the above succeed, the server formats a KRB_AS_REP message (see 766section 5.4.2), copying the addresses in the request into the caddr of the 767response, placing any required pre-authentication data into the padata of 768the response, and encrypts the ciphertext part in the client's key using the 769requested encryption method, and sends it to the client. See section A.2 for 770pseudocode. 771 7723.1.4. Generation of KRB_ERROR message 773 774Several errors can occur, and the Authentication Server responds by 775returning an error message, KRB_ERROR, to the client, with the error-code 776and e-text fields set to appropriate values. The error message contents and 777details are described in Section 5.9.1. 778 7793.1.5. Receipt of KRB_AS_REP message 780 781If the reply message type is KRB_AS_REP, then the client verifies that the 782cname and crealm fields in the cleartext portion of the reply match what it 783requested. If any padata fields are present, they may be used to derive the 784proper secret key to decrypt the message. The client decrypts the encrypted 785part of the response using its secret key, verifies that the nonce in the 786encrypted part matches the nonce it supplied in its request (to detect 787replays). It also verifies that the sname and srealm in the response match 788those in the request (or are otherwise expected values), and that the host 789address field is also correct. It then stores the ticket, session key, start 790and expiration times, and other information for later use. The 791key-expiration field from the encrypted part of the response may be checked 792to notify the user of impending key expiration (the client program could 793then suggest remedial action, such as a password change). See section A.3 794for pseudocode. 795 796Proper decryption of the KRB_AS_REP message is not sufficient to verify the 797identity of the user; the user and an attacker could cooperate to generate a 798KRB_AS_REP format message which decrypts properly but is not from the proper 799KDC. If the host wishes to verify the identity of the user, it must require 800the user to present application credentials which can be verified using a 801securely-stored secret key for the host. If those credentials can be 802verified, then the identity of the user can be assured. 803 8043.1.6. Receipt of KRB_ERROR message 805 806If the reply message type is KRB_ERROR, then the client interprets it as an 807error and performs whatever application-specific tasks are necessary to 808recover. 809 810 811draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 812 813 8143.2. The Client/Server Authentication Exchange 815 816 Summary 817Message direction Message type Section 818Client to Application server KRB_AP_REQ 5.5.1 819[optional] Application server to client KRB_AP_REP or 5.5.2 820 KRB_ERROR 5.9.1 821 822The client/server authentication (CS) exchange is used by network 823applications to authenticate the client to the server and vice versa. The 824client must have already acquired credentials for the server using the AS or 825TGS exchange. 826 8273.2.1. The KRB_AP_REQ message 828 829The KRB_AP_REQ contains authentication information which should be part of 830the first message in an authenticated transaction. It contains a ticket, an 831authenticator, and some additional bookkeeping information (see section 8325.5.1 for the exact format). The ticket by itself is insufficient to 833authenticate a client, since tickets are passed across the network in 834cleartext[DS90], so the authenticator is used to prevent invalid replay of 835tickets by proving to the server that the client knows the session key of 836the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is 837referred to elsewhere as the 'authentication header.' 838 8393.2.2. Generation of a KRB_AP_REQ message 840 841When a client wishes to initiate authentication to a server, it obtains 842(either through a credentials cache, the AS exchange, or the TGS exchange) a 843ticket and session key for the desired service. The client may re-use any 844tickets it holds until they expire. To use a ticket the client constructs a 845new Authenticator from the the system time, its name, and optionally an 846application specific checksum, an initial sequence number to be used in 847KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in 848negotiations for a session key unique to this particular session. 849Authenticators may not be re-used and will be rejected if replayed to a 850server[LGDSR87]. If a sequence number is to be included, it should be 851randomly chosen so that even after many messages have been exchanged it is 852not likely to collide with other sequence numbers in use. 853 854The client may indicate a requirement of mutual authentication or the use of 855a session-key based ticket by setting the appropriate flag(s) in the 856ap-options field of the message. 857 858The Authenticator is encrypted in the session key and combined with the 859ticket to form the KRB_AP_REQ message which is then sent to the end server 860along with any additional application-specific information. See section A.9 861for pseudocode. 862 8633.2.3. Receipt of KRB_AP_REQ message 864 865Authentication is based on the server's current time of day (clocks must be 866loosely synchronized), the authenticator, and the ticket. Several errors are 867 868 869draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 870 871possible. If an error occurs, the server is expected to reply to the client 872with a KRB_ERROR message. This message may be encapsulated in the 873application protocol if its 'raw' form is not acceptable to the protocol. 874The format of error messages is described in section 5.9.1. 875 876The algorithm for verifying authentication information is as follows. If the 877message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE 878error. If the key version indicated by the Ticket in the KRB_AP_REQ is not 879one the server can use (e.g., it indicates an old key, and the server no 880longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is 881returned. If the USE-SESSION-KEY flag is set in the ap-options field, it 882indicates to the server that the ticket is encrypted in the session key from 883the server's ticket-granting ticket rather than its secret key[10]. Since it 884is possible for the server to be registered in multiple realms, with 885different keys in each, the srealm field in the unencrypted portion of the 886ticket in the KRB_AP_REQ is used to specify which secret key the server 887should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is 888returned if the server doesn't have the proper key to decipher the ticket. 889 890The ticket is decrypted using the version of the server's key specified by 891the ticket. If the decryption routines detect a modification of the ticket 892(each encryption system must provide safeguards to detect modified 893ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned 894(chances are good that different keys were used to encrypt and decrypt). 895 896The authenticator is decrypted using the session key extracted from the 897decrypted ticket. If decryption shows it to have been modified, the 898KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client 899from the ticket are compared against the same fields in the authenticator. 900If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might 901not match, for example, if the wrong session key was used to encrypt the 902authenticator). The addresses in the ticket (if any) are then searched for 903an address matching the operating-system reported address of the client. If 904no match is found or the server insists on ticket addresses but none are 905present in the ticket, the KRB_AP_ERR_BADADDR error is returned. 906 907If the local (server) time and the client time in the authenticator differ 908by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW 909error is returned. If the server name, along with the client name, time and 910microsecond fields from the Authenticator match any recently-seen such 911tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must 912remember any authenticator presented within the allowable clock skew, so 913that a replay attempt is guaranteed to fail. If a server loses track of any 914authenticator presented within the allowable clock skew, it must reject all 915requests until the clock skew interval has passed. This assures that any 916lost or re-played authenticators will fall outside the allowable clock skew 917and can no longer be successfully replayed (If this is not done, an attacker 918could conceivably record the ticket and authenticator sent over the network 919to a server, then disable the client's host, pose as the disabled host, and 920replay the ticket and authenticator to subvert the authentication.). If a 921sequence number is provided in the authenticator, the server saves it for 922later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is 923present, the server either saves it for later use or uses it to help 924generate its own choice for a subkey to be returned in a KRB_AP_REP message. 925 926 927draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 928 929 930The server computes the age of the ticket: local (server) time minus the 931start time inside the Ticket. If the start time is later than the current 932time by more than the allowable clock skew or if the INVALID flag is set in 933the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the 934current time is later than end time by more than the allowable clock skew, 935the KRB_AP_ERR_TKT_EXPIRED error is returned. 936 937If all these checks succeed without an error, the server is assured that the 938client possesses the credentials of the principal named in the ticket and 939thus, the client has been authenticated to the server. See section A.10 for 940pseudocode. 941 942Passing these checks provides only authentication of the named principal; it 943does not imply authorization to use the named service. Applications must 944make a separate authorization decisions based upon the authenticated name of 945the user, the requested operation, local acces control information such as 946that contained in a .k5login or .k5users file, and possibly a separate 947distributed authorization service. 948 9493.2.4. Generation of a KRB_AP_REP message 950 951Typically, a client's request will include both the authentication 952information and its initial request in the same message, and the server need 953not explicitly reply to the KRB_AP_REQ. However, if mutual authentication 954(not only authenticating the client to the server, but also the server to 955the client) is being performed, the KRB_AP_REQ message will have 956MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is 957required in response. As with the error message, this message may be 958encapsulated in the application protocol if its "raw" form is not acceptable 959to the application's protocol. The timestamp and microsecond field used in 960the reply must be the client's timestamp and microsecond field (as provided 961in the authenticator)[12]. If a sequence number is to be included, it should 962be randomly chosen as described above for the authenticator. A subkey may be 963included if the server desires to negotiate a different subkey. The 964KRB_AP_REP message is encrypted in the session key extracted from the 965ticket. See section A.11 for pseudocode. 966 9673.2.5. Receipt of KRB_AP_REP message 968 969If a KRB_AP_REP message is returned, the client uses the session key from 970the credentials obtained for the server[13] to decrypt the message, and 971verifies that the timestamp and microsecond fields match those in the 972Authenticator it sent to the server. If they match, then the client is 973assured that the server is genuine. The sequence number and subkey (if 974present) are retained for later use. See section A.12 for pseudocode. 975 9763.2.6. Using the encryption key 977 978After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server 979share an encryption key which can be used by the application. The 'true 980session key' to be used for KRB_PRIV, KRB_SAFE, or other 981application-specific uses may be chosen by the application based on the 982subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, 983 984 985draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 986 987the use of this session key will be implicit in the protocol; in others the 988method of use must be chosen from several alternatives. We leave the 989protocol negotiations of how to use the key (e.g. selecting an encryption or 990checksum type) to the application programmer; the Kerberos protocol does not 991constrain the implementation options, but an example of how this might be 992done follows. 993 994One way that an application may choose to negotiate a key to be used for 995subequent integrity and privacy protection is for the client to propose a 996key in the subkey field of the authenticator. The server can then choose a 997key using the proposed key from the client as input, returning the new 998subkey in the subkey field of the application reply. This key could then be 999used for subsequent communication. To make this example more concrete, if 1000the encryption method in use required a 56 bit key, and for whatever reason, 1001one of the parties was prevented from using a key with more than 40 unknown 1002bits, this method would allow the the party which is prevented from using 1003more than 40 bits to either propose (if the client) an initial key with a 1004known quantity for 16 of those bits, or to mask 16 of the bits (if the 1005server) with the known quantity. The application implementor is warned, 1006however, that this is only an example, and that an analysis of the 1007particular crytosystem to be used, and the reasons for limiting the key 1008length, must be made before deciding whether it is acceptable to mask bits 1009of the key. 1010 1011With both the one-way and mutual authentication exchanges, the peers should 1012take care not to send sensitive information to each other without proper 1013assurances. In particular, applications that require privacy or integrity 1014should use the KRB_AP_REP response from the server to client to assure both 1015client and server of their peer's identity. If an application protocol 1016requires privacy of its messages, it can use the KRB_PRIV message (section 10173.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 1018 10193.3. The Ticket-Granting Service (TGS) Exchange 1020 1021 Summary 1022 Message direction Message type Section 1023 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1024 2. Kerberos to client KRB_TGS_REP or 5.4.2 1025 KRB_ERROR 5.9.1 1026 1027The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1028initiated by a client when it wishes to obtain authentication credentials 1029for a given server (which might be registered in a remote realm), when it 1030wishes to renew or validate an existing ticket, or when it wishes to obtain 1031a proxy ticket. In the first case, the client must already have acquired a 1032ticket for the Ticket-Granting Service using the AS exchange (the 1033ticket-granting ticket is usually obtained when a client initially 1034authenticates to the system, such as when a user logs in). The message 1035format for the TGS exchange is almost identical to that for the AS exchange. 1036The primary difference is that encryption and decryption in the TGS exchange 1037does not take place under the client's key. Instead, the session key from 1038the ticket-granting ticket or renewable ticket, or sub-session key from an 1039Authenticator is used. As is the case for all application servers, expired 1040tickets are not accepted by the TGS, so once a renewable or ticket-granting 1041 1042 1043draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1044 1045ticket expires, the client must use a separate exchange to obtain valid 1046tickets. 1047 1048The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1049client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1050KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1051client plus a request for credentials. The authentication information 1052consists of the authentication header (KRB_AP_REQ) which includes the 1053client's previously obtained ticket-granting, renewable, or invalid ticket. 1054In the ticket-granting ticket and proxy cases, the request may include one 1055or more of: a list of network addresses, a collection of typed authorization 1056data to be sealed in the ticket for authorization use by the application 1057server, or additional tickets (the use of which are described later). The 1058TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1059session key from the ticket-granting ticket or renewable ticket, or if 1060present, in the sub-session key from the Authenticator (part of the 1061authentication header). The KRB_ERROR message contains an error code and 1062text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1063KRB_TGS_REP message contains information which can be used to detect 1064replays, and to associate it with the message to which it replies. The 1065KRB_ERROR message also contains information which can be used to associate 1066it with the message to which it replies, but the lack of encryption in the 1067KRB_ERROR message precludes the ability to detect replays or fabrications of 1068such messages. 1069 10703.3.1. Generation of KRB_TGS_REQ message 1071 1072Before sending a request to the ticket-granting service, the client must 1073determine in which realm the application server is registered[15]. If the 1074client does not already possess a ticket-granting ticket for the appropriate 1075realm, then one must be obtained. This is first attempted by requesting a 1076ticket-granting ticket for the destination realm from a Kerberos server for 1077which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ 1078message recursively). The Kerberos server may return a TGT for the desired 1079realm in which case one can proceed. Alternatively, the Kerberos server may 1080return a TGT for a realm which is 'closer' to the desired realm (further 1081along the standard hierarchical path), in which case this step must be 1082repeated with a Kerberos server in the realm specified in the returned TGT. 1083If neither are returned, then the request must be retried with a Kerberos 1084server for a realm higher in the hierarchy. This request will itself require 1085a ticket-granting ticket for the higher realm which must be obtained by 1086recursively applying these directions. 1087 1088Once the client obtains a ticket-granting ticket for the appropriate realm, 1089it determines which Kerberos servers serve that realm, and contacts one. The 1090list might be obtained through a configuration file or network service or it 1091may be generated from the name of the realm; as long as the secret keys 1092exchanged by realms are kept secret, only denial of service results from 1093using a false Kerberos server. 1094 1095As in the AS exchange, the client may specify a number of options in the 1096KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing 1097an authentication header as an element of the padata field, and including 1098the same fields as used in the KRB_AS_REQ message along with several 1099 1100 1101draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1102 1103optional fields: the enc-authorization-data field for application server use 1104and additional tickets required by some options. 1105 1106In preparing the authentication header, the client can select a sub-session 1107key under which the response from the Kerberos server will be encrypted[16]. 1108If the sub-session key is not specified, the session key from the 1109ticket-granting ticket will be used. If the enc-authorization-data is 1110present, it must be encrypted in the sub-session key, if present, from the 1111authenticator portion of the authentication header, or if not present, using 1112the session key from the ticket-granting ticket. 1113 1114Once prepared, the message is sent to a Kerberos server for the destination 1115realm. See section A.5 for pseudocode. 1116 11173.3.2. Receipt of KRB_TGS_REQ message 1118 1119The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1120message, but there are many additional checks to be performed. First, the 1121Kerberos server must determine which server the accompanying ticket is for 1122and it must select the appropriate key to decrypt it. For a normal 1123KRB_TGS_REQ message, it will be for the ticket granting service, and the 1124TGS's key will be used. If the TGT was issued by another realm, then the 1125appropriate inter-realm key must be used. If the accompanying ticket is not 1126a ticket granting ticket for the current realm, but is for an application 1127server in the current realm, the RENEW, VALIDATE, or PROXY options are 1128specified in the request, and the server for which a ticket is requested is 1129the server named in the accompanying ticket, then the KDC will decrypt the 1130ticket in the authentication header using the key of the server for which it 1131was issued. If no ticket can be found in the padata field, the 1132KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1133 1134Once the accompanying ticket has been decrypted, the user-supplied checksum 1135in the Authenticator must be verified against the contents of the request, 1136and the message rejected if the checksums do not match (with an error code 1137of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1138collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1139checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1140returned. If the authorization-data are present, they are decrypted using 1141the sub-session key from the Authenticator. 1142 1143If any of the decryptions indicate failed integrity checks, the 1144KRB_AP_ERR_BAD_INTEGRITY error is returned. 1145 11463.3.3. Generation of KRB_TGS_REP message 1147 1148The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1149but with its type field set to KRB_TGS_REP. The detailed specification is in 1150section 5.4.2. 1151 1152The response will include a ticket for the requested server. The Kerberos 1153database is queried to retrieve the record for the requested server 1154(including the key with which the ticket will be encrypted). If the request 1155is for a ticket granting ticket for a remote realm, and if no key is shared 1156with the requested realm, then the Kerberos server will select the realm 1157 1158 1159draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1160 1161"closest" to the requested realm with which it does share a key, and use 1162that realm instead. This is the only case where the response from the KDC 1163will be for a different server than that requested by the client. 1164 1165By default, the address field, the client's name and realm, the list of 1166transited realms, the time of initial authentication, the expiration time, 1167and the authorization data of the newly-issued ticket will be copied from 1168the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1169needs to be updated, but the transited type is not supported, the 1170KDC_ERR_TRTYPE_NOSUPP error is returned. 1171 1172If the request specifies an endtime, then the endtime of the new ticket is 1173set to the minimum of (a) that request, (b) the endtime from the TGT, and 1174(c) the starttime of the TGT plus the minimum of the maximum life for the 1175application server and the maximum life for the local realm (the maximum 1176life for the requesting principal was already applied when the TGT was 1177issued). If the new ticket is to be a renewal, then the endtime above is 1178replaced by the minimum of (a) the value of the renew_till field of the 1179ticket and (b) the starttime for the new ticket plus the life 1180(endtime-starttime) of the old ticket. 1181 1182If the FORWARDED option has been requested, then the resulting ticket will 1183contain the addresses specified by the client. This option will only be 1184honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1185similar; the resulting ticket will contain the addresses specified by the 1186client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1187PROXY option will not be honored on requests for additional ticket-granting 1188tickets. 1189 1190If the requested start time is absent, indicates a time in the past, or is 1191within the window of acceptable clock skew for the KDC and the POSTDATE 1192option has not been specified, then the start time of the ticket is set to 1193the authentication server's current time. If it indicates a time in the 1194future beyond the acceptable clock skew, but the POSTDATED option has not 1195been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1196error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1197ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1198postdated and the requested starttime is checked against the policy of the 1199local realm. If acceptable, the ticket's start time is set as requested, and 1200the INVALID flag is set. The postdated ticket must be validated before use 1201by presenting it to the KDC after the starttime has been reached. However, 1202in no case may the starttime, endtime, or renew-till time of a newly-issued 1203postdated ticket extend beyond the renew-till time of the ticket-granting 1204ticket. 1205 1206If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1207has been included in the request, the KDC will decrypt the additional ticket 1208using the key for the server to which the additional ticket was issued and 1209verify that it is a ticket-granting ticket. If the name of the requested 1210server is missing from the request, the name of the client in the additional 1211ticket will be used. Otherwise the name of the requested server will be 1212compared to the name of the client in the additional ticket and if 1213different, the request will be rejected. If the request succeeds, the 1214session key from the additional ticket will be used to encrypt the new 1215 1216 1217draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1218 1219ticket that is issued instead of using the key of the server for which the 1220new ticket will be used[17]. 1221 1222If the name of the server in the ticket that is presented to the KDC as part 1223of the authentication header is not that of the ticket-granting server 1224itself, the server is registered in the realm of the KDC, and the RENEW 1225option is requested, then the KDC will verify that the RENEWABLE flag is set 1226in the ticket, that the INVALID flag is not set in the ticket, and that the 1227renew_till time is still in the future. If the VALIDATE option is rqeuested, 1228the KDC will check that the starttime has passed and the INVALID flag is 1229set. If the PROXY option is requested, then the KDC will check that the 1230PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1231passes the hotlist check described in the next paragraph, the KDC will issue 1232the appropriate new ticket. 1233 12343.3.3.1. Checking for revoked tickets 1235 1236Whenever a request is made to the ticket-granting server, the presented 1237ticket(s) is(are) checked against a hot-list of tickets which have been 1238canceled. This hot-list might be implemented by storing a range of issue 1239timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1240that range, it would be rejected. In this way, a stolen ticket-granting 1241ticket or renewable ticket cannot be used to gain additional tickets 1242(renewals or otherwise) once the theft has been reported. Any normal ticket 1243obtained before it was reported stolen will still be valid (because they 1244require no interaction with the KDC), but only until their normal expiration 1245time. 1246 1247The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1248in the sub-session key from the Authenticator, if present, or the session 1249key key from the ticket-granting ticket. It is not encrypted using the 1250client's secret key. Furthermore, the client's key's expiration date and the 1251key version number fields are left out since these values are stored along 1252with the client's database record, and that record is not needed to satisfy 1253a request based on a ticket-granting ticket. See section A.6 for pseudocode. 1254 12553.3.3.2. Encoding the transited field 1256 1257If the identity of the server in the TGT that is presented to the KDC as 1258part of the authentication header is that of the ticket-granting service, 1259but the TGT was issued from another realm, the KDC will look up the 1260inter-realm key shared with that realm and use that key to decrypt the 1261ticket. If the ticket is valid, then the KDC will honor the request, subject 1262to the constraints outlined above in the section describing the AS exchange. 1263The realm part of the client's identity will be taken from the 1264ticket-granting ticket. The name of the realm that issued the 1265ticket-granting ticket will be added to the transited field of the ticket to 1266be issued. This is accomplished by reading the transited field from the 1267ticket-granting ticket (which is treated as an unordered set of realm 1268names), adding the new realm to the set, then constructing and writing out 1269its encoded (shorthand) form (this may involve a rearrangement of the 1270existing encoding). 1271 1272Note that the ticket-granting service does not add the name of its own 1273 1274 1275draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1276 1277realm. Instead, its responsibility is to add the name of the previous realm. 1278This prevents a malicious Kerberos server from intentionally leaving out its 1279own name (it could, however, omit other realms' names). 1280 1281The names of neither the local realm nor the principal's realm are to be 1282included in the transited field. They appear elsewhere in the ticket and 1283both are known to have taken part in authenticating the principal. Since the 1284endpoints are not included, both local and single-hop inter-realm 1285authentication result in a transited field that is empty. 1286 1287Because the name of each realm transited is added to this field, it might 1288potentially be very long. To decrease the length of this field, its contents 1289are encoded. The initially supported encoding is optimized for the normal 1290case of inter-realm communication: a hierarchical arrangement of realms 1291using either domain or X.500 style realm names. This encoding (called 1292DOMAIN-X500-COMPRESS) is now described. 1293 1294Realm names in the transited field are separated by a ",". The ",", "\", 1295trailing "."s, and leading spaces (" ") are special characters, and if they 1296are part of a realm name, they must be quoted in the transited field by 1297preced- ing them with a "\". 1298 1299A realm name ending with a "." is interpreted as being prepended to the 1300previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1301ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1302 1303 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1304 1305Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1306would not be included in this field, and we would have: 1307 1308 "EDU,MIT.,WASHINGTON.EDU" 1309 1310A realm name beginning with a "/" is interpreted as being appended to the 1311previous realm[18]. If it is to stand by itself, then it should be preceded 1312by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1313/COM/HP, /COM, and /COM/DEC as: 1314 1315 "/COM,/HP,/APOLLO, /COM/DEC". 1316 1317Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1318they would not be included in this field, and we would have: 1319 1320 "/COM,/HP" 1321 1322A null subfield preceding or following a "," indicates that all realms 1323between the previous realm and the next realm have been traversed[19]. Thus, 1324"," means that all realms along the path between the client and the server 1325have been traversed. ",EDU, /COM," means that that all realms from the 1326client's realm up to EDU (in a domain style hierarchy) have been traversed, 1327and that everything from /COM down to the server's realm in an X.500 style 1328has also been traversed. This could occur if the EDU realm in one hierarchy 1329shares an inter-realm key directly with the /COM realm in another hierarchy. 1330 1331 1332 1333draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1334 13353.3.4. Receipt of KRB_TGS_REP message 1336 1337When the KRB_TGS_REP is received by the client, it is processed in the same 1338manner as the KRB_AS_REP processing described above. The primary difference 1339is that the ciphertext part of the response must be decrypted using the 1340session key from the ticket-granting ticket rather than the client's secret 1341key. See section A.7 for pseudocode. 1342 13433.4. The KRB_SAFE Exchange 1344 1345The KRB_SAFE message may be used by clients requiring the ability to detect 1346modifications of messages they exchange. It achieves this by including a 1347keyed collision-proof checksum of the user data and some control 1348information. The checksum is keyed with an encryption key (usually the last 1349key negotiated via subkeys, or the session key if no negotiation has 1350occured). 1351 13523.4.1. Generation of a KRB_SAFE message 1353 1354When an application wishes to send a KRB_SAFE message, it collects its data 1355and the appropriate control information and computes a checksum over them. 1356The checksum algorithm should be a keyed one-way hash function (such as the 1357RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), 1358generated using the sub-session key if present, or the session key. 1359Different algorithms may be selected by changing the checksum type in the 1360message. Unkeyed or non-collision-proof checksums are not suitable for this 1361use. 1362 1363The control information for the KRB_SAFE message includes both a timestamp 1364and a sequence number. The designer of an application using the KRB_SAFE 1365message must choose at least one of the two mechanisms. This choice should 1366be based on the needs of the application protocol. 1367 1368Sequence numbers are useful when all messages sent will be received by one's 1369peer. Connection state is presently required to maintain the session key, so 1370maintaining the next sequence number should not present an additional 1371problem. 1372 1373If the application protocol is expected to tolerate lost messages without 1374them being resent, the use of the timestamp is the appropriate replay 1375detection mechanism. Using timestamps is also the appropriate mechanism for 1376multi-cast protocols where all of one's peers share a common sub-session 1377key, but some messages will be sent to a subset of one's peers. 1378 1379After computing the checksum, the client then transmits the information and 1380checksum to the recipient in the message format specified in section 5.6.1. 1381 13823.4.2. Receipt of KRB_SAFE message 1383 1384When an application receives a KRB_SAFE message, it verifies it as follows. 1385If any error occurs, an error code is reported for use by the application. 1386 1387The message is first checked by verifying that the protocol version and type 1388fields match the current version and KRB_SAFE, respectively. A mismatch 1389 1390 1391draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1392 1393generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1394application verifies that the checksum used is a collision-proof keyed 1395checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. The 1396recipient verifies that the operating system's report of the sender's 1397address matches the sender's address in the message, and (if a recipient 1398address is specified or the recipient requires an address) that one of the 1399recipient's addresses appears as the recipient's address in the message. A 1400failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the 1401timestamp and usec and/or the sequence number fields are checked. If 1402timestamp and usec are expected and not present, or they are present but not 1403current, the KRB_AP_ERR_SKEW error is generated. If the server name, along 1404with the client name, time and microsecond fields from the Authenticator 1405match any recently-seen (sent or received[20] ) such tuples, the 1406KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is 1407included, or a sequence number is expected but not present, the 1408KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1409a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1410Finally, the checksum is computed over the data and control information, and 1411if it doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is 1412generated. 1413 1414If all the checks succeed, the application is assured that the message was 1415generated by its peer and was not modi- fied in transit. 1416 14173.5. The KRB_PRIV Exchange 1418 1419The KRB_PRIV message may be used by clients requiring confidentiality and 1420the ability to detect modifications of exchanged messages. It achieves this 1421by encrypting the messages and adding control information. 1422 14233.5.1. Generation of a KRB_PRIV message 1424 1425When an application wishes to send a KRB_PRIV message, it collects its data 1426and the appropriate control information (specified in section 5.7.1) and 1427encrypts them under an encryption key (usually the last key negotiated via 1428subkeys, or the session key if no negotiation has occured). As part of the 1429control information, the client must choose to use either a timestamp or a 1430sequence number (or both); see the discussion in section 3.4.1 for 1431guidelines on which to use. After the user data and control information are 1432encrypted, the client transmits the ciphertext and some 'envelope' 1433information to the recipient. 1434 14353.5.2. Receipt of KRB_PRIV message 1436 1437When an application receives a KRB_PRIV message, it verifies it as follows. 1438If any error occurs, an error code is reported for use by the application. 1439 1440The message is first checked by verifying that the protocol version and type 1441fields match the current version and KRB_PRIV, respectively. A mismatch 1442generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1443application then decrypts the ciphertext and processes the resultant 1444plaintext. If decryption shows the data to have been modified, a 1445KRB_AP_ERR_BAD_INTEGRITY error is generated. The recipient verifies that the 1446operating system's report of the sender's address matches the sender's 1447 1448 1449draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1450 1451address in the message, and (if a recipient address is specified or the 1452recipient requires an address) that one of the recipient's addresses appears 1453as the recipient's address in the message. A failed match for either case 1454generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1455sequence number fields are checked. If timestamp and usec are expected and 1456not present, or they are present but not current, the KRB_AP_ERR_SKEW error 1457is generated. If the server name, along with the client name, time and 1458microsecond fields from the Authenticator match any recently-seen such 1459tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 1460number is included, or a sequence number is expected but not present, the 1461KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1462a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1463 1464If all the checks succeed, the application can assume the message was 1465generated by its peer, and was securely transmitted (without intruders able 1466to see the unencrypted contents). 1467 14683.6. The KRB_CRED Exchange 1469 1470The KRB_CRED message may be used by clients requiring the ability to send 1471Kerberos credentials from one host to another. It achieves this by sending 1472the tickets together with encrypted data containing the session keys and 1473other information associated with the tickets. 1474 14753.6.1. Generation of a KRB_CRED message 1476 1477When an application wishes to send a KRB_CRED message it first (using the 1478KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1479constructs a KRB_CRED message using the ticket or tickets so obtained, 1480placing the session key needed to use each ticket in the key field of the 1481corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1482message. 1483 1484Other information associated with each ticket and obtained during the 1485KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1486the encrypted part of the KRB_CRED message. The current time and, if 1487specifically required by the application the nonce, s-address, and r-address 1488fields, are placed in the encrypted part of the KRB_CRED message which is 1489then encrypted under an encryption key previosuly exchanged in the KRB_AP 1490exchange (usually the last key negotiated via subkeys, or the session key if 1491no negotiation has occured). 1492 14933.6.2. Receipt of KRB_CRED message 1494 1495When an application receives a KRB_CRED message, it verifies it. If any 1496error occurs, an error code is reported for use by the application. The 1497message is verified by checking that the protocol version and type fields 1498match the current version and KRB_CRED, respectively. A mismatch generates a 1499KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1500decrypts the ciphertext and processes the resultant plaintext. If decryption 1501shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1502generated. 1503 1504If present or required, the recipient verifies that the operating system's 1505 1506 1507draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1508 1509report of the sender's address matches the sender's address in the message, 1510and that one of the recipient's addresses appears as the recipient's address 1511in the message. A failed match for either case generates a 1512KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field 1513if required) are checked next. If the timestamp and usec are not present, or 1514they are present but not current, the KRB_AP_ERR_SKEW error is generated. 1515 1516If all the checks succeed, the application stores each of the new tickets in 1517its ticket cache together with the session key and other information in the 1518corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1519message. 1520 15214. The Kerberos Database 1522 1523The Kerberos server must have access to a database contain- ing the 1524principal identifiers and secret keys of principals to be authenticated[21]. 1525 15264.1. Database contents 1527 1528A database entry should contain at least the following fields: 1529 1530Field Value 1531 1532name Principal's identifier 1533key Principal's secret key 1534p_kvno Principal's key version 1535max_life Maximum lifetime for Tickets 1536max_renewable_life Maximum total lifetime for renewable Tickets 1537 1538The name field is an encoding of the principal's identifier. The key field 1539contains an encryption key. This key is the principal's secret key. (The key 1540can be encrypted before storage under a Kerberos "master key" to protect it 1541in case the database is compromised but the master key is not. In that case, 1542an extra field must be added to indicate the master key version used, see 1543below.) The p_kvno field is the key version number of the principal's secret 1544key. The max_life field contains the maximum allowable lifetime (endtime - 1545starttime) for any Ticket issued for this principal. The max_renewable_life 1546field contains the maximum allowable total lifetime for any renewable Ticket 1547issued for this principal. (See section 3.1 for a description of how these 1548lifetimes are used in determining the lifetime of a given Ticket.) 1549 1550A server may provide KDC service to several realms, as long as the database 1551representation provides a mechanism to distinguish between principal records 1552with identifiers which differ only in the realm name. 1553 1554When an application server's key changes, if the change is routine (i.e. not 1555the result of disclosure of the old key), the old key should be retained by 1556the server until all tickets that had been issued using that key have 1557expired. Because of this, it is possible for several keys to be active for a 1558single principal. Ciphertext encrypted in a principal's key is always tagged 1559with the version of the key that was used for encryption, to help the 1560recipient find the proper key for decryption. 1561 1562When more than one key is active for a particular principal, the principal 1563 1564 1565draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1566 1567will have more than one record in the Kerberos database. The keys and key 1568version numbers will differ between the records (the rest of the fields may 1569or may not be the same). Whenever Kerberos issues a ticket, or responds to a 1570request for initial authentication, the most recent key (known by the 1571Kerberos server) will be used for encryption. This is the key with the 1572highest key version number. 1573 15744.2. Additional fields 1575 1576Project Athena's KDC implementation uses additional fields in its database: 1577 1578Field Value 1579 1580K_kvno Kerberos' key version 1581expiration Expiration date for entry 1582attributes Bit field of attributes 1583mod_date Timestamp of last modification 1584mod_name Modifying principal's identifier 1585 1586The K_kvno field indicates the key version of the Kerberos master key under 1587which the principal's secret key is encrypted. 1588 1589After an entry's expiration date has passed, the KDC will return an error to 1590any client attempting to gain tickets as or for the principal. (A database 1591may want to maintain two expiration dates: one for the principal, and one 1592for the principal's current key. This allows password aging to work 1593independently of the principal's expiration date. However, due to the 1594limited space in the responses, the KDC must combine the key expiration and 1595principal expiration date into a single value called 'key_exp', which is 1596used as a hint to the user to take administrative action.) 1597 1598The attributes field is a bitfield used to govern the operations involving 1599the principal. This field might be useful in conjunction with user 1600registration procedures, for site-specific policy implementations (Project 1601Athena currently uses it for their user registration process controlled by 1602the system-wide database service, Moira [LGDSR87]), to identify whether a 1603principal can play the role of a client or server or both, to note whether a 1604server is appropriate trusted to recieve credentials delegated by a client, 1605or to identify the 'string to key' conversion algorithm used for a 1606principal's key[22]. Other bits are used to indicate that certain ticket 1607options should not be allowed in tickets encrypted under a principal's key 1608(one bit each): Disallow issuing postdated tickets, disallow issuing 1609forwardable tickets, disallow issuing tickets based on TGT authentication, 1610disallow issuing renewable tickets, disallow issuing proxiable tickets, and 1611disallow issuing tickets for which the principal is the server. 1612 1613The mod_date field contains the time of last modification of the entry, and 1614the mod_name field contains the name of the principal which last modified 1615the entry. 1616 16174.3. Frequently Changing Fields 1618 1619Some KDC implementations may wish to maintain the last time that a request 1620was made by a particular principal. Information that might be maintained 1621 1622 1623draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1624 1625includes the time of the last request, the time of the last request for a 1626ticket-granting ticket, the time of the last use of a ticket-granting 1627ticket, or other times. This information can then be returned to the user in 1628the last-req field (see section 5.2). 1629 1630Other frequently changing information that can be maintained is the latest 1631expiration time for any tickets that have been issued using each key. This 1632field would be used to indicate how long old keys must remain valid to allow 1633the continued use of outstanding tickets. 1634 16354.4. Site Constants 1636 1637The KDC implementation should have the following configurable constants or 1638options, to allow an administrator to make and enforce policy decisions: 1639 1640 * The minimum supported lifetime (used to determine whether the 1641 KDC_ERR_NEVER_VALID error should be returned). This constant should 1642 reflect reasonable expectations of round-trip time to the KDC, 1643 encryption/decryption time, and processing time by the client and 1644 target server, and it should allow for a minimum 'useful' lifetime. 1645 * The maximum allowable total (renewable) lifetime of a ticket 1646 (renew_till - starttime). 1647 * The maximum allowable lifetime of a ticket (endtime - starttime). 1648 * Whether to allow the issue of tickets with empty address fields 1649 (including the ability to specify that such tickets may only be issued 1650 if the request specifies some authorization_data). 1651 * Whether proxiable, forwardable, renewable or post-datable tickets are 1652 to be issued. 1653 16545. Message Specifications 1655 1656The following sections describe the exact contents and encoding of protocol 1657messages and objects. The ASN.1 base definitions are presented in the first 1658subsection. The remaining subsections specify the protocol objects (tickets 1659and authenticators) and messages. Specification of encryption and checksum 1660techniques, and the fields related to them, appear in section 6. 1661 16625.1. ASN.1 Distinguished Encoding Representation 1663 1664All uses of ASN.1 in Kerberos shall use the Distinguished Encoding 1665Representation of the data elements as described in the X.509 specification, 1666section 8.7 [X509-88]. 1667 16685.2. ASN.1 Base Definitions 1669 1670The following ASN.1 base definitions are used in the rest of this section. 1671Note that since the underscore character (_) is not permitted in ASN.1 1672names, the hyphen (-) is used in its place for the purposes of ASN.1 names. 1673 1674Realm ::= GeneralString 1675PrincipalName ::= SEQUENCE { 1676 name-type[0] INTEGER, 1677 name-string[1] SEQUENCE OF GeneralString 1678} 1679 1680 1681draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1682 1683 1684Kerberos realms are encoded as GeneralStrings. Realms shall not contain a 1685character with the code 0 (the ASCII NUL). Most realms will usually consist 1686of several components separated by periods (.), in the style of Internet 1687Domain Names, or separated by slashes (/) in the style of X.500 names. 1688Acceptable forms for realm names are specified in section 7. A PrincipalName 1689is a typed sequence of components consisting of the following sub-fields: 1690 1691name-type 1692 This field specifies the type of name that follows. Pre-defined values 1693 for this field are specified in section 7.2. The name-type should be 1694 treated as a hint. Ignoring the name type, no two names can be the same 1695 (i.e. at least one of the components, or the realm, must be different). 1696 This constraint may be eliminated in the future. 1697name-string 1698 This field encodes a sequence of components that form a name, each 1699 component encoded as a GeneralString. Taken together, a PrincipalName 1700 and a Realm form a principal identifier. Most PrincipalNames will have 1701 only a few components (typically one or two). 1702 1703KerberosTime ::= GeneralizedTime 1704 -- Specifying UTC time zone (Z) 1705 1706The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding 1707shall specify the UTC time zone (Z) and shall not include any fractional 1708portions of the seconds. It further shall not include any separators. 1709Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm 1710on 6 November 1985 is 19851106210627Z. 1711 1712HostAddress ::= SEQUENCE { 1713 addr-type[0] INTEGER, 1714 address[1] OCTET STRING 1715} 1716 1717HostAddresses ::= SEQUENCE OF HostAddress 1718 1719The host adddress encodings consists of two fields: 1720 1721addr-type 1722 This field specifies the type of address that follows. Pre-defined 1723 values for this field are specified in section 8.1. 1724address 1725 This field encodes a single address of type addr-type. 1726 1727The two forms differ slightly. HostAddress contains exactly one address; 1728HostAddresses contains a sequence of possibly many addresses. 1729 1730AuthorizationData ::= SEQUENCE OF SEQUENCE { 1731 ad-type[0] INTEGER, 1732 ad-data[1] OCTET STRING 1733} 1734 1735ad-data 1736 This field contains authorization data to be interpreted according to 1737 1738 1739draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1740 1741 the value of the corresponding ad-type field. 1742ad-type 1743 This field specifies the format for the ad-data subfield. All negative 1744 values are reserved for local use. Non-negative values are reserved for 1745 registered use. 1746 1747Each sequence of type and data is refered to as an authorization element. 1748Elements may be application specific, however, there is a common set of 1749recursive elements that should be understood by all implementations. These 1750elements contain other elements embedded within them, and the interpretation 1751of the encapsulating element determines which of the embedded elements must 1752be interpreted, and which may be ignored. Definitions for these common 1753elements may be found in Appendix B. 1754 1755TicketExtensions ::= SEQUENCE OF SEQUENCE { 1756 te-type[0] INTEGER, 1757 te-data[1] OCTET STRING 1758} 1759 1760 1761 1762te-data 1763 This field contains opaque data that must be caried with the ticket to 1764 support extensions to the Kerberos protocol including but not limited 1765 to some forms of inter-realm key exchange and plaintext authorization 1766 data. See appendix C for some common uses of this field. 1767te-type 1768 This field specifies the format for the te-data subfield. All negative 1769 values are reserved for local use. Non-negative values are reserved for 1770 registered use. 1771 1772APOptions ::= BIT STRING { 1773 reserved(0), 1774 use-session-key(1), 1775 mutual-required(2) 1776} 1777 1778TicketFlags ::= BIT STRING { 1779 reserved(0), 1780 forwardable(1), 1781 forwarded(2), 1782 proxiable(3), 1783 proxy(4), 1784 may-postdate(5), 1785 postdated(6), 1786 invalid(7), 1787 renewable(8), 1788 initial(9), 1789 pre-authent(10), 1790 hw-authent(11), 1791 transited-policy-checked(12), 1792 ok-as-delegate(13) 1793} 1794 1795 1796 1797draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1798 1799KDCOptions ::= BIT STRING { 1800 reserved(0), 1801 forwardable(1), 1802 forwarded(2), 1803 proxiable(3), 1804 proxy(4), 1805 allow-postdate(5), 1806 postdated(6), 1807 unused7(7), 1808 renewable(8), 1809 unused9(9), 1810 unused10(10), 1811 unused11(11), 1812 unused12(12), 1813 unused13(13), 1814 disable-transited-check(26), 1815 renewable-ok(27), 1816 enc-tkt-in-skey(28), 1817 renew(30), 1818 validate(31) 1819} 1820 1821ASN.1 Bit strings have a length and a value. When used in Kerberos for the 1822APOptions, TicketFlags, and KDCOptions, the length of the bit string on 1823generated values should be the smallest multiple of 32 bits needed to 1824include the highest order bit that is set (1), but in no case less than 32 1825bits. Implementations should accept values of bit strings of any length and 1826treat the value of flags cooresponding to bits beyond the end of the bit 1827string as if the bit were reset (0). Comparisonof bit strings of different 1828length should treat the smaller string as if it were padded with zeros 1829beyond the high order bits to the length of the longer string[23]. 1830 1831LastReq ::= SEQUENCE OF SEQUENCE { 1832 lr-type[0] INTEGER, 1833 lr-value[1] KerberosTime 1834} 1835 1836lr-type 1837 This field indicates how the following lr-value field is to be 1838 interpreted. Negative values indicate that the information pertains 1839 only to the responding server. Non-negative values pertain to all 1840 servers for the realm. If the lr-type field is zero (0), then no 1841 information is conveyed by the lr-value subfield. If the absolute value 1842 of the lr-type field is one (1), then the lr-value subfield is the time 1843 of last initial request for a TGT. If it is two (2), then the lr-value 1844 subfield is the time of last initial request. If it is three (3), then 1845 the lr-value subfield is the time of issue for the newest 1846 ticket-granting ticket used. If it is four (4), then the lr-value 1847 subfield is the time of the last renewal. If it is five (5), then the 1848 lr-value subfield is the time of last request (of any type). 1849lr-value 1850 This field contains the time of the last request. the time must be 1851 interpreted according to the contents of the accompanying lr-type 1852 subfield. 1853 1854 1855draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1856 1857 1858See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, 1859EncryptionKey, EncryptionType, and KeyType. 1860 18615.3. Tickets and Authenticators 1862 1863This section describes the format and encryption parameters for tickets and 1864authenticators. When a ticket or authenticator is included in a protocol 1865message it is treated as an opaque object. 1866 18675.3.1. Tickets 1868 1869A ticket is a record that helps a client authenticate to a service. A Ticket 1870contains the following information: 1871 1872Ticket ::= [APPLICATION 1] SEQUENCE { 1873 tkt-vno[0] INTEGER, 1874 realm[1] Realm, 1875 sname[2] PrincipalName, 1876 enc-part[3] EncryptedData, 1877 extensions[4] TicketExtensions OPTIONAL 1878} 1879 1880-- Encrypted part of ticket 1881EncTicketPart ::= [APPLICATION 3] SEQUENCE { 1882 flags[0] TicketFlags, 1883 key[1] EncryptionKey, 1884 crealm[2] Realm, 1885 cname[3] PrincipalName, 1886 transited[4] TransitedEncoding, 1887 authtime[5] KerberosTime, 1888 starttime[6] KerberosTime OPTIONAL, 1889 endtime[7] KerberosTime, 1890 renew-till[8] KerberosTime OPTIONAL, 1891 caddr[9] HostAddresses OPTIONAL, 1892 authorization-data[10] AuthorizationData OPTIONAL 1893} 1894-- encoded Transited field 1895TransitedEncoding ::= SEQUENCE { 1896 tr-type[0] INTEGER, -- must be registered 1897 contents[1] OCTET STRING 1898} 1899 1900The encoding of EncTicketPart is encrypted in the key shared by Kerberos and 1901the end server (the server's secret key). See section 6 for the format of 1902the ciphertext. 1903 1904tkt-vno 1905 This field specifies the version number for the ticket format. This 1906 document describes version number 5. 1907realm 1908 This field specifies the realm that issued a ticket. It also serves to 1909 identify the realm part of the server's principal identifier. Since a 1910 Kerberos server can only issue tickets for servers within its realm, 1911 1912 1913draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1914 1915 the two will always be identical. 1916sname 1917 This field specifies the name part of the server's identity. 1918enc-part 1919 This field holds the encrypted encoding of the EncTicketPart sequence. 1920extensions 1921 This optional field contains a sequence of extentions that may be used 1922 to carry information that must be carried with the ticket to support 1923 several extensions, including but not limited to plaintext 1924 authorization data, tokens for exchanging inter-realm keys, and other 1925 information that must be associated with a ticket for use by the 1926 application server. See Appendix C for definitions of some common 1927 extensions. 1928 1929 Note that some older versions of Kerberos did not support this field. 1930 Because this is an optional field it will not break older clients, but 1931 older clients might strip this field from the ticket before sending it 1932 to the application server. This limits the usefulness of this ticket 1933 field to environments where the ticket will not be parsed and 1934 reconstructed by these older Kerberos clients. 1935 1936 If it is known that the client will strip this field from the ticket, 1937 as an interim measure the KDC may append this field to the end of the 1938 enc-part of the ticket and append a traler indicating the lenght of the 1939 appended extensions field. (this paragraph is open for discussion, 1940 including the form of the traler). 1941flags 1942 This field indicates which of various options were used or requested 1943 when the ticket was issued. It is a bit-field, where the selected 1944 options are indicated by the bit being set (1), and the unselected 1945 options and reserved fields being reset (0). Bit 0 is the most 1946 significant bit. The encoding of the bits is specified in section 5.2. 1947 The flags are described in more detail above in section 2. The meanings 1948 of the flags are: 1949 1950 Bit(s) Name Description 1951 1952 0 RESERVED 1953 Reserved for future expansion of this 1954 field. 1955 1956 1 FORWARDABLE 1957 The FORWARDABLE flag is normally only 1958 interpreted by the TGS, and can be 1959 ignored by end servers. When set, this 1960 flag tells the ticket-granting server 1961 that it is OK to issue a new ticket- 1962 granting ticket with a different network 1963 address based on the presented ticket. 1964 1965 2 FORWARDED 1966 When set, this flag indicates that the 1967 ticket has either been forwarded or was 1968 issued based on authentication involving 1969 1970 1971draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 1972 1973 a forwarded ticket-granting ticket. 1974 1975 3 PROXIABLE 1976 The PROXIABLE flag is normally only 1977 interpreted by the TGS, and can be 1978 ignored by end servers. The PROXIABLE 1979 flag has an interpretation identical to 1980 that of the FORWARDABLE flag, except 1981 that the PROXIABLE flag tells the 1982 ticket-granting server that only non- 1983 ticket-granting tickets may be issued 1984 with different network addresses. 1985 1986 4 PROXY 1987 When set, this flag indicates that a 1988 ticket is a proxy. 1989 1990 5 MAY-POSTDATE 1991 The MAY-POSTDATE flag is normally only 1992 interpreted by the TGS, and can be 1993 ignored by end servers. This flag tells 1994 the ticket-granting server that a post- 1995 dated ticket may be issued based on this 1996 ticket-granting ticket. 1997 1998 6 POSTDATED 1999 This flag indicates that this ticket has 2000 been postdated. The end-service can 2001 check the authtime field to see when the 2002 original authentication occurred. 2003 2004 7 INVALID 2005 This flag indicates that a ticket is 2006 invalid, and it must be validated by the 2007 KDC before use. Application servers 2008 must reject tickets which have this flag 2009 set. 2010 2011 8 RENEWABLE 2012 The RENEWABLE flag is normally only 2013 interpreted by the TGS, and can usually 2014 be ignored by end servers (some particu- 2015 larly careful servers may wish to disal- 2016 low renewable tickets). A renewable 2017 ticket can be used to obtain a replace- 2018 ment ticket that expires at a later 2019 date. 2020 2021 9 INITIAL 2022 This flag indicates that this ticket was 2023 issued using the AS protocol, and not 2024 issued based on a ticket-granting 2025 ticket. 2026 2027 2028 2029draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2030 2031 10 PRE-AUTHENT 2032 This flag indicates that during initial 2033 authentication, the client was authenti- 2034 cated by the KDC before a ticket was 2035 issued. The strength of the pre- 2036 authentication method is not indicated, 2037 but is acceptable to the KDC. 2038 2039 11 HW-AUTHENT 2040 This flag indicates that the protocol 2041 employed for initial authentication 2042 required the use of hardware expected to 2043 be possessed solely by the named client. 2044 The hardware authentication method is 2045 selected by the KDC and the strength of 2046 the method is not indicated. 2047 2048 12 TRANSITED This flag indicates that the KDC for the 2049 POLICY-CHECKED realm has checked the transited field 2050 against a realm defined policy for 2051 trusted certifiers. If this flag is 2052 reset (0), then the application server 2053 must check the transited field itself, 2054 and if unable to do so it must reject 2055 the authentication. If the flag is set 2056 (1) then the application server may skip 2057 its own validation of the transited 2058 field, relying on the validation 2059 performed by the KDC. At its option the 2060 application server may still apply its 2061 own validation based on a separate 2062 policy for acceptance. 2063 2064 13 OK-AS-DELEGATE This flag indicates that the server (not 2065 the client) specified in the ticket has 2066 been determined by policy of the realm 2067 to be a suitable recipient of 2068 delegation. A client can use the 2069 presence of this flag to help it make a 2070 decision whether to delegate credentials 2071 (either grant a proxy or a forwarded 2072 ticket granting ticket) to this server. 2073 The client is free to ignore the value 2074 of this flag. When setting this flag, 2075 an administrator should consider the 2076 Security and placement of the server on 2077 which the service will run, as well as 2078 whether the service requires the use of 2079 delegated credentials. 2080 2081 14 ANONYMOUS 2082 This flag indicates that the principal 2083 named in the ticket is a generic princi- 2084 pal for the realm and does not identify 2085 2086 2087draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2088 2089 the individual using the ticket. The 2090 purpose of the ticket is only to 2091 securely distribute a session key, and 2092 not to identify the user. Subsequent 2093 requests using the same ticket and ses- 2094 sion may be considered as originating 2095 from the same user, but requests with 2096 the same username but a different ticket 2097 are likely to originate from different 2098 users. 2099 2100 15-31 RESERVED 2101 Reserved for future use. 2102 2103key 2104 This field exists in the ticket and the KDC response and is used to 2105 pass the session key from Kerberos to the application server and the 2106 client. The field's encoding is described in section 6.2. 2107crealm 2108 This field contains the name of the realm in which the client is 2109 registered and in which initial authentication took place. 2110cname 2111 This field contains the name part of the client's principal identifier. 2112transited 2113 This field lists the names of the Kerberos realms that took part in 2114 authenticating the user to whom this ticket was issued. It does not 2115 specify the order in which the realms were transited. See section 2116 3.3.3.2 for details on how this field encodes the traversed realms. 2117authtime 2118 This field indicates the time of initial authentication for the named 2119 principal. It is the time of issue for the original ticket on which 2120 this ticket is based. It is included in the ticket to provide 2121 additional information to the end service, and to provide the necessary 2122 information for implementation of a `hot list' service at the KDC. An 2123 end service that is particularly paranoid could refuse to accept 2124 tickets for which the initial authentication occurred "too far" in the 2125 past. This field is also returned as part of the response from the KDC. 2126 When returned as part of the response to initial authentication 2127 (KRB_AS_REP), this is the current time on the Ker- beros server[24]. 2128starttime 2129 This field in the ticket specifies the time after which the ticket is 2130 valid. Together with endtime, this field specifies the life of the 2131 ticket. If it is absent from the ticket, its value should be treated as 2132 that of the authtime field. 2133endtime 2134 This field contains the time after which the ticket will not be honored 2135 (its expiration time). Note that individual services may place their 2136 own limits on the life of a ticket and may reject tickets which have 2137 not yet expired. As such, this is really an upper bound on the 2138 expiration time for the ticket. 2139renew-till 2140 This field is only present in tickets that have the RENEWABLE flag set 2141 in the flags field. It indicates the maximum endtime that may be 2142 included in a renewal. It can be thought of as the absolute expiration 2143 2144 2145draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2146 2147 time for the ticket, including all renewals. 2148caddr 2149 This field in a ticket contains zero (if omitted) or more (if present) 2150 host addresses. These are the addresses from which the ticket can be 2151 used. If there are no addresses, the ticket can be used from any 2152 location. The decision by the KDC to issue or by the end server to 2153 accept zero-address tickets is a policy decision and is left to the 2154 Kerberos and end-service administrators; they may refuse to issue or 2155 accept such tickets. The suggested and default policy, however, is that 2156 such tickets will only be issued or accepted when additional 2157 information that can be used to restrict the use of the ticket is 2158 included in the authorization_data field. Such a ticket is a 2159 capability. 2160 2161 Network addresses are included in the ticket to make it harder for an 2162 attacker to use stolen credentials. Because the session key is not sent 2163 over the network in cleartext, credentials can't be stolen simply by 2164 listening to the network; an attacker has to gain access to the session 2165 key (perhaps through operating system security breaches or a careless 2166 user's unattended session) to make use of stolen tickets. 2167 2168 It is important to note that the network address from which a 2169 connection is received cannot be reliably determined. Even if it could 2170 be, an attacker who has compromised the client's worksta- tion could 2171 use the credentials from there. Including the network addresses only 2172 makes it more difficult, not impossible, for an attacker to walk off 2173 with stolen credentials and then use them from a "safe" location. 2174authorization-data 2175 The authorization-data field is used to pass authorization data from 2176 the principal on whose behalf a ticket was issued to the application 2177 service. If no authorization data is included, this field will be left 2178 out. Experience has shown that the name of this field is confusing, and 2179 that a better name for this field would be restrictions. Unfortunately, 2180 it is not possible to change the name of this field at this time. 2181 2182 This field contains restrictions on any authority obtained on the basis 2183 of authentication using the ticket. It is possible for any principal in 2184 posession of credentials to add entries to the authorization data field 2185 since these entries further restrict what can be done with the ticket. 2186 Such additions can be made by specifying the additional entries when a 2187 new ticket is obtained during the TGS exchange, or they may be added 2188 during chained delegation using the authorization data field of the 2189 authenticator. 2190 2191 Because entries may be added to this field by the holder of 2192 credentials, it is not allowable for the presence of an entry in the 2193 authorization data field of a ticket to amplify the priveleges one 2194 would obtain from using a ticket. 2195 2196 The data in this field may be specific to the end service; the field 2197 will contain the names of service specific objects, and the rights to 2198 those objects. The format for this field is described in section 5.2. 2199 Although Kerberos is not concerned with the format of the contents of 2200 the sub-fields, it does carry type information (ad-type). 2201 2202 2203draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2204 2205 2206 By using the authorization_data field, a principal is able to issue a 2207 proxy that is valid for a specific purpose. For example, a client 2208 wishing to print a file can obtain a file server proxy to be passed to 2209 the print server. By specifying the name of the file in the 2210 authorization_data field, the file server knows that the print server 2211 can only use the client's rights when accessing the particular file to 2212 be printed. 2213 2214 A separate service providing authorization or certifying group 2215 membership may be built using the authorization-data field. In this 2216 case, the entity granting authorization (not the authorized entity), 2217 obtains a ticket in its own name (e.g. the ticket is issued in the name 2218 of a privelege server), and this entity adds restrictions on its own 2219 authority and delegates the restricted authority through a proxy to the 2220 client. The client would then present this authorization credential to 2221 the application server separately from the authentication exchange. 2222 2223 Similarly, if one specifies the authorization-data field of a proxy and 2224 leaves the host addresses blank, the resulting ticket and session key 2225 can be treated as a capability. See [Neu93] for some suggested uses of 2226 this field. 2227 2228 The authorization-data field is optional and does not have to be 2229 included in a ticket. 2230 22315.3.2. Authenticators 2232 2233An authenticator is a record sent with a ticket to a server to certify the 2234client's knowledge of the encryption key in the ticket, to help the server 2235detect replays, and to help choose a "true session key" to use with the 2236particular session. The encoding is encrypted in the ticket's session key 2237shared by the client and the server: 2238 2239-- Unencrypted authenticator 2240Authenticator ::= [APPLICATION 2] SEQUENCE { 2241 authenticator-vno[0] INTEGER, 2242 crealm[1] Realm, 2243 cname[2] PrincipalName, 2244 cksum[3] Checksum OPTIONAL, 2245 cusec[4] INTEGER, 2246 ctime[5] KerberosTime, 2247 subkey[6] EncryptionKey OPTIONAL, 2248 seq-number[7] INTEGER OPTIONAL, 2249 authorization-data[8] AuthorizationData OPTIONAL 2250} 2251 2252 2253authenticator-vno 2254 This field specifies the version number for the format of the 2255 authenticator. This document specifies version 5. 2256crealm and cname 2257 These fields are the same as those described for the ticket in section 2258 5.3.1. 2259 2260 2261draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2262 2263cksum 2264 This field contains a checksum of the the applica- tion data that 2265 accompanies the KRB_AP_REQ. 2266cusec 2267 This field contains the microsecond part of the client's timestamp. Its 2268 value (before encryption) ranges from 0 to 999999. It often appears 2269 along with ctime. The two fields are used together to specify a 2270 reasonably accurate timestamp. 2271ctime 2272 This field contains the current time on the client's host. 2273subkey 2274 This field contains the client's choice for an encryption key which is 2275 to be used to protect this specific application session. Unless an 2276 application specifies otherwise, if this field is left out the session 2277 key from the ticket will be used. 2278seq-number 2279 This optional field includes the initial sequence number to be used by 2280 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 2281 detect replays (It may also be used by application specific messages). 2282 When included in the authenticator this field specifies the initial 2283 sequence number for messages from the client to the server. When 2284 included in the AP-REP message, the initial sequence number is that for 2285 messages from the server to the client. When used in KRB_PRIV or 2286 KRB_SAFE messages, it is incremented by one after each message is sent. 2287 2288 For sequence numbers to adequately support the detection of replays 2289 they should be non-repeating, even across connection boundaries. The 2290 initial sequence number should be random and uniformly distributed 2291 across the full space of possible sequence numbers, so that it cannot 2292 be guessed by an attacker and so that it and the successive sequence 2293 numbers do not repeat other sequences. 2294authorization-data 2295 This field is the same as described for the ticket in section 5.3.1. It 2296 is optional and will only appear when additional restrictions are to be 2297 placed on the use of a ticket, beyond those carried in the ticket 2298 itself. 2299 23005.4. Specifications for the AS and TGS exchanges 2301 2302This section specifies the format of the messages used in the exchange 2303between the client and the Kerberos server. The format of possible error 2304messages appears in section 5.9.1. 2305 23065.4.1. KRB_KDC_REQ definition 2307 2308The KRB_KDC_REQ message has no type of its own. Instead, its type is one of 2309KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial 2310ticket or an additional ticket. In either case, the message is sent from the 2311client to the Authentication Server to request credentials for a service. 2312 2313The message fields are: 2314 2315AS-REQ ::= [APPLICATION 10] KDC-REQ 2316TGS-REQ ::= [APPLICATION 12] KDC-REQ 2317 2318 2319draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2320 2321 2322KDC-REQ ::= SEQUENCE { 2323 pvno[1] INTEGER, 2324 msg-type[2] INTEGER, 2325 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2326 req-body[4] KDC-REQ-BODY 2327} 2328 2329PA-DATA ::= SEQUENCE { 2330 padata-type[1] INTEGER, 2331 padata-value[2] OCTET STRING, 2332 -- might be encoded AP-REQ 2333} 2334 2335KDC-REQ-BODY ::= SEQUENCE { 2336 kdc-options[0] KDCOptions, 2337 cname[1] PrincipalName OPTIONAL, 2338 -- Used only in AS-REQ 2339 realm[2] Realm, -- Server's realm 2340 -- Also client's in AS-REQ 2341 sname[3] PrincipalName OPTIONAL, 2342 from[4] KerberosTime OPTIONAL, 2343 till[5] KerberosTime OPTIONAL, 2344 rtime[6] KerberosTime OPTIONAL, 2345 nonce[7] INTEGER, 2346 etype[8] SEQUENCE OF INTEGER, 2347 -- EncryptionType, 2348 -- in preference order 2349 addresses[9] HostAddresses OPTIONAL, 2350 enc-authorization-data[10] EncryptedData OPTIONAL, 2351 -- Encrypted AuthorizationData 2352 -- encoding 2353 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2354} 2355 2356The fields in this message are: 2357 2358pvno 2359 This field is included in each message, and specifies the protocol 2360 version number. This document specifies protocol version 5. 2361msg-type 2362 This field indicates the type of a protocol message. It will almost 2363 always be the same as the application identifier associated with a 2364 message. It is included to make the identifier more readily accessible 2365 to the application. For the KDC-REQ message, this type will be 2366 KRB_AS_REQ or KRB_TGS_REQ. 2367padata 2368 The padata (pre-authentication data) field contains a sequence of 2369 authentication information which may be needed before credentials can 2370 be issued or decrypted. In the case of requests for additional tickets 2371 (KRB_TGS_REQ), this field will include an element with padata-type of 2372 PA-TGS-REQ and data of an authentication header (ticket-granting ticket 2373 and authenticator). The checksum in the authenticator (which must be 2374 collision-proof) is to be computed over the KDC-REQ-BODY encoding. In 2375 2376 2377draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2378 2379 most requests for initial authentication (KRB_AS_REQ) and most replies 2380 (KDC-REP), the padata field will be left out. 2381 2382 This field may also contain information needed by certain extensions to 2383 the Kerberos protocol. For example, it might be used to initially 2384 verify the identity of a client before any response is returned. This 2385 is accomplished with a padata field with padata-type equal to 2386 PA-ENC-TIMESTAMP and padata-value defined as follows: 2387 2388 padata-type ::= PA-ENC-TIMESTAMP 2389 padata-value ::= EncryptedData -- PA-ENC-TS-ENC 2390 2391 PA-ENC-TS-ENC ::= SEQUENCE { 2392 patimestamp[0] KerberosTime, -- client's time 2393 pausec[1] INTEGER OPTIONAL 2394 } 2395 2396 with patimestamp containing the client's time and pausec containing the 2397 microseconds which may be omitted if a client will not generate more 2398 than one request per second. The ciphertext (padata-value) consists of 2399 the PA-ENC-TS-ENC sequence, encrypted using the client's secret key. 2400 2401 [use-specified-kvno item is here for discussion and may be removed] It 2402 may also be used by the client to specify the version of a key that is 2403 being used for accompanying preauthentication, and/or which should be 2404 used to encrypt the reply from the KDC. 2405 2406 PA-USE-SPECIFIED-KVNO ::= Integer 2407 2408 The KDC should only accept and abide by the value of the 2409 use-specified-kvno preauthentication data field when the specified key 2410 is still valid and until use of a new key is confirmed. This situation 2411 is likely to occur primarily during the period during which an updated 2412 key is propagating to other KDC's in a realm. 2413 2414 The padata field can also contain information needed to help the KDC or 2415 the client select the key needed for generating or decrypting the 2416 response. This form of the padata is useful for supporting the use of 2417 certain token cards with Kerberos. The details of such extensions are 2418 specified in separate documents. See [Pat92] for additional uses of 2419 this field. 2420padata-type 2421 The padata-type element of the padata field indicates the way that the 2422 padata-value element is to be interpreted. Negative values of 2423 padata-type are reserved for unregistered use; non-negative values are 2424 used for a registered interpretation of the element type. 2425req-body 2426 This field is a placeholder delimiting the extent of the remaining 2427 fields. If a checksum is to be calculated over the request, it is 2428 calculated over an encoding of the KDC-REQ-BODY sequence which is 2429 enclosed within the req-body field. 2430kdc-options 2431 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2432 KDC and indicates the flags that the client wants set on the tickets as 2433 2434 2435draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2436 2437 well as other information that is to modify the behavior of the KDC. 2438 Where appropriate, the name of an option may be the same as the flag 2439 that is set by that option. Although in most case, the bit in the 2440 options field will be the same as that in the flags field, this is not 2441 guaranteed, so it is not acceptable to simply copy the options field to 2442 the flags field. There are various checks that must be made before 2443 honoring an option anyway. 2444 2445 The kdc_options field is a bit-field, where the selected options are 2446 indicated by the bit being set (1), and the unselected options and 2447 reserved fields being reset (0). The encoding of the bits is specified 2448 in section 5.2. The options are described in more detail above in 2449 section 2. The meanings of the options are: 2450 2451 Bit(s) Name Description 2452 0 RESERVED 2453 Reserved for future expansion of this 2454 field. 2455 2456 1 FORWARDABLE 2457 The FORWARDABLE option indicates that 2458 the ticket to be issued is to have its 2459 forwardable flag set. It may only be 2460 set on the initial request, or in a sub- 2461 sequent request if the ticket-granting 2462 ticket on which it is based is also for- 2463 wardable. 2464 2465 2 FORWARDED 2466 The FORWARDED option is only specified 2467 in a request to the ticket-granting 2468 server and will only be honored if the 2469 ticket-granting ticket in the request 2470 has its FORWARDABLE bit set. This 2471 option indicates that this is a request 2472 for forwarding. The address(es) of the 2473 host from which the resulting ticket is 2474 to be valid are included in the 2475 addresses field of the request. 2476 2477 3 PROXIABLE 2478 The PROXIABLE option indicates that the 2479 ticket to be issued is to have its prox- 2480 iable flag set. It may only be set on 2481 the initial request, or in a subsequent 2482 request if the ticket-granting ticket on 2483 which it is based is also proxiable. 2484 2485 4 PROXY 2486 The PROXY option indicates that this is 2487 a request for a proxy. This option will 2488 only be honored if the ticket-granting 2489 ticket in the request has its PROXIABLE 2490 bit set. The address(es) of the host 2491 2492 2493draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2494 2495 from which the resulting ticket is to be 2496 valid are included in the addresses 2497 field of the request. 2498 2499 5 ALLOW-POSTDATE 2500 The ALLOW-POSTDATE option indicates that 2501 the ticket to be issued is to have its 2502 MAY-POSTDATE flag set. It may only be 2503 set on the initial request, or in a sub- 2504 sequent request if the ticket-granting 2505 ticket on which it is based also has its 2506 MAY-POSTDATE flag set. 2507 2508 6 POSTDATED 2509 The POSTDATED option indicates that this 2510 is a request for a postdated ticket. 2511 This option will only be honored if the 2512 ticket-granting ticket on which it is 2513 based has its MAY-POSTDATE flag set. 2514 The resulting ticket will also have its 2515 INVALID flag set, and that flag may be 2516 reset by a subsequent request to the KDC 2517 after the starttime in the ticket has 2518 been reached. 2519 2520 7 UNUSED 2521 This option is presently unused. 2522 2523 8 RENEWABLE 2524 The RENEWABLE option indicates that the 2525 ticket to be issued is to have its 2526 RENEWABLE flag set. It may only be set 2527 on the initial request, or when the 2528 ticket-granting ticket on which the 2529 request is based is also renewable. If 2530 this option is requested, then the rtime 2531 field in the request contains the 2532 desired absolute expiration time for the 2533 ticket. 2534 2535 9-13 UNUSED 2536 These options are presently unused. 2537 2538 14 REQUEST-ANONYMOUS 2539 The REQUEST-ANONYMOUS option indicates 2540 that the ticket to be issued is not to 2541 identify the user to which it was 2542 issued. Instead, the principal identif- 2543 ier is to be generic, as specified by 2544 the policy of the realm (e.g. usually 2545 anonymous@realm). The purpose of the 2546 ticket is only to securely distribute a 2547 session key, and not to identify the 2548 user. The ANONYMOUS flag on the ticket 2549 2550 2551draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2552 2553 to be returned should be set. If the 2554 local realms policy does not permit 2555 anonymous credentials, the request is to 2556 be rejected. 2557 2558 15-25 RESERVED 2559 Reserved for future use. 2560 2561 26 DISABLE-TRANSITED-CHECK 2562 By default the KDC will check the 2563 transited field of a ticket-granting- 2564 ticket against the policy of the local 2565 realm before it will issue derivative 2566 tickets based on the ticket granting 2567 ticket. If this flag is set in the 2568 request, checking of the transited field 2569 is disabled. Tickets issued without the 2570 performance of this check will be noted 2571 by the reset (0) value of the 2572 TRANSITED-POLICY-CHECKED flag, 2573 indicating to the application server 2574 that the tranisted field must be checked 2575 locally. KDC's are encouraged but not 2576 required to honor the 2577 DISABLE-TRANSITED-CHECK option. 2578 2579 27 RENEWABLE-OK 2580 The RENEWABLE-OK option indicates that a 2581 renewable ticket will be acceptable if a 2582 ticket with the requested life cannot 2583 otherwise be provided. If a ticket with 2584 the requested life cannot be provided, 2585 then a renewable ticket may be issued 2586 with a renew-till equal to the the 2587 requested endtime. The value of the 2588 renew-till field may still be limited by 2589 local limits, or limits selected by the 2590 individual principal or server. 2591 2592 28 ENC-TKT-IN-SKEY 2593 This option is used only by the ticket- 2594 granting service. The ENC-TKT-IN-SKEY 2595 option indicates that the ticket for the 2596 end server is to be encrypted in the 2597 session key from the additional ticket- 2598 granting ticket provided. 2599 2600 29 RESERVED 2601 Reserved for future use. 2602 2603 30 RENEW 2604 This option is used only by the ticket- 2605 granting service. The RENEW option 2606 indicates that the present request is 2607 2608 2609draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2610 2611 for a renewal. The ticket provided is 2612 encrypted in the secret key for the 2613 server on which it is valid. This 2614 option will only be honored if the 2615 ticket to be renewed has its RENEWABLE 2616 flag set and if the time in its renew- 2617 till field has not passed. The ticket 2618 to be renewed is passed in the padata 2619 field as part of the authentication 2620 header. 2621 2622 31 VALIDATE 2623 This option is used only by the ticket- 2624 granting service. The VALIDATE option 2625 indicates that the request is to vali- 2626 date a postdated ticket. It will only 2627 be honored if the ticket presented is 2628 postdated, presently has its INVALID 2629 flag set, and would be otherwise usable 2630 at this time. A ticket cannot be vali- 2631 dated before its starttime. The ticket 2632 presented for validation is encrypted in 2633 the key of the server for which it is 2634 valid and is passed in the padata field 2635 as part of the authentication header. 2636 2637cname and sname 2638 These fields are the same as those described for the ticket in section 2639 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is 2640 specified. If absent, the name of the server is taken from the name of 2641 the client in the ticket passed as additional-tickets. 2642enc-authorization-data 2643 The enc-authorization-data, if present (and it can only be present in 2644 the TGS_REQ form), is an encoding of the desired authorization-data 2645 encrypted under the sub-session key if present in the Authenticator, or 2646 alternatively from the session key in the ticket-granting ticket, both 2647 from the padata field in the KRB_AP_REQ. 2648realm 2649 This field specifies the realm part of the server's principal 2650 identifier. In the AS exchange, this is also the realm part of the 2651 client's principal identifier. 2652from 2653 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 2654 requests when the requested ticket is to be postdated. It specifies the 2655 desired start time for the requested ticket. If this field is omitted 2656 then the KDC should use the current time instead. 2657till 2658 This field contains the expiration date requested by the client in a 2659 ticket request. It is optional and if omitted the requested ticket is 2660 to have the maximum endtime permitted according to KDC policy for the 2661 parties to the authentication exchange as limited by expiration date of 2662 the ticket granting ticket or other preauthentication credentials. 2663rtime 2664 This field is the requested renew-till time sent from a client to the 2665 2666 2667draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2668 2669 KDC in a ticket request. It is optional. 2670nonce 2671 This field is part of the KDC request and response. It it intended to 2672 hold a random number generated by the client. If the same number is 2673 included in the encrypted response from the KDC, it provides evidence 2674 that the response is fresh and has not been replayed by an attacker. 2675 Nonces must never be re-used. Ideally, it should be generated randomly, 2676 but if the correct time is known, it may suffice[25]. 2677etype 2678 This field specifies the desired encryption algorithm to be used in the 2679 response. 2680addresses 2681 This field is included in the initial request for tickets, and 2682 optionally included in requests for additional tickets from the 2683 ticket-granting server. It specifies the addresses from which the 2684 requested ticket is to be valid. Normally it includes the addresses for 2685 the client's host. If a proxy is requested, this field will contain 2686 other addresses. The contents of this field are usually copied by the 2687 KDC into the caddr field of the resulting ticket. 2688additional-tickets 2689 Additional tickets may be optionally included in a request to the 2690 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 2691 specified, then the session key from the additional ticket will be used 2692 in place of the server's key to encrypt the new ticket. If more than 2693 one option which requires additional tickets has been specified, then 2694 the additional tickets are used in the order specified by the ordering 2695 of the options bits (see kdc-options, above). 2696 2697The application code will be either ten (10) or twelve (12) depending on 2698whether the request is for an initial ticket (AS-REQ) or for an additional 2699ticket (TGS-REQ). 2700 2701The optional fields (addresses, authorization-data and additional-tickets) 2702are only included if necessary to perform the operation specified in the 2703kdc-options field. 2704 2705It should be noted that in KRB_TGS_REQ, the protocol version number appears 2706twice and two different message types appear: the KRB_TGS_REQ message 2707contains these fields as does the authentication header (KRB_AP_REQ) that is 2708passed in the padata field. 2709 27105.4.2. KRB_KDC_REP definition 2711 2712The KRB_KDC_REP message format is used for the reply from the KDC for either 2713an initial (AS) request or a subsequent (TGS) request. There is no message 2714type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 2715KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 2716depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 2717the client's secret key, and the client's key version number is included in 2718the key version number for the encrypted data. For KRB_TGS_REP, the 2719ciphertext is encrypted in the sub-session key from the Authenticator, or if 2720absent, the session key from the ticket-granting ticket used in the request. 2721In that case, no version number will be present in the EncryptedData 2722sequence. 2723 2724 2725draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2726 2727 2728The KRB_KDC_REP message contains the following fields: 2729 2730AS-REP ::= [APPLICATION 11] KDC-REP 2731TGS-REP ::= [APPLICATION 13] KDC-REP 2732 2733KDC-REP ::= SEQUENCE { 2734 pvno[0] INTEGER, 2735 msg-type[1] INTEGER, 2736 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 2737 crealm[3] Realm, 2738 cname[4] PrincipalName, 2739 ticket[5] Ticket, 2740 enc-part[6] EncryptedData 2741} 2742 2743EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart 2744EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 2745 2746EncKDCRepPart ::= SEQUENCE { 2747 key[0] EncryptionKey, 2748 last-req[1] LastReq, 2749 nonce[2] INTEGER, 2750 key-expiration[3] KerberosTime OPTIONAL, 2751 flags[4] TicketFlags, 2752 authtime[5] KerberosTime, 2753 starttime[6] KerberosTime OPTIONAL, 2754 endtime[7] KerberosTime, 2755 renew-till[8] KerberosTime OPTIONAL, 2756 srealm[9] Realm, 2757 sname[10] PrincipalName, 2758 caddr[11] HostAddresses OPTIONAL 2759} 2760 2761pvno and msg-type 2762 These fields are described above in section 5.4.1. msg-type is either 2763 KRB_AS_REP or KRB_TGS_REP. 2764padata 2765 This field is described in detail in section 5.4.1. One possible use 2766 for this field is to encode an alternate "mix-in" string to be used 2767 with a string-to-key algorithm (such as is described in section 6.3.2). 2768 This ability is useful to ease transitions if a realm name needs to 2769 change (e.g. when a company is acquired); in such a case all existing 2770 password-derived entries in the KDC database would be flagged as 2771 needing a special mix-in string until the next password change. 2772crealm, cname, srealm and sname 2773 These fields are the same as those described for the ticket in section 2774 5.3.1. 2775ticket 2776 The newly-issued ticket, from section 5.3.1. 2777enc-part 2778 This field is a place holder for the ciphertext and related information 2779 that forms the encrypted part of a message. The description of the 2780 encrypted part of the message follows each appearance of this field. 2781 2782 2783draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2784 2785 The encrypted part is encoded as described in section 6.1. 2786key 2787 This field is the same as described for the ticket in section 5.3.1. 2788last-req 2789 This field is returned by the KDC and specifies the time(s) of the last 2790 request by a principal. Depending on what information is available, 2791 this might be the last time that a request for a ticket-granting ticket 2792 was made, or the last time that a request based on a ticket-granting 2793 ticket was successful. It also might cover all servers for a realm, or 2794 just the particular server. Some implementations may display this 2795 information to the user to aid in discovering unauthorized use of one's 2796 identity. It is similar in spirit to the last login time displayed when 2797 logging into timesharing systems. 2798nonce 2799 This field is described above in section 5.4.1. 2800key-expiration 2801 The key-expiration field is part of the response from the KDC and 2802 specifies the time that the client's secret key is due to expire. The 2803 expiration might be the result of password aging or an account 2804 expiration. This field will usually be left out of the TGS reply since 2805 the response to the TGS request is encrypted in a session key and no 2806 client information need be retrieved from the KDC database. It is up to 2807 the application client (usually the login program) to take appropriate 2808 action (such as notifying the user) if the expiration time is imminent. 2809flags, authtime, starttime, endtime, renew-till and caddr 2810 These fields are duplicates of those found in the encrypted portion of 2811 the attached ticket (see section 5.3.1), provided so the client may 2812 verify they match the intended request and to assist in proper ticket 2813 caching. If the message is of type KRB_TGS_REP, the caddr field will 2814 only be filled in if the request was for a proxy or forwarded ticket, 2815 or if the user is substituting a subset of the addresses from the 2816 ticket granting ticket. If the client-requested addresses are not 2817 present or not used, then the addresses contained in the ticket will be 2818 the same as those included in the ticket-granting ticket. 2819 28205.5. Client/Server (CS) message specifications 2821 2822This section specifies the format of the messages used for the 2823authentication of the client to the application server. 2824 28255.5.1. KRB_AP_REQ definition 2826 2827The KRB_AP_REQ message contains the Kerberos protocol version number, the 2828message type KRB_AP_REQ, an options field to indicate any options in use, 2829and the ticket and authenticator themselves. The KRB_AP_REQ message is often 2830referred to as the 'authentication header'. 2831 2832AP-REQ ::= [APPLICATION 14] SEQUENCE { 2833 pvno[0] INTEGER, 2834 msg-type[1] INTEGER, 2835 ap-options[2] APOptions, 2836 ticket[3] Ticket, 2837 authenticator[4] EncryptedData 2838} 2839 2840 2841draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2842 2843 2844APOptions ::= BIT STRING { 2845 reserved(0), 2846 use-session-key(1), 2847 mutual-required(2) 2848} 2849 2850 2851 2852pvno and msg-type 2853 These fields are described above in section 5.4.1. msg-type is 2854 KRB_AP_REQ. 2855ap-options 2856 This field appears in the application request (KRB_AP_REQ) and affects 2857 the way the request is processed. It is a bit-field, where the selected 2858 options are indicated by the bit being set (1), and the unselected 2859 options and reserved fields being reset (0). The encoding of the bits 2860 is specified in section 5.2. The meanings of the options are: 2861 2862 Bit(s) Name Description 2863 0 RESERVED 2864 Reserved for future expansion of this 2865 field. 2866 2867 1 USE-SESSION-KEY 2868 The USE-SESSION-KEY option indicates 2869 that the ticket the client is presenting 2870 to a server is encrypted in the session 2871 key from the server's ticket-granting 2872 ticket. When this option is not speci- 2873 fied, the ticket is encrypted in the 2874 server's secret key. 2875 2876 2 MUTUAL-REQUIRED 2877 The MUTUAL-REQUIRED option tells the 2878 server that the client requires mutual 2879 authentication, and that it must respond 2880 with a KRB_AP_REP message. 2881 2882 3-31 RESERVED 2883 Reserved for future use. 2884ticket 2885 This field is a ticket authenticating the client to the server. 2886authenticator 2887 This contains the authenticator, which includes the client's choice of 2888 a subkey. Its encoding is described in section 5.3.2. 2889 28905.5.2. KRB_AP_REP definition 2891 2892The KRB_AP_REP message contains the Kerberos protocol version number, the 2893message type, and an encrypted time- stamp. The message is sent in in 2894response to an application request (KRB_AP_REQ) where the mutual 2895authentication option has been selected in the ap-options field. 2896 2897 2898 2899draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2900 2901AP-REP ::= [APPLICATION 15] SEQUENCE { 2902 pvno[0] INTEGER, 2903 msg-type[1] INTEGER, 2904 enc-part[2] EncryptedData 2905} 2906 2907EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { 2908 ctime[0] KerberosTime, 2909 cusec[1] INTEGER, 2910 subkey[2] EncryptionKey OPTIONAL, 2911 seq-number[3] INTEGER OPTIONAL 2912} 2913 2914The encoded EncAPRepPart is encrypted in the shared session key of the 2915ticket. The optional subkey field can be used in an application-arranged 2916negotiation to choose a per association session key. 2917 2918pvno and msg-type 2919 These fields are described above in section 5.4.1. msg-type is 2920 KRB_AP_REP. 2921enc-part 2922 This field is described above in section 5.4.2. 2923ctime 2924 This field contains the current time on the client's host. 2925cusec 2926 This field contains the microsecond part of the client's timestamp. 2927subkey 2928 This field contains an encryption key which is to be used to protect 2929 this specific application session. See section 3.2.6 for specifics on 2930 how this field is used to negotiate a key. Unless an application 2931 specifies otherwise, if this field is left out, the sub-session key 2932 from the authenticator, or if also left out, the session key from the 2933 ticket will be used. 2934 29355.5.3. Error message reply 2936 2937If an error occurs while processing the application request, the KRB_ERROR 2938message will be sent in response. See section 5.9.1 for the format of the 2939error message. The cname and crealm fields may be left out if the server 2940cannot determine their appropriate values from the corresponding KRB_AP_REQ 2941message. If the authenticator was decipherable, the ctime and cusec fields 2942will contain the values from it. 2943 29445.6. KRB_SAFE message specification 2945 2946This section specifies the format of a message that can be used by either 2947side (client or server) of an application to send a tamper-proof message to 2948its peer. It presumes that a session key has previously been exchanged (for 2949example, by using the KRB_AP_REQ/KRB_AP_REP messages). 2950 29515.6.1. KRB_SAFE definition 2952 2953The KRB_SAFE message contains user data along with a collision-proof 2954checksum keyed with the last encryption key negotiated via subkeys, or the 2955 2956 2957draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 2958 2959session key if no negotiation has occured. The message fields are: 2960 2961KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 2962 pvno[0] INTEGER, 2963 msg-type[1] INTEGER, 2964 safe-body[2] KRB-SAFE-BODY, 2965 cksum[3] Checksum 2966} 2967 2968KRB-SAFE-BODY ::= SEQUENCE { 2969 user-data[0] OCTET STRING, 2970 timestamp[1] KerberosTime OPTIONAL, 2971 usec[2] INTEGER OPTIONAL, 2972 seq-number[3] INTEGER OPTIONAL, 2973 s-address[4] HostAddress OPTIONAL, 2974 r-address[5] HostAddress OPTIONAL 2975} 2976 2977pvno and msg-type 2978 These fields are described above in section 5.4.1. msg-type is 2979 KRB_SAFE. 2980safe-body 2981 This field is a placeholder for the body of the KRB-SAFE message. It is 2982 to be encoded separately and then have the checksum computed over it, 2983 for use in the cksum field. 2984cksum 2985 This field contains the checksum of the application data. Checksum 2986 details are described in section 6.4. The checksum is computed over the 2987 encoding of the KRB-SAFE-BODY sequence. 2988user-data 2989 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 2990 the application specific data that is being passed from the sender to 2991 the recipient. 2992timestamp 2993 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 2994 are the current time as known by the sender of the message. By checking 2995 the timestamp, the recipient of the message is able to make sure that 2996 it was recently generated, and is not a replay. 2997usec 2998 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 2999 the microsecond part of the timestamp. 3000seq-number 3001 This field is described above in section 5.3.2. 3002s-address 3003 This field specifies the address in use by the sender of the message. 3004r-address 3005 This field specifies the address in use by the recipient of the 3006 message. It may be omitted for some uses (such as broadcast protocols), 3007 but the recipient may arbitrarily reject such messages. This field 3008 along with s-address can be used to help detect messages which have 3009 been incorrectly or maliciously delivered to the wrong recipient. 3010 30115.7. KRB_PRIV message specification 3012 3013 3014 3015draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3016 3017This section specifies the format of a message that can be used by either 3018side (client or server) of an application to securely and privately send a 3019message to its peer. It presumes that a session key has previously been 3020exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3021 30225.7.1. KRB_PRIV definition 3023 3024The KRB_PRIV message contains user data encrypted in the Session Key. The 3025message fields are: 3026 3027KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3028 pvno[0] INTEGER, 3029 msg-type[1] INTEGER, 3030 enc-part[3] EncryptedData 3031} 3032 3033EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { 3034 user-data[0] OCTET STRING, 3035 timestamp[1] KerberosTime OPTIONAL, 3036 usec[2] INTEGER OPTIONAL, 3037 seq-number[3] INTEGER OPTIONAL, 3038 s-address[4] HostAddress OPTIONAL, -- sender's addr 3039 r-address[5] HostAddress OPTIONAL -- recip's addr 3040} 3041 3042pvno and msg-type 3043 These fields are described above in section 5.4.1. msg-type is 3044 KRB_PRIV. 3045enc-part 3046 This field holds an encoding of the EncKrbPrivPart sequence encrypted 3047 under the session key[32]. This encrypted encoding is used for the 3048 enc-part field of the KRB-PRIV message. See section 6 for the format of 3049 the ciphertext. 3050user-data, timestamp, usec, s-address and r-address 3051 These fields are described above in section 5.6.1. 3052seq-number 3053 This field is described above in section 5.3.2. 3054 30555.8. KRB_CRED message specification 3056 3057This section specifies the format of a message that can be used to send 3058Kerberos credentials from one principal to another. It is presented here to 3059encourage a common mechanism to be used by applications when forwarding 3060tickets or providing proxies to subordinate servers. It presumes that a 3061session key has already been exchanged perhaps by using the 3062KRB_AP_REQ/KRB_AP_REP messages. 3063 30645.8.1. KRB_CRED definition 3065 3066The KRB_CRED message contains a sequence of tickets to be sent and 3067information needed to use the tickets, including the session key from each. 3068The information needed to use the tickets is encrypted under an encryption 3069key previously exchanged or transferred alongside the KRB_CRED message. The 3070message fields are: 3071 3072 3073draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3074 3075 3076KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3077 pvno[0] INTEGER, 3078 msg-type[1] INTEGER, -- KRB_CRED 3079 tickets[2] SEQUENCE OF Ticket, 3080 enc-part[3] EncryptedData 3081} 3082 3083EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3084 ticket-info[0] SEQUENCE OF KrbCredInfo, 3085 nonce[1] INTEGER OPTIONAL, 3086 timestamp[2] KerberosTime OPTIONAL, 3087 usec[3] INTEGER OPTIONAL, 3088 s-address[4] HostAddress OPTIONAL, 3089 r-address[5] HostAddress OPTIONAL 3090} 3091 3092KrbCredInfo ::= SEQUENCE { 3093 key[0] EncryptionKey, 3094 prealm[1] Realm OPTIONAL, 3095 pname[2] PrincipalName OPTIONAL, 3096 flags[3] TicketFlags OPTIONAL, 3097 authtime[4] KerberosTime OPTIONAL, 3098 starttime[5] KerberosTime OPTIONAL, 3099 endtime[6] KerberosTime OPTIONAL 3100 renew-till[7] KerberosTime OPTIONAL, 3101 srealm[8] Realm OPTIONAL, 3102 sname[9] PrincipalName OPTIONAL, 3103 caddr[10] HostAddresses OPTIONAL 3104} 3105 3106pvno and msg-type 3107 These fields are described above in section 5.4.1. msg-type is 3108 KRB_CRED. 3109tickets 3110 These are the tickets obtained from the KDC specifically for use by the 3111 intended recipient. Successive tickets are paired with the 3112 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3113 message. 3114enc-part 3115 This field holds an encoding of the EncKrbCredPart sequence encrypted 3116 under the session key shared between the sender and the intended 3117 recipient. This encrypted encoding is used for the enc-part field of 3118 the KRB-CRED message. See section 6 for the format of the ciphertext. 3119nonce 3120 If practical, an application may require the inclusion of a nonce 3121 generated by the recipient of the message. If the same value is 3122 included as the nonce in the message, it provides evidence that the 3123 message is fresh and has not been replayed by an attacker. A nonce must 3124 never be re-used; it should be generated randomly by the recipient of 3125 the message and provided to the sender of the message in an application 3126 specific manner. 3127timestamp and usec 3128 These fields specify the time that the KRB-CRED message was generated. 3129 3130 3131draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3132 3133 The time is used to provide assurance that the message is fresh. 3134s-address and r-address 3135 These fields are described above in section 5.6.1. They are used 3136 optionally to provide additional assurance of the integrity of the 3137 KRB-CRED message. 3138key 3139 This field exists in the corresponding ticket passed by the KRB-CRED 3140 message and is used to pass the session key from the sender to the 3141 intended recipient. The field's encoding is described in section 6.2. 3142 3143The following fields are optional. If present, they can be associated with 3144the credentials in the remote ticket file. If left out, then it is assumed 3145that the recipient of the credentials already knows their value. 3146 3147prealm and pname 3148 The name and realm of the delegated principal identity. 3149flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3150 These fields contain the values of the correspond- ing fields from the 3151 ticket found in the ticket field. Descriptions of the fields are 3152 identical to the descriptions in the KDC-REP message. 3153 31545.9. Error message specification 3155 3156This section specifies the format for the KRB_ERROR message. The fields 3157included in the message are intended to return as much information as 3158possible about an error. It is not expected that all the information 3159required by the fields will be available for all types of errors. If the 3160appropriate information is not available when the message is composed, the 3161corresponding field will be left out of the message. 3162 3163Note that since the KRB_ERROR message is not protected by any encryption, it 3164is quite possible for an intruder to synthesize or modify such a message. In 3165particular, this means that the client should not use any fields in this 3166message for security-critical purposes, such as setting a system clock or 3167generating a fresh authenticator. The message can be useful, however, for 3168advising a user on the reason for some failure. 3169 31705.9.1. KRB_ERROR definition 3171 3172The KRB_ERROR message consists of the following fields: 3173 3174KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3175 pvno[0] INTEGER, 3176 msg-type[1] INTEGER, 3177 ctime[2] KerberosTime OPTIONAL, 3178 cusec[3] INTEGER OPTIONAL, 3179 stime[4] KerberosTime, 3180 susec[5] INTEGER, 3181 error-code[6] INTEGER, 3182 crealm[7] Realm OPTIONAL, 3183 cname[8] PrincipalName OPTIONAL, 3184 realm[9] Realm, -- Correct realm 3185 sname[10] PrincipalName, -- Correct name 3186 e-text[11] GeneralString OPTIONAL, 3187 3188 3189draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3190 3191 e-data[12] OCTET STRING OPTIONAL, 3192 e-cksum[13] Checksum OPTIONAL, 3193 e-typed-data[14] SEQUENCE of ETypedData OPTIONAL 3194} 3195 3196ETypedData ::= SEQUENCE { 3197 e-data-type [1] INTEGER, 3198 e-data-value [2] OCTET STRING, 3199} 3200 3201 3202 3203pvno and msg-type 3204 These fields are described above in section 5.4.1. msg-type is 3205 KRB_ERROR. 3206ctime 3207 This field is described above in section 5.4.1. 3208cusec 3209 This field is described above in section 5.5.2. 3210stime 3211 This field contains the current time on the server. It is of type 3212 KerberosTime. 3213susec 3214 This field contains the microsecond part of the server's timestamp. Its 3215 value ranges from 0 to 999999. It appears along with stime. The two 3216 fields are used in conjunction to specify a reasonably accurate 3217 timestamp. 3218error-code 3219 This field contains the error code returned by Kerberos or the server 3220 when a request fails. To interpret the value of this field see the list 3221 of error codes in section 8. Implementations are encouraged to provide 3222 for national language support in the display of error messages. 3223crealm, cname, srealm and sname 3224 These fields are described above in section 5.3.1. 3225e-text 3226 This field contains additional text to help explain the error code 3227 associated with the failed request (for example, it might include a 3228 principal name which was unknown). 3229e-data 3230 This field contains additional data about the error for use by the 3231 application to help it recover from or handle the error. If the 3232 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 3233 contain an encoding of a sequence of padata fields, each corresponding 3234 to an acceptable pre-authentication method and optionally containing 3235 data for the method: 3236 3237 METHOD-DATA ::= SEQUENCE of PA-DATA 3238 3239 If the error-code is KRB_AP_ERR_METHOD, then the e-data field will 3240 contain an encoding of the following sequence: 3241 3242 METHOD-DATA ::= SEQUENCE { 3243 method-type[0] INTEGER, 3244 method-data[1] OCTET STRING OPTIONAL 3245 3246 3247draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3248 3249 } 3250 3251 method-type will indicate the required alternate method; method-data 3252 will contain any required additional information. 3253e-cksum 3254 This field contains an optional checksum for the KRB-ERROR message. The 3255 checksum is calculated over the Kerberos ASN.1 encoding of the 3256 KRB-ERROR message with the checksum absent. The checksum is then added 3257 to the KRB-ERROR structure and the message is re-encoded. The Checksum 3258 should be calculated using the session key from the ticket granting 3259 ticket or service ticket, where available. If the error is in response 3260 to a TGS or AP request, the checksum should be calculated uing the the 3261 session key from the client's ticket. If the error is in response to an 3262 AS request, then the checksum should be calulated using the client's 3263 secret key ONLY if there has been suitable preauthentication to prove 3264 knowledge of the secret key by the client[33]. If a checksum can not be 3265 computed because the key to be used is not available, no checksum will 3266 be included. 3267e-typed-data 3268 [This field for discussion, may be deleted from final spec] This field 3269 contains optional data that may be used to help the client recover from 3270 the indicated error. [This could contain the METHOD-DATA specified 3271 since I don't think anyone actually uses it yet. It could also contain 3272 the PA-DATA sequence for the preauth required error if we had a clear 3273 way to transition to the use of this field from the use of the untype 3274 e-data field.] For example, this field may specify the key version of 3275 the key used to verify preauthentication: 3276 3277 e-data-type := 20 -- Key version number 3278 e-data-value := Integer -- Key version number used to verify 3279 preauthentication 3280 32816. Encryption and Checksum Specifications 3282 3283The Kerberos protocols described in this document are designed to use stream 3284encryption ciphers, which can be simulated using commonly available block 3285encryption ciphers, such as the Data Encryption Standard, [DES77] in 3286conjunction with block chaining and checksum methods [DESM80]. Encryption is 3287used to prove the identities of the network entities participating in 3288message exchanges. The Key Distribution Center for each realm is trusted by 3289all principals registered in that realm to store a secret key in confidence. 3290Proof of knowledge of this secret key is used to verify the authenticity of 3291a principal. 3292 3293The KDC uses the principal's secret key (in the AS exchange) or a shared 3294session key (in the TGS exchange) to encrypt responses to ticket requests; 3295the ability to obtain the secret key or session key implies the knowledge of 3296the appropriate keys and the identity of the KDC. The ability of a principal 3297to decrypt the KDC response and present a Ticket and a properly formed 3298Authenticator (generated with the session key from the KDC response) to a 3299service verifies the identity of the principal; likewise the ability of the 3300service to extract the session key from the Ticket and prove its knowledge 3301thereof in a response verifies the identity of the service. 3302 3303 3304 3305draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3306 3307The Kerberos protocols generally assume that the encryption used is secure 3308from cryptanalysis; however, in some cases, the order of fields in the 3309encrypted portions of messages are arranged to minimize the effects of 3310poorly chosen keys. It is still important to choose good keys. If keys are 3311derived from user-typed passwords, those passwords need to be well chosen to 3312make brute force attacks more difficult. Poorly chosen keys still make easy 3313targets for intruders. 3314 3315The following sections specify the encryption and checksum mechanisms 3316currently defined for Kerberos. The encodings, chaining, and padding 3317requirements for each are described. For encryption methods, it is often 3318desirable to place random information (often referred to as a confounder) at 3319the start of the message. The requirements for a confounder are specified 3320with each encryption mechanism. 3321 3322Some encryption systems use a block-chaining method to improve the the 3323security characteristics of the ciphertext. However, these chaining methods 3324often don't provide an integrity check upon decryption. Such systems (such 3325as DES in CBC mode) must be augmented with a checksum of the plain-text 3326which can be verified at decryption and used to detect any tampering or 3327damage. Such checksums should be good at detecting burst errors in the 3328input. If any damage is detected, the decryption routine is expected to 3329return an error indicating the failure of an integrity check. Each 3330encryption type is expected to provide and verify an appropriate checksum. 3331The specification of each encryption method sets out its checksum 3332requirements. 3333 3334Finally, where a key is to be derived from a user's password, an algorithm 3335for converting the password to a key of the appropriate type is included. It 3336is desirable for the string to key function to be one-way, and for the 3337mapping to be different in different realms. This is important because users 3338who are registered in more than one realm will often use the same password 3339in each, and it is desirable that an attacker compromising the Kerberos 3340server in one realm not obtain or derive the user's key in another. 3341 3342For an discussion of the integrity characteristics of the candidate 3343encryption and checksum methods considered for Kerberos, the the reader is 3344referred to [SG92]. 3345 33466.1. Encryption Specifications 3347 3348The following ASN.1 definition describes all encrypted messages. The 3349enc-part field which appears in the unencrypted part of messages in section 33505 is a sequence consisting of an encryption type, an optional key version 3351number, and the ciphertext. 3352 3353EncryptedData ::= SEQUENCE { 3354 etype[0] INTEGER, -- EncryptionType 3355 kvno[1] INTEGER OPTIONAL, 3356 cipher[2] OCTET STRING -- ciphertext 3357} 3358 3359 3360 3361 3362 3363draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3364 3365etype 3366 This field identifies which encryption algorithm was used to encipher 3367 the cipher. Detailed specifications for selected encryption types 3368 appear later in this section. 3369kvno 3370 This field contains the version number of the key under which data is 3371 encrypted. It is only present in messages encrypted under long lasting 3372 keys, such as principals' secret keys. 3373cipher 3374 This field contains the enciphered text, encoded as an OCTET STRING. 3375 3376The cipher field is generated by applying the specified encryption algorithm 3377to data composed of the message and algorithm-specific inputs. Encryption 3378mechanisms defined for use with Kerberos must take sufficient measures to 3379guarantee the integrity of the plaintext, and we recommend they also take 3380measures to protect against precomputed dictionary attacks. If the 3381encryption algorithm is not itself capable of doing so, the protections can 3382often be enhanced by adding a checksum and a confounder. 3383 3384The suggested format for the data to be encrypted includes a confounder, a 3385checksum, the encoded plaintext, and any necessary padding. The msg-seq 3386field contains the part of the protocol message described in section 5 which 3387is to be encrypted. The confounder, checksum, and padding are all untagged 3388and untyped, and their length is exactly sufficient to hold the appropriate 3389item. The type and length is implicit and specified by the particular 3390encryption type being used (etype). The format for the data to be encrypted 3391is described in the following diagram: 3392 3393 +-----------+----------+-------------+-----+ 3394 |confounder | check | msg-seq | pad | 3395 +-----------+----------+-------------+-----+ 3396 3397The format cannot be described in ASN.1, but for those who prefer an 3398ASN.1-like notation: 3399 3400CipherText ::= ENCRYPTED SEQUENCE { 3401 confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, 3402 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 3403 msg-seq[2] MsgSequence, 3404 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 3405} 3406 3407One generates a random confounder of the appropriate length, placing it in 3408confounder; zeroes out check; calculates the appropriate checksum over 3409confounder, check, and msg-seq, placing the result in check; adds the 3410necessary padding; then encrypts using the specified encryption type and the 3411appropriate key. 3412 3413Unless otherwise specified, a definition of an encryption algorithm that 3414specifies a checksum, a length for the confounder field, or an octet 3415boundary for padding uses this ciphertext format[36]. Those fields which are 3416not specified will be omitted. 3417 3418In the interest of allowing all implementations using a particular 3419 3420 3421draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3422 3423encryption type to communicate with all others using that type, the 3424specification of an encryption type defines any checksum that is needed as 3425part of the encryption process. If an alternative checksum is to be used, a 3426new encryption type must be defined. 3427 3428Some cryptosystems require additional information beyond the key and the 3429data to be encrypted. For example, DES, when used in cipher-block-chaining 3430mode, requires an initialization vector. If required, the description for 3431each encryption type must specify the source of such additional information. 34326.2. Encryption Keys 3433 3434The sequence below shows the encoding of an encryption key: 3435 3436 EncryptionKey ::= SEQUENCE { 3437 keytype[0] INTEGER, 3438 keyvalue[1] OCTET STRING 3439 } 3440 3441keytype 3442 This field specifies the type of encryption key that follows in the 3443 keyvalue field. It will almost always correspond to the encryption 3444 algorithm used to generate the EncryptedData, though more than one 3445 algorithm may use the same type of key (the mapping is many to one). 3446 This might happen, for example, if the encryption algorithm uses an 3447 alternate checksum algorithm for an integrity check, or a different 3448 chaining mechanism. 3449keyvalue 3450 This field contains the key itself, encoded as an octet string. 3451 3452All negative values for the encryption key type are reserved for local use. 3453All non-negative values are reserved for officially assigned type fields and 3454interpreta- tions. 3455 34566.3. Encryption Systems 3457 34586.3.1. The NULL Encryption System (null) 3459 3460If no encryption is in use, the encryption system is said to be the NULL 3461encryption system. In the NULL encryption system there is no checksum, 3462confounder or padding. The ciphertext is simply the plaintext. The NULL Key 3463is used by the null encryption system and is zero octets in length, with 3464keytype zero (0). 3465 34666.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) 3467 3468The des-cbc-crc encryption mode encrypts information under the Data 3469Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A 3470CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the 3471confounder and message sequence (msg-seq) and placed in the cksum field. DES 3472blocks are 8 bytes. As a result, the data to be encrypted (the concatenation 3473of confounder, checksum, and message) must be padded to an 8 byte boundary 3474before encryption. The details of the encryption of this data are identical 3475to those for the des-cbc-md5 encryption mode. 3476 3477 3478 3479draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3480 3481Note that, since the CRC-32 checksum is not collision-proof, an attacker 3482could use a probabilistic chosen-plaintext attack to generate a valid 3483message even if a confounder is used [SG92]. The use of collision-proof 3484checksums is recommended for environments where such attacks represent a 3485significant threat. The use of the CRC-32 as the checksum for ticket or 3486authenticator is no longer mandated as an interoperability requirement for 3487Kerberos Version 5 Specification 1 (See section 9.1 for specific details). 3488 34896.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) 3490 3491The des-cbc-md4 encryption mode encrypts information under the Data 3492Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 3493An MD4 checksum (described in [MD492]) is applied to the confounder and 3494message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 3495bytes. As a result, the data to be encrypted (the concatenation of 3496confounder, checksum, and message) must be padded to an 8 byte boundary 3497before encryption. The details of the encryption of this data are identical 3498to those for the des-cbc-md5 encryption mode. 3499 35006.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) 3501 3502The des-cbc-md5 encryption mode encrypts information under the Data 3503Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 3504An MD5 checksum (described in [MD5-92].) is applied to the confounder and 3505message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 3506bytes. As a result, the data to be encrypted (the concatenation of 3507confounder, checksum, and message) must be padded to an 8 byte boundary 3508before encryption. 3509 3510Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are 3511concatenated to make the 64-bit inputs for the DES algorithms. The first 3512octet supplies the 8 most significant bits (with the octet's MSbit used as 3513the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., 3514and the eighth octet supplies the 8 least significant bits. 3515 3516Encryption under DES using cipher block chaining requires an additional 3517input in the form of an initialization vector. Unless otherwise specified, 3518zero should be used as the initialization vector. Kerberos' use of DES 3519requires an 8 octet confounder. 3520 3521The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 3522shall not be used for encrypting messages for use in Kerberos. Additionally, 3523because of the way that keys are derived for the encryption of checksums, 3524keys shall not be used that yield 'weak' or 'semi-weak' keys when 3525eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0. 3526 3527A DES key is 8 octets of data, with keytype one (1). This consists of 56 3528bits of key, and 8 parity bits (one per octet). The key is encoded as a 3529series of 8 octets written in MSB-first order. The bits within the key are 3530also encoded in MSB order. For example, if the encryption key is 3531(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where 3532B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity 3533bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the 3534MSbit). [See the FIPS 81 introduction for reference.] 3535 3536 3537draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3538 3539 3540String to key transformation 3541 3542To generate a DES key from a text string (password), the text string 3543normally must have the realm and each component of the principal's name 3544appended[37], then padded with ASCII nulls to an 8 byte boundary. This 3545string is then fan-folded and eXclusive-ORed with itself to form an 8 byte 3546DES key. The parity is corrected on the key, and it is used to generate a 3547DES CBC checksum on the initial string (with the realm and name appended). 3548Next, parity is corrected on the CBC checksum. If the result matches a 3549'weak' or 'semi-weak' key as described in the DES specification, it is 3550eXclusive-ORed with the constant 00000000000000F0. Finally, the result is 3551returned as the key. Pseudocode follows: 3552 3553 string_to_key(string,realm,name) { 3554 odd = 1; 3555 s = string + realm; 3556 for(each component in name) { 3557 s = s + component; 3558 } 3559 tempkey = NULL; 3560 pad(s); /* with nulls to 8 byte boundary */ 3561 for(8byteblock in s) { 3562 if(odd == 0) { 3563 odd = 1; 3564 reverse(8byteblock) 3565 } 3566 else odd = 0; 3567 tempkey = tempkey XOR 8byteblock; 3568 } 3569 fixparity(tempkey); 3570 key = DES-CBC-check(s,tempkey); 3571 fixparity(key); 3572 if(is_weak_key_key(key)) 3573 key = key XOR 0xF0; 3574 return(key); 3575 } 3576 35776.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-sum 3578(des3-cbc-sha1) 3579 3580The des3-cbc-sha1 encryption encodes information using three Data Encryption 3581Standard transformations with three DES keys. The first key is used to 3582perform a DES ECB encryption on an eight-octet data block using the first 3583DES key, followed by a DES ECB decryption of the result using the second DES 3584key, and a DES ECB encryption of the result using the third DES key. Because 3585DES blocks are 8 bytes, the data to be encrypted (the concatenation of 3586confounder, checksum, and message) must first be padded to an 8 byte 3587boundary before encryption. To support the outer CBC mode, the input is 3588padded to an eight-octet boundary. The first 8 octets of the data to be 3589encrypted (the confounder) is exclusive-ored with an initialization vector 3590of zero and then ECB encrypted using triple DES as described above. 3591Subsequent blocks of 8 octets are exclusive-ored with the ciphertext 3592produced by the encryption on the previous block before ECB encryption. 3593 3594 3595draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3596 3597 3598An HMAC-SHA1 checksum (described in [KBC96].) is applied to the confounder 3599and message sequence (msg-seq) and placed in the cksum field. 3600 3601Plaintext are encoded as blocks of 8 octets which are concatenated to make 3602the 64-bit inputs for the DES algorithms. The first octet supplies the 8 3603most significant bits (with the octet's MSbit used as the DES input block's 3604MSbit, etc.), the second octet the next 8 bits, ..., and the eighth octet 3605supplies the 8 least significant bits. 3606 3607Encryption under Triple DES using cipher block chaining requires an 3608additional input in the form of an initialization vector. Unless otherwise 3609specified, zero should be used as the initialization vector. Kerberos' use 3610of DES requires an 8 octet confounder. 3611 3612The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 3613shall not be used for encrypting messages for use in Kerberos. Additionally, 3614because of the way that keys are derived for the encryption of checksums, 3615keys shall not be used that yield 'weak' or 'semi-weak' keys when 3616eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0. 3617 3618A Triple DES key is 24 octets of data, with keytype seven (7). This consists 3619of 168 bits of key, and 24 parity bits (one per octet). The key is encoded 3620as a series of 24 octets written in MSB-first order, with the first 8 octets 3621treated as the first DES key, the second 8 octets as the second key, and the 3622third 8 octets the third DES key. The bits within each key are also encoded 3623in MSB order. For example, if the encryption key is 3624(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where 3625B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity 3626bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the 3627MSbit). [See the FIPS 81 introduction for reference.] 3628 3629Key derivation for specified operations (Horowitz) 3630 3631[Discussion is needed for this section, especially since it does not simply 3632derive key generation, but also specifies encryption using triple DES in a 3633manner that is different than the basic template that was specified for 3634single DES and similar systems] 3635 3636In the Kerberos protocol cryptographic keys are used in a number of places. 3637In order to minimize the effect of compromising a key, it is desirable to 3638use a different key in each of these places. Key derivation [Horowitz96] can 3639be used to construct different keys for each operation from the keys 3640transported on the network or derived from the password specified by the 3641user. 3642 3643For each place where a key is used in Kerberos, a ``key usage'' is specified 3644for that purpose. The key, key usage, and encryption/checksum type together 3645describe the transformation from plaintext to ciphertext. For backwards 3646compatibility, this key derivation is only specified here for encryption 3647methods based on triple DES. Encryption methods specified for use by 3648Kerberos in the future should specify the key derivation function to be 3649used. 3650 3651 3652 3653draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3654 3655Kerberos requires that the ciphertext component of EncryptedData be 3656tamper-resistant as well as confidential. This implies encryption and 3657integrity functions, which must each use their own separate keys. So, for 3658each key usage, two keys must be generated, one for encryption (Ke), and one 3659for integrity (Ki): 3660 3661 Ke = DK(protocol key, key usage | 0xAA) 3662 Ki = DK(protocol key, key usage | 0x55) 3663 3664where the key usage is represented as a 32 bit integer in network byte 3665order. The ciphertest must be generated from the plaintext as follows: 3666 3667 ciphertext = E(Ke, confounder | length | plaintext | padding) | 3668 H(Ki, confounder | length | plaintext | padding) 3669 3670The confounder and padding are specific to the encryption algorithm E. 3671 3672When generating a checksum only, there is no need for a confounder or 3673padding. Again, a new key (Kc) must be used. Checksums must be generated 3674from the plaintext as follows: 3675 3676 Kc = DK(protocol key, key usage | 0x99) 3677 MAC = H(Kc, length | plaintext) 3678 3679 3680Note that each enctype is described by an encryption algorithm E and a keyed 3681hash algorithm H, and each checksum type is described by a keyed hash 3682algorithm H. HMAC, with an appropriate hash, is recommended for use as H. 3683 3684The key usage value will be taken from the following list of places where 3685keys are used in the Kerberos protocol, with key usage values and Kerberos 3686specification section numbers: 3687 3688 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 3689 client key (section 5.4.1) 3690 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or 3691 application session key), encrypted with the service key 3692 (section 5.4.2) 3693 3. AS-REP encrypted part (includes tgs session key or application 3694 session key), encrypted with the client key (section 5.4.2) 3695 3696 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 3697 session key (section 5.4.1) 3698 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 3699 authenticator subkey (section 5.4.1) 3700 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 3701 with the tgs session key (sections 5.3.2, 5.4.1) 3702 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs 3703 authenticator subkey), encrypted with the tgs session key 3704 (section 5.3.2) 3705 8. TGS-REP encrypted part (includes application session key), 3706 encrypted with the tgs session key (section 5.4.2) 3707 9. TGS-REP encrypted part (includes application session key), 3708 encrypted with the tgs authenticator subkey (section 5.4.2) 3709 3710 3711draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3712 3713 3714 10. AP-REQ Authenticator cksum, keyed with the application session 3715 key (section 5.3.2) 3716 11. AP-REQ Authenticator (includes application authenticator 3717 subkey), encrypted with the application session key (section 3718 5.3.2) 3719 12. AP-REP encrypted part (includes application session subkey), 3720 encrypted with the application session key (section 5.5.2) 3721 3722 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 3723 application (section 5.7.1) 3724 14. KRB-CRED encrypted part, encrypted with a key chosen by the 3725 application (section 5.6.1) 3726 15. KRB-SAFE cksum, keyed with a key chosen by the application 3727 (section 5.8.1) 3728 3729 16. Data which is defined in some specification outside of 3730 Kerberos to be encrypted using Kerberos encryption type. 3731 17. Data which is defined in some specification outside of 3732 Kerberos to be checksummed using Kerberos checksum type. 3733 3734 18. KRB-ERROR checksum (e-cksum in section 5.9.1) 3735 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) 3736 20. Checksum for Mandatory Ticket Extensions (appendix B.6) 3737 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) 3738 3739String to key transformation 3740 3741To generate a DES key from a text string (password), the text string 3742normally must have the realm and each component of the principal's name 3743appended[38]. 3744 3745The input string (with any salt data appended to it) is n-folded into a 24 3746octet (192 bit) string. To n-fold a number X, replicate the input value to a 3747length that is the least common multiple of n and the length of X. Before 3748each repetition, the input X is rotated to the right by 13 bit positions. 3749The successive n-bit chunks are added together using 1's-complement addition 3750(addition with end-around carry) to yield a n-bit result. (This 3751transformation was proposed by Richard Basch) 3752 3753Each successive set of 8 octets is taken as a DES key, and its parity is 3754adjusted in the same manner as previously described. If any of the three 3755sets of 8 octets match a 'weak' or 'semi-weak key as described in the DES 3756specification, that chunk is eXclusive-ORed with the hexadecimal constant 375700000000000000F0. The resulting DES keys are then used in sequence to 3758perform a Triple-DES CBC encryption of the n-folded input string (appended 3759with any salt data), using a zero initial vector. Parity, weak, and 3760semi-weak keys are once again corrected and the result is returned as the 24 3761octet key. 3762 3763Pseudocode follows: 3764 3765 string_to_key(string,realm,name) { 3766 s = string + realm; 3767 3768 3769draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3770 3771 for(each component in name) { 3772 s = s + component; 3773 } 3774 tkey[24] = fold(s); 3775 fixparity(tkey); 3776 if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0; 3777 if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0; 3778 if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0; 3779 key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0); 3780 fixparity(key); 3781 if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0; 3782 if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0; 3783 if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0; 3784 return(key); 3785 } 3786 37876.4. Checksums 3788 3789The following is the ASN.1 definition used for a checksum: 3790 3791 Checksum ::= SEQUENCE { 3792 cksumtype[0] INTEGER, 3793 checksum[1] OCTET STRING 3794 } 3795 3796cksumtype 3797 This field indicates the algorithm used to generate the accompanying 3798 checksum. 3799checksum 3800 This field contains the checksum itself, encoded as an octet string. 3801 3802Detailed specification of selected checksum types appear later in this 3803section. Negative values for the checksum type are reserved for local use. 3804All non-negative values are reserved for officially assigned type fields and 3805interpretations. 3806 3807Checksums used by Kerberos can be classified by two properties: whether they 3808are collision-proof, and whether they are keyed. It is infeasible to find 3809two plaintexts which generate the same checksum value for a collision-proof 3810checksum. A key is required to perturb or initialize the algorithm in a 3811keyed checksum. To prevent message-stream modification by an active 3812attacker, unkeyed checksums should only be used when the checksum and 3813message will be subsequently encrypted (e.g. the checksums defined as part 3814of the encryption algorithms covered earlier in this section). 3815 3816Collision-proof checksums can be made tamper-proof if the checksum value is 3817encrypted before inclusion in a message. In such cases, the composition of 3818the checksum and the encryption algorithm must be considered a separate 3819checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum 3820algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the 3821encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a 3822confounder before the checksum is calculated. 3823 38246.4.1. The CRC-32 Checksum (crc32) 3825 3826 3827draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3828 3829 3830The CRC-32 checksum calculates a checksum based on a cyclic redundancy check 3831as described in ISO 3309 [ISO3309]. The resulting checksum is four (4) 3832octets in length. The CRC-32 is neither keyed nor collision-proof. The use 3833of this checksum is not recommended. An attacker using a probabilistic 3834chosen-plaintext attack as described in [SG92] might be able to generate an 3835alternative message that satisfies the checksum. The use of collision-proof 3836checksums is recommended for environments where such attacks represent a 3837significant threat. 3838 38396.4.2. The RSA MD4 Checksum (rsa-md4) 3840 3841The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm 3842[MD4-92]. The algorithm takes as input an input message of arbitrary length 3843and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to 3844be collision-proof. 3845 38466.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) 3847 3848The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by 3849prepending an 8 octet confounder before the text, applying the RSA MD4 3850checksum algorithm, and encrypting the confounder and the checksum using DES 3851in cipher-block-chaining (CBC) mode using a variant of the key, where the 3852variant is computed by eXclusive-ORing the key with the constant 3853F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The 3854resulting checksum is 24 octets long (8 octets of which are redundant). This 3855checksum is tamper-proof and believed to be collision-proof. 3856 3857The DES specifications identify some weak keys' and 'semi-weak keys'; those 3858keys shall not be used for generating RSA-MD4 checksums for use in Kerberos. 3859 3860The format for the checksum is described in the follow- ing diagram: 3861 3862+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3863| des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 3864+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3865 3866The format cannot be described in ASN.1, but for those who prefer an 3867ASN.1-like notation: 3868 3869rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3870 confounder[0] UNTAGGED OCTET STRING(8), 3871 check[1] UNTAGGED OCTET STRING(16) 3872} 3873 38746.4.4. The RSA MD5 Checksum (rsa-md5) 3875 3876The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm. 3877[MD5-92]. The algorithm takes as input an input message of arbitrary length 3878and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to 3879be collision-proof. 3880 38816.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) 3882 3883 3884 3885draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3886 3887The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by 3888prepending an 8 octet confounder before the text, applying the RSA MD5 3889checksum algorithm, and encrypting the confounder and the checksum using DES 3890in cipher-block-chaining (CBC) mode using a variant of the key, where the 3891variant is computed by eXclusive-ORing the key with the hexadecimal constant 3892F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 3893checksum is 24 octets long (8 octets of which are redundant). This checksum 3894is tamper-proof and believed to be collision-proof. 3895 3896The DES specifications identify some 'weak keys' and 'semi-weak keys'; those 3897keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos. 3898 3899The format for the checksum is described in the following diagram: 3900 3901+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3902| des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 3903+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3904 3905The format cannot be described in ASN.1, but for those who prefer an 3906ASN.1-like notation: 3907 3908rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3909 confounder[0] UNTAGGED OCTET STRING(8), 3910 check[1] UNTAGGED OCTET STRING(16) 3911} 3912 39136.4.6. DES cipher-block chained checksum (des-mac) 3914 3915The DES-MAC checksum is computed by prepending an 8 octet confounder to the 3916plaintext, performing a DES CBC-mode encryption on the result using the key 3917and an initialization vector of zero, taking the last block of the 3918ciphertext, prepending the same confounder and encrypting the pair using DES 3919in cipher-block-chaining (CBC) mode using a a variant of the key, where the 3920variant is computed by eXclusive-ORing the key with the hexadecimal constant 3921F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 3922checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This 3923checksum is tamper-proof and collision-proof. 3924 3925The format for the checksum is described in the following diagram: 3926 3927+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 3928| des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | 3929+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 3930 3931The format cannot be described in ASN.1, but for those who prefer an 3932ASN.1-like notation: 3933 3934des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3935 confounder[0] UNTAGGED OCTET STRING(8), 3936 check[1] UNTAGGED OCTET STRING(8) 3937} 3938 3939The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 3940shall not be used for generating DES-MAC checksums for use in Kerberos, nor 3941 3942 3943draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 3944 3945shall a key be used whose variant is 'weak' or 'semi-weak'. 3946 39476.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k) 3948 3949The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by 3950applying the RSA MD4 checksum algorithm and encrypting the results using DES 3951in cipher-block-chaining (CBC) mode using a DES key as both key and 3952initialization vector. The resulting checksum is 16 octets long. This 3953checksum is tamper-proof and believed to be collision-proof. Note that this 3954checksum type is the old method for encoding the RSA-MD4-DES checksum and it 3955is no longer recommended. 3956 39576.4.8. DES cipher-block chained checksum alternative (des-mac-k) 3958 3959The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption 3960of the plaintext, and using the last block of the ciphertext as the checksum 3961value. It is keyed with an encryption key and an initialization vector; any 3962uses which do not specify an additional initialization vector will use the 3963key as both key and initialization vector. The resulting checksum is 64 bits 3964(8 octets) long. This checksum is tamper-proof and collision-proof. Note 3965that this checksum type is the old method for encoding the DES-MAC checksum 3966and it is no longer recommended. The DES specifications identify some 'weak 3967keys' and 'semi-weak keys'; those keys shall not be used for generating 3968DES-MAC checksums for use in Kerberos. 3969 39707. Naming Constraints 3971 39727.1. Realm Names 3973 3974Although realm names are encoded as GeneralStrings and although a realm can 3975technically select any name it chooses, interoperability across realm 3976boundaries requires agreement on how realm names are to be assigned, and 3977what information they imply. 3978 3979To enforce these conventions, each realm must conform to the conventions 3980itself, and it must require that any realms with which inter-realm keys are 3981shared also conform to the conventions and require the same from its 3982neighbors. 3983 3984Kerberos realm names are case sensitive. Realm names that differ only in the 3985case of the characters are not equivalent. There are presently four styles 3986of realm names: domain, X500, other, and reserved. Examples of each style 3987follow: 3988 3989 domain: ATHENA.MIT.EDU (example) 3990 X500: C=US/O=OSF (example) 3991 other: NAMETYPE:rest/of.name=without-restrictions (example) 3992 reserved: reserved, but will not conflict with above 3993 3994Domain names must look like domain names: they consist of components 3995separated by periods (.) and they contain neither colons (:) nor slashes 3996(/). Domain names must be converted to upper case when used as realm names. 3997 3998X.500 names contain an equal (=) and cannot contain a colon (:) before the 3999 4000 4001draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4002 4003equal. The realm names for X.500 names will be string representations of the 4004names with components separated by slashes. Leading and trailing slashes 4005will not be included. 4006 4007Names that fall into the other category must begin with a prefix that 4008contains no equal (=) or period (.) and the prefix must be followed by a 4009colon (:) and the rest of the name. All prefixes must be assigned before 4010they may be used. Presently none are assigned. 4011 4012The reserved category includes strings which do not fall into the first 4013three categories. All names in this category are reserved. It is unlikely 4014that names will be assigned to this category unless there is a very strong 4015argument for not using the 'other' category. 4016 4017These rules guarantee that there will be no conflicts between the various 4018name styles. The following additional constraints apply to the assignment of 4019realm names in the domain and X.500 categories: the name of a realm for the 4020domain or X.500 formats must either be used by the organization owning (to 4021whom it was assigned) an Internet domain name or X.500 name, or in the case 4022that no such names are registered, authority to use a realm name may be 4023derived from the authority of the parent realm. For example, if there is no 4024domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4025authorize the creation of a realm with that name. 4026 4027This is acceptable because the organization to which the parent is assigned 4028is presumably the organization authorized to assign names to its children in 4029the X.500 and domain name systems as well. If the parent assigns a realm 4030name without also registering it in the domain name or X.500 hierarchy, it 4031is the parent's responsibility to make sure that there will not in the 4032future exists a name identical to the realm name of the child unless it is 4033assigned to the same entity as the realm name. 4034 40357.2. Principal Names 4036 4037As was the case for realm names, conventions are needed to ensure that all 4038agree on what information is implied by a principal name. The name-type 4039field that is part of the principal name indicates the kind of information 4040implied by the name. The name-type should be treated as a hint. Ignoring the 4041name type, no two names can be the same (i.e. at least one of the 4042components, or the realm, must be different). The following name types are 4043defined: 4044 4045 name-type value meaning 4046 4047 NT-UNKNOWN 0 Name type not known 4048 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) 4049 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4050 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4051 NT-SRV-XHST 4 Service with slash-separated host name components 4052 NT-UID 5 Unique ID 4053 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4054 4055When a name implies no information other than its uniqueness at a particular 4056time the name type PRINCIPAL should be used. The principal name type should 4057 4058 4059draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4060 4061be used for users, and it might also be used for a unique server. If the 4062name is a unique machine generated ID that is guaranteed never to be 4063reassigned then the name type of UID should be used (note that it is 4064generally a bad idea to reassign names of any type since stale entries might 4065remain in access control lists). 4066 4067If the first component of a name identifies a service and the remaining 4068components identify an instance of the service in a server specified manner, 4069then the name type of SRV-INST should be used. An example of this name type 4070is the Kerberos ticket-granting service whose name has a first component of 4071krbtgt and a second component identifying the realm for which the ticket is 4072valid. 4073 4074If instance is a single component following the service name and the 4075instance identifies the host on which the server is running, then the name 4076type SRV-HST should be used. This type is typically used for Internet 4077services such as telnet and the Berkeley R commands. If the separate 4078components of the host name appear as successive components following the 4079name of the service, then the name type SRV-XHST should be used. This type 4080might be used to identify servers on hosts with X.500 names where the slash 4081(/) might otherwise be ambiguous. 4082 4083A name type of NT-X500-PRINCIPAL should be used when a name from an X.509 4084certificiate is translated into a Kerberos name. The encoding of the X.509 4085name as a Kerberos principal shall conform to the encoding rules specified 4086in RFC 1779. 4087 4088A name type of UNKNOWN should be used when the form of the name is not 4089known. When comparing names, a name of type UNKNOWN will match principals 4090authenticated with names of any type. A principal authenticated with a name 4091of type UNKNOWN, however, will only match other names of type UNKNOWN. 4092 4093Names of any type with an initial component of 'krbtgt' are reserved for the 4094Kerberos ticket granting service. See section 8.2.3 for the form of such 4095names. 4096 40977.2.1. Name of server principals 4098 4099The principal identifier for a server on a host will generally be composed 4100of two parts: (1) the realm of the KDC with which the server is registered, 4101and (2) a two-component name of type NT-SRV-HST if the host name is an 4102Internet domain name or a multi-component name of type NT-SRV-XHST if the 4103name of the host is of a form such as X.500 that allows slash (/) 4104separators. The first component of the two- or multi-component name will 4105identify the service and the latter components will identify the host. Where 4106the name of the host is not case sensitive (for example, with Internet 4107domain names) the name of the host must be lower case. If specified by the 4108application protocol for services such as telnet and the Berkeley R commands 4109which run with system privileges, the first component may be the string 4110'host' instead of a service specific identifier. When a host has an official 4111name and one or more aliases, the official name of the host must be used 4112when constructing the name of the server principal. 4113 41148. Constants and other defined values 4115 4116 4117draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4118 4119 41208.1. Host address types 4121 4122All negative values for the host address type are reserved for local use. 4123All non-negative values are reserved for officially assigned type fields and 4124interpretations. 4125 4126The values of the types for the following addresses are chosen to match the 4127defined address family constants in the Berkeley Standard Distributions of 4128Unix. They can be found in with symbolic names AF_xxx (where xxx is an 4129abbreviation of the address family name). 4130 4131Internet (IPv4) Addresses 4132 4133Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB 4134order. The type of IPv4 addresses is two (2). 4135 4136Internet (IPv6) Addresses 4137 4138IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The 4139type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The 4140following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 4141 4142 * the Unspecified Address 4143 * the Loopback Address 4144 * Link-Local addresses 4145 4146IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 4147 4148CHAOSnet addresses 4149 4150CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order. 4151The type of CHAOSnet addresses is five (5). 4152 4153ISO addresses 4154 4155ISO addresses are variable-length. The type of ISO addresses is seven (7). 4156 4157Xerox Network Services (XNS) addresses 4158 4159XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The 4160type of XNS addresses is six (6). 4161 4162AppleTalk Datagram Delivery Protocol (DDP) addresses 4163 4164AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network 4165number. The first octet of the address is the node number; the remaining two 4166octets encode the network number in MSB order. The type of AppleTalk DDP 4167addresses is sixteen (16). 4168 4169DECnet Phase IV addresses 4170 4171DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The 4172type of DECnet Phase IV addresses is twelve (12). 4173 4174 4175draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4176 4177 41788.2. KDC messages 4179 41808.2.1. UDP/IP transport 4181 4182When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP 4183IP transport, the client shall send a UDP datagram containing only an 4184encoding of the request to port 88 (decimal) at the KDC's IP address; the 4185KDC will respond with a reply datagram containing only an encoding of the 4186reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at 4187the sender's IP address. Kerberos servers supporting IP transport must 4188accept UDP requests on port 88 (decimal). The response to a request made 4189through UDP/IP transport must also use UDP/IP transport. 4190 41918.2.2. TCP/IP transport 4192 4193Kerberos servers (KDC's) must accept TCP requests on port 88 (decimal). When 4194the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new 4195connection will be established for each authentication exchange (request and 4196response). The KRB_KDC_REP or KRB_ERROR message will be returned to the 4197client on the same TCP stream that was established for the request. The 4198connection will be broken after the reply has been received (or upon 4199time-out). Care must be taken in managing TCP/IP connections with the KDC to 4200prevent denial of service attacks based on the number of TCP/IP connections 4201with the KDC that remain open. If multiple exchanges with the KDC are needed 4202for certain forms of preauthentication, multiple TCP connections will be 4203required. The response to a request made through TCP/IP transport must also 4204use TCP/IP transport. 4205 4206The first four octets of the TCP stream used to transmit the request request 4207will encode in network byte order the length of the request (KRB_KDC_REQ), 4208and the length will be followed by the request itself. The response will 4209similarly be preceeded by a 4 octet encoding in network byte order of the 4210length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by 4211the KRB_KDC_REP or the KRB_ERROR response. 4212 42138.2.3. OSI transport 4214 4215During authentication of an OSI client to an OSI server, the mutual 4216authentication of an OSI server to an OSI client, the transfer of 4217credentials from an OSI client to an OSI server, or during exchange of 4218private or integrity checked messages, Kerberos protocol messages may be 4219treated as opaque objects and the type of the authentication mechanism will 4220be: 4221 4222OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} 4223 4224Depending on the situation, the opaque object will be an authentication 4225header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message 4226(KRB_SAFE), a private message (KRB_PRIV), or a credentials message 4227(KRB_CRED). The opaque data contains an application code as specified in the 4228ASN.1 description for each message. The application code may be used by 4229Kerberos to determine the message type. 4230 4231 4232 4233draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4234 42358.2.3. Name of the TGS 4236 4237The principal identifier of the ticket-granting service shall be composed of 4238three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part 4239name of type NT-SRV-INST, with the first part "krbtgt" and the second part 4240the name of the realm which will accept the ticket-granting ticket. For 4241example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 4242used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier 4243of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 4244ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get 4245tickets from the MIT.EDU realm has a principal identifier of 4246"ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name). 4247 42488.3. Protocol constants and associated values 4249 4250The following tables list constants used in the protocol and defines their 4251meanings. 4252 4253Encryption type etype value block size minimum pad size confounder size 4254NULL 0 1 0 0 4255des-cbc-crc 1 8 4 8 4256des-cbc-md4 2 8 0 8 4257des-cbc-md5 3 8 0 8 4258 4 4259des3-cbc-md5 5 8 0 8 4260 6 4261des3-cbc-sha1 7 8 0 8 4262sign-dsa-generate 8 (pkinit) 4263encrypt-rsa-priv 9 (pkinit) 4264encrypt-rsa-pub 10 (pkinit) 4265rsa-pub-md5 11 (pkinit) 4266rsa-pub-sha1 12 (pkinit) 4267ENCTYPE_PK_CROSS 48 (reserved for pkcross) 4268 0x8003 4269 4270Checksum type sumtype value checksum size 4271CRC32 1 4 4272rsa-md4 2 16 4273rsa-md4-des 3 24 4274des-mac 4 16 4275des-mac-k 5 8 4276rsa-md4-des-k 6 16 4277rsa-md5 7 16 4278rsa-md5-des 8 24 4279rsa-md5-des3 9 24 4280hmac-sha1-des3 10 20 (I had this as 10, is it 12) 4281 4282padata type padata-type value 4283 4284PA-TGS-REQ 1 4285PA-ENC-TIMESTAMP 2 4286PA-PW-SALT 3 4287 4 4288PA-ENC-UNIX-TIME 5 4289 4290 4291draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4292 4293PA-SANDIA-SECUREID 6 4294PA-SESAME 7 4295PA-OSF-DCE 8 4296PA-CYBERSAFE-SECUREID 9 4297PA-AFS3-SALT 10 4298PA-ETYPE-INFO 11 4299SAM-CHALLENGE 12 (sam/otp) 4300SAM-RESPONSE 13 (sam/otp) 4301PA-PK-AS-REQ 14 (pkinit) 4302PA-PK-AS-REP 15 (pkinit) 4303PA-PK-AS-SIGN 16 (pkinit) 4304PA-PK-KEY-REQ 17 (pkinit) 4305PA-PK-KEY-REP 18 (pkinit) 4306PA-USE-SPECIFIED-KVNO 20 4307 4308authorization data type ad-type value 4309AD-KDC-ISSUED 1 4310AD-INTENDED-FOR-SERVER 2 4311AD-INTENDED-FOR-APPLICATION-CLASS 3 4312AD-IF-RELEVANT 4 4313AD-OR 5 4314AD-MANDATORY-TICKET-EXTENSIONS 6 4315AD-IN-TICKET-EXTENSIONS 7 4316reserved values 8-63 4317OSF-DCE 64 4318SESAME 65 4319 4320Ticket Extension Types 4321 4322TE-TYPE-NULL 0 Null ticket extension 4323TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 4324 2 TE-TYPE-PKCROSS-KDC (I have reservations) 4325TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 4326TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 4327 5 TE-TYPE-DEST-HOST (I have reservations) 4328 4329alternate authentication type method-type value 4330reserved values 0-63 4331ATT-CHALLENGE-RESPONSE 64 4332 4333transited encoding type tr-type value 4334DOMAIN-X500-COMPRESS 1 4335reserved values all others 4336 4337Label Value Meaning or MIT code 4338 4339pvno 5 current Kerberos protocol version number 4340 4341message types 4342 4343KRB_AS_REQ 10 Request for initial authentication 4344KRB_AS_REP 11 Response to KRB_AS_REQ request 4345KRB_TGS_REQ 12 Request for authentication based on TGT 4346KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4347 4348 4349draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4350 4351KRB_AP_REQ 14 application request to server 4352KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4353KRB_SAFE 20 Safe (checksummed) application message 4354KRB_PRIV 21 Private (encrypted) application message 4355KRB_CRED 22 Private (encrypted) message to forward credentials 4356KRB_ERROR 30 Error response 4357 4358name types 4359 4360KRB_NT_UNKNOWN 0 Name type not known 4361KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4362KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4363KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 4364KRB_NT_SRV_XHST 4 Service with host as remaining components 4365KRB_NT_UID 5 Unique ID 4366KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4367 4368error codes 4369 4370KDC_ERR_NONE 0 No error 4371KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4372KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4373KDC_ERR_BAD_PVNO 3 Requested protocol version number not 4374 supported 4375KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 4376KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 4377KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4378KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4379KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 4380KDC_ERR_NULL_KEY 9 The client or server has a null key 4381KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4382KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 4383KDC_ERR_POLICY 12 KDC policy rejects request 4384KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4385KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4386KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4387KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4388KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4389KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4390KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4391KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4392KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4393KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4394KDC_ERR_KEY_EXPIRED 23 Password has expired - change password 4395 to reset 4396KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 4397KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 4398KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 4399KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 4400KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 4401KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 4402KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4403KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4404KRB_AP_ERR_REPEAT 34 Request is a replay 4405KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4406KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4407 4408 4409draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4410 4411KRB_AP_ERR_SKEW 37 Clock skew too great 4412KRB_AP_ERR_BADADDR 38 Incorrect net address 4413KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4414KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4415KRB_AP_ERR_MODIFIED 41 Message stream modified 4416KRB_AP_ERR_BADORDER 42 Message out of order 4417KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 4418KRB_AP_ERR_NOKEY 45 Service key not available 4419KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4420KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4421KRB_AP_ERR_METHOD 48 Alternative authentication method required 4422KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4423KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 4424KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 4425KRB_ERR_GENERIC 60 Generic error (description in e-text) 4426KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 4427KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 4428KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 4429KDC_ERROR_INVALID_SIG 64 (pkinit) 4430KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 4431KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 4432 44339. Interoperability requirements 4434 4435Version 5 of the Kerberos protocol supports a myriad of options. Among these 4436are multiple encryption and checksum types, alternative encoding schemes for 4437the transited field, optional mechanisms for pre-authentication, the 4438handling of tickets with no addresses, options for mutual authentication, 4439user to user authentication, support for proxies, forwarding, postdating, 4440and renewing tickets, the format of realm names, and the handling of 4441authorization data. 4442 4443In order to ensure the interoperability of realms, it is necessary to define 4444a minimal configuration which must be supported by all implementations. This 4445minimal configuration is subject to change as technology does. For example, 4446if at some later date it is discovered that one of the required encryption 4447or checksum algorithms is not secure, it will be replaced. 4448 44499.1. Specification 2 4450 4451This section defines the second specification of these options. 4452Implementations which are configured in this way can be said to support 4453Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may 4454be found in RFC1510. 4455 4456Transport 4457 4458TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance 4459to specification 2. Kerberos clients claiming conformance to specification 2 4460must support UDP/IP transport for messages with the KDC and may support 4461TCP/IP transport. 4462 4463Encryption and checksum methods 4464 4465 4466 4467draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4468 4469The following encryption and checksum mechanisms must be supported. 4470Implementations may support other mechanisms as well, but the additional 4471mechanisms may only be used when communicating with principals known to also 4472support them: This list is to be determined. 4473 4474Encryption: DES-CBC-MD5 4475Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 4476 4477Realm Names 4478 4479All implementations must understand hierarchical realms in both the Internet 4480Domain and the X.500 style. When a ticket granting ticket for an unknown 4481realm is requested, the KDC must be able to determine the names of the 4482intermediate realms between the KDCs realm and the requested realm. 4483 4484Transited field encoding 4485 4486DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 4487Alternative encodings may be supported, but they may be used only when that 4488encoding is supported by ALL intermediate realms. 4489 4490Pre-authentication methods 4491 4492The TGS-REQ method must be supported. The TGS-REQ method is not used on the 4493initial request. The PA-ENC-TIMESTAMP method must be supported by clients 4494but whether it is enabled by default may be determined on a realm by realm 4495basis. If not used in the initial request and the error 4496KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 4497acceptable method, the client should retry the initial request using the 4498PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 4499PA-ENC-TIMESTAMP method, but if not supported the server should ignore the 4500presence of PA-ENC-TIMESTAMP pre-authentication in a request. 4501 4502Mutual authentication 4503 4504Mutual authentication (via the KRB_AP_REP message) must be supported. 4505 4506Ticket addresses and flags 4507 4508All KDC's must pass on tickets that carry no addresses (i.e. if a TGT 4509contains no addresses, the KDC will return derivative tickets), but each 4510realm may set its own policy for issuing such tickets, and each application 4511server will set its own policy with respect to accepting them. 4512 4513Proxies and forwarded tickets must be supported. Individual realms and 4514application servers can set their own policy on when such tickets will be 4515accepted. 4516 4517All implementations must recognize renewable and postdated tickets, but need 4518not actually implement them. If these options are not supported, the 4519starttime and endtime in the ticket shall specify a ticket's entire useful 4520life. When a postdated ticket is decoded by a server, all implementations 4521shall make the presence of the postdated flag visible to the calling server. 4522 4523 4524 4525draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4526 4527User-to-user authentication 4528 4529Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option) 4530must be provided by implementations, but individual realms may decide as a 4531matter of policy to reject such requests on a per-principal or realm-wide 4532basis. 4533 4534Authorization data 4535 4536Implementations must pass all authorization data subfields from 4537ticket-granting tickets to any derivative tickets unless directed to 4538suppress a subfield as part of the definition of that registered subfield 4539type (it is never incorrect to pass on a subfield, and no registered 4540subfield types presently specify suppression at the KDC). 4541 4542Implementations must make the contents of any authorization data subfields 4543available to the server when a ticket is used. Implementations are not 4544required to allow clients to specify the contents of the authorization data 4545fields. 4546 45479.2. Recommended KDC values 4548 4549Following is a list of recommended values for a KDC implementation, based on 4550the list of suggested configuration constants (see section 4.4). 4551 4552minimum lifetime 5 minutes 4553maximum renewable lifetime 1 week 4554maximum ticket lifetime 1 day 4555empty addresses only when suitable restrictions appear 4556 in authorization data 4557proxiable, etc. Allowed. 4558 455910. REFERENCES 4560 4561[NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- 4562 cation Service for Computer Networks," IEEE Communica- 4563 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). 4564 4565[MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 4566 Saltzer, Section E.2.1: Kerberos Authentication and 4567 Authorization System, M.I.T. Project Athena, Cambridge, 4568 Massachusetts (December 21, 1987). 4569 4570[SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 4571 beros: An Authentication Service for Open Network Sys- 4572 tems," pp. 191-202 in Usenix Conference Proceedings, 4573 Dallas, Texas (February, 1988). 4574 4575[NS78] Roger M. Needham and Michael D. Schroeder, "Using 4576 Encryption for Authentication in Large Networks of Com- 4577 puters," Communications of the ACM, Vol. 21(12), 4578 pp. 993-999 (December, 1978). 4579 4580[DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- 4581 4582 4583draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4584 4585 stamps in Key Distribution Protocols," Communications 4586 of the ACM, Vol. 24(8), pp. 533-536 (August 1981). 4587 4588[KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 4589 "The Evolution of the Kerberos Authentication Service," 4590 in an IEEE Computer Society Text soon to be published 4591 (June 1992). 4592 4593[Neu93] B. Clifford Neuman, "Proxy-Based Authorization and 4594 Accounting for Distributed Systems," in Proceedings of 4595 the 13th International Conference on Distributed Com- 4596 puting Systems, Pittsburgh, PA (May, 1993). 4597 4598[DS90] Don Davis and Ralph Swick, "Workstation Services and 4599 Kerberos Authentication at Project Athena," Technical 4600 Memorandum TM-424, MIT Laboratory for Computer Science 4601 (February 1990). 4602 4603[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 4604 merfeld, and K. Raeburn, Section E.1: Service Manage- 4605 ment System, M.I.T. Project Athena, Cambridge, Mas- 4606 sachusetts (1987). 4607 4608[X509-88] CCITT, Recommendation X.509: The Directory Authentica- 4609 tion Framework, December 1988. 4610 4611[Pat92]. J. Pato, Using Pre-Authentication to Avoid Password 4612 Guessing Attacks, Open Software Foundation DCE Request 4613 for Comments 26 (December 1992). 4614 4615[DES77] National Bureau of Standards, U.S. Department of Com- 4616 merce, "Data Encryption Standard," Federal Information 4617 Processing Standards Publication 46, Washington, DC 4618 (1977). 4619 4620[DESM80] National Bureau of Standards, U.S. Department of Com- 4621 merce, "DES Modes of Operation," Federal Information 4622 Processing Standards Publication 81, Springfield, VA 4623 (December 1980). 4624 4625[SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message 4626 Integrity in Cryptographic Protocols," in Proceedings 4627 of the IEEE Symposium on Research in Security and 4628 Privacy, Oakland, California (May 1992). 4629 4630[IS3309] International Organization for Standardization, "ISO 4631 Information Processing Systems - Data Communication - 4632 High-Level Data Link Control Procedure - Frame Struc- 4633 ture," IS 3309 (October 1984). 3rd Edition. 4634 4635[MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC 4636 1320, MIT Laboratory for Computer Science (April 4637 1992). 4638 4639 4640 4641draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4642 4643[MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC 4644 1321, MIT Laboratory for Computer Science (April 4645 1992). 4646 4647[KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- 4648 Hashing for Message Authentication," Working Draft 4649 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 4650 4651A. Pseudo-code for protocol processing 4652 4653This appendix provides pseudo-code describing how the messages are to be 4654constructed and interpreted by clients and servers. 4655 4656A.1. KRB_AS_REQ generation 4657 4658 request.pvno := protocol version; /* pvno = 5 */ 4659 request.msg-type := message type; /* type = KRB_AS_REQ */ 4660 4661 if(pa_enc_timestamp_required) then 4662 request.padata.padata-type = PA-ENC-TIMESTAMP; 4663 get system_time; 4664 padata-body.patimestamp,pausec = system_time; 4665 encrypt padata-body into request.padata.padata-value 4666 using client.key; /* derived from password */ 4667 endif 4668 4669 body.kdc-options := users's preferences; 4670 body.cname := user's name; 4671 body.realm := user's realm; 4672 body.sname := service's name; /* usually "krbtgt", "localrealm" */ 4673 if (body.kdc-options.POSTDATED is set) then 4674 body.from := requested starting time; 4675 else 4676 omit body.from; 4677 endif 4678 body.till := requested end time; 4679 if (body.kdc-options.RENEWABLE is set) then 4680 body.rtime := requested final renewal time; 4681 endif 4682 body.nonce := random_nonce(); 4683 body.etype := requested etypes; 4684 if (user supplied addresses) then 4685 body.addresses := user's addresses; 4686 else 4687 omit body.addresses; 4688 endif 4689 omit body.enc-authorization-data; 4690 request.req-body := body; 4691 4692 kerberos := lookup(name of local kerberos server (or servers)); 4693 send(packet,kerberos); 4694 4695 wait(for response); 4696 if (timed_out) then 4697 4698 4699draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4700 4701 retry or use alternate server; 4702 endif 4703 4704A.2. KRB_AS_REQ verification and KRB_AS_REP generation 4705 4706 decode message into req; 4707 4708 client := lookup(req.cname,req.realm); 4709 server := lookup(req.sname,req.realm); 4710 4711 get system_time; 4712 kdc_time := system_time.seconds; 4713 4714 if (!client) then 4715 /* no client in Database */ 4716 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 4717 endif 4718 if (!server) then 4719 /* no server in Database */ 4720 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 4721 endif 4722 4723 if(client.pa_enc_timestamp_required and 4724 pa_enc_timestamp not present) then 4725 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 4726 endif 4727 4728 if(pa_enc_timestamp present) then 4729 decrypt req.padata-value into decrypted_enc_timestamp 4730 using client.key; 4731 using auth_hdr.authenticator.subkey; 4732 if (decrypt_error()) then 4733 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4734 if(decrypted_enc_timestamp is not within allowable skew) then 4735 error_out(KDC_ERR_PREAUTH_FAILED); 4736 endif 4737 if(decrypted_enc_timestamp and usec is replay) 4738 error_out(KDC_ERR_PREAUTH_FAILED); 4739 endif 4740 add decrypted_enc_timestamp and usec to replay cache; 4741 endif 4742 4743 use_etype := first supported etype in req.etypes; 4744 4745 if (no support for req.etypes) then 4746 error_out(KDC_ERR_ETYPE_NOSUPP); 4747 endif 4748 4749 new_tkt.vno := ticket version; /* = 5 */ 4750 new_tkt.sname := req.sname; 4751 new_tkt.srealm := req.srealm; 4752 reset all flags in new_tkt.flags; 4753 4754 /* It should be noted that local policy may affect the */ 4755 4756 4757draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4758 4759 /* processing of any of these flags. For example, some */ 4760 /* realms may refuse to issue renewable tickets */ 4761 4762 if (req.kdc-options.FORWARDABLE is set) then 4763 set new_tkt.flags.FORWARDABLE; 4764 endif 4765 if (req.kdc-options.PROXIABLE is set) then 4766 set new_tkt.flags.PROXIABLE; 4767 endif 4768 4769 if (req.kdc-options.ALLOW-POSTDATE is set) then 4770 set new_tkt.flags.MAY-POSTDATE; 4771 endif 4772 if ((req.kdc-options.RENEW is set) or 4773 (req.kdc-options.VALIDATE is set) or 4774 (req.kdc-options.PROXY is set) or 4775 (req.kdc-options.FORWARDED is set) or 4776 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 4777 error_out(KDC_ERR_BADOPTION); 4778 endif 4779 4780 new_tkt.session := random_session_key(); 4781 new_tkt.cname := req.cname; 4782 new_tkt.crealm := req.crealm; 4783 new_tkt.transited := empty_transited_field(); 4784 4785 new_tkt.authtime := kdc_time; 4786 4787 if (req.kdc-options.POSTDATED is set) then 4788 if (against_postdate_policy(req.from)) then 4789 error_out(KDC_ERR_POLICY); 4790 endif 4791 set new_tkt.flags.POSTDATED; 4792 set new_tkt.flags.INVALID; 4793 new_tkt.starttime := req.from; 4794 else 4795 omit new_tkt.starttime; /* treated as authtime when omitted */ 4796 endif 4797 if (req.till = 0) then 4798 till := infinity; 4799 else 4800 till := req.till; 4801 endif 4802 4803 new_tkt.endtime := min(till, 4804 new_tkt.starttime+client.max_life, 4805 new_tkt.starttime+server.max_life, 4806 new_tkt.starttime+max_life_for_realm); 4807 4808 if ((req.kdc-options.RENEWABLE-OK is set) and 4809 (new_tkt.endtime < req.till)) then 4810 /* we set the RENEWABLE option for later processing */ 4811 set req.kdc-options.RENEWABLE; 4812 req.rtime := req.till; 4813 4814 4815draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4816 4817 endif 4818 4819 if (req.rtime = 0) then 4820 rtime := infinity; 4821 else 4822 rtime := req.rtime; 4823 endif 4824 4825 if (req.kdc-options.RENEWABLE is set) then 4826 set new_tkt.flags.RENEWABLE; 4827 new_tkt.renew-till := min(rtime, 4828 new_tkt.starttime+client.max_rlife, 4829 new_tkt.starttime+server.max_rlife, 4830 new_tkt.starttime+max_rlife_for_realm); 4831 else 4832 omit new_tkt.renew-till; /* only present if RENEWABLE */ 4833 endif 4834 4835 if (req.addresses) then 4836 new_tkt.caddr := req.addresses; 4837 else 4838 omit new_tkt.caddr; 4839 endif 4840 4841 new_tkt.authorization_data := empty_authorization_data(); 4842 4843 encode to-be-encrypted part of ticket into OCTET STRING; 4844 new_tkt.enc-part := encrypt OCTET STRING 4845 using etype_for_key(server.key), server.key, server.p_kvno; 4846 4847 /* Start processing the response */ 4848 4849 resp.pvno := 5; 4850 resp.msg-type := KRB_AS_REP; 4851 resp.cname := req.cname; 4852 resp.crealm := req.realm; 4853 resp.ticket := new_tkt; 4854 4855 resp.key := new_tkt.session; 4856 resp.last-req := fetch_last_request_info(client); 4857 resp.nonce := req.nonce; 4858 resp.key-expiration := client.expiration; 4859 resp.flags := new_tkt.flags; 4860 4861 resp.authtime := new_tkt.authtime; 4862 resp.starttime := new_tkt.starttime; 4863 resp.endtime := new_tkt.endtime; 4864 4865 if (new_tkt.flags.RENEWABLE) then 4866 resp.renew-till := new_tkt.renew-till; 4867 endif 4868 4869 resp.realm := new_tkt.realm; 4870 resp.sname := new_tkt.sname; 4871 4872 4873draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4874 4875 4876 resp.caddr := new_tkt.caddr; 4877 4878 encode body of reply into OCTET STRING; 4879 4880 resp.enc-part := encrypt OCTET STRING 4881 using use_etype, client.key, client.p_kvno; 4882 send(resp); 4883 4884A.3. KRB_AS_REP verification 4885 4886 decode response into resp; 4887 4888 if (resp.msg-type = KRB_ERROR) then 4889 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 4890 set pa_enc_timestamp_required; 4891 goto KRB_AS_REQ; 4892 endif 4893 process_error(resp); 4894 return; 4895 endif 4896 4897 /* On error, discard the response, and zero the session key */ 4898 /* from the response immediately */ 4899 4900 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 4901 resp.padata); 4902 unencrypted part of resp := decode of decrypt of resp.enc-part 4903 using resp.enc-part.etype and key; 4904 zero(key); 4905 4906 if (common_as_rep_tgs_rep_checks fail) then 4907 destroy resp.key; 4908 return error; 4909 endif 4910 4911 if near(resp.princ_exp) then 4912 print(warning message); 4913 endif 4914 save_for_later(ticket,session,client,server,times,flags); 4915 4916A.4. KRB_AS_REP and KRB_TGS_REP common checks 4917 4918 if (decryption_error() or 4919 (req.cname != resp.cname) or 4920 (req.realm != resp.crealm) or 4921 (req.sname != resp.sname) or 4922 (req.realm != resp.realm) or 4923 (req.nonce != resp.nonce) or 4924 (req.addresses != resp.caddr)) then 4925 destroy resp.key; 4926 return KRB_AP_ERR_MODIFIED; 4927 endif 4928 4929 4930 4931draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4932 4933 /* make sure no flags are set that shouldn't be, and that all that */ 4934 /* should be are set */ 4935 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 4936 destroy resp.key; 4937 return KRB_AP_ERR_MODIFIED; 4938 endif 4939 4940 if ((req.from = 0) and 4941 (resp.starttime is not within allowable skew)) then 4942 destroy resp.key; 4943 return KRB_AP_ERR_SKEW; 4944 endif 4945 if ((req.from != 0) and (req.from != resp.starttime)) then 4946 destroy resp.key; 4947 return KRB_AP_ERR_MODIFIED; 4948 endif 4949 if ((req.till != 0) and (resp.endtime > req.till)) then 4950 destroy resp.key; 4951 return KRB_AP_ERR_MODIFIED; 4952 endif 4953 4954 if ((req.kdc-options.RENEWABLE is set) and 4955 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 4956 destroy resp.key; 4957 return KRB_AP_ERR_MODIFIED; 4958 endif 4959 if ((req.kdc-options.RENEWABLE-OK is set) and 4960 (resp.flags.RENEWABLE) and 4961 (req.till != 0) and 4962 (resp.renew-till > req.till)) then 4963 destroy resp.key; 4964 return KRB_AP_ERR_MODIFIED; 4965 endif 4966 4967A.5. KRB_TGS_REQ generation 4968 4969 /* Note that make_application_request might have to recursivly */ 4970 /* call this routine to get the appropriate ticket-granting ticket */ 4971 4972 request.pvno := protocol version; /* pvno = 5 */ 4973 request.msg-type := message type; /* type = KRB_TGS_REQ */ 4974 4975 body.kdc-options := users's preferences; 4976 /* If the TGT is not for the realm of the end-server */ 4977 /* then the sname will be for a TGT for the end-realm */ 4978 /* and the realm of the requested ticket (body.realm) */ 4979 /* will be that of the TGS to which the TGT we are */ 4980 /* sending applies */ 4981 body.sname := service's name; 4982 body.realm := service's realm; 4983 4984 if (body.kdc-options.POSTDATED is set) then 4985 body.from := requested starting time; 4986 else 4987 4988 4989draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 4990 4991 omit body.from; 4992 endif 4993 body.till := requested end time; 4994 if (body.kdc-options.RENEWABLE is set) then 4995 body.rtime := requested final renewal time; 4996 endif 4997 body.nonce := random_nonce(); 4998 body.etype := requested etypes; 4999 if (user supplied addresses) then 5000 body.addresses := user's addresses; 5001 else 5002 omit body.addresses; 5003 endif 5004 5005 body.enc-authorization-data := user-supplied data; 5006 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5007 body.additional-tickets_ticket := second TGT; 5008 endif 5009 5010 request.req-body := body; 5011 check := generate_checksum (req.body,checksumtype); 5012 5013 request.padata[0].padata-type := PA-TGS-REQ; 5014 request.padata[0].padata-value := create a KRB_AP_REQ using 5015 the TGT and checksum 5016 5017 /* add in any other padata as required/supplied */ 5018 5019 kerberos := lookup(name of local kerberose server (or servers)); 5020 send(packet,kerberos); 5021 5022 wait(for response); 5023 if (timed_out) then 5024 retry or use alternate server; 5025 endif 5026 5027A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5028 5029 /* note that reading the application request requires first 5030 determining the server for which a ticket was issued, and choosing the 5031 correct key for decryption. The name of the server appears in the 5032 plaintext part of the ticket. */ 5033 5034 if (no KRB_AP_REQ in req.padata) then 5035 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5036 endif 5037 verify KRB_AP_REQ in req.padata; 5038 5039 /* Note that the realm in which the Kerberos server is operating is 5040 determined by the instance from the ticket-granting ticket. The realm 5041 in the ticket-granting ticket is the realm under which the ticket 5042 granting ticket was issued. It is possible for a single Kerberos 5043 server to support more than one realm. */ 5044 5045 5046 5047draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5048 5049 auth_hdr := KRB_AP_REQ; 5050 tgt := auth_hdr.ticket; 5051 5052 if (tgt.sname is not a TGT for local realm and is not req.sname) then 5053 error_out(KRB_AP_ERR_NOT_US); 5054 5055 realm := realm_tgt_is_for(tgt); 5056 5057 decode remainder of request; 5058 5059 if (auth_hdr.authenticator.cksum is missing) then 5060 error_out(KRB_AP_ERR_INAPP_CKSUM); 5061 endif 5062 5063 if (auth_hdr.authenticator.cksum type is not supported) then 5064 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5065 endif 5066 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 5067 error_out(KRB_AP_ERR_INAPP_CKSUM); 5068 endif 5069 5070 set computed_checksum := checksum(req); 5071 if (computed_checksum != auth_hdr.authenticatory.cksum) then 5072 error_out(KRB_AP_ERR_MODIFIED); 5073 endif 5074 5075 server := lookup(req.sname,realm); 5076 5077 if (!server) then 5078 if (is_foreign_tgt_name(req.sname)) then 5079 server := best_intermediate_tgs(req.sname); 5080 else 5081 /* no server in Database */ 5082 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5083 endif 5084 endif 5085 5086 session := generate_random_session_key(); 5087 5088 use_etype := first supported etype in req.etypes; 5089 5090 if (no support for req.etypes) then 5091 error_out(KDC_ERR_ETYPE_NOSUPP); 5092 endif 5093 5094 new_tkt.vno := ticket version; /* = 5 */ 5095 new_tkt.sname := req.sname; 5096 new_tkt.srealm := realm; 5097 reset all flags in new_tkt.flags; 5098 5099 /* It should be noted that local policy may affect the */ 5100 /* processing of any of these flags. For example, some */ 5101 /* realms may refuse to issue renewable tickets */ 5102 5103 5104 5105draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5106 5107 new_tkt.caddr := tgt.caddr; 5108 resp.caddr := NULL; /* We only include this if they change */ 5109 if (req.kdc-options.FORWARDABLE is set) then 5110 if (tgt.flags.FORWARDABLE is reset) then 5111 error_out(KDC_ERR_BADOPTION); 5112 endif 5113 set new_tkt.flags.FORWARDABLE; 5114 endif 5115 if (req.kdc-options.FORWARDED is set) then 5116 if (tgt.flags.FORWARDABLE is reset) then 5117 error_out(KDC_ERR_BADOPTION); 5118 endif 5119 set new_tkt.flags.FORWARDED; 5120 new_tkt.caddr := req.addresses; 5121 resp.caddr := req.addresses; 5122 endif 5123 if (tgt.flags.FORWARDED is set) then 5124 set new_tkt.flags.FORWARDED; 5125 endif 5126 5127 if (req.kdc-options.PROXIABLE is set) then 5128 if (tgt.flags.PROXIABLE is reset) 5129 error_out(KDC_ERR_BADOPTION); 5130 endif 5131 set new_tkt.flags.PROXIABLE; 5132 endif 5133 if (req.kdc-options.PROXY is set) then 5134 if (tgt.flags.PROXIABLE is reset) then 5135 error_out(KDC_ERR_BADOPTION); 5136 endif 5137 set new_tkt.flags.PROXY; 5138 new_tkt.caddr := req.addresses; 5139 resp.caddr := req.addresses; 5140 endif 5141 5142 if (req.kdc-options.ALLOW-POSTDATE is set) then 5143 if (tgt.flags.MAY-POSTDATE is reset) 5144 error_out(KDC_ERR_BADOPTION); 5145 endif 5146 set new_tkt.flags.MAY-POSTDATE; 5147 endif 5148 if (req.kdc-options.POSTDATED is set) then 5149 if (tgt.flags.MAY-POSTDATE is reset) then 5150 error_out(KDC_ERR_BADOPTION); 5151 endif 5152 set new_tkt.flags.POSTDATED; 5153 set new_tkt.flags.INVALID; 5154 if (against_postdate_policy(req.from)) then 5155 error_out(KDC_ERR_POLICY); 5156 endif 5157 new_tkt.starttime := req.from; 5158 endif 5159 5160 if (req.kdc-options.VALIDATE is set) then 5161 5162 5163draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5164 5165 if (tgt.flags.INVALID is reset) then 5166 error_out(KDC_ERR_POLICY); 5167 endif 5168 if (tgt.starttime > kdc_time) then 5169 error_out(KRB_AP_ERR_NYV); 5170 endif 5171 if (check_hot_list(tgt)) then 5172 error_out(KRB_AP_ERR_REPEAT); 5173 endif 5174 tkt := tgt; 5175 reset new_tkt.flags.INVALID; 5176 endif 5177 5178 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 5179 and those already processed) is set) then 5180 error_out(KDC_ERR_BADOPTION); 5181 endif 5182 5183 new_tkt.authtime := tgt.authtime; 5184 5185 if (req.kdc-options.RENEW is set) then 5186 /* Note that if the endtime has already passed, the ticket would */ 5187 /* have been rejected in the initial authentication stage, so */ 5188 /* there is no need to check again here */ 5189 if (tgt.flags.RENEWABLE is reset) then 5190 error_out(KDC_ERR_BADOPTION); 5191 endif 5192 if (tgt.renew-till < kdc_time) then 5193 error_out(KRB_AP_ERR_TKT_EXPIRED); 5194 endif 5195 tkt := tgt; 5196 new_tkt.starttime := kdc_time; 5197 old_life := tgt.endttime - tgt.starttime; 5198 new_tkt.endtime := min(tgt.renew-till, 5199 new_tkt.starttime + old_life); 5200 else 5201 new_tkt.starttime := kdc_time; 5202 if (req.till = 0) then 5203 till := infinity; 5204 else 5205 till := req.till; 5206 endif 5207 new_tkt.endtime := min(till, 5208 new_tkt.starttime+client.max_life, 5209 new_tkt.starttime+server.max_life, 5210 new_tkt.starttime+max_life_for_realm, 5211 tgt.endtime); 5212 5213 if ((req.kdc-options.RENEWABLE-OK is set) and 5214 (new_tkt.endtime < req.till) and 5215 (tgt.flags.RENEWABLE is set) then 5216 /* we set the RENEWABLE option for later processing */ 5217 set req.kdc-options.RENEWABLE; 5218 req.rtime := min(req.till, tgt.renew-till); 5219 5220 5221draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5222 5223 endif 5224 endif 5225 5226 if (req.rtime = 0) then 5227 rtime := infinity; 5228 else 5229 rtime := req.rtime; 5230 endif 5231 5232 if ((req.kdc-options.RENEWABLE is set) and 5233 (tgt.flags.RENEWABLE is set)) then 5234 set new_tkt.flags.RENEWABLE; 5235 new_tkt.renew-till := min(rtime, 5236 new_tkt.starttime+client.max_rlife, 5237 new_tkt.starttime+server.max_rlife, 5238 new_tkt.starttime+max_rlife_for_realm, 5239 tgt.renew-till); 5240 else 5241 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 5242 endif 5243 if (req.enc-authorization-data is present) then 5244 decrypt req.enc-authorization-data into decrypted_authorization_data 5245 using auth_hdr.authenticator.subkey; 5246 if (decrypt_error()) then 5247 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5248 endif 5249 endif 5250 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 5251 decrypted_authorization_data; 5252 5253 new_tkt.key := session; 5254 new_tkt.crealm := tgt.crealm; 5255 new_tkt.cname := req.auth_hdr.ticket.cname; 5256 5257 if (realm_tgt_is_for(tgt) := tgt.realm) then 5258 /* tgt issued by local realm */ 5259 new_tkt.transited := tgt.transited; 5260 else 5261 /* was issued for this realm by some other realm */ 5262 if (tgt.transited.tr-type not supported) then 5263 error_out(KDC_ERR_TRTYPE_NOSUPP); 5264 endif 5265 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 5266 /* Don't check tranited field if TGT for foreign realm, 5267 * or requested not to check */ 5268 if (is_not_foreign_tgt_name(new_tkt.server) 5269 && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then 5270 /* Check it, so end-server does not have to 5271 * but don't fail, end-server may still accept it */ 5272 if (check_transited_field(new_tkt.transited) == OK) 5273 set new_tkt.flags.TRANSITED-POLICY-CHECKED; 5274 endif 5275 endif 5276 endif 5277 5278 5279draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5280 5281 5282 encode encrypted part of new_tkt into OCTET STRING; 5283 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 5284 if (server not specified) then 5285 server = req.second_ticket.client; 5286 endif 5287 if ((req.second_ticket is not a TGT) or 5288 (req.second_ticket.client != server)) then 5289 error_out(KDC_ERR_POLICY); 5290 endif 5291 5292 new_tkt.enc-part := encrypt OCTET STRING using 5293 using etype_for_key(second-ticket.key), second-ticket.key; 5294 else 5295 new_tkt.enc-part := encrypt OCTET STRING 5296 using etype_for_key(server.key), server.key, server.p_kvno; 5297 endif 5298 5299 resp.pvno := 5; 5300 resp.msg-type := KRB_TGS_REP; 5301 resp.crealm := tgt.crealm; 5302 resp.cname := tgt.cname; 5303 resp.ticket := new_tkt; 5304 5305 resp.key := session; 5306 resp.nonce := req.nonce; 5307 resp.last-req := fetch_last_request_info(client); 5308 resp.flags := new_tkt.flags; 5309 5310 resp.authtime := new_tkt.authtime; 5311 resp.starttime := new_tkt.starttime; 5312 resp.endtime := new_tkt.endtime; 5313 5314 omit resp.key-expiration; 5315 5316 resp.sname := new_tkt.sname; 5317 resp.realm := new_tkt.realm; 5318 5319 if (new_tkt.flags.RENEWABLE) then 5320 resp.renew-till := new_tkt.renew-till; 5321 endif 5322 5323 encode body of reply into OCTET STRING; 5324 5325 if (req.padata.authenticator.subkey) 5326 resp.enc-part := encrypt OCTET STRING using use_etype, 5327 req.padata.authenticator.subkey; 5328 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 5329 5330 send(resp); 5331 5332A.7. KRB_TGS_REP verification 5333 5334 decode response into resp; 5335 5336 5337draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5338 5339 5340 if (resp.msg-type = KRB_ERROR) then 5341 process_error(resp); 5342 return; 5343 endif 5344 5345 /* On error, discard the response, and zero the session key from 5346 the response immediately */ 5347 5348 if (req.padata.authenticator.subkey) 5349 unencrypted part of resp := decode of decrypt of resp.enc-part 5350 using resp.enc-part.etype and subkey; 5351 else unencrypted part of resp := decode of decrypt of resp.enc-part 5352 using resp.enc-part.etype and tgt's session key; 5353 if (common_as_rep_tgs_rep_checks fail) then 5354 destroy resp.key; 5355 return error; 5356 endif 5357 5358 check authorization_data as necessary; 5359 save_for_later(ticket,session,client,server,times,flags); 5360 5361A.8. Authenticator generation 5362 5363 body.authenticator-vno := authenticator vno; /* = 5 */ 5364 body.cname, body.crealm := client name; 5365 if (supplying checksum) then 5366 body.cksum := checksum; 5367 endif 5368 get system_time; 5369 body.ctime, body.cusec := system_time; 5370 if (selecting sub-session key) then 5371 select sub-session key; 5372 body.subkey := sub-session key; 5373 endif 5374 if (using sequence numbers) then 5375 select initial sequence number; 5376 body.seq-number := initial sequence; 5377 endif 5378 5379A.9. KRB_AP_REQ generation 5380 5381 obtain ticket and session_key from cache; 5382 5383 packet.pvno := protocol version; /* 5 */ 5384 packet.msg-type := message type; /* KRB_AP_REQ */ 5385 5386 if (desired(MUTUAL_AUTHENTICATION)) then 5387 set packet.ap-options.MUTUAL-REQUIRED; 5388 else 5389 reset packet.ap-options.MUTUAL-REQUIRED; 5390 endif 5391 if (using session key for ticket) then 5392 set packet.ap-options.USE-SESSION-KEY; 5393 5394 5395draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5396 5397 else 5398 reset packet.ap-options.USE-SESSION-KEY; 5399 endif 5400 packet.ticket := ticket; /* ticket */ 5401 generate authenticator; 5402 encode authenticator into OCTET STRING; 5403 encrypt OCTET STRING into packet.authenticator using session_key; 5404 5405A.10. KRB_AP_REQ verification 5406 5407 receive packet; 5408 if (packet.pvno != 5) then 5409 either process using other protocol spec 5410 or error_out(KRB_AP_ERR_BADVERSION); 5411 endif 5412 if (packet.msg-type != KRB_AP_REQ) then 5413 error_out(KRB_AP_ERR_MSG_TYPE); 5414 endif 5415 if (packet.ticket.tkt_vno != 5) then 5416 either process using other protocol spec 5417 or error_out(KRB_AP_ERR_BADVERSION); 5418 endif 5419 if (packet.ap_options.USE-SESSION-KEY is set) then 5420 retrieve session key from ticket-granting ticket for 5421 packet.ticket.{sname,srealm,enc-part.etype}; 5422 else 5423 retrieve service key for 5424 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 5425 endif 5426 if (no_key_available) then 5427 if (cannot_find_specified_skvno) then 5428 error_out(KRB_AP_ERR_BADKEYVER); 5429 else 5430 error_out(KRB_AP_ERR_NOKEY); 5431 endif 5432 endif 5433 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 5434 if (decryption_error()) then 5435 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5436 endif 5437 decrypt packet.authenticator into decr_authenticator 5438 using decr_ticket.key; 5439 if (decryption_error()) then 5440 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5441 endif 5442 if (decr_authenticator.{cname,crealm} != 5443 decr_ticket.{cname,crealm}) then 5444 error_out(KRB_AP_ERR_BADMATCH); 5445 endif 5446 if (decr_ticket.caddr is present) then 5447 if (sender_address(packet) is not in decr_ticket.caddr) then 5448 error_out(KRB_AP_ERR_BADADDR); 5449 endif 5450 elseif (application requires addresses) then 5451 5452 5453draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5454 5455 error_out(KRB_AP_ERR_BADADDR); 5456 endif 5457 if (not in_clock_skew(decr_authenticator.ctime, 5458 decr_authenticator.cusec)) then 5459 error_out(KRB_AP_ERR_SKEW); 5460 endif 5461 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 5462 error_out(KRB_AP_ERR_REPEAT); 5463 endif 5464 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 5465 get system_time; 5466 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 5467 (decr_ticket.flags.INVALID is set)) then 5468 /* it hasn't yet become valid */ 5469 error_out(KRB_AP_ERR_TKT_NYV); 5470 endif 5471 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 5472 error_out(KRB_AP_ERR_TKT_EXPIRED); 5473 endif 5474 if (decr_ticket.transited) then 5475 /* caller may ignore the TRANSITED-POLICY-CHECKED and do 5476 * check anyway */ 5477 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then 5478 if (check_transited_field(decr_ticket.transited) then 5479 error_out(KDC_AP_PATH_NOT_ACCPETED); 5480 endif 5481 endif 5482 endif 5483 /* caller must check decr_ticket.flags for any pertinent details */ 5484 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 5485 5486A.11. KRB_AP_REP generation 5487 5488 packet.pvno := protocol version; /* 5 */ 5489 packet.msg-type := message type; /* KRB_AP_REP */ 5490 5491 body.ctime := packet.ctime; 5492 body.cusec := packet.cusec; 5493 if (selecting sub-session key) then 5494 select sub-session key; 5495 body.subkey := sub-session key; 5496 endif 5497 if (using sequence numbers) then 5498 select initial sequence number; 5499 body.seq-number := initial sequence; 5500 endif 5501 5502 encode body into OCTET STRING; 5503 5504 select encryption type; 5505 encrypt OCTET STRING into packet.enc-part; 5506 5507A.12. KRB_AP_REP verification 5508 5509 5510 5511draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5512 5513 receive packet; 5514 if (packet.pvno != 5) then 5515 either process using other protocol spec 5516 or error_out(KRB_AP_ERR_BADVERSION); 5517 endif 5518 if (packet.msg-type != KRB_AP_REP) then 5519 error_out(KRB_AP_ERR_MSG_TYPE); 5520 endif 5521 cleartext := decrypt(packet.enc-part) using ticket's session key; 5522 if (decryption_error()) then 5523 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5524 endif 5525 if (cleartext.ctime != authenticator.ctime) then 5526 error_out(KRB_AP_ERR_MUT_FAIL); 5527 endif 5528 if (cleartext.cusec != authenticator.cusec) then 5529 error_out(KRB_AP_ERR_MUT_FAIL); 5530 endif 5531 if (cleartext.subkey is present) then 5532 save cleartext.subkey for future use; 5533 endif 5534 if (cleartext.seq-number is present) then 5535 save cleartext.seq-number for future verifications; 5536 endif 5537 return(AUTHENTICATION_SUCCEEDED); 5538 5539A.13. KRB_SAFE generation 5540 5541 collect user data in buffer; 5542 5543 /* assemble packet: */ 5544 packet.pvno := protocol version; /* 5 */ 5545 packet.msg-type := message type; /* KRB_SAFE */ 5546 5547 body.user-data := buffer; /* DATA */ 5548 if (using timestamp) then 5549 get system_time; 5550 body.timestamp, body.usec := system_time; 5551 endif 5552 if (using sequence numbers) then 5553 body.seq-number := sequence number; 5554 endif 5555 body.s-address := sender host addresses; 5556 if (only one recipient) then 5557 body.r-address := recipient host address; 5558 endif 5559 checksum.cksumtype := checksum type; 5560 compute checksum over body; 5561 checksum.checksum := checksum value; /* checksum.checksum */ 5562 packet.cksum := checksum; 5563 packet.safe-body := body; 5564 5565A.14. KRB_SAFE verification 5566 5567 5568 5569draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5570 5571 receive packet; 5572 if (packet.pvno != 5) then 5573 either process using other protocol spec 5574 or error_out(KRB_AP_ERR_BADVERSION); 5575 endif 5576 if (packet.msg-type != KRB_SAFE) then 5577 error_out(KRB_AP_ERR_MSG_TYPE); 5578 endif 5579 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 5580 error_out(KRB_AP_ERR_INAPP_CKSUM); 5581 endif 5582 if (safe_priv_common_checks_ok(packet)) then 5583 set computed_checksum := checksum(packet.body); 5584 if (computed_checksum != packet.checksum) then 5585 error_out(KRB_AP_ERR_MODIFIED); 5586 endif 5587 return (packet, PACKET_IS_GENUINE); 5588 else 5589 return common_checks_error; 5590 endif 5591 5592A.15. KRB_SAFE and KRB_PRIV common checks 5593 5594 if (packet.s-address != O/S_sender(packet)) then 5595 /* O/S report of sender not who claims to have sent it */ 5596 error_out(KRB_AP_ERR_BADADDR); 5597 endif 5598 if ((packet.r-address is present) and 5599 (packet.r-address != local_host_address)) then 5600 /* was not sent to proper place */ 5601 error_out(KRB_AP_ERR_BADADDR); 5602 endif 5603 if (((packet.timestamp is present) and 5604 (not in_clock_skew(packet.timestamp,packet.usec))) or 5605 (packet.timestamp is not present and timestamp expected)) then 5606 error_out(KRB_AP_ERR_SKEW); 5607 endif 5608 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 5609 error_out(KRB_AP_ERR_REPEAT); 5610 endif 5611 5612 if (((packet.seq-number is present) and 5613 ((not in_sequence(packet.seq-number)))) or 5614 (packet.seq-number is not present and sequence expected)) then 5615 error_out(KRB_AP_ERR_BADORDER); 5616 endif 5617 if (packet.timestamp not present and packet.seq-number not present) 5618 then 5619 error_out(KRB_AP_ERR_MODIFIED); 5620 endif 5621 5622 save_identifier(packet.{timestamp,usec,s-address}, 5623 sender_principal(packet)); 5624 5625 return PACKET_IS_OK; 5626 5627 5628draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5629 5630 5631A.16. KRB_PRIV generation 5632 5633 collect user data in buffer; 5634 5635 /* assemble packet: */ 5636 packet.pvno := protocol version; /* 5 */ 5637 packet.msg-type := message type; /* KRB_PRIV */ 5638 5639 packet.enc-part.etype := encryption type; 5640 5641 body.user-data := buffer; 5642 if (using timestamp) then 5643 get system_time; 5644 body.timestamp, body.usec := system_time; 5645 endif 5646 if (using sequence numbers) then 5647 body.seq-number := sequence number; 5648 endif 5649 body.s-address := sender host addresses; 5650 if (only one recipient) then 5651 body.r-address := recipient host address; 5652 endif 5653 5654 encode body into OCTET STRING; 5655 5656 select encryption type; 5657 encrypt OCTET STRING into packet.enc-part.cipher; 5658 5659A.17. KRB_PRIV verification 5660 5661 receive packet; 5662 if (packet.pvno != 5) then 5663 either process using other protocol spec 5664 or error_out(KRB_AP_ERR_BADVERSION); 5665 endif 5666 if (packet.msg-type != KRB_PRIV) then 5667 error_out(KRB_AP_ERR_MSG_TYPE); 5668 endif 5669 5670 cleartext := decrypt(packet.enc-part) using negotiated key; 5671 if (decryption_error()) then 5672 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5673 endif 5674 5675 if (safe_priv_common_checks_ok(cleartext)) then 5676 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 5677 else 5678 return common_checks_error; 5679 endif 5680 5681A.18. KRB_CRED generation 5682 5683 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 5684 5685 5686draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5687 5688 5689 /* assemble packet: */ 5690 packet.pvno := protocol version; /* 5 */ 5691 packet.msg-type := message type; /* KRB_CRED */ 5692 5693 for (tickets[n] in tickets to be forwarded) do 5694 packet.tickets[n] = tickets[n].ticket; 5695 done 5696 5697 packet.enc-part.etype := encryption type; 5698 5699 for (ticket[n] in tickets to be forwarded) do 5700 body.ticket-info[n].key = tickets[n].session; 5701 body.ticket-info[n].prealm = tickets[n].crealm; 5702 body.ticket-info[n].pname = tickets[n].cname; 5703 body.ticket-info[n].flags = tickets[n].flags; 5704 body.ticket-info[n].authtime = tickets[n].authtime; 5705 body.ticket-info[n].starttime = tickets[n].starttime; 5706 body.ticket-info[n].endtime = tickets[n].endtime; 5707 body.ticket-info[n].renew-till = tickets[n].renew-till; 5708 body.ticket-info[n].srealm = tickets[n].srealm; 5709 body.ticket-info[n].sname = tickets[n].sname; 5710 body.ticket-info[n].caddr = tickets[n].caddr; 5711 done 5712 5713 get system_time; 5714 body.timestamp, body.usec := system_time; 5715 5716 if (using nonce) then 5717 body.nonce := nonce; 5718 endif 5719 5720 if (using s-address) then 5721 body.s-address := sender host addresses; 5722 endif 5723 if (limited recipients) then 5724 body.r-address := recipient host address; 5725 endif 5726 5727 encode body into OCTET STRING; 5728 5729 select encryption type; 5730 encrypt OCTET STRING into packet.enc-part.cipher 5731 using negotiated encryption key; 5732 5733A.19. KRB_CRED verification 5734 5735 receive packet; 5736 if (packet.pvno != 5) then 5737 either process using other protocol spec 5738 or error_out(KRB_AP_ERR_BADVERSION); 5739 endif 5740 if (packet.msg-type != KRB_CRED) then 5741 error_out(KRB_AP_ERR_MSG_TYPE); 5742 5743 5744draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5745 5746 endif 5747 5748 cleartext := decrypt(packet.enc-part) using negotiated key; 5749 if (decryption_error()) then 5750 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5751 endif 5752 if ((packet.r-address is present or required) and 5753 (packet.s-address != O/S_sender(packet)) then 5754 /* O/S report of sender not who claims to have sent it */ 5755 error_out(KRB_AP_ERR_BADADDR); 5756 endif 5757 if ((packet.r-address is present) and 5758 (packet.r-address != local_host_address)) then 5759 /* was not sent to proper place */ 5760 error_out(KRB_AP_ERR_BADADDR); 5761 endif 5762 if (not in_clock_skew(packet.timestamp,packet.usec)) then 5763 error_out(KRB_AP_ERR_SKEW); 5764 endif 5765 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 5766 error_out(KRB_AP_ERR_REPEAT); 5767 endif 5768 if (packet.nonce is required or present) and 5769 (packet.nonce != expected-nonce) then 5770 error_out(KRB_AP_ERR_MODIFIED); 5771 endif 5772 5773 for (ticket[n] in tickets that were forwarded) do 5774 save_for_later(ticket[n],key[n],principal[n], 5775 server[n],times[n],flags[n]); 5776 return 5777 5778A.20. KRB_ERROR generation 5779 5780 /* assemble packet: */ 5781 packet.pvno := protocol version; /* 5 */ 5782 packet.msg-type := message type; /* KRB_ERROR */ 5783 5784 get system_time; 5785 packet.stime, packet.susec := system_time; 5786 packet.realm, packet.sname := server name; 5787 5788 if (client time available) then 5789 packet.ctime, packet.cusec := client_time; 5790 endif 5791 packet.error-code := error code; 5792 if (client name available) then 5793 packet.cname, packet.crealm := client name; 5794 endif 5795 if (error text available) then 5796 packet.e-text := error text; 5797 endif 5798 if (error data available) then 5799 packet.e-data := error data; 5800 5801 5802draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5803 5804 endif 5805 5806B. Definition of common authorization data elements 5807 5808This appendix contains the definitions of common authorization data 5809elements. These common authorization data elements are recursivly defined, 5810meaning the ad-data for these types will itself contain a sequence of 5811authorization data whose interpretation is affected by the encapsulating 5812element. Depending on the meaning of the encapsulating element, the 5813encapsulated elements may be ignored, might be interpreted as issued 5814directly by the KDC, or they might be stored in a separate plaintext part of 5815the ticket. The types of the encapsulating elements are specified as part of 5816the Kerberos specification ebcause the behavior based on these values should 5817be understood across implementations whereas other elements need only be 5818understood by the applications which they affect. 5819 5820In the definitions that follow, the value of the ad-type for the element 5821will be specified in the subsection number, and the value of the ad-data 5822will be as shown in the ASN.1 structure that follows the subsection heading. 5823 5824B.1. KDC Issued 5825 5826AD-KDCIssued SEQUENCE { 5827 ad-checksum[0] Checksum, 5828 i-realm[1] Realm OPTIONAL, 5829 i-sname[2] PrincipalName OPTIONAL, 5830 elements[3] AuthorizationData. 5831} 5832 5833ad-checksum 5834 A checksum over the elements field using a cryptographic checksum 5835 method that is identical to the checksum used to protect the ticket 5836 itself (i.e. using the same hash function and the same encryption 5837 algorithm used to encrypt the ticket) and using a key derived from the 5838 same key used to protect the ticket. 5839i-realm, i-sname 5840 The name of the issuing principal if different from the KDC itself. 5841 This field would be used when the KDC can verify the authenticity of 5842 elements signed by the issuing principal and it allows this KDC to 5843 notify the application server of the validity of those elements. 5844elements 5845 A sequence of authorization data elements issued by the KDC. 5846 5847The KDC-issued ad-data field is intended to provide a means for Kerberos 5848principal credentials to embed within themselves privilege attributes and 5849other mechanisms for positive authorization, amplifying the priveleges of 5850the principal beyond what can be done using a credentials without such an 5851a-data element. 5852 5853This can not be provided without this element because the definition of the 5854authorization-data field allows elements to be added at will by the bearer 5855of a TGT at the time that they request service tickets and elements may also 5856be added to a delegated ticket by inclusion in the authenticator. 5857 5858 5859 5860draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5861 5862For KDC-issued elements this is prevented because the elements are signed by 5863the KDC by including a checksum encrypted using the server's key (the same 5864key used to encrypt the ticket - or a key derived from that key). Elements 5865encapsulated with in the KDC-issued element will be ignored by the 5866application server if this "signature" is not present. Further, elements 5867encapsulated within this element from a ticket granting ticket may be 5868interpreted by the KDC, and used as a basis according to policy for 5869including new signed elements within derivative tickets, but they will not 5870be copied to a derivative ticket directly. If they are copied directly to a 5871derivative ticket by a KDC that is not aware of this element, the signature 5872will not be correct for the application ticket elements, and the field will 5873be ignored by the application server. 5874 5875This element and the elements it encapulates may be safely ignored by 5876applications, application servers, and KDCs that do not implement this 5877element. 5878 5879B.2. Intended for server 5880 5881AD-INTENDED-FOR-SERVER SEQUENCE { 5882 intended-server[0] SEQUENCE OF PrincipalName 5883 elements[1] AuthorizationData 5884} 5885 5886AD elements encapsulated within the intended-for-server element may be 5887ignored if the application server is not in the list of principal names of 5888intended servers. Further, a KDC issuing a ticket for an application server 5889can remove this element if the application server is not in the list of 5890intended servers. 5891 5892Application servers should check for their principal name in the 5893intended-server field of this element. If their principal name is not found, 5894this element should be ignored. If found, then the encapsulated elements 5895should be evaluated in the same manner as if they were present in the top 5896level authorization data field. Applications and application servers that do 5897not implement this element should reject tickets that contain authorization 5898data elements of this type. 5899 5900B.3. Intended for application class 5901 5902AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] 5903SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements 5904encapsulated within the intended-for-application-class element may be 5905ignored if the application server is not in one of the named classes of 5906application servers. Examples of application server classes include 5907"FILESYSTEM", and other kinds of servers. 5908 5909This element and the elements it encapulates may be safely ignored by 5910applications, application servers, and KDCs that do not implement this 5911element. 5912 5913B.4. If relevant 5914 5915AD-IF-RELEVANT AuthorizationData 5916 5917 5918draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5919 5920 5921AD elements encapsulated within the if-relevant element are intended for 5922interpretation only by application servers that understand the particular 5923ad-type of the embedded element. Application servers that do not understand 5924the type of an element embedded within the if-relevant element may ignore 5925the uninterpretable element. This element promotes interoperability across 5926implementations which may have local extensions for authorization. 5927 5928B.5. And-Or 5929 5930AD-AND-OR SEQUENCE { 5931 condition-count[0] INTEGER, 5932 elements[1] AuthorizationData 5933} 5934 5935When restrictive AD elements encapsulated within the and-or element are 5936encountered, only the number specified in condition-count of the 5937encapsulated conditions must be met in order to satisfy this element. This 5938element may be used to implement an "or" operation by setting the 5939condition-count field to 1, and it may specify an "and" operation by setting 5940the condition count to the number of embedded elements. Application servers 5941that do not implement this element must reject tickets that contain 5942authorization data elements of this type. 5943 5944B.6. Mandatory ticket extensions 5945 5946AD-Mandatory-Ticket-Extensions Checksum 5947 5948An authorization data element of type mandatory-ticket-extensions specifies 5949a collision-proof checksum using the same has angorithm used to protect the 5950integrity of the ticket itself. This checksum will be calculated over the 5951entire extensions field. If there are more than one extension, all will be 5952covered by the checksum. This restriction indicates that the ticket should 5953not be accepted if the checksum does not match that calculated over the 5954ticket extensions. Application servers that do not implement this element 5955must reject tickets that contain authorization data elements of this type. 5956 5957B.7. Authorization Data in ticket extensions 5958 5959AD-IN-Ticket-Extensions Checksum 5960 5961An authorization data element of type in-ticket-extensions specifies a 5962collision-proof checksum using the same has angorithm used to protect the 5963integrity of the ticket itself. This checksum is calculated over a separate 5964external AuthorizationData field carried in the ticket extensions. 5965Application servers that do not implement this element must reject tickets 5966that contain authorization data elements of this type. Application servers 5967that do implement this element will search the ticket extensions for 5968authorization data fields, calculate the specified checksum over each 5969authorization data field and look for one matching the checksum in this 5970in-ticket-extensions element. If not found, then the ticket must be 5971rejected. If found, the corresponding authorization data elements will be 5972interpreted in the same manner as if they were contained in the top level 5973authorization data field. 5974 5975 5976draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 5977 5978 5979Note that if multiple external authorization data fields are present in a 5980ticket, each will have a corresponding element of type in-ticket-extensions 5981in the top level authorization data field, and the external entries will be 5982linked to the corresponding element by their checksums. 5983 5984C. Definition of common ticket extensions 5985 5986This appendix contains the definitions of common ticket extensions. Support 5987for these extensions is optional. However, certain extensions have 5988associated authorization data elements that may require rejection of a 5989ticket containing an extension by application servers that do not implement 5990the particular extension. Other extensions have been defined beyond those 5991described in this specification. Such extensions are described elswhere and 5992for some of those extensions the reserved number may be found in the list of 5993constants. 5994 5995It is known that older versions of Kerberos did not support this field, and 5996that some clients will strip this field from a ticket when they parse and 5997then reassemble a ticket as it is passed to the application servers. The 5998presence of the extension will not break such clients, but any functionaly 5999dependent on the extensions will not work when such tickets are handled by 6000old clients. In such situations, some implementation may use alternate 6001methods to transmit the information in the extensions field. 6002 6003C.1. Null ticket extension 6004 6005TE-NullExtension OctetString -- The empty Octet String 6006 6007The te-data field in the null ticket extension is an octet string of lenght 6008zero. This extension may be included in a ticket granting ticket so that the 6009KDC can determine on presentation of the ticket granting ticket whether the 6010client software will strip the extensions field. 6011 6012C.2. External Authorization Data 6013 6014TE-ExternalAuthorizationData AuthorizationData 6015 6016The te-data field in the external authorization data ticket extension is 6017field of type AuthorizationData containing one or more authorization data 6018elements. If present, a corresponding authorization data element will be 6019present in the primary authorization data for the ticket and that element 6020will contain a checksum of the external authorization data ticket extension. 6021---------------------------------------------------------------------------- 6022[TM] Project Athena, Athena, and Kerberos are trademarks of the 6023Massachusetts Institute of Technology (MIT). No commercial use of these 6024trademarks may be made without prior written permission of MIT. 6025 6026[1] Note, however, that many applications use Kerberos' functions only upon 6027the initiation of a stream-based network connection. Unless an application 6028subsequently provides integrity protection for the data stream, the identity 6029verification applies only to the initiation of the connection, and does not 6030guarantee that subsequent messages on the connection originate from the same 6031principal. 6032 6033 6034draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 6035 6036 6037[2] Secret and private are often used interchangeably in the literature. In 6038our usage, it takes two (or more) to share a secret, thus a shared DES key 6039is a secret key. Something is only private when no one but its owner knows 6040it. Thus, in public key cryptosystems, one has a public and a private key. 6041 6042[3] Of course, with appropriate permission the client could arrange 6043registration of a separately-named prin- cipal in a remote realm, and engage 6044in normal exchanges with that realm's services. However, for even small 6045numbers of clients this becomes cumbersome, and more automatic methods as 6046described here are necessary. 6047 6048[4] Though it is permissible to request or issue tick- ets with no network 6049addresses specified. 6050 6051[5] The password-changing request must not be honored unless the requester 6052can provide the old password (the user's current secret key). Otherwise, it 6053would be possible for someone to walk up to an unattended ses- sion and 6054change another user's password. 6055 6056[6] To authenticate a user logging on to a local system, the credentials 6057obtained in the AS exchange may first be used in a TGS exchange to obtain 6058credentials for a local server. Those credentials must then be verified by a 6059local server through successful completion of the Client/Server exchange. 6060 6061[7] "Random" means that, among other things, it should be impossible to 6062guess the next session key based on knowledge of past session keys. This can 6063only be achieved in a pseudo-random number generator if it is based on 6064cryptographic principles. It is more desirable to use a truly random number 6065generator, such as one based on measurements of random physical phenomena. 6066 6067[8] Tickets contain both an encrypted and unencrypted portion, so cleartext 6068here refers to the entire unit, which can be copied from one message and 6069replayed in another without any cryptographic skill. 6070 6071[9] Note that this can make applications based on unreliable transports 6072difficult to code correctly. If the transport might deliver duplicated 6073messages, either a new authenticator must be generated for each retry, or 6074the application server must match requests and replies and replay the first 6075reply in response to a detected duplicate. 6076 6077[10] This is used for user-to-user authentication as described in [8]. 6078 6079[11] Note that the rejection here is restricted to authenticators from the 6080same principal to the same server. Other client principals communicating 6081with the same server principal should not be have their authenticators 6082rejected if the time and microsecond fields happen to match some other 6083client's authenticator. 6084 6085[12] In the Kerberos version 4 protocol, the timestamp in the reply was the 6086client's timestamp plus one. This is not necessary in version 5 because 6087version 5 messages are formatted in such a way that it is not possible to 6088create the reply by judicious message surgery (even in encrypted form) 6089without knowledge of the appropriate encryption keys. 6090 6091 6092draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 6093 6094 6095[13] Note that for encrypting the KRB_AP_REP message, the sub-session key is 6096not used, even if present in the Authenticator. 6097 6098[14] Implementations of the protocol may wish to provide routines to choose 6099subkeys based on session keys and random numbers and to generate a 6100negotiated key to be returned in the KRB_AP_REP message. 6101 6102[15]This can be accomplished in several ways. It might be known beforehand 6103(since the realm is part of the principal identifier), it might be stored in 6104a nameserver, or it might be obtained from a configura- tion file. If the 6105realm to be used is obtained from a nameserver, there is a danger of being 6106spoofed if the nameservice providing the realm name is not authenti- cated. 6107This might result in the use of a realm which has been compromised, and 6108would result in an attacker's ability to compromise the authentication of 6109the application server to the client. 6110 6111[16] If the client selects a sub-session key, care must be taken to ensure 6112the randomness of the selected sub- session key. One approach would be to 6113generate a random number and XOR it with the session key from the 6114ticket-granting ticket. 6115 6116[17] This allows easy implementation of user-to-user authentication [8], 6117which uses ticket-granting ticket session keys in lieu of secret server keys 6118in situa- tions where such secret keys could be easily comprom- ised. 6119 6120[18] For the purpose of appending, the realm preceding the first listed 6121realm is considered to be the null realm (""). 6122 6123[19] For the purpose of interpreting null subfields, the client's realm is 6124considered to precede those in the transited field, and the server's realm 6125is considered to follow them. 6126 6127[20] This means that a client and server running on the same host and 6128communicating with one another using the KRB_SAFE messages should not share 6129a common replay cache to detect KRB_SAFE replays. 6130 6131[21] The implementation of the Kerberos server need not combine the database 6132and the server on the same machine; it is feasible to store the principal 6133database in, say, a network name service, as long as the entries stored 6134therein are protected from disclosure to and modification by unauthorized 6135parties. However, we recommend against such strategies, as they can make 6136system management and threat analysis quite complex. 6137 6138[22] See the discussion of the padata field in section 5.4.2 for details on 6139why this can be useful. 6140 6141[23] Warning for implementations that unpack and repack data structures 6142during the generation and verification of embedded checksums: Because any 6143checksums applied to data structures must be checked against the original 6144data the length of bit strings must be preserved within a data structure 6145between the time that a checksum is generated through transmission to the 6146time that the checksum is verified. 6147 6148 6149 6150draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 6151 6152[24] It is NOT recommended that this time value be used to adjust the 6153workstation's clock since the workstation cannot reliably determine that 6154such a KRB_AS_REP actually came from the proper KDC in a timely manner. 6155 6156[25] Note, however, that if the time is used as the nonce, one must make 6157sure that the workstation time is monotonically increasing. If the time is 6158ever reset backwards, there is a small, but finite, probability that a nonce 6159will be reused. 6160 6161[27] An application code in the encrypted part of a message provides an 6162additional check that the message was decrypted properly. 6163 6164[29] An application code in the encrypted part of a message provides an 6165additional check that the message was decrypted properly. 6166 6167[31] An application code in the encrypted part of a message provides an 6168additional check that the message was decrypted properly. 6169 6170[32] If supported by the encryption method in use, an initialization vector 6171may be passed to the encryption procedure, in order to achieve proper cipher 6172chaining. The initialization vector might come from the last block of the 6173ciphertext from the previous KRB_PRIV message, but it is the application's 6174choice whether or not to use such an initialization vector. If left out, the 6175default initialization vector for the encryption algorithm will be used. 6176 6177[33] This prevents an attacker who generates an incorrect AS request from 6178obtaining verifiable plaintext for use in an off-line password guessing 6179attack. 6180 6181[35] In the above specification, UNTAGGED OCTET STRING(length) is the 6182notation for an octet string with its tag and length removed. It is not a 6183valid ASN.1 type. The tag bits and length must be removed from the 6184confounder since the purpose of the confounder is so that the message starts 6185with random data, but the tag and its length are fixed. For other fields, 6186the length and tag would be redundant if they were included because they are 6187specified by the encryption type. [36] The ordering of the fields in the 6188CipherText is important. Additionally, messages encoded in this format must 6189include a length as part of the msg-seq field. This allows the recipient to 6190verify that the message has not been truncated. Without a length, an 6191attacker could use a chosen plaintext attack to generate a message which 6192could be truncated, while leaving the checksum intact. Note that if the 6193msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length 6194is part of that encoding. 6195 6196[37] In some cases, it may be necessary to use a different "mix-in" string 6197for compatibility reasons; see the discussion of padata in section 5.4.2. 6198 6199[38] In some cases, it may be necessary to use a different "mix-in" string 6200for compatibility reasons; see the discussion of padata in section 5.4.2. 6201 6202[39] A variant of the key is used to limit the use of a key to a particular 6203function, separating the functions of generating a checksum from other 6204encryption performed using the session key. The constant F0F0F0F0F0F0F0F0 6205was chosen because it maintains key parity. The properties of DES precluded 6206 6207 6208draft-ietf-cat-kerberos-r-01 Expires 21 May 1998 6209 6210the use of the complement. The same constant is used for similar purpose in 6211the Message Integrity Check in the Privacy Enhanced Mail standard. 6212 6213[40] This error carries additional information in the e- data field. The 6214contents of the e-data field for this message is described in section 5.9.1. 6215