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