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