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