1 2INTERNET-DRAFT Clifford Neuman 3 John Kohl 4 Theodore Ts'o 5 11 July 1997 6 7 8 9 The Kerberos Network Authentication Service (V5) 10 11 12STATUS OF THIS MEMO 13 14 This document is an Internet-Draft. Internet-Drafts 15are working documents of the Internet Engineering Task Force 16(IETF), its areas, and its working groups. Note that other 17groups may also distribute working documents as Internet- 18Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum 21of six months and may be updated, replaced, or obsoleted by 22other documents at any time. It is inappropriate to use 23Internet-Drafts as reference material or to cite them other 24than as "work in progress." 25 26 To learn the current status of any Internet-Draft, 27please check the "1id-abstracts.txt" listing contained in 28the Internet-Drafts Shadow Directories on ds.internic.net 29(US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US 30West Coast), or munnari.oz.au (Pacific Rim). 31 32 The distribution of this memo is unlimited. It is 33filed as draft-ietf-cat-kerberos-revisions-00.txt, and expires 3411 January 1998. Please send comments to: 35 36 krb-protocol@MIT.EDU 37 38ABSTRACT 39 40 41 This document provides an overview and specification of 42Version 5 of the Kerberos protocol, and updates RFC1510 to 43clarify aspects of the protocol and its intended use that 44require more detailed or clearer explanation than was pro- 45vided in RFC1510. This document is intended to provide a 46detailed description of the protocol, suitable for implemen- 47tation, together with descriptions of the appropriate use of 48protocol messages and fields within those messages. 49 50 This document is not intended to describe Kerberos to 51__________________________ 52Project Athena, Athena, and Kerberos are trademarks of 53the Massachusetts Institute of Technology (MIT). No 54commercial use of these trademarks may be made without 55prior written permission of MIT. 56 57 58 59Overview - 1 - Expires 11 January 1998 60 61 62 63 64 65 66 67 Version 5 - Specification Revision 6 68 69 70the end user, system administrator, or application 71developer. Higher level papers describing Version 5 of the 72Kerberos system [1] and documenting version 4 [23], are 73available elsewhere. 74 75OVERVIEW 76 77 This INTERNET-DRAFT describes the concepts and model 78upon which the Kerberos network authentication system is 79based. It also specifies Version 5 of the Kerberos proto- 80col. 81 82 The motivations, goals, assumptions, and rationale 83behind most design decisions are treated cursorily; they are 84more fully described in a paper available in IEEE communica- 85tions [1] and earlier in the Kerberos portion of the Athena 86Technical Plan [2]. The protocols have been a proposed 87standard and are being considered for advancement for draft 88standard through the IETF standard process. Comments are 89encouraged on the presentation, but only minor refinements 90to the protocol as implemented or extensions that fit within 91current protocol framework will be considered at this time. 92 93 Requests for addition to an electronic mailing list for 94discussion of Kerberos, kerberos@MIT.EDU, may be addressed 95to kerberos-request@MIT.EDU. This mailing list is gatewayed 96onto the Usenet as the group comp.protocols.kerberos. 97Requests for further information, including documents and 98code availability, may be sent to info-kerberos@MIT.EDU. 99 100BACKGROUND 101 102 The Kerberos model is based in part on Needham and 103Schroeder's trusted third-party authentication protocol [4] 104and on modifications suggested by Denning and Sacco [5]. 105The original design and implementation of Kerberos Versions 1061 through 4 was the work of two former Project Athena staff 107members, Steve Miller of Digital Equipment Corporation and 108Clifford Neuman (now at the Information Sciences Institute 109of the University of Southern California), along with Jerome 110Saltzer, Technical Director of Project Athena, and Jeffrey 111Schiller, MIT Campus Network Manager. Many other members of 112Project Athena have also contributed to the work on Ker- 113beros. 114 115 Version 5 of the Kerberos protocol (described in this 116document) has evolved from Version 4 based on new require- 117ments and desires for features not available in Version 4. 118The design of Version 5 of the Kerberos protocol was led by 119Clifford Neuman and John Kohl with much input from the com- 120munity. The development of the MIT reference implementation 121was led at MIT by John Kohl and Theodore T'so, with help and 122contributed code from many others. Reference implementa- 123tions of both version 4 and version 5 of Kerberos are pub- 124licly available and commercial implementations have been 125 126Overview - 2 - Expires 11 January 1998 127 128 129 130 131 132 133 134 Version 5 - Specification Revision 6 135 136 137developed and are widely used. 138 139 Details on the differences between Kerberos Versions 4 140and 5 can be found in [6]. 141 1421. Introduction 143 144 Kerberos provides a means of verifying the identities 145of principals, (e.g. a workstation user or a network server) 146on an open (unprotected) network. This is accomplished 147without relying on assertions by the host operating system, 148without basing trust on host addresses, without requiring 149physical security of all the hosts on the network, and under 150the assumption that packets traveling along the network can 151be read, modified, and inserted at will[1]. Kerberos per- 152forms authentication under these conditions as a trusted 153third-party authentication service by using conventional 154(shared secret key[2]) cryptography. Kerberos extensions 155have been proposed and implemented that provide for the use 156of public key cryptography during certain phases of the 157authentication protocol. These extensions provide for 158authentication of users registered with public key certifi- 159cation authorities, and allow the system to provide certain 160benefits of public key cryptography in situations where they 161are needed. 162 163 The basic Kerberos authentication process proceeds as 164follows: A client sends a request to the authentication 165server (AS) requesting "credentials" for a given server. 166The AS responds with these credentials, encrypted in the 167client's key. The credentials consist of 1) a "ticket" for 168the server and 2) a temporary encryption key (often called a 169"session key"). The client transmits the ticket (which con- 170tains the client's identity and a copy of the session key, 171all encrypted in the server's key) to the server. The ses- 172sion key (now shared by the client and server) is used to 173authenticate the client, and may optionally be used to 174__________________________ 175[1] Note, however, that many applications use Kerberos' 176functions only upon the initiation of a stream-based 177network connection. Unless an application subsequently 178provides integrity protection for the data stream, the 179identity verification applies only to the initiation of 180the connection, and does not guarantee that subsequent 181messages on the connection originate from the same 182principal. 183[2] Secret and private are often used interchangeably 184in the literature. In our usage, it takes two (or 185more) to share a secret, thus a shared DES key is a 186secret key. Something is only private when no one but 187its owner knows it. Thus, in public key cryptosystems, 188one has a public and a private key. 189 190 191 192Section 1. - 3 - Expires 11 January 1998 193 194 195 196 197 198 199 200 Version 5 - Specification Revision 6 201 202 203authenticate the server. It may also be used to encrypt 204further communication between the two parties or to exchange 205a separate sub-session key to be used to encrypt further 206communication. 207 208 Implementation of the basic protocol consists of one or 209more authentication servers running on physically secure 210hosts. The authentication servers maintain a database of 211principals (i.e., users and servers) and their secret keys. 212Code libraries provide encryption and implement the Kerberos 213protocol. In order to add authentication to its transac- 214tions, a typical network application adds one or two calls 215to the Kerberos library directly or through the Generic 216Security Services Application Programming Interface, GSSAPI, 217described in separate document. These calls result in the 218transmission of the necessary messages to achieve authenti- 219cation. 220 221 The Kerberos protocol consists of several sub-protocols 222(or exchanges). There are two basic methods by which a 223client can ask a Kerberos server for credentials. In the 224first approach, the client sends a cleartext request for a 225ticket for the desired server to the AS. The reply is sent 226encrypted in the client's secret key. Usually this request 227is for a ticket-granting ticket (TGT) which can later be 228used with the ticket-granting server (TGS). In the second 229method, the client sends a request to the TGS. The client 230uses the TGT to authenticate itself to the TGS in the same 231manner as if it were contacting any other application server 232that requires Kerberos authentication. The reply is 233encrypted in the session key from the TGT. Though the pro- 234tocol specification describes the AS and the TGS as separate 235servers, they are implemented in practice as different pro- 236tocol entry points within a single Kerberos server. 237 238 Once obtained, credentials may be used to verify the 239identity of the principals in a transaction, to ensure the 240integrity of messages exchanged between them, or to preserve 241privacy of the messages. The application is free to choose 242whatever protection may be necessary. 243 244 To verify the identities of the principals in a tran- 245saction, the client transmits the ticket to the application 246server. Since the ticket is sent "in the clear" (parts of 247it are encrypted, but this encryption doesn't thwart replay) 248and might be intercepted and reused by an attacker, addi- 249tional information is sent to prove that the message ori- 250ginated with the principal to whom the ticket was issued. 251This information (called the authenticator) is encrypted in 252the session key, and includes a timestamp. The timestamp 253proves that the message was recently generated and is not a 254replay. Encrypting the authenticator in the session key 255proves that it was generated by a party possessing the ses- 256sion key. Since no one except the requesting principal and 257 258 259Section 1. - 4 - Expires 11 January 1998 260 261 262 263 264 265 266 267 Version 5 - Specification Revision 6 268 269 270the server know the session key (it is never sent over the 271network in the clear) this guarantees the identity of the 272client. 273 274 The integrity of the messages exchanged between princi- 275pals can also be guaranteed using the session key (passed in 276the ticket and contained in the credentials). This approach 277provides detection of both replay attacks and message stream 278modification attacks. It is accomplished by generating and 279transmitting a collision-proof checksum (elsewhere called a 280hash or digest function) of the client's message, keyed with 281the session key. Privacy and integrity of the messages 282exchanged between principals can be secured by encrypting 283the data to be passed using the session key contained in the 284ticket or the subsession key found in the authenticator. 285 286 The authentication exchanges mentioned above require 287read-only access to the Kerberos database. Sometimes, how- 288ever, the entries in the database must be modified, such as 289when adding new principals or changing a principal's key. 290This is done using a protocol between a client and a third 291Kerberos server, the Kerberos Administration Server (KADM). 292There is also a protocol for maintaining multiple copies of 293the Kerberos database. Neither of these protocols are 294described in this document. 295 2961.1. Cross-Realm Operation 297 298 The Kerberos protocol is designed to operate across 299organizational boundaries. A client in one organization can 300be authenticated to a server in another. Each organization 301wishing to run a Kerberos server establishes its own 302"realm". The name of the realm in which a client is 303registered is part of the client's name, and can be used by 304the end-service to decide whether to honor a request. 305 306 By establishing "inter-realm" keys, the administrators 307of two realms can allow a client authenticated in the local 308realm to prove its identity to servers in other realms[3]. 309The exchange of inter-realm keys (a separate key may be used 310for each direction) registers the ticket-granting service of 311each realm as a principal in the other realm. A client is 312then able to obtain a ticket-granting ticket for the remote 313realm's ticket-granting service from its local realm. When 314that ticket-granting ticket is used, the remote ticket- 315granting service uses the inter-realm key (which usually 316__________________________ 317[3] Of course, with appropriate permission the client 318could arrange registration of a separately-named prin- 319cipal in a remote realm, and engage in normal exchanges 320with that realm's services. However, for even small 321numbers of clients this becomes cumbersome, and more 322automatic methods as described here are necessary. 323 324 325Section 1.1. - 5 - Expires 11 January 1998 326 327 328 329 330 331 332 333 Version 5 - Specification Revision 6 334 335 336differs from its own normal TGS key) to decrypt the ticket- 337granting ticket, and is thus certain that it was issued by 338the client's own TGS. Tickets issued by the remote ticket- 339granting service will indicate to the end-service that the 340client was authenticated from another realm. 341 342 A realm is said to communicate with another realm if 343the two realms share an inter-realm key, or if the local 344realm shares an inter-realm key with an intermediate realm 345that communicates with the remote realm. An authentication 346path is the sequence of intermediate realms that are tran- 347sited in communicating from one realm to another. 348 349 Realms are typically organized hierarchically. Each 350realm shares a key with its parent and a different key with 351each child. If an inter-realm key is not directly shared by 352two realms, the hierarchical organization allows an authen- 353tication path to be easily constructed. If a hierarchical 354organization is not used, it may be necessary to consult a 355database in order to construct an authentication path 356between realms. 357 358 Although realms are typically hierarchical, intermedi- 359ate realms may be bypassed to achieve cross-realm authenti- 360cation through alternate authentication paths (these might 361be established to make communication between two realms more 362efficient). It is important for the end-service to know 363which realms were transited when deciding how much faith to 364place in the authentication process. To facilitate this 365decision, a field in each ticket contains the names of the 366realms that were involved in authenticating the client. 367 3681.2. Authorization 369 370As an authentication service, Kerberos provides a means of 371verifying the identity of principals on a network. Authen- 372tication is usually useful primarily as a first step in the 373process of authorization, determining whether a client may 374use a service, which objects the client is allowed to 375access, and the type of access allowed for each. Kerberos 376does not, by itself, provide authorization. Possession of a 377client ticket for a service provides only for authentication 378of the client to that service, and in the absence of a 379separate authorization procedure, it should not be con- 380sidered by an application as authorizing the use of that 381service. 382 383 Such separate authorization methods may be implemented 384as application specific access control functions and may be 385based on files such as the application server, or on 386separately issued authorization credentials such as those 387based on proxies [7] , or on other authorization services. 388 389 Applications should not be modified to accept the 390issuance of a service ticket by the Kerberos server (even by 391 392Section 1.2. - 6 - Expires 11 January 1998 393 394 395 396 397 398 399 400 Version 5 - Specification Revision 6 401 402 403an modified Kerberos server) as granting authority to use 404the service, since such applications may become vulnerable 405to the bypass of this authorization check in an environment 406where they interoperate with other KDCs or where other 407options for application authentication (e.g. the PKTAPP pro- 408posal) are provided. 409 4101.3. Environmental assumptions 411 412Kerberos imposes a few assumptions on the environment in 413which it can properly function: 414 415+ "Denial of service" attacks are not solved with Ker- 416 beros. There are places in these protocols where an 417 intruder can prevent an application from participating 418 in the proper authentication steps. Detection and 419 solution of such attacks (some of which can appear to 420 be not-uncommon "normal" failure modes for the system) 421 is usually best left to the human administrators and 422 users. 423 424+ Principals must keep their secret keys secret. If an 425 intruder somehow steals a principal's key, it will be 426 able to masquerade as that principal or impersonate any 427 server to the legitimate principal. 428 429+ "Password guessing" attacks are not solved by Kerberos. 430 If a user chooses a poor password, it is possible for 431 an attacker to successfully mount an offline dictionary 432 attack by repeatedly attempting to decrypt, with suc- 433 cessive entries from a dictionary, messages obtained 434 which are encrypted under a key derived from the user's 435 password. 436 437+ Each host on the network must have a clock which is 438 "loosely synchronized" to the time of the other hosts; 439 this synchronization is used to reduce the bookkeeping 440 needs of application servers when they do replay detec- 441 tion. The degree of "looseness" can be configured on a 442 per-server basis, but is typically on the order of 5 443 minutes. If the clocks are synchronized over the net- 444 work, the clock synchronization protocol must itself be 445 secured from network attackers. 446 447+ Principal identifiers are not recycled on a short-term 448 basis. A typical mode of access control will use 449 access control lists (ACLs) to grant permissions to 450 particular principals. If a stale ACL entry remains 451 for a deleted principal and the principal identifier is 452 reused, the new principal will inherit rights specified 453 in the stale ACL entry. By not re-using principal 454 identifiers, the danger of inadvertent access is 455 removed. 456 457 458 459Section 1.3. - 7 - Expires 11 January 1998 460 461 462 463 464 465 466 467 Version 5 - Specification Revision 6 468 469 4701.4. Glossary of terms 471 472Below is a list of terms used throughout this document. 473 474 475Authentication Verifying the claimed identity of a 476 principal. 477 478 479Authentication headerA record containing a Ticket and an 480 Authenticator to be presented to a 481 server as part of the authentication 482 process. 483 484 485Authentication path A sequence of intermediate realms tran- 486 sited in the authentication process when 487 communicating from one realm to another. 488 489 490Authenticator A record containing information that can 491 be shown to have been recently generated 492 using the session key known only by the 493 client and server. 494 495 496Authorization The process of determining whether a 497 client may use a service, which objects 498 the client is allowed to access, and the 499 type of access allowed for each. 500 501 502Capability A token that grants the bearer permis- 503 sion to access an object or service. In 504 Kerberos, this might be a ticket whose 505 use is restricted by the contents of the 506 authorization data field, but which 507 lists no network addresses, together 508 with the session key necessary to use 509 the ticket. 510 511 512Ciphertext The output of an encryption function. 513 Encryption transforms plaintext into 514 ciphertext. 515 516 517Client A process that makes use of a network 518 service on behalf of a user. Note that 519 in some cases a Server may itself be a 520 client of some other server (e.g. a 521 print server may be a client of a file 522 server). 523 524 525 526Section 1.4. - 8 - Expires 11 January 1998 527 528 529 530 531 532 533 534 Version 5 - Specification Revision 6 535 536 537Credentials A ticket plus the secret session key 538 necessary to successfully use that 539 ticket in an authentication exchange. 540 541 542KDC Key Distribution Center, a network ser- 543 vice that supplies tickets and temporary 544 session keys; or an instance of that 545 service or the host on which it runs. 546 The KDC services both initial ticket and 547 ticket-granting ticket requests. The 548 initial ticket portion is sometimes 549 referred to as the Authentication Server 550 (or service). The ticket-granting 551 ticket portion is sometimes referred to 552 as the ticket-granting server (or ser- 553 vice). 554 555 556Kerberos Aside from the 3-headed dog guarding 557 Hades, the name given to Project 558 Athena's authentication service, the 559 protocol used by that service, or the 560 code used to implement the authentica- 561 tion service. 562 563 564Plaintext The input to an encryption function or 565 the output of a decryption function. 566 Decryption transforms ciphertext into 567 plaintext. 568 569 570Principal A uniquely named client or server 571 instance that participates in a network 572 communication. 573 574 575Principal identifierThe name used to uniquely identify each 576 different principal. 577 578 579Seal To encipher a record containing several 580 fields in such a way that the fields 581 cannot be individually replaced without 582 either knowledge of the encryption key 583 or leaving evidence of tampering. 584 585 586Secret key An encryption key shared by a principal 587 and the KDC, distributed outside the 588 bounds of the system, with a long life- 589 time. In the case of a human user's 590 principal, the secret key is derived 591 592 593Section 1.4. - 9 - Expires 11 January 1998 594 595 596 597 598 599 600 601 Version 5 - Specification Revision 6 602 603 604 from a password. 605 606 607Server A particular Principal which provides a 608 resource to network clients. The server 609 is sometimes refered to as the Applica- 610 tion Server. 611 612 613Service A resource provided to network clients; 614 often provided by more than one server 615 (for example, remote file service). 616 617 618Session key A temporary encryption key used between 619 two principals, with a lifetime limited 620 to the duration of a single login "ses- 621 sion". 622 623 624Sub-session key A temporary encryption key used between 625 two principals, selected and exchanged 626 by the principals using the session key, 627 and with a lifetime limited to the dura- 628 tion of a single association. 629 630 631Ticket A record that helps a client authenti- 632 cate itself to a server; it contains the 633 client's identity, a session key, a 634 timestamp, and other information, all 635 sealed using the server's secret key. 636 It only serves to authenticate a client 637 when presented along with a fresh 638 Authenticator. 639 6402. Ticket flag uses and requests 641 642Each Kerberos ticket contains a set of flags which are used 643to indicate various attributes of that ticket. Most flags 644may be requested by a client when the ticket is obtained; 645some are automatically turned on and off by a Kerberos 646server as required. The following sections explain what the 647various flags mean, and gives examples of reasons to use 648such a flag. 649 6502.1. Initial and pre-authenticated tickets 651 652 The INITIAL flag indicates that a ticket was issued 653using the AS protocol and not issued based on a ticket- 654granting ticket. Application servers that want to require 655the demonstrated knowledge of a client's secret key (e.g. a 656password-changing program) can insist that this flag be set 657in any tickets they accept, and thus be assured that the 658 659 660Section 2.1. - 10 - Expires 11 January 1998 661 662 663 664 665 666 667 668 Version 5 - Specification Revision 6 669 670 671client's key was recently presented to the application 672client. 673 674 The PRE-AUTHENT and HW-AUTHENT flags provide addition 675information about the initial authentication, regardless of 676whether the current ticket was issued directly (in which 677case INITIAL will also be set) or issued on the basis of a 678ticket-granting ticket (in which case the INITIAL flag is 679clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried 680forward from the ticket-granting ticket). 681 6822.2. Invalid tickets 683 684 The INVALID flag indicates that a ticket is invalid. 685Application servers must reject tickets which have this flag 686set. A postdated ticket will usually be issued in this 687form. Invalid tickets must be validated by the KDC before 688use, by presenting them to the KDC in a TGS request with the 689VALIDATE option specified. The KDC will only validate tick- 690ets after their starttime has passed. The validation is 691required so that postdated tickets which have been stolen 692before their starttime can be rendered permanently invalid 693(through a hot-list mechanism) (see section 3.3.3.1). 694 6952.3. Renewable tickets 696 697 Applications may desire to hold tickets which can be 698valid for long periods of time. However, this can expose 699their credentials to potential theft for equally long 700periods, and those stolen credentials would be valid until 701the expiration time of the ticket(s). Simply using short- 702lived tickets and obtaining new ones periodically would 703require the client to have long-term access to its secret 704key, an even greater risk. Renewable tickets can be used to 705mitigate the consequences of theft. Renewable tickets have 706two "expiration times": the first is when the current 707instance of the ticket expires, and the second is the latest 708permissible value for an individual expiration time. An 709application client must periodically (i.e. before it 710expires) present a renewable ticket to the KDC, with the 711RENEW option set in the KDC request. The KDC will issue a 712new ticket with a new session key and a later expiration 713time. All other fields of the ticket are left unmodified by 714the renewal process. When the latest permissible expiration 715time arrives, the ticket expires permanently. At each 716renewal, the KDC may consult a hot-list to determine if the 717ticket had been reported stolen since its last renewal; it 718will refuse to renew such stolen tickets, and thus the 719usable lifetime of stolen tickets is reduced. 720 721 The RENEWABLE flag in a ticket is normally only inter- 722preted by the ticket-granting service (discussed below in 723section 3.3). It can usually be ignored by application 724servers. However, some particularly careful application 725 726 727Section 2.3. - 11 - Expires 11 January 1998 728 729 730 731 732 733 734 735 Version 5 - Specification Revision 6 736 737 738servers may wish to disallow renewable tickets. 739 740 If a renewable ticket is not renewed by its expiration 741time, the KDC will not renew the ticket. The RENEWABLE flag 742is reset by default, but a client may request it be set by 743setting the RENEWABLE option in the KRB_AS_REQ message. If 744it is set, then the renew-till field in the ticket contains 745the time after which the ticket may not be renewed. 746 7472.4. Postdated tickets 748 749 Applications may occasionally need to obtain tickets 750for use much later, e.g. a batch submission system would 751need tickets to be valid at the time the batch job is ser- 752viced. However, it is dangerous to hold valid tickets in a 753batch queue, since they will be on-line longer and more 754prone to theft. Postdated tickets provide a way to obtain 755these tickets from the KDC at job submission time, but to 756leave them "dormant" until they are activated and validated 757by a further request of the KDC. If a ticket theft were 758reported in the interim, the KDC would refuse to validate 759the ticket, and the thief would be foiled. 760 761 The MAY-POSTDATE flag in a ticket is normally only 762interpreted by the ticket-granting service. It can be 763ignored by application servers. This flag must be set in a 764ticket-granting ticket in order to issue a postdated ticket 765based on the presented ticket. It is reset by default; it 766may be requested by a client by setting the ALLOW-POSTDATE 767option in the KRB_AS_REQ message. This flag does not allow 768a client to obtain a postdated ticket-granting ticket; post- 769dated ticket-granting tickets can only by obtained by 770requesting the postdating in the KRB_AS_REQ message. The 771life (endtime-starttime) of a postdated ticket will be the 772remaining life of the ticket-granting ticket at the time of 773the request, unless the RENEWABLE option is also set, in 774which case it can be the full life (endtime-starttime) of 775the ticket-granting ticket. The KDC may limit how far in 776the future a ticket may be postdated. 777 778 The POSTDATED flag indicates that a ticket has been 779postdated. The application server can check the authtime 780field in the ticket to see when the original authentication 781occurred. Some services may choose to reject postdated 782tickets, or they may only accept them within a certain 783period after the original authentication. When the KDC 784issues a POSTDATED ticket, it will also be marked as 785INVALID, so that the application client must present the 786ticket to the KDC to be validated before use. 787 7882.5. Proxiable and proxy tickets 789 790 At times it may be necessary for a principal to allow a 791service to perform an operation on its behalf. The service 792 793 794Section 2.5. - 12 - Expires 11 January 1998 795 796 797 798 799 800 801 802 Version 5 - Specification Revision 6 803 804 805must be able to take on the identity of the client, but only 806for a particular purpose. A principal can allow a service 807to take on the principal's identity for a particular purpose 808by granting it a proxy. 809 810 The process of granting a proxy using the proxy and 811proxiable flags is used to provide credentials for use with 812specific services. Though conceptually also a proxy, user's 813wishing to delegate their identity for ANY purpose must use 814the ticket forwarding mechanism described in the next sec- 815tion to forward a ticket granting ticket. 816 817 The PROXIABLE flag in a ticket is normally only inter- 818preted by the ticket-granting service. It can be ignored by 819application servers. When set, this flag tells the ticket- 820granting server that it is OK to issue a new ticket (but not 821a ticket-granting ticket) with a different network address 822based on this ticket. This flag is set if requested by the 823client on initial authentication. By default, the client 824will request that it be set when requesting a ticket grant- 825ing ticket, and reset when requesting any other ticket. 826 827 This flag allows a client to pass a proxy to a server 828to perform a remote request on its behalf, e.g. a print ser- 829vice client can give the print server a proxy to access the 830client's files on a particular file server in order to 831satisfy a print request. 832 833 In order to complicate the use of stolen credentials, 834Kerberos tickets are usually valid from only those network 835addresses specifically included in the ticket[4]. When 836granting a proxy, the client must specify the new network 837address from which the proxy is to be used, or indicate that 838the proxy is to be issued for use from any address. 839 840 The PROXY flag is set in a ticket by the TGS when it 841issues a proxy ticket. Application servers may check this 842flag and at their option they may require additional authen- 843tication from the agent presenting the proxy in order to 844provide an audit trail. 845 8462.6. Forwardable tickets 847 848 Authentication forwarding is an instance of a proxy 849where the service is granted complete use of the client's 850identity. An example where it might be used is when a user 851logs in to a remote system and wants authentication to work 852from that system as if the login were local. 853 854 The FORWARDABLE flag in a ticket is normally only 855__________________________ 856[4] Though it is permissible to request or issue tick- 857ets with no network addresses specified. 858 859 860Section 2.6. - 13 - Expires 11 January 1998 861 862 863 864 865 866 867 868 Version 5 - Specification Revision 6 869 870 871interpreted by the ticket-granting service. It can be 872ignored by application servers. The FORWARDABLE flag has an 873interpretation similar to that of the PROXIABLE flag, except 874ticket-granting tickets may also be issued with different 875network addresses. This flag is reset by default, but users 876may request that it be set by setting the FORWARDABLE option 877in the AS request when they request their initial ticket- 878granting ticket. 879 880 This flag allows for authentication forwarding without 881requiring the user to enter a password again. If the flag 882is not set, then authentication forwarding is not permitted, 883but the same result can still be achieved if the user 884engages in the AS exchange specifying the requested network 885addresses and supplies a password. 886 887 The FORWARDED flag is set by the TGS when a client 888presents a ticket with the FORWARDABLE flag set and requests 889a forwarded ticket by specifying the FORWARDED KDC option 890and supplying a set of addresses for the new ticket. It is 891also set in all tickets issued based on tickets with the 892FORWARDED flag set. Application servers may choose to pro- 893cess FORWARDED tickets differently than non-FORWARDED tick- 894ets. 895 8962.7. Other KDC options 897 898 There are two additional options which may be set in a 899client's request of the KDC. The RENEWABLE-OK option indi- 900cates that the client will accept a renewable ticket if a 901ticket with the requested life cannot otherwise be provided. 902If a ticket with the requested life cannot be provided, then 903the KDC may issue a renewable ticket with a renew-till equal 904to the the requested endtime. The value of the renew-till 905field may still be adjusted by site-determined limits or 906limits imposed by the individual principal or server. 907 908 The ENC-TKT-IN-SKEY option is honored only by the 909ticket-granting service. It indicates that the ticket to be 910issued for the end server is to be encrypted in the session 911key from the a additional second ticket-granting ticket pro- 912vided with the request. See section 3.3.3 for specific 913details. 914 915__________________________ 916[5] The password-changing request must not be honored 917unless the requester can provide the old password (the 918user's current secret key). Otherwise, it would be 919possible for someone to walk up to an unattended ses- 920sion and change another user's password. 921[6] To authenticate a user logging on to a local sys- 922tem, the credentials obtained in the AS exchange may 923first be used in a TGS exchange to obtain credentials 924 925 926Section 3.1. - 14 - Expires 11 January 1998 927 928 929 930 931 932 933 Version 5 - Specification Revision 6 934 935 936 9373. Message Exchanges 938 939The following sections describe the interactions between 940network clients and servers and the messages involved in 941those exchanges. 942 9433.1. The Authentication Service Exchange 944 945 Summary 946 Message direction Message type Section 947 1. Client to Kerberos KRB_AS_REQ 5.4.1 948 2. Kerberos to client KRB_AS_REP or 5.4.2 949 KRB_ERROR 5.9.1 950 951 952 The Authentication Service (AS) Exchange between the 953client and the Kerberos Authentication Server is initiated 954by a client when it wishes to obtain authentication creden- 955tials for a given server but currently holds no credentials. 956In its basic form, the client's secret key is used for en- 957cryption and decryption. This exchange is typically used at 958the initiation of a login session to obtain credentials for 959a Ticket-Granting Server which will subsequently be used to 960obtain credentials for other servers (see section 3.3) 961without requiring further use of the client's secret key. 962This exchange is also used to request credentials for ser- 963vices which must not be mediated through the Ticket-Granting 964Service, but rather require a principal's secret key, such 965as the password-changing service[5]. This exchange does not 966by itself provide any assurance of the the identity of the 967user[6]. 968 969 The exchange consists of two messages: KRB_AS_REQ from 970the client to Kerberos, and KRB_AS_REP or KRB_ERROR in 971reply. The formats for these messages are described in sec- 972tions 5.4.1, 5.4.2, and 5.9.1. 973 974 In the request, the client sends (in cleartext) its own 975identity and the identity of the server for which it is 976requesting credentials. The response, KRB_AS_REP, contains 977a ticket for the client to present to the server, and a ses- 978sion key that will be shared by the client and the server. 979The session key and additional information are encrypted in 980the client's secret key. The KRB_AS_REP message contains 981information which can be used to detect replays, and to 982associate it with the message to which it replies. Various 983errors can occur; these are indicated by an error response 984(KRB_ERROR) instead of the KRB_AS_REP response. The error 985__________________________ 986for a local server. Those credentials must then be 987verified by a local server through successful comple- 988tion of the Client/Server exchange. 989 990 991 992Section 3.1. - 15 - Expires 11 January 1998 993 994 995 996 997 998 999 1000 Version 5 - Specification Revision 6 1001 1002 1003message is not encrypted. The KRB_ERROR message contains 1004information which can be used to associate it with the mes- 1005sage to which it replies. The lack of encryption in the 1006KRB_ERROR message precludes the ability to detect replays, 1007fabrications, or modifications of such messages. 1008 1009 Without preautentication, the authentication server 1010does not know whether the client is actually the principal 1011named in the request. It simply sends a reply without know- 1012ing or caring whether they are the same. This is acceptable 1013because nobody but the principal whose identity was given in 1014the request will be able to use the reply. Its critical 1015information is encrypted in that principal's key. The ini- 1016tial request supports an optional field that can be used to 1017pass additional information that might be needed for the 1018initial exchange. This field may be used for pre- 1019authentication as described in section <<sec preauth>>. 1020 10213.1.1. Generation of KRB_AS_REQ message 1022 1023 The client may specify a number of options in the ini- 1024tial request. Among these options are whether pre- 1025authentication is to be performed; whether the requested 1026ticket is to be renewable, proxiable, or forwardable; 1027whether it should be postdated or allow postdating of 1028derivative tickets; and whether a renewable ticket will be 1029accepted in lieu of a non-renewable ticket if the requested 1030ticket expiration date cannot be satisfied by a non- 1031renewable ticket (due to configuration constraints; see sec- 1032tion 4). See section A.1 for pseudocode. 1033 1034 The client prepares the KRB_AS_REQ message and sends it 1035to the KDC. 1036 10373.1.2. Receipt of KRB_AS_REQ message 1038 1039 If all goes well, processing the KRB_AS_REQ message 1040will result in the creation of a ticket for the client to 1041present to the server. The format for the ticket is 1042described in section 5.3.1. The contents of the ticket are 1043determined as follows. 1044 10453.1.3. Generation of KRB_AS_REP message 1046 1047 The authentication server looks up the client and 1048server principals named in the KRB_AS_REQ in its database, 1049extracting their respective keys. If required, the server 1050pre-authenticates the request, and if the pre-authentication 1051check fails, an error message with the code 1052KDC_ERR_PREAUTH_FAILED is returned. If the server cannot 1053accommodate the requested encryption type, an error message 1054with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it 1055generates a "random" session key[7]. 1056__________________________ 1057 1058 1059Section 3.1.3. - 16 - Expires 11 January 1998 1060 1061 1062 1063 1064 1065 1066 1067 Version 5 - Specification Revision 6 1068 1069 1070 If there are multiple encryption keys registered for a 1071client in the Kerberos database (or if the key registered 1072supports multiple encryption types; e.g. DES-CBC-CRC and 1073DES-CBC-MD5), then the etype field from the AS request is 1074used by the KDC to select the encryption method to be used 1075for encrypting the response to the client. If there is more 1076than one supported, strong encryption type in the etype 1077list, the first valid etype for which an encryption key is 1078available is used. The encryption method used to respond to 1079a TGS request is taken from the keytype of the session key 1080found in the ticket granting ticket. 1081 1082 When the etype field is present in a KDC request, 1083whether an AS or TGS request, the KDC will attempt to assign 1084the type of the random session key from the list of methods 1085in the etype field. The KDC will select the appropriate 1086type using the list of methods provided together with infor- 1087mation from the Kerberos database indicating acceptable 1088encryption methods for the application server. The KDC will 1089not issue tickets with a weak session key encryption type. 1090 1091 If the requested start time is absent, indicates a time 1092in the past, or is within the window of acceptable clock 1093skew for the KDC and the POSTDATE option has not been speci- 1094fied, then the start time of the ticket is set to the 1095authentication server's current time. If it indicates a 1096time in the future beyond the acceptable clock skew, but the 1097POSTDATED option has not been specified then the error 1098KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the 1099requested start time is checked against the policy of the 1100local realm (the administrator might decide to prohibit cer- 1101tain types or ranges of postdated tickets), and if accept- 1102able, the ticket's start time is set as requested and the 1103INVALID flag is set in the new ticket. The postdated ticket 1104must be validated before use by presenting it to the KDC 1105after the start time has been reached. 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115__________________________ 1116[7] "Random" means that, among other things, it should 1117be impossible to guess the next session key based on 1118knowledge of past session keys. This can only be 1119achieved in a pseudo-random number generator if it is 1120based on cryptographic principles. It is more desir- 1121able to use a truly random number generator, such as 1122one based on measurements of random physical phenomena. 1123 1124 1125 1126Section 3.1.3. - 17 - Expires 11 January 1998 1127 1128 1129 1130 1131 1132 1133 1134 Version 5 - Specification Revision 6 1135 1136 1137The expiration time of the ticket will be set to the minimum 1138of the following: 1139 1140+The expiration time (endtime) requested in the KRB_AS_REQ 1141 message. 1142 1143+The ticket's start time plus the maximum allowable lifetime 1144 associated with the client principal (the authentication 1145 server's database includes a maximum ticket lifetime field 1146 in each principal's record; see section 4). 1147 1148+The ticket's start time plus the maximum allowable lifetime 1149 associated with the server principal. 1150 1151+The ticket's start time plus the maximum lifetime set by 1152 the policy of the local realm. 1153 1154 If the requested expiration time minus the start time 1155(as determined above) is less than a site-determined minimum 1156lifetime, an error message with code KDC_ERR_NEVER_VALID is 1157returned. If the requested expiration time for the ticket 1158exceeds what was determined as above, and if the 1159"RENEWABLE-OK" option was requested, then the "RENEWABLE" 1160flag is set in the new ticket, and the renew-till value is 1161set as if the "RENEWABLE" option were requested (the field 1162and option names are described fully in section 5.4.1). 1163 1164If the RENEWABLE option has been requested or if the 1165RENEWABLE-OK option has been set and a renewable ticket is 1166to be issued, then the renew-till field is set to the 1167minimum of: 1168 1169+Its requested value. 1170 1171+The start time of the ticket plus the minimum of the two 1172 maximum renewable lifetimes associated with the principals' 1173 database entries. 1174 1175+The start time of the ticket plus the maximum renewable 1176 lifetime set by the policy of the local realm. 1177 1178 The flags field of the new ticket will have the follow- 1179ing options set if they have been requested and if the pol- 1180icy of the local realm allows: FORWARDABLE, MAY-POSTDATE, 1181POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is post- 1182dated (the start time is in the future), its INVALID flag 1183will also be set. 1184 1185 If all of the above succeed, the server formats a 1186KRB_AS_REP message (see section 5.4.2), copying the 1187addresses in the request into the caddr of the response, 1188placing any required pre-authentication data into the padata 1189of the response, and encrypts the ciphertext part in the 1190client's key using the requested encryption method, and 1191 1192 1193Section 3.1.3. - 18 - Expires 11 January 1998 1194 1195 1196 1197 1198 1199 1200 1201 Version 5 - Specification Revision 6 1202 1203 1204sends it to the client. See section A.2 for pseudocode. 1205 12063.1.4. Generation of KRB_ERROR message 1207 1208 Several errors can occur, and the Authentication Server 1209responds by returning an error message, KRB_ERROR, to the 1210client, with the error-code and e-text fields set to 1211appropriate values. The error message contents and details 1212are described in Section 5.9.1. 1213 12143.1.5. Receipt of KRB_AS_REP message 1215 1216 If the reply message type is KRB_AS_REP, then the 1217client verifies that the cname and crealm fields in the 1218cleartext portion of the reply match what it requested. If 1219any padata fields are present, they may be used to derive 1220the proper secret key to decrypt the message. The client 1221decrypts the encrypted part of the response using its secret 1222key, verifies that the nonce in the encrypted part matches 1223the nonce it supplied in its request (to detect replays). 1224It also verifies that the sname and srealm in the response 1225match those in the request (or are otherwise expected 1226values), and that the host address field is also correct. 1227It then stores the ticket, session key, start and expiration 1228times, and other information for later use. The key- 1229expiration field from the encrypted part of the response may 1230be checked to notify the user of impending key expiration 1231(the client program could then suggest remedial action, such 1232as a password change). See section A.3 for pseudocode. 1233 1234 Proper decryption of the KRB_AS_REP message is not suf- 1235ficient to verify the identity of the user; the user and an 1236attacker could cooperate to generate a KRB_AS_REP format 1237message which decrypts properly but is not from the proper 1238KDC. If the host wishes to verify the identity of the user, 1239it must require the user to present application credentials 1240which can be verified using a securely-stored secret key for 1241the host. If those credentials can be verified, then the 1242identity of the user can be assured. 1243 12443.1.6. Receipt of KRB_ERROR message 1245 1246 If the reply message type is KRB_ERROR, then the client 1247interprets it as an error and performs whatever 1248application-specific tasks are necessary to recover. 1249 12503.2. The Client/Server Authentication Exchange 1251 1252 Summary 1253Message direction Message type Section 1254Client to Application server KRB_AP_REQ 5.5.1 1255[optional] Application server to client KRB_AP_REP or 5.5.2 1256 KRB_ERROR 5.9.1 1257 1258 1259 1260Section 3.2. - 19 - Expires 11 January 1998 1261 1262 1263 1264 1265 1266 1267 1268 Version 5 - Specification Revision 6 1269 1270 1271 The client/server authentication (CS) exchange is used 1272by network applications to authenticate the client to the 1273server and vice versa. The client must have already 1274acquired credentials for the server using the AS or TGS 1275exchange. 1276 12773.2.1. The KRB_AP_REQ message 1278 1279 The KRB_AP_REQ contains authentication information 1280which should be part of the first message in an authenti- 1281cated transaction. It contains a ticket, an authenticator, 1282and some additional bookkeeping information (see section 12835.5.1 for the exact format). The ticket by itself is insuf- 1284ficient to authenticate a client, since tickets are passed 1285across the network in cleartext[8], so the authenticator is 1286used to prevent invalid replay of tickets by proving to the 1287server that the client knows the session key of the ticket 1288and thus is entitled to use the ticket. The KRB_AP_REQ mes- 1289sage is referred to elsewhere as the "authentication 1290header." 1291 12923.2.2. Generation of a KRB_AP_REQ message 1293 1294 When a client wishes to initiate authentication to a 1295server, it obtains (either through a credentials cache, the 1296AS exchange, or the TGS exchange) a ticket and session key 1297for the desired service. The client may re-use any tickets 1298it holds until they expire. To use a ticket the client con- 1299structs a new Authenticator from the the system time, its 1300name, and optionally an application specific checksum, an 1301initial sequence number to be used in KRB_SAFE or KRB_PRIV 1302messages, and/or a session subkey to be used in negotiations 1303for a session key unique to this particular session. 1304Authenticators may not be re-used and will be rejected if 1305replayed to a server[9]. If a sequence number is to be 1306included, it should be randomly chosen so that even after 1307many messages have been exchanged it is not likely to col- 1308lide with other sequence numbers in use. 1309 1310 The client may indicate a requirement of mutual 1311__________________________ 1312[8] Tickets contain both an encrypted and unencrypted 1313portion, so cleartext here refers to the entire unit, 1314which can be copied from one message and replayed in 1315another without any cryptographic skill. 1316[9] Note that this can make applications based on un- 1317reliable transports difficult to code correctly. If the 1318transport might deliver duplicated messages, either a 1319new authenticator must be generated for each retry, or 1320the application server must match requests and replies 1321and replay the first reply in response to a detected 1322duplicate. 1323 1324 1325 1326Section 3.2.2. - 20 - Expires 11 January 1998 1327 1328 1329 1330 1331 1332 1333 1334 Version 5 - Specification Revision 6 1335 1336 1337authentication or the use of a session-key based ticket by 1338setting the appropriate flag(s) in the ap-options field of 1339the message. 1340 1341 The Authenticator is encrypted in the session key and 1342combined with the ticket to form the KRB_AP_REQ message 1343which is then sent to the end server along with any addi- 1344tional application-specific information. See section A.9 1345for pseudocode. 1346 13473.2.3. Receipt of KRB_AP_REQ message 1348 1349 Authentication is based on the server's current time of 1350day (clocks must be loosely synchronized), the authentica- 1351tor, and the ticket. Several errors are possible. If an 1352error occurs, the server is expected to reply to the client 1353with a KRB_ERROR message. This message may be encapsulated 1354in the application protocol if its "raw" form is not accept- 1355able to the protocol. The format of error messages is 1356described in section 5.9.1. 1357 1358 The algorithm for verifying authentication information 1359is as follows. If the message type is not KRB_AP_REQ, the 1360server returns the KRB_AP_ERR_MSG_TYPE error. If the key 1361version indicated by the Ticket in the KRB_AP_REQ is not one 1362the server can use (e.g., it indicates an old key, and the 1363server no longer possesses a copy of the old key), the 1364KRB_AP_ERR_BADKEYVER error is returned. If the USE- 1365SESSION-KEY flag is set in the ap-options field, it indi- 1366cates to the server that the ticket is encrypted in the ses- 1367sion key from the server's ticket-granting ticket rather 1368than its secret key[10]. Since it is possible for the 1369server to be registered in multiple realms, with different 1370keys in each, the srealm field in the unencrypted portion of 1371the ticket in the KRB_AP_REQ is used to specify which secret 1372key the server should use to decrypt that ticket. The 1373KRB_AP_ERR_NOKEY error code is returned if the server 1374doesn't have the proper key to decipher the ticket. 1375 1376 The ticket is decrypted using the version of the 1377server's key specified by the ticket. If the decryption 1378routines detect a modification of the ticket (each encryp- 1379tion system must provide safeguards to detect modified 1380ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY 1381error is returned (chances are good that different keys were 1382used to encrypt and decrypt). 1383 1384 The authenticator is decrypted using the session key 1385extracted from the decrypted ticket. If decryption shows it 1386to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is 1387__________________________ 1388[10] This is used for user-to-user authentication as 1389described in [8]. 1390 1391 1392Section 3.2.3. - 21 - Expires 11 January 1998 1393 1394 1395 1396 1397 1398 1399 1400 Version 5 - Specification Revision 6 1401 1402 1403returned. The name and realm of the client from the ticket 1404are compared against the same fields in the authenticator. 1405If they don't match, the KRB_AP_ERR_BADMATCH error is 1406returned (they might not match, for example, if the wrong 1407session key was used to encrypt the authenticator). The 1408addresses in the ticket (if any) are then searched for an 1409address matching the operating-system reported address of 1410the client. If no match is found or the server insists on 1411ticket addresses but none are present in the ticket, the 1412KRB_AP_ERR_BADADDR error is returned. 1413 1414 If the local (server) time and the client time in the 1415authenticator differ by more than the allowable clock skew 1416(e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned. 1417If the server name, along with the client name, time and 1418microsecond fields from the Authenticator match any 1419recently-seen such tuples, the KRB_AP_ERR_REPEAT error is 1420returned[11]. The server must remember any authenticator 1421presented within the allowable clock skew, so that a replay 1422attempt is guaranteed to fail. If a server loses track of 1423any authenticator presented within the allowable clock skew, 1424it must reject all requests until the clock skew interval 1425has passed. This assures that any lost or re-played authen- 1426ticators will fall outside the allowable clock skew and can 1427no longer be successfully replayed (If this is not done, an 1428attacker could conceivably record the ticket and authentica- 1429tor sent over the network to a server, then disable the 1430client's host, pose as the disabled host, and replay the 1431ticket and authenticator to subvert the authentication.). 1432If a sequence number is provided in the authenticator, the 1433server saves it for later use in processing KRB_SAFE and/or 1434KRB_PRIV messages. If a subkey is present, the server 1435either saves it for later use or uses it to help generate 1436its own choice for a subkey to be returned in a KRB_AP_REP 1437message. 1438 1439 The server computes the age of the ticket: local 1440(server) time minus the start time inside the Ticket. If 1441the start time is later than the current time by more than 1442the allowable clock skew or if the INVALID flag is set in 1443the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Oth- 1444erwise, if the current time is later than end time by more 1445than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED 1446error is returned. 1447 1448 If all these checks succeed without an error, the 1449__________________________ 1450[11] Note that the rejection here is restricted to au- 1451thenticators from the same principal to the same 1452server. Other client principals communicating with the 1453same server principal should not be have their authen- 1454ticators rejected if the time and microsecond fields 1455happen to match some other client's authenticator. 1456 1457 1458Section 3.2.3. - 22 - Expires 11 January 1998 1459 1460 1461 1462 1463 1464 1465 1466 Version 5 - Specification Revision 6 1467 1468 1469server is assured that the client possesses the credentials 1470of the principal named in the ticket and thus, the client 1471has been authenticated to the server. See section A.10 for 1472pseudocode. 1473 1474 Passing these checks provides only authentication of 1475the named principal; it does not imply authorization to use 1476the named service. Applications must make a separate 1477authorization decisions based upon the authenticated name of 1478the user, the requested operation, local acces control 1479information such as that contained in a .k5login or .k5users 1480file, and possibly a separate distributed authorization ser- 1481vice. 1482 14833.2.4. Generation of a KRB_AP_REP message 1484 1485 Typically, a client's request will include both the 1486authentication information and its initial request in the 1487same message, and the server need not explicitly reply to 1488the KRB_AP_REQ. However, if mutual authentication (not only 1489authenticating the client to the server, but also the server 1490to the client) is being performed, the KRB_AP_REQ message 1491will have MUTUAL-REQUIRED set in its ap-options field, and a 1492KRB_AP_REP message is required in response. As with the 1493error message, this message may be encapsulated in the 1494application protocol if its "raw" form is not acceptable to 1495the application's protocol. The timestamp and microsecond 1496field used in the reply must be the client's timestamp and 1497microsecond field (as provided in the authenticator)[12]. 1498If a sequence number is to be included, it should be ran- 1499domly chosen as described above for the authenticator. A 1500subkey may be included if the server desires to negotiate a 1501different subkey. The KRB_AP_REP message is encrypted in 1502the session key extracted from the ticket. See section A.11 1503for pseudocode. 1504 15053.2.5. Receipt of KRB_AP_REP message 1506 1507 1508 If a KRB_AP_REP message is returned, the client uses 1509the session key from the credentials obtained for the 1510server[13] to decrypt the message, and verifies that the 1511__________________________ 1512[12] In the Kerberos version 4 protocol, the timestamp 1513in the reply was the client's timestamp plus one. This 1514is not necessary in version 5 because version 5 mes- 1515sages are formatted in such a way that it is not possi- 1516ble to create the reply by judicious message surgery 1517(even in encrypted form) without knowledge of the ap- 1518propriate encryption keys. 1519[13] Note that for encrypting the KRB_AP_REP message, 1520the sub-session key is not used, even if present in the 1521Authenticator. 1522 1523 1524Section 3.2.5. - 23 - Expires 11 January 1998 1525 1526 1527 1528 1529 1530 1531 1532 Version 5 - Specification Revision 6 1533 1534 1535timestamp and microsecond fields match those in the Authen- 1536ticator it sent to the server. If they match, then the 1537client is assured that the server is genuine. The sequence 1538number and subkey (if present) are retained for later use. 1539See section A.12 for pseudocode. 1540 1541 15423.2.6. Using the encryption key 1543 1544 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, 1545the client and server share an encryption key which can be 1546used by the application. The "true session key" to be used 1547for KRB_PRIV, KRB_SAFE, or other application-specific uses 1548may be chosen by the application based on the subkeys in the 1549KRB_AP_REP message and the authenticator[14]. In some 1550cases, the use of this session key will be implicit in the 1551protocol; in others the method of use must be chosen from 1552several alternatives. We leave the protocol negotiations of 1553how to use the key (e.g. selecting an encryption or check- 1554sum type) to the application programmer; the Kerberos proto- 1555col does not constrain the implementation options, but an 1556example of how this might be done follows. 1557 1558 One way that an application may choose to negotiate a 1559key to be used for subequent integrity and privacy protec- 1560tion is for the client to propose a key in the subkey field 1561of the authenticator. The server can then choose a key 1562using the proposed key from the client as input, returning 1563the new subkey in the subkey field of the application reply. 1564This key could then be used for subsequent communication. 1565To make this example more concrete, if the encryption method 1566in use required a 56 bit key, and for whatever reason, one 1567of the parties was prevented from using a key with more than 156840 unknown bits, this method would allow the the party which 1569is prevented from using more than 40 bits to either propose 1570(if the client) an initial key with a known quantity for 16 1571of those bits, or to mask 16 of the bits (if the server) 1572with the known quantity. The application implementor is 1573warned, however, that this is only an example, and that an 1574analysis of the particular crytosystem to be used, and the 1575reasons for limiting the key length, must be made before 1576deciding whether it is acceptable to mask bits of the key. 1577 1578 With both the one-way and mutual authentication 1579exchanges, the peers should take care not to send sensitive 1580information to each other without proper assurances. In 1581particular, applications that require privacy or integrity 1582should use the KRB_AP_REP response from the server to client 1583__________________________ 1584[14] Implementations of the protocol may wish to pro- 1585vide routines to choose subkeys based on session keys 1586and random numbers and to generate a negotiated key to 1587be returned in the KRB_AP_REP message. 1588 1589 1590Section 3.2.6. - 24 - Expires 11 January 1998 1591 1592 1593 1594 1595 1596 1597 1598 Version 5 - Specification Revision 6 1599 1600 1601to assure both client and server of their peer's identity. 1602If an application protocol requires privacy of its messages, 1603it can use the KRB_PRIV message (section 3.5). The KRB_SAFE 1604message (section 3.4) can be used to assure integrity. 1605 1606 16073.3. The Ticket-Granting Service (TGS) Exchange 1608 1609 Summary 1610 Message direction Message type Section 1611 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1612 2. Kerberos to client KRB_TGS_REP or 5.4.2 1613 KRB_ERROR 5.9.1 1614 1615 1616 The TGS exchange between a client and the Kerberos 1617Ticket-Granting Server is initiated by a client when it 1618wishes to obtain authentication credentials for a given 1619server (which might be registered in a remote realm), when 1620it wishes to renew or validate an existing ticket, or when 1621it wishes to obtain a proxy ticket. In the first case, the 1622client must already have acquired a ticket for the Ticket- 1623Granting Service using the AS exchange (the ticket-granting 1624ticket is usually obtained when a client initially authenti- 1625cates to the system, such as when a user logs in). The mes- 1626sage format for the TGS exchange is almost identical to that 1627for the AS exchange. The primary difference is that encryp- 1628tion and decryption in the TGS exchange does not take place 1629under the client's key. Instead, the session key from the 1630ticket-granting ticket or renewable ticket, or sub-session 1631key from an Authenticator is used. As is the case for all 1632application servers, expired tickets are not accepted by the 1633TGS, so once a renewable or ticket-granting ticket expires, 1634the client must use a separate exchange to obtain valid 1635tickets. 1636 1637 The TGS exchange consists of two messages: A request 1638(KRB_TGS_REQ) from the client to the Kerberos Ticket- 1639Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR). 1640The KRB_TGS_REQ message includes information authenticating 1641the client plus a request for credentials. The authentica- 1642tion information consists of the authentication header 1643(KRB_AP_REQ) which includes the client's previously obtained 1644ticket-granting, renewable, or invalid ticket. In the 1645ticket-granting ticket and proxy cases, the request may 1646include one or more of: a list of network addresses, a col- 1647lection of typed authorization data to be sealed in the 1648ticket for authorization use by the application server, or 1649additional tickets (the use of which are described later). 1650The TGS reply (KRB_TGS_REP) contains the requested creden- 1651tials, encrypted in the session key from the ticket-granting 1652ticket or renewable ticket, or if present, in the sub- 1653session key from the Authenticator (part of the authentica- 1654tion header). The KRB_ERROR message contains an error code 1655 1656 1657Section 3.3. - 25 - Expires 11 January 1998 1658 1659 1660 1661 1662 1663 1664 1665 Version 5 - Specification Revision 6 1666 1667 1668and text explaining what went wrong. The KRB_ERROR message 1669is not encrypted. The KRB_TGS_REP message contains informa- 1670tion which can be used to detect replays, and to associate 1671it with the message to which it replies. The KRB_ERROR mes- 1672sage also contains information which can be used to associ- 1673ate it with the message to which it replies, but the lack of 1674encryption in the KRB_ERROR message precludes the ability to 1675detect replays or fabrications of such messages. 1676 16773.3.1. Generation of KRB_TGS_REQ message 1678 1679 Before sending a request to the ticket-granting ser- 1680vice, the client must determine in which realm the applica- 1681tion server is registered[15]. If the client does not 1682already possess a ticket-granting ticket for the appropriate 1683realm, then one must be obtained. This is first attempted 1684by requesting a ticket-granting ticket for the destination 1685realm from a Kerberos server for which the client does 1686posess a ticket-granting ticket (using the KRB_TGS_REQ mes- 1687sage recursively). The Kerberos server may return a TGT for 1688the desired realm in which case one can proceed. Alterna- 1689tively, the Kerberos server may return a TGT for a realm 1690which is "closer" to the desired realm (further along the 1691standard hierarchical path), in which case this step must be 1692repeated with a Kerberos server in the realm specified in 1693the returned TGT. If neither are returned, then the request 1694must be retried with a Kerberos server for a realm higher in 1695the hierarchy. This request will itself require a ticket- 1696granting ticket for the higher realm which must be obtained 1697by recursively applying these directions. 1698 1699 1700 Once the client obtains a ticket-granting ticket for 1701the appropriate realm, it determines which Kerberos servers 1702serve that realm, and contacts one. The list might be 1703obtained through a configuration file or network service or 1704it may be generated from the name of the realm; as long as 1705the secret keys exchanged by realms are kept secret, only 1706denial of service results from using a false Kerberos 1707server. 1708__________________________ 1709[15] This can be accomplished in several ways. It 1710might be known beforehand (since the realm is part of 1711the principal identifier), it might be stored in a 1712nameserver, or it might be obtained from a configura- 1713tion file. If the realm to be used is obtained from a 1714nameserver, there is a danger of being spoofed if the 1715nameservice providing the realm name is not authenti- 1716cated. This might result in the use of a realm which 1717has been compromised, and would result in an attacker's 1718ability to compromise the authentication of the appli- 1719cation server to the client. 1720 1721 1722 1723Section 3.3.1. - 26 - Expires 11 January 1998 1724 1725 1726 1727 1728 1729 1730 1731 Version 5 - Specification Revision 6 1732 1733 1734 As in the AS exchange, the client may specify a number 1735of options in the KRB_TGS_REQ message. The client prepares 1736the KRB_TGS_REQ message, providing an authentication header 1737as an element of the padata field, and including the same 1738fields as used in the KRB_AS_REQ message along with several 1739optional fields: the enc-authorization-data field for appli- 1740cation server use and additional tickets required by some 1741options. 1742 1743 In preparing the authentication header, the client can 1744select a sub-session key under which the response from the 1745Kerberos server will be encrypted[16]. If the sub-session 1746key is not specified, the session key from the ticket- 1747granting ticket will be used. If the enc-authorization-data 1748is present, it must be encrypted in the sub-session key, if 1749present, from the authenticator portion of the authentica- 1750tion header, or if not present, using the session key from 1751the ticket-granting ticket. 1752 1753 Once prepared, the message is sent to a Kerberos server 1754for the destination realm. See section A.5 for pseudocode. 1755 17563.3.2. Receipt of KRB_TGS_REQ message 1757 1758 The KRB_TGS_REQ message is processed in a manner simi- 1759lar to the KRB_AS_REQ message, but there are many additional 1760checks to be performed. First, the Kerberos server must 1761determine which server the accompanying ticket is for and it 1762must select the appropriate key to decrypt it. For a normal 1763KRB_TGS_REQ message, it will be for the ticket granting ser- 1764vice, and the TGS's key will be used. If the TGT was issued 1765by another realm, then the appropriate inter-realm key must 1766be used. If the accompanying ticket is not a ticket grant- 1767ing ticket for the current realm, but is for an application 1768server in the current realm, the RENEW, VALIDATE, or PROXY 1769options are specified in the request, and the server for 1770which a ticket is requested is the server named in the 1771accompanying ticket, then the KDC will decrypt the ticket in 1772the authentication header using the key of the server for 1773which it was issued. If no ticket can be found in the 1774padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is 1775returned. 1776 1777 Once the accompanying ticket has been decrypted, the 1778user-supplied checksum in the Authenticator must be verified 1779against the contents of the request, and the message 1780rejected if the checksums do not match (with an error code 1781__________________________ 1782[16] If the client selects a sub-session key, care must 1783be taken to ensure the randomness of the selected sub- 1784session key. One approach would be to generate a ran- 1785dom number and XOR it with the session key from the 1786ticket-granting ticket. 1787 1788 1789Section 3.3.2. - 27 - Expires 11 January 1998 1790 1791 1792 1793 1794 1795 1796 1797 Version 5 - Specification Revision 6 1798 1799 1800of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or 1801not collision-proof (with an error code of 1802KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not sup- 1803ported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If 1804the authorization-data are present, they are decrypted using 1805the sub-session key from the Authenticator. 1806 1807 If any of the decryptions indicate failed integrity 1808checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned. 1809 18103.3.3. Generation of KRB_TGS_REP message 1811 1812 The KRB_TGS_REP message shares its format with the 1813KRB_AS_REP (KRB_KDC_REP), but with its type field set to 1814KRB_TGS_REP. The detailed specification is in section 18155.4.2. 1816 1817 The response will include a ticket for the requested 1818server. The Kerberos database is queried to retrieve the 1819record for the requested server (including the key with 1820which the ticket will be encrypted). If the request is for 1821a ticket granting ticket for a remote realm, and if no key 1822is shared with the requested realm, then the Kerberos server 1823will select the realm "closest" to the requested realm with 1824which it does share a key, and use that realm instead. This 1825is the only case where the response from the KDC will be for 1826a different server than that requested by the client. 1827 1828 By default, the address field, the client's name and 1829realm, the list of transited realms, the time of initial 1830authentication, the expiration time, and the authorization 1831data of the newly-issued ticket will be copied from the 1832ticket-granting ticket (TGT) or renewable ticket. If the 1833transited field needs to be updated, but the transited type 1834is not supported, the KDC_ERR_TRTYPE_NOSUPP error is 1835returned. 1836 1837 If the request specifies an endtime, then the endtime 1838of the new ticket is set to the minimum of (a) that request, 1839(b) the endtime from the TGT, and (c) the starttime of the 1840TGT plus the minimum of the maximum life for the application 1841server and the maximum life for the local realm (the maximum 1842life for the requesting principal was already applied when 1843the TGT was issued). If the new ticket is to be a renewal, 1844then the endtime above is replaced by the minimum of (a) the 1845value of the renew_till field of the ticket and (b) the 1846starttime for the new ticket plus the life (endtime- 1847starttime) of the old ticket. 1848 1849 If the FORWARDED option has been requested, then the 1850resulting ticket will contain the addresses specified by the 1851client. This option will only be honored if the FORWARDABLE 1852flag is set in the TGT. The PROXY option is similar; the 1853resulting ticket will contain the addresses specified by the 1854 1855 1856Section 3.3.3. - 28 - Expires 11 January 1998 1857 1858 1859 1860 1861 1862 1863 1864 Version 5 - Specification Revision 6 1865 1866 1867client. It will be honored only if the PROXIABLE flag in 1868the TGT is set. The PROXY option will not be honored on 1869requests for additional ticket-granting tickets. 1870 1871 If the requested start time is absent, indicates a time 1872in the past, or is within the window of acceptable clock 1873skew for the KDC and the POSTDATE option has not been speci- 1874fied, then the start time of the ticket is set to the 1875authentication server's current time. If it indicates a 1876time in the future beyond the acceptable clock skew, but the 1877POSTDATED option has not been specified or the MAY-POSTDATE 1878flag is not set in the TGT, then the error 1879KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the 1880ticket-granting ticket has the MAY-POSTDATE flag set, then 1881the resulting ticket will be postdated and the requested 1882starttime is checked against the policy of the local realm. 1883If acceptable, the ticket's start time is set as requested, 1884and the INVALID flag is set. The postdated ticket must be 1885validated before use by presenting it to the KDC after the 1886starttime has been reached. However, in no case may the 1887starttime, endtime, or renew-till time of a newly-issued 1888postdated ticket extend beyond the renew-till time of the 1889ticket-granting ticket. 1890 1891 If the ENC-TKT-IN-SKEY option has been specified and an 1892additional ticket has been included in the request, the KDC 1893will decrypt the additional ticket using the key for the 1894server to which the additional ticket was issued and verify 1895that it is a ticket-granting ticket. If the name of the 1896requested server is missing from the request, the name of 1897the client in the additional ticket will be used. Otherwise 1898the name of the requested server will be compared to the 1899name of the client in the additional ticket and if dif- 1900ferent, the request will be rejected. If the request 1901succeeds, the session key from the additional ticket will be 1902used to encrypt the new ticket that is issued instead of 1903using the key of the server for which the new ticket will be 1904used[17]. 1905 1906 If the name of the server in the ticket that is 1907presented to the KDC as part of the authentication header is 1908not that of the ticket-granting server itself, the server is 1909registered in the realm of the KDC, and the RENEW option is 1910requested, then the KDC will verify that the RENEWABLE flag 1911is set in the ticket, that the INVALID flag is not set in 1912the ticket, and that the renew_till time is still in the 1913future. If the VALIDATE option is rqeuested, the KDC will 1914__________________________ 1915[17] This allows easy implementation of user-to-user 1916authentication [8], which uses ticket-granting ticket 1917session keys in lieu of secret server keys in situa- 1918tions where such secret keys could be easily comprom- 1919ised. 1920 1921 1922Section 3.3.3. - 29 - Expires 11 January 1998 1923 1924 1925 1926 1927 1928 1929 1930 Version 5 - Specification Revision 6 1931 1932 1933check that the starttime has passed and the INVALID flag is 1934set. If the PROXY option is requested, then the KDC will 1935check that the PROXIABLE flag is set in the ticket. If the 1936tests succeed, and the ticket passes the hotlist check 1937described in the next paragraph, the KDC will issue the 1938appropriate new ticket. 1939 1940 19413.3.3.1. Checking for revoked tickets 1942 1943 Whenever a request is made to the ticket-granting 1944server, the presented ticket(s) is(are) checked against a 1945hot-list of tickets which have been canceled. This hot-list 1946might be implemented by storing a range of issue timestamps 1947for "suspect tickets"; if a presented ticket had an authtime 1948in that range, it would be rejected. In this way, a stolen 1949ticket-granting ticket or renewable ticket cannot be used to 1950gain additional tickets (renewals or otherwise) once the 1951theft has been reported. Any normal ticket obtained before 1952it was reported stolen will still be valid (because they 1953require no interaction with the KDC), but only until their 1954normal expiration time. 1955 1956 The ciphertext part of the response in the KRB_TGS_REP 1957message is encrypted in the sub-session key from the Authen- 1958ticator, if present, or the session key key from the 1959ticket-granting ticket. It is not encrypted using the 1960client's secret key. Furthermore, the client's key's 1961expiration date and the key version number fields are left 1962out since these values are stored along with the client's 1963database record, and that record is not needed to satisfy a 1964request based on a ticket-granting ticket. See section A.6 1965for pseudocode. 1966 19673.3.3.2. Encoding the transited field 1968 1969 If the identity of the server in the TGT that is 1970presented to the KDC as part of the authentication header is 1971that of the ticket-granting service, but the TGT was issued 1972from another realm, the KDC will look up the inter-realm key 1973shared with that realm and use that key to decrypt the 1974ticket. If the ticket is valid, then the KDC will honor the 1975request, subject to the constraints outlined above in the 1976section describing the AS exchange. The realm part of the 1977client's identity will be taken from the ticket-granting 1978ticket. The name of the realm that issued the ticket- 1979granting ticket will be added to the transited field of the 1980ticket to be issued. This is accomplished by reading the 1981transited field from the ticket-granting ticket (which is 1982treated as an unordered set of realm names), adding the new 1983realm to the set, then constructing and writing out its 1984encoded (shorthand) form (this may involve a rearrangement 1985of the existing encoding). 1986 1987 1988 1989Section 3.3.3.2. - 30 - Expires 11 January 1998 1990 1991 1992 1993 1994 1995 1996 1997 Version 5 - Specification Revision 6 1998 1999 2000 Note that the ticket-granting service does not add the 2001name of its own realm. Instead, its responsibility is to 2002add the name of the previous realm. This prevents a mali- 2003cious Kerberos server from intentionally leaving out its own 2004name (it could, however, omit other realms' names). 2005 2006 The names of neither the local realm nor the 2007principal's realm are to be included in the transited field. 2008They appear elsewhere in the ticket and both are known to 2009have taken part in authenticating the principal. Since the 2010endpoints are not included, both local and single-hop 2011inter-realm authentication result in a transited field that 2012is empty. 2013 2014 Because the name of each realm transited is added to 2015this field, it might potentially be very long. To decrease 2016the length of this field, its contents are encoded. The 2017initially supported encoding is optimized for the normal 2018case of inter-realm communication: a hierarchical arrange- 2019ment of realms using either domain or X.500 style realm 2020names. This encoding (called DOMAIN-X500-COMPRESS) is now 2021described. 2022 2023 Realm names in the transited field are separated by a 2024",". The ",", "\", trailing "."s, and leading spaces (" ") 2025are special characters, and if they are part of a realm 2026name, they must be quoted in the transited field by preced- 2027ing them with a "\". 2028 2029 A realm name ending with a "." is interpreted as being 2030prepended to the previous realm. For example, we can encode 2031traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, 2032and CS.WASHINGTON.EDU as: 2033 2034 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 2035 2036Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end- 2037points, that they would not be included in this field, and 2038we would have: 2039 2040 "EDU,MIT.,WASHINGTON.EDU" 2041 2042A realm name beginning with a "/" is interpreted as being 2043appended to the previous realm[18]. If it is to stand by 2044itself, then it should be preceded by a space (" "). For 2045example, we can encode traversal of /COM/HP/APOLLO, /COM/HP, 2046/COM, and /COM/DEC as: 2047 2048 "/COM,/HP,/APOLLO, /COM/DEC". 2049__________________________ 2050[18] For the purpose of appending, the realm preceding 2051the first listed realm is considered to be the null 2052realm (""). 2053 2054 2055Section 3.3.3.2. - 31 - Expires 11 January 1998 2056 2057 2058 2059 2060 2061 2062 2063 Version 5 - Specification Revision 6 2064 2065 2066Like the example above, if /COM/HP/APOLLO and /COM/DEC are 2067endpoints, they they would not be included in this field, 2068and we would have: 2069 2070 "/COM,/HP" 2071 2072 2073 A null subfield preceding or following a "," indicates 2074that all realms between the previous realm and the next 2075realm have been traversed[19]. Thus, "," means that all 2076realms along the path between the client and the server have 2077been traversed. ",EDU, /COM," means that that all realms 2078from the client's realm up to EDU (in a domain style hierar- 2079chy) have been traversed, and that everything from /COM down 2080to the server's realm in an X.500 style has also been 2081traversed. This could occur if the EDU realm in one hierar- 2082chy shares an inter-realm key directly with the /COM realm 2083in another hierarchy. 2084 20853.3.4. Receipt of KRB_TGS_REP message 2086 2087When the KRB_TGS_REP is received by the client, it is pro- 2088cessed in the same manner as the KRB_AS_REP processing 2089described above. The primary difference is that the cipher- 2090text part of the response must be decrypted using the ses- 2091sion key from the ticket-granting ticket rather than the 2092client's secret key. See section A.7 for pseudocode. 2093 2094 20953.4. The KRB_SAFE Exchange 2096 2097 The KRB_SAFE message may be used by clients requiring 2098the ability to detect modifications of messages they 2099exchange. It achieves this by including a keyed collision- 2100proof checksum of the user data and some control informa- 2101tion. The checksum is keyed with an encryption key (usually 2102the last key negotiated via subkeys, or the session key if 2103no negotiation has occured). 2104 21053.4.1. Generation of a KRB_SAFE message 2106 2107When an application wishes to send a KRB_SAFE message, it 2108collects its data and the appropriate control information 2109and computes a checksum over them. The checksum algorithm 2110should be a keyed one-way hash function (such as the RSA- 2111MD5-DES checksum algorithm specified in section 6.4.5, or 2112the DES MAC), generated using the sub-session key if 2113present, or the session key. Different algorithms may be 2114__________________________ 2115[19] For the purpose of interpreting null subfields, 2116the client's realm is considered to precede those in 2117the transited field, and the server's realm is con- 2118sidered to follow them. 2119 2120 2121Section 3.4.1. - 32 - Expires 11 January 1998 2122 2123 2124 2125 2126 2127 2128 2129 Version 5 - Specification Revision 6 2130 2131 2132selected by changing the checksum type in the message. 2133Unkeyed or non-collision-proof checksums are not suitable 2134for this use. 2135 2136 The control information for the KRB_SAFE message 2137includes both a timestamp and a sequence number. The 2138designer of an application using the KRB_SAFE message must 2139choose at least one of the two mechanisms. This choice 2140should be based on the needs of the application protocol. 2141 2142 Sequence numbers are useful when all messages sent will 2143be received by one's peer. Connection state is presently 2144required to maintain the session key, so maintaining the 2145next sequence number should not present an additional prob- 2146lem. 2147 2148 If the application protocol is expected to tolerate 2149lost messages without them being resent, the use of the 2150timestamp is the appropriate replay detection mechanism. 2151Using timestamps is also the appropriate mechanism for 2152multi-cast protocols where all of one's peers share a common 2153sub-session key, but some messages will be sent to a subset 2154of one's peers. 2155 2156 After computing the checksum, the client then transmits 2157the information and checksum to the recipient in the message 2158format specified in section 5.6.1. 2159 21603.4.2. Receipt of KRB_SAFE message 2161 2162When an application receives a KRB_SAFE message, it verifies 2163it as follows. If any error occurs, an error code is 2164reported for use by the application. 2165 2166 The message is first checked by verifying that the pro- 2167tocol version and type fields match the current version and 2168KRB_SAFE, respectively. A mismatch generates a 2169KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 2170application verifies that the checksum used is a collision- 2171proof keyed checksum, and if it is not, a 2172KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient 2173verifies that the operating system's report of the sender's 2174address matches the sender's address in the message, and (if 2175a recipient address is specified or the recipient requires 2176an address) that one of the recipient's addresses appears as 2177the recipient's address in the message. A failed match for 2178either case generates a KRB_AP_ERR_BADADDR error. Then the 2179timestamp and usec and/or the sequence number fields are 2180checked. If timestamp and usec are expected and not 2181present, or they are present but not current, the 2182KRB_AP_ERR_SKEW error is generated. If the server name, 2183along with the client name, time and microsecond fields from 2184the Authenticator match any recently-seen (sent or 2185received[20] ) such tuples, the KRB_AP_ERR_REPEAT error is 2186__________________________ 2187[20] This means that a client and server running on the 2188 2189 2190 2191 2192 2193 2194 Version 5 - Specification Revision 6 2195 2196 2197generated. If an incorrect sequence number is included, or 2198a sequence number is expected but not present, the 2199KRB_AP_ERR_BADORDER error is generated. If neither a time- 2200stamp and usec or a sequence number is present, a 2201KRB_AP_ERR_MODIFIED error is generated. Finally, the check- 2202sum is computed over the data and control information, and 2203if it doesn't match the received checksum, a 2204KRB_AP_ERR_MODIFIED error is generated. 2205 2206 If all the checks succeed, the application is assured 2207that the message was generated by its peer and was not modi- 2208fied in transit. 2209 22103.5. The KRB_PRIV Exchange 2211 2212 The KRB_PRIV message may be used by clients requiring 2213confidentiality and the ability to detect modifications of 2214exchanged messages. It achieves this by encrypting the mes- 2215sages and adding control information. 2216 22173.5.1. Generation of a KRB_PRIV message 2218 2219When an application wishes to send a KRB_PRIV message, it 2220collects its data and the appropriate control information 2221(specified in section 5.7.1) and encrypts them under an 2222encryption key (usually the last key negotiated via subkeys, 2223or the session key if no negotiation has occured). As part 2224of the control information, the client must choose to use 2225either a timestamp or a sequence number (or both); see the 2226discussion in section 3.4.1 for guidelines on which to use. 2227After the user data and control information are encrypted, 2228the client transmits the ciphertext and some "envelope" 2229information to the recipient. 2230 22313.5.2. Receipt of KRB_PRIV message 2232 2233When an application receives a KRB_PRIV message, it verifies 2234it as follows. If any error occurs, an error code is 2235reported for use by the application. 2236 2237 The message is first checked by verifying that the pro- 2238tocol version and type fields match the current version and 2239KRB_PRIV, respectively. A mismatch generates a 2240KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 2241application then decrypts the ciphertext and processes the 2242resultant plaintext. If decryption shows the data to have 2243been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- 2244erated. The recipient verifies that the operating system's 2245report of the sender's address matches the sender's address 2246__________________________ 2247same host and communicating with one another using the 2248KRB_SAFE messages should not share a common replay 2249cache to detect KRB_SAFE replays. 2250 2251 2252 2253Section 3.5.2. - 34 - Expires 11 January 1998 2254 2255 2256 2257 2258 2259 2260 2261 Version 5 - Specification Revision 6 2262 2263 2264in the message, and (if a recipient address is specified or 2265the recipient requires an address) that one of the 2266recipient's addresses appears as the recipient's address in 2267the message. A failed match for either case generates a 2268KRB_AP_ERR_BADADDR error. Then the timestamp and usec 2269and/or the sequence number fields are checked. If timestamp 2270and usec are expected and not present, or they are present 2271but not current, the KRB_AP_ERR_SKEW error is generated. If 2272the server name, along with the client name, time and 2273microsecond fields from the Authenticator match any 2274recently-seen such tuples, the KRB_AP_ERR_REPEAT error is 2275generated. If an incorrect sequence number is included, or 2276a sequence number is expected but not present, the 2277KRB_AP_ERR_BADORDER error is generated. If neither a time- 2278stamp and usec or a sequence number is present, a 2279KRB_AP_ERR_MODIFIED error is generated. 2280 2281 If all the checks succeed, the application can assume 2282the message was generated by its peer, and was securely 2283transmitted (without intruders able to see the unencrypted 2284contents). 2285 22863.6. The KRB_CRED Exchange 2287 2288 The KRB_CRED message may be used by clients requiring 2289the ability to send Kerberos credentials from one host to 2290another. It achieves this by sending the tickets together 2291with encrypted data containing the session keys and other 2292information associated with the tickets. 2293 22943.6.1. Generation of a KRB_CRED message 2295 2296When an application wishes to send a KRB_CRED message it 2297first (using the KRB_TGS exchange) obtains credentials to be 2298sent to the remote host. It then constructs a KRB_CRED mes- 2299sage using the ticket or tickets so obtained, placing the 2300session key needed to use each ticket in the key field of 2301the corresponding KrbCredInfo sequence of the encrypted part 2302of the the KRB_CRED message. 2303 2304 Other information associated with each ticket and 2305obtained during the KRB_TGS exchange is also placed in the 2306corresponding KrbCredInfo sequence in the encrypted part of 2307the KRB_CRED message. The current time and, if specifically 2308required by the application the nonce, s-address, and r- 2309address fields, are placed in the encrypted part of the 2310KRB_CRED message which is then encrypted under an encryption 2311key previosuly exchanged in the KRB_AP exchange (usually the 2312last key negotiated via subkeys, or the session key if no 2313negotiation has occured). 2314 23153.6.2. Receipt of KRB_CRED message 2316 2317When an application receives a KRB_CRED message, it verifies 2318 2319 2320Section 3.6.2. - 35 - Expires 11 January 1998 2321 2322 2323 2324 2325 2326 2327 2328 Version 5 - Specification Revision 6 2329 2330 2331it. If any error occurs, an error code is reported for use 2332by the application. The message is verified by checking 2333that the protocol version and type fields match the current 2334version and KRB_CRED, respectively. A mismatch generates a 2335KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 2336application then decrypts the ciphertext and processes the 2337resultant plaintext. If decryption shows the data to have 2338been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- 2339erated. 2340 2341 If present or required, the recipient verifies that the 2342operating system's report of the sender's address matches 2343the sender's address in the message, and that one of the 2344recipient's addresses appears as the recipient's address in 2345the message. A failed match for either case generates a 2346KRB_AP_ERR_BADADDR error. The timestamp and usec fields 2347(and the nonce field if required) are checked next. If the 2348timestamp and usec are not present, or they are present but 2349not current, the KRB_AP_ERR_SKEW error is generated. 2350 2351 If all the checks succeed, the application stores each 2352of the new tickets in its ticket cache together with the 2353session key and other information in the corresponding 2354KrbCredInfo sequence from the encrypted part of the KRB_CRED 2355message. 2356 23574. The Kerberos Database 2358 2359The Kerberos server must have access to a database contain- 2360ing the principal identifiers and secret keys of principals 2361to be authenticated[21]. 2362 23634.1. Database contents 2364 2365A database entry should contain at least the following 2366fields: 2367 2368Field Value 2369 2370name Principal's identif- 2371ier 2372key Principal's secret key 2373p_kvno Principal's key version 2374max_life Maximum lifetime for Tickets 2375__________________________ 2376[21] The implementation of the Kerberos server need not 2377combine the database and the server on the same 2378machine; it is feasible to store the principal database 2379in, say, a network name service, as long as the entries 2380stored therein are protected from disclosure to and 2381modification by unauthorized parties. However, we 2382recommend against such strategies, as they can make 2383system management and threat analysis quite complex. 2384 2385 2386Section 4.1. - 36 - Expires 11 January 1998 2387 2388 2389 2390 2391 2392 2393 2394 Version 5 - Specification Revision 6 2395 2396 2397max_renewable_life Maximum total lifetime for renewable Tickets 2398 2399The name field is an encoding of the principal's identifier. 2400The key field contains an encryption key. This key is the 2401principal's secret key. (The key can be encrypted before 2402storage under a Kerberos "master key" to protect it in case 2403the database is compromised but the master key is not. In 2404that case, an extra field must be added to indicate the mas- 2405ter key version used, see below.) The p_kvno field is the 2406key version number of the principal's secret key. The 2407max_life field contains the maximum allowable lifetime (end- 2408time - starttime) for any Ticket issued for this principal. 2409The max_renewable_life field contains the maximum allowable 2410total lifetime for any renewable Ticket issued for this 2411principal. (See section 3.1 for a description of how these 2412lifetimes are used in determining the lifetime of a given 2413Ticket.) 2414 2415 A server may provide KDC service to several realms, as 2416long as the database representation provides a mechanism to 2417distinguish between principal records with identifiers which 2418differ only in the realm name. 2419 2420 When an application server's key changes, if the change 2421is routine (i.e. not the result of disclosure of the old 2422key), the old key should be retained by the server until all 2423tickets that had been issued using that key have expired. 2424Because of this, it is possible for several keys to be 2425active for a single principal. Ciphertext encrypted in a 2426principal's key is always tagged with the version of the key 2427that was used for encryption, to help the recipient find the 2428proper key for decryption. 2429 2430 When more than one key is active for a particular prin- 2431cipal, the principal will have more than one record in the 2432Kerberos database. The keys and key version numbers will 2433differ between the records (the rest of the fields may or 2434may not be the same). Whenever Kerberos issues a ticket, or 2435responds to a request for initial authentication, the most 2436recent key (known by the Kerberos server) will be used for 2437encryption. This is the key with the highest key version 2438number. 2439 24404.2. Additional fields 2441 2442Project Athena's KDC implementation uses additional fields 2443in its database: 2444 2445Field Value 2446 2447K_kvno Kerberos' key version 2448expiration Expiration date for entry 2449attributes Bit field of attributes 2450mod_date Timestamp of last modification 2451 2452 2453Section 4.2. - 37 - Expires 11 January 1998 2454 2455 2456 2457 2458 2459 2460 2461 Version 5 - Specification Revision 6 2462 2463 2464mod_name Modifying principal's identifier 2465 2466 2467The K_kvno field indicates the key version of the Kerberos 2468master key under which the principal's secret key is 2469encrypted. 2470 2471 After an entry's expiration date has passed, the KDC 2472will return an error to any client attempting to gain tick- 2473ets as or for the principal. (A database may want to main- 2474tain two expiration dates: one for the principal, and one 2475for the principal's current key. This allows password aging 2476to work independently of the principal's expiration date. 2477However, due to the limited space in the responses, the KDC 2478must combine the key expiration and principal expiration 2479date into a single value called "key_exp", which is used as 2480a hint to the user to take administrative action.) 2481 2482 The attributes field is a bitfield used to govern the 2483operations involving the principal. This field might be 2484useful in conjunction with user registration procedures, for 2485site-specific policy implementations (Project Athena 2486currently uses it for their user registration process con- 2487trolled by the system-wide database service, Moira [9]), to 2488identify whether a principal can play the role of a client 2489or server or both, to note whether a server is appropriate 2490trusted to recieve credentials delegated by a client, or to 2491identify the "string to key" conversion algorithm used for a 2492principal's key[22]. Other bits are used to indicate that 2493certain ticket options should not be allowed in tickets 2494encrypted under a principal's key (one bit each): Disallow 2495issuing postdated tickets, disallow issuing forwardable 2496tickets, disallow issuing tickets based on TGT authentica- 2497tion, disallow issuing renewable tickets, disallow issuing 2498proxiable tickets, and disallow issuing tickets for which 2499the principal is the server. 2500 2501 The mod_date field contains the time of last modifica- 2502tion of the entry, and the mod_name field contains the name 2503of the principal which last modified the entry. 2504 25054.3. Frequently Changing Fields 2506 2507 Some KDC implementations may wish to maintain the last 2508time that a request was made by a particular principal. 2509Information that might be maintained includes the time of 2510the last request, the time of the last request for a 2511ticket-granting ticket, the time of the last use of a 2512ticket-granting ticket, or other times. This information 2513can then be returned to the user in the last-req field (see 2514__________________________ 2515[22] See the discussion of the padata field in section 25165.4.2 for details on why this can be useful. 2517 2518 2519Section 4.3. - 38 - Expires 11 January 1998 2520 2521 2522 2523 2524 2525 2526 2527 Version 5 - Specification Revision 6 2528 2529 2530section 5.2). 2531 2532 Other frequently changing information that can be main- 2533tained is the latest expiration time for any tickets that 2534have been issued using each key. This field would be used 2535to indicate how long old keys must remain valid to allow the 2536continued use of outstanding tickets. 2537 25384.4. Site Constants 2539 2540 The KDC implementation should have the following confi- 2541gurable constants or options, to allow an administrator to 2542make and enforce policy decisions: 2543 2544+ The minimum supported lifetime (used to determine whether 2545 the KDC_ERR_NEVER_VALID error should be returned). This 2546 constant should reflect reasonable expectations of 2547 round-trip time to the KDC, encryption/decryption time, 2548 and processing time by the client and target server, and 2549 it should allow for a minimum "useful" lifetime. 2550 2551+ The maximum allowable total (renewable) lifetime of a 2552 ticket (renew_till - starttime). 2553 2554+ The maximum allowable lifetime of a ticket (endtime - 2555 starttime). 2556 2557+ Whether to allow the issue of tickets with empty address 2558 fields (including the ability to specify that such tick- 2559 ets may only be issued if the request specifies some 2560 authorization_data). 2561 2562+ Whether proxiable, forwardable, renewable or post-datable 2563 tickets are to be issued. 2564 2565 25665. Message Specifications 2567 2568 The following sections describe the exact contents and 2569encoding of protocol messages and objects. The ASN.1 base 2570definitions are presented in the first subsection. The 2571remaining subsections specify the protocol objects (tickets 2572and authenticators) and messages. Specification of encryp- 2573tion and checksum techniques, and the fields related to 2574them, appear in section 6. 2575 25765.1. ASN.1 Distinguished Encoding Representation 2577 2578 All uses of ASN.1 in Kerberos shall use the Dis- 2579tinguished Encoding Representation of the data elements as 2580described in the X.509 specification, section 8.7 [10]. 2581 2582 2583 2584 2585 2586Section 5.1. - 39 - Expires 11 January 1998 2587 2588 2589 2590 2591 2592 2593 2594 Version 5 - Specification Revision 6 2595 2596 25975.2. ASN.1 Base Definitions 2598 2599 The following ASN.1 base definitions are used in the 2600rest of this section. Note that since the underscore char- 2601acter (_) is not permitted in ASN.1 names, the hyphen (-) is 2602used in its place for the purposes of ASN.1 names. 2603 2604Realm ::= GeneralString 2605PrincipalName ::= SEQUENCE { 2606 name-type[0] INTEGER, 2607 name-string[1] SEQUENCE OF GeneralString 2608} 2609 2610 2611Kerberos realms are encoded as GeneralStrings. Realms shall 2612not contain a character with the code 0 (the ASCII NUL). 2613Most realms will usually consist of several components 2614separated by periods (.), in the style of Internet Domain 2615Names, or separated by slashes (/) in the style of X.500 2616names. Acceptable forms for realm names are specified in 2617section 7. A PrincipalName is a typed sequence of com- 2618ponents consisting of the following sub-fields: 2619 2620name-type This field specifies the type of name that fol- 2621 lows. Pre-defined values for this field are 2622 specified in section 7.2. The name-type should be 2623 treated as a hint. Ignoring the name type, no two 2624 names can be the same (i.e. at least one of the 2625 components, or the realm, must be different). 2626 This constraint may be eliminated in the future. 2627 2628name-stringThis field encodes a sequence of components that 2629 form a name, each component encoded as a General- 2630 String. Taken together, a PrincipalName and a 2631 Realm form a principal identifier. Most Princi- 2632 palNames will have only a few components (typi- 2633 cally one or two). 2634 2635 2636 2637 KerberosTime ::= GeneralizedTime 2638 -- Specifying UTC time zone (Z) 2639 2640 2641 The timestamps used in Kerberos are encoded as General- 2642izedTimes. An encoding shall specify the UTC time zone (Z) 2643and shall not include any fractional portions of the 2644seconds. It further shall not include any separators. 2645Example: The only valid format for UTC time 6 minutes, 27 2646seconds after 9 pm on 6 November 1985 is 19851106210627Z. 2647 2648 HostAddress ::= SEQUENCE { 2649 addr-type[0] INTEGER, 2650 address[1] OCTET STRING 2651 2652 2653Section 5.2. - 40 - Expires 11 January 1998 2654 2655 2656 2657 2658 2659 2660 2661 Version 5 - Specification Revision 6 2662 2663 2664 } 2665 2666 HostAddresses ::= SEQUENCE OF SEQUENCE { 2667 addr-type[0] INTEGER, 2668 address[1] OCTET STRING 2669 } 2670 2671 2672 The host adddress encodings consists of two fields: 2673 2674addr-type This field specifies the type of address that 2675 follows. Pre-defined values for this field are 2676 specified in section 8.1. 2677 2678 2679address This field encodes a single address of type addr- 2680 type. 2681 2682The two forms differ slightly. HostAddress contains exactly 2683one address; HostAddresses contains a sequence of possibly 2684many addresses. 2685 2686AuthorizationData ::= SEQUENCE OF SEQUENCE { 2687 ad-type[0] INTEGER, 2688 ad-data[1] OCTET STRING 2689} 2690 2691 2692ad-data This field contains authorization data to be 2693 interpreted according to the value of the 2694 corresponding ad-type field. 2695 2696ad-type This field specifies the format for the ad-data 2697 subfield. All negative values are reserved for 2698 local use. Non-negative values are reserved for 2699 registered use. 2700 2701 APOptions ::= BIT STRING { 2702 reserved(0), 2703 use-session-key(1), 2704 mutual-required(2) 2705 } 2706 2707 2708 TicketFlags ::= BIT STRING { 2709 reserved(0), 2710 forwardable(1), 2711 forwarded(2), 2712 proxiable(3), 2713 proxy(4), 2714 may-postdate(5), 2715 postdated(6), 2716 invalid(7), 2717 renewable(8), 2718 initial(9), 2719 2720 2721Section 5.2. - 41 - Expires 11 January 1998 2722 2723 2724 2725 2726 2727 2728 2729 Version 5 - Specification Revision 6 2730 2731 2732 pre-authent(10), 2733 hw-authent(11), 2734 transited-policy-checked(12), 2735 ok-as-delegate(13) 2736 } 2737 2738 2739 KDCOptions ::= BIT STRING { 2740 reserved(0), 2741 forwardable(1), 2742 forwarded(2), 2743 proxiable(3), 2744 proxy(4), 2745 allow-postdate(5), 2746 postdated(6), 2747 unused7(7), 2748 renewable(8), 2749 unused9(9), 2750 unused10(10), 2751 unused11(11), 2752 unused12(12), 2753 unused13(13), 2754 disable-transited-check(26), 2755 renewable-ok(27), 2756 enc-tkt-in-skey(28), 2757 renew(30), 2758 validate(31) 2759 } 2760 2761 ASN.1 Bit strings have a length and a value. When 2762 used in Kerberos for the APOptions, TicketFlags, 2763 and KDCOptions, the length of the bit string on 2764 generated values should be the smallest multiple 2765 of 32 bits needed to include the highest order bit 2766 that is set (1), but in no case less than 32 bits. 2767 Implementations should accept values of bit 2768 strings of any length and treat the value of flags 2769 cooresponding to bits beyond the end of the bit 2770 string as if the bit were reset (0). Comparisonof 2771 bit strings of different length should treat the 2772 smaller string as if it were padded with zeros 2773 beyond the high order bits to the length of the 2774 longer string[23]. 2775 2776__________________________ 2777[23] Warning for implementations that unpack and repack 2778data structures during the generation and verification 2779of embedded checksums: Because any checksums applied to 2780data structures must be checked against the original 2781data the length of bit strings must be preserved within 2782a data structure between the time that a checksum is 2783generated through transmission to the time that the 2784checksum is verified. 2785 2786 2787 2788Section 5.2. - 42 - Expires 11 January 1998 2789 2790 2791 2792 2793 2794 2795 2796 Version 5 - Specification Revision 6 2797 2798 2799 LastReq ::= SEQUENCE OF SEQUENCE { 2800 lr-type[0] INTEGER, 2801 lr-value[1] KerberosTime 2802 } 2803 2804 2805lr-type This field indicates how the following lr-value 2806 field is to be interpreted. Negative values indi- 2807 cate that the information pertains only to the 2808 responding server. Non-negative values pertain to 2809 all servers for the realm. 2810 2811 If the lr-type field is zero (0), then no informa- 2812 tion is conveyed by the lr-value subfield. If the 2813 absolute value of the lr-type field is one (1), 2814 then the lr-value subfield is the time of last 2815 initial request for a TGT. If it is two (2), then 2816 the lr-value subfield is the time of last initial 2817 request. If it is three (3), then the lr-value 2818 subfield is the time of issue for the newest 2819 ticket-granting ticket used. If it is four (4), 2820 then the lr-value subfield is the time of the last 2821 renewal. If it is five (5), then the lr-value 2822 subfield is the time of last request (of any 2823 type). 2824 2825 2826lr-value This field contains the time of the last request. 2827 The time must be interpreted according to the con- 2828 tents of the accompanying lr-type subfield. 2829 2830 See section 6 for the definitions of Checksum, Check- 2831sumType, EncryptedData, EncryptionKey, EncryptionType, and 2832KeyType. 2833 2834 28355.3. Tickets and Authenticators 2836 2837 This section describes the format and encryption param- 2838eters for tickets and authenticators. When a ticket or 2839authenticator is included in a protocol message it is 2840treated as an opaque object. 2841 28425.3.1. Tickets 2843 2844 A ticket is a record that helps a client authenticate 2845to a service. A Ticket contains the following information: 2846 2847Ticket ::= [APPLICATION 1] SEQUENCE { 2848 tkt-vno[0] INTEGER, 2849 realm[1] Realm, 2850 sname[2] PrincipalName, 2851 enc-part[3] EncryptedData 2852} 2853 2854 2855Section 5.3.1. - 43 - Expires 11 January 1998 2856 2857 2858 2859 2860 2861 2862 2863 Version 5 - Specification Revision 6 2864 2865 2866-- Encrypted part of ticket 2867EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2868 flags[0] TicketFlags, 2869 key[1] EncryptionKey, 2870 crealm[2] Realm, 2871 cname[3] PrincipalName, 2872 transited[4] TransitedEncoding, 2873 authtime[5] KerberosTime, 2874 starttime[6] KerberosTime OPTIONAL, 2875 endtime[7] KerberosTime, 2876 renew-till[8] KerberosTime OPTIONAL, 2877 caddr[9] HostAddresses OPTIONAL, 2878 authorization-data[10] AuthorizationData OPTIONAL 2879} 2880-- encoded Transited field 2881TransitedEncoding ::= SEQUENCE { 2882 tr-type[0] INTEGER, -- must be registered 2883 contents[1] OCTET STRING 2884} 2885 2886The encoding of EncTicketPart is encrypted in the key shared 2887by Kerberos and the end server (the server's secret key). 2888See section 6 for the format of the ciphertext. 2889 2890tkt-vno This field specifies the version number for the 2891 ticket format. This document describes version 2892 number 5. 2893 2894 2895realm This field specifies the realm that issued a 2896 ticket. It also serves to identify the realm part 2897 of the server's principal identifier. Since a 2898 Kerberos server can only issue tickets for servers 2899 within its realm, the two will always be identi- 2900 cal. 2901 2902 2903sname This field specifies the name part of the server's 2904 identity. 2905 2906 2907enc-part This field holds the encrypted encoding of the 2908 EncTicketPart sequence. 2909 2910 2911flags This field indicates which of various options were 2912 used or requested when the ticket was issued. It 2913 is a bit-field, where the selected options are 2914 indicated by the bit being set (1), and the 2915 unselected options and reserved fields being reset 2916 (0). Bit 0 is the most significant bit. The 2917 encoding of the bits is specified in section 5.2. 2918 The flags are described in more detail above in 2919 section 2. The meanings of the flags are: 2920 2921 2922Section 5.3.1. - 44 - Expires 11 January 1998 2923 2924 2925 2926 2927 2928 Version 5 - Specification Revision 6 2929 2930 2931 Bit(s) Name Description 2932 2933 0 RESERVED 2934 Reserved for future expansion of this 2935 field. 2936 2937 1 FORWARDABLE 2938 The FORWARDABLE flag is normally only 2939 interpreted by the TGS, and can be 2940 ignored by end servers. When set, this 2941 flag tells the ticket-granting server 2942 that it is OK to issue a new ticket- 2943 granting ticket with a different network 2944 address based on the presented ticket. 2945 2946 2 FORWARDED 2947 When set, this flag indicates that the 2948 ticket has either been forwarded or was 2949 issued based on authentication involving 2950 a forwarded ticket-granting ticket. 2951 2952 3 PROXIABLE 2953 The PROXIABLE flag is normally only 2954 interpreted by the TGS, and can be 2955 ignored by end servers. The PROXIABLE 2956 flag has an interpretation identical to 2957 that of the FORWARDABLE flag, except 2958 that the PROXIABLE flag tells the 2959 ticket-granting server that only non- 2960 ticket-granting tickets may be issued 2961 with different network addresses. 2962 2963 4 PROXY 2964 When set, this flag indicates that a 2965 ticket is a proxy. 2966 2967 5 MAY-POSTDATE 2968 The MAY-POSTDATE flag is normally only 2969 interpreted by the TGS, and can be 2970 ignored by end servers. This flag tells 2971 the ticket-granting server that a post- 2972 dated ticket may be issued based on this 2973 ticket-granting ticket. 2974 2975 6 POSTDATED 2976 This flag indicates that this ticket has 2977 been postdated. The end-service can 2978 check the authtime field to see when the 2979 original authentication occurred. 2980 2981 7 INVALID 2982 This flag indicates that a ticket is 2983 invalid, and it must be validated by the 2984 KDC before use. Application servers 2985 must reject tickets which have this flag 2986 set. 2987 2988 2989 2990 2991 2992 2993 2994 2995Section 5.3.1. - 45 - Expires 11 January 1998 2996 2997 2998 2999 3000 3001 3002 3003 Version 5 - Specification Revision 6 3004 3005 3006 8 RENEWABLE 3007 The RENEWABLE flag is normally only 3008 interpreted by the TGS, and can usually 3009 be ignored by end servers (some particu- 3010 larly careful servers may wish to disal- 3011 low renewable tickets). A renewable 3012 ticket can be used to obtain a replace- 3013 ment ticket that expires at a later 3014 date. 3015 3016 9 INITIAL 3017 This flag indicates that this ticket was 3018 issued using the AS protocol, and not 3019 issued based on a ticket-granting 3020 ticket. 3021 3022 10 PRE-AUTHENT 3023 This flag indicates that during initial 3024 authentication, the client was authenti- 3025 cated by the KDC before a ticket was 3026 issued. The strength of the pre- 3027 authentication method is not indicated, 3028 but is acceptable to the KDC. 3029 3030 11 HW-AUTHENT 3031 This flag indicates that the protocol 3032 employed for initial authentication 3033 required the use of hardware expected to 3034 be possessed solely by the named client. 3035 The hardware authentication method is 3036 selected by the KDC and the strength of 3037 the method is not indicated. 3038 3039 3040 3041 3042Section 5.3.1. - 46 - Expires 11 January 1998 3043 3044 3045 3046 3047 3048 3049 3050 Version 5 - Specification Revision 6 3051 3052 3053 12 TRANSITED This flag indicates that the KDC for the 3054 POLICY-CHECKED realm has checked the transited field 3055 against a realm defined policy for 3056 trusted certifiers. If this flag is 3057 reset (0), then the application server 3058 must check the transited field itself, 3059 and if unable to do so it must reject 3060 the authentication. If the flag is set 3061 (1) then the application server may skip 3062 its own validation of the transited 3063 field, relying on the validation 3064 performed by the KDC. At its option the 3065 application server may still apply its 3066 own validation based on a separate 3067 policy for acceptance. 3068 3069Section 5.3.1. - 47 - Expires 11 January 1998 3070 3071 3072 3073 3074 3075 3076 3077 Version 5 - Specification Revision 6 3078 3079 3080 13 OK-AS-DELEGATE This flag indicates that the server (not 3081 the client) specified in the ticket has 3082 been determined by policy of the realm 3083 to be a suitable recipient of 3084 delegation. A client can use the 3085 presence of this flag to help it make a 3086 decision whether to delegate credentials 3087 (either grant a proxy or a forwarded 3088 ticket granting ticket) to this server. 3089 The client is free to ignore the value 3090 of this flag. When setting this flag, 3091 an administrator should consider the 3092 security and placement of the server on 3093 which the service will run, as well as 3094 whether the service requires the use of 3095 delegated credentials. 3096 3097 3098 3099 3100Section 5.3.1. - 48 - Expires 11 January 1998 3101 3102 3103 3104 3105 3106 3107 3108 Version 5 - Specification Revision 6 3109 3110 3111 14 ANONYMOUS 3112 This flag indicates that the principal 3113 named in the ticket is a generic princi- 3114 pal for the realm and does not identify 3115 the individual using the ticket. The 3116 purpose of the ticket is only to 3117 securely distribute a session key, and 3118 not to identify the user. Subsequent 3119 requests using the same ticket and ses- 3120 sion may be considered as originating 3121 from the same user, but requests with 3122 the same username but a different ticket 3123 are likely to originate from different 3124 users. 3125 3126 15-31 RESERVED 3127 Reserved for future use. 3128 3129 3130 3131key This field exists in the ticket and the KDC 3132 response and is used to pass the session key from 3133 Kerberos to the application server and the client. 3134 The field's encoding is described in section 6.2. 3135 3136crealm This field contains the name of the realm in which 3137 the client is registered and in which initial 3138 authentication took place. 3139 3140 3141cname This field contains the name part of the client's 3142 principal identifier. 3143 3144 3145transited This field lists the names of the Kerberos realms 3146 that took part in authenticating the user to whom 3147 this ticket was issued. It does not specify the 3148 order in which the realms were transited. See 3149 section 3.3.3.2 for details on how this field 3150 encodes the traversed realms. 3151 3152 3153authtime This field indicates the time of initial authenti- 3154 cation for the named principal. It is the time of 3155 issue for the original ticket on which this ticket 3156 is based. It is included in the ticket to provide 3157 additional information to the end service, and to 3158 provide the necessary information for implementa- 3159 tion of a `hot list' service at the KDC. An end 3160 service that is particularly paranoid could refuse 3161 to accept tickets for which the initial authenti- 3162 cation occurred "too far" in the past. 3163 3164 This field is also returned as part of the 3165 response from the KDC. When returned as part of 3166 the response to initial authentication 3167 3168 3169Section 5.3.1. - 49 - Expires 11 January 1998 3170 3171 3172 3173 3174 3175 3176 3177 Version 5 - Specification Revision 6 3178 3179 3180 (KRB_AS_REP), this is the current time on the Ker- 3181 beros server[24]. 3182 3183 3184starttime This field in the ticket specifies the time after 3185 which the ticket is valid. Together with endtime, 3186 this field specifies the life of the ticket. If 3187 it is absent from the ticket, its value should be 3188 treated as that of the authtime field. 3189 3190 3191endtime This field contains the time after which the 3192 ticket will not be honored (its expiration time). 3193 Note that individual services may place their own 3194 limits on the life of a ticket and may reject 3195 tickets which have not yet expired. As such, this 3196 is really an upper bound on the expiration time 3197 for the ticket. 3198 3199 3200renew-tillThis field is only present in tickets that have 3201 the RENEWABLE flag set in the flags field. It 3202 indicates the maximum endtime that may be included 3203 in a renewal. It can be thought of as the abso- 3204 lute expiration time for the ticket, including all 3205 renewals. 3206 3207 3208caddr This field in a ticket contains zero (if omitted) 3209 or more (if present) host addresses. These are 3210 the addresses from which the ticket can be used. 3211 If there are no addresses, the ticket can be used 3212 from any location. The decision by the KDC to 3213 issue or by the end server to accept zero-address 3214 tickets is a policy decision and is left to the 3215 Kerberos and end-service administrators; they may 3216 refuse to issue or accept such tickets. The sug- 3217 gested and default policy, however, is that such 3218 tickets will only be issued or accepted when addi- 3219 tional information that can be used to restrict 3220 the use of the ticket is included in the 3221 authorization_data field. Such a ticket is a 3222 capability. 3223 3224 Network addresses are included in the ticket to 3225 make it harder for an attacker to use stolen 3226 credentials. Because the session key is not sent 3227 over the network in cleartext, credentials can't 3228__________________________ 3229[24] It is NOT recommended that this time value be used 3230to adjust the workstation's clock since the workstation 3231cannot reliably determine that such a KRB_AS_REP actu- 3232ally came from the proper KDC in a timely manner. 3233 3234 3235Section 5.3.1. - 50 - Expires 11 January 1998 3236 3237 3238 3239 3240 3241 3242 3243 Version 5 - Specification Revision 6 3244 3245 3246 be stolen simply by listening to the network; an 3247 attacker has to gain access to the session key 3248 (perhaps through operating system security 3249 breaches or a careless user's unattended session) 3250 to make use of stolen tickets. 3251 3252 It is important to note that the network address 3253 from which a connection is received cannot be 3254 reliably determined. Even if it could be, an 3255 attacker who has compromised the client's worksta- 3256 tion could use the credentials from there. 3257 Including the network addresses only makes it more 3258 difficult, not impossible, for an attacker to walk 3259 off with stolen credentials and then use them from 3260 a "safe" location. 3261 3262 3263authorization-data 3264 The authorization-data field is used to pass 3265 authorization data from the principal on whose 3266 behalf a ticket was issued to the application ser- 3267 vice. If no authorization data is included, this 3268 field will be left out. Experience has shown that 3269 the name of this field is confusing, and that a 3270 better name for this field would be restrictions. 3271 Unfortunately, it is not possible to change the 3272 name of this field at this time. 3273 3274 This field contains restrictions on any authority 3275 obtained on the bases of authentication using the 3276 ticket. It is possible for any principal in 3277 posession of credentials to add entries to the 3278 authorization data field since these entries 3279 further restrict what can be done with the ticket. 3280 Such additions can be made by specifying the addi- 3281 tional entries when a new ticket is obtained dur- 3282 ing the TGS exchange, or they may be added during 3283 chained delegation using the authorization data 3284 field of the authenticator. 3285 3286 Because entries may be added to this field by the 3287 holder of credentials, it is not allowable for the 3288 presence of an entry in the authorization data 3289 field of a ticket to amplify the priveleges one 3290 would obtain from using a ticket. 3291 3292 The data in this field may be specific to the end 3293 service; the field will contain the names of ser- 3294 vice specific objects, and the rights to those 3295 objects. The format for this field is described 3296 in section 5.2. Although Kerberos is not con- 3297 cerned with the format of the contents of the sub- 3298 fields, it does carry type information (ad-type). 3299 3300 3301 3302Section 5.3.1. - 51 - Expires 11 January 1998 3303 3304 3305 3306 3307 3308 3309 3310 Version 5 - Specification Revision 6 3311 3312 3313 By using the authorization_data field, a principal 3314 is able to issue a proxy that is valid for a 3315 specific purpose. For example, a client wishing 3316 to print a file can obtain a file server proxy to 3317 be passed to the print server. By specifying the 3318 name of the file in the authorization_data field, 3319 the file server knows that the print server can 3320 only use the client's rights when accessing the 3321 particular file to be printed. 3322 3323 A separate service providing providing authoriza- 3324 tion or certifying group membership may be built 3325 using the authorization-data field. In this case, 3326 the entity granting authorization (not the author- 3327 ized entity), obtains a ticket in its own name 3328 (e.g. the ticket is issued in the name of a 3329 privelege server), and this entity adds restric- 3330 tions on its own authority and delegates the res- 3331 tricted authority through a proxy to the client. 3332 The client would then present this authorization 3333 credential to the application server separately 3334 from the authentication exchange. 3335 3336 Similarly, if one specifies the authorization-data 3337 field of a proxy and leaves the host addresses 3338 blank, the resulting ticket and session key can be 3339 treated as a capability. See [7] for some sug- 3340 gested uses of this field. 3341 3342 The authorization-data field is optional and does 3343 not have to be included in a ticket. 3344 3345 33465.3.2. Authenticators 3347 3348 An authenticator is a record sent with a ticket to a 3349server to certify the client's knowledge of the encryption 3350key in the ticket, to help the server detect replays, and to 3351help choose a "true session key" to use with the particular 3352session. The encoding is encrypted in the ticket's session 3353key shared by the client and the server: 3354 3355-- Unencrypted authenticator 3356Authenticator ::= [APPLICATION 2] SEQUENCE { 3357 authenticator-vno[0] INTEGER, 3358 crealm[1] Realm, 3359 cname[2] PrincipalName, 3360 cksum[3] Checksum OPTIONAL, 3361 cusec[4] INTEGER, 3362 ctime[5] KerberosTime, 3363 subkey[6] EncryptionKey OPTIONAL, 3364 seq-number[7] INTEGER OPTIONAL, 3365 authorization-data[8] AuthorizationData OPTIONAL 3366} 3367 3368 3369 3370Section 5.3.2. - 52 - Expires 11 January 1998 3371 3372 3373 3374 3375 3376 3377 3378 Version 5 - Specification Revision 6 3379 3380 3381authenticator-vno 3382 This field specifies the version number for the 3383 format of the authenticator. This document speci- 3384 fies version 5. 3385 3386 3387crealm and cname 3388 These fields are the same as those described for 3389 the ticket in section 5.3.1. 3390 3391 3392cksum This field contains a checksum of the the applica- 3393 tion data that accompanies the KRB_AP_REQ. 3394 3395 3396cusec This field contains the microsecond part of the 3397 client's timestamp. Its value (before encryption) 3398 ranges from 0 to 999999. It often appears along 3399 with ctime. The two fields are used together to 3400 specify a reasonably accurate timestamp. 3401 3402 3403ctime This field contains the current time on the 3404 client's host. 3405 3406 3407subkey This field contains the client's choice for an 3408 encryption key which is to be used to protect this 3409 specific application session. Unless an applica- 3410 tion specifies otherwise, if this field is left 3411 out the session key from the ticket will be used. 3412 3413seq-numberThis optional field includes the initial sequence 3414 number to be used by the KRB_PRIV or KRB_SAFE mes- 3415 sages when sequence numbers are used to detect 3416 replays (It may also be used by application 3417 specific messages). When included in the authen- 3418 ticator this field specifies the initial sequence 3419 number for messages from the client to the server. 3420 When included in the AP-REP message, the initial 3421 sequence number is that for messages from the 3422 server to the client. When used in KRB_PRIV or 3423 KRB_SAFE messages, it is incremented by one after 3424 each message is sent. 3425 3426 For sequence numbers to adequately support the 3427 detection of replays they should be non-repeating, 3428 even across connection boundaries. The initial 3429 sequence number should be random and uniformly 3430 distributed across the full space of possible 3431 sequence numbers, so that it cannot be guessed by 3432 an attacker and so that it and the successive 3433 sequence numbers do not repeat other sequences. 3434 3435 3436 3437Section 5.3.2. - 53 - Expires 11 January 1998 3438 3439 3440 3441 3442 3443 3444 3445 Version 5 - Specification Revision 6 3446 3447 3448authorization-data 3449 This field is the same as described for the ticket 3450 in section 5.3.1. It is optional and will only 3451 appear when additional restrictions are to be 3452 placed on the use of a ticket, beyond those car- 3453 ried in the ticket itself. 3454 34555.4. Specifications for the AS and TGS exchanges 3456 3457 This section specifies the format of the messages used 3458in the exchange between the client and the Kerberos server. 3459The format of possible error messages appears in section 34605.9.1. 3461 34625.4.1. KRB_KDC_REQ definition 3463 3464 The KRB_KDC_REQ message has no type of its own. 3465Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ 3466depending on whether the request is for an initial ticket or 3467an additional ticket. In either case, the message is sent 3468from the client to the Authentication Server to request 3469credentials for a service. 3470 3471 The message fields are: 3472 3473AS-REQ ::= [APPLICATION 10] KDC-REQ 3474TGS-REQ ::= [APPLICATION 12] KDC-REQ 3475 3476KDC-REQ ::= SEQUENCE { 3477 pvno[1] INTEGER, 3478 msg-type[2] INTEGER, 3479 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 3480 req-body[4] KDC-REQ-BODY 3481} 3482 3483PA-DATA ::= SEQUENCE { 3484 padata-type[1] INTEGER, 3485 padata-value[2] OCTET STRING, 3486 -- might be encoded AP-REQ 3487} 3488 3489KDC-REQ-BODY ::= SEQUENCE { 3490 kdc-options[0] KDCOptions, 3491 cname[1] PrincipalName OPTIONAL, 3492 -- Used only in AS-REQ 3493 realm[2] Realm, -- Server's realm 3494 -- Also client's in AS-REQ 3495 sname[3] PrincipalName OPTIONAL, 3496 from[4] KerberosTime OPTIONAL, 3497 till[5] KerberosTime OPTIONAL, 3498 rtime[6] KerberosTime OPTIONAL, 3499 nonce[7] INTEGER, 3500 etype[8] SEQUENCE OF INTEGER, 3501 -- EncryptionType, 3502 -- in preference order 3503 3504 3505Section 5.4.1. - 54 - Expires 11 January 1998 3506 3507 3508 3509 3510 3511 3512 3513 Version 5 - Specification Revision 6 3514 3515 3516 addresses[9] HostAddresses OPTIONAL, 3517 enc-authorization-data[10] EncryptedData OPTIONAL, 3518 -- Encrypted AuthorizationData 3519 -- encoding 3520 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 3521} 3522 3523The fields in this message are: 3524 3525 3526pvno This field is included in each message, and speci- 3527 fies the protocol version number. This document 3528 specifies protocol version 5. 3529 3530 3531msg-type This field indicates the type of a protocol mes- 3532 sage. It will almost always be the same as the 3533 application identifier associated with a message. 3534 It is included to make the identifier more readily 3535 accessible to the application. For the KDC-REQ 3536 message, this type will be KRB_AS_REQ or 3537 KRB_TGS_REQ. 3538 3539 3540padata The padata (pre-authentication data) field con- 3541 tains a sequence of authentication information 3542 which may be needed before credentials can be 3543 issued or decrypted. In the case of requests for 3544 additional tickets (KRB_TGS_REQ), this field will 3545 include an element with padata-type of PA-TGS-REQ 3546 and data of an authentication header (ticket- 3547 granting ticket and authenticator). The checksum 3548 in the authenticator (which must be collision- 3549 proof) is to be computed over the KDC-REQ-BODY 3550 encoding. In most requests for initial authenti- 3551 cation (KRB_AS_REQ) and most replies (KDC-REP), 3552 the padata field will be left out. 3553 3554 This field may also contain information needed by 3555 certain extensions to the Kerberos protocol. For 3556 example, it might be used to initially verify the 3557 identity of a client before any response is 3558 returned. This is accomplished with a padata 3559 field with padata-type equal to PA-ENC-TIMESTAMP 3560 and padata-value defined as follows: 3561 3562padata-type ::= PA-ENC-TIMESTAMP 3563padata-value ::= EncryptedData -- PA-ENC-TS-ENC 3564 3565PA-ENC-TS-ENC ::= SEQUENCE { 3566 patimestamp[0] KerberosTime, -- client's time 3567 pausec[1] INTEGER OPTIONAL 3568} 3569 3570 with patimestamp containing the client's time and 3571 3572 3573Section 5.4.1. - 55 - Expires 11 January 1998 3574 3575 3576 3577 3578 3579 3580 3581 Version 5 - Specification Revision 6 3582 3583 3584 pausec containing the microseconds which may be 3585 omitted if a client will not generate more than 3586 one request per second. The ciphertext (padata- 3587 value) consists of the PA-ENC-TS-ENC sequence, 3588 encrypted using the client's secret key. 3589 3590 The padata field can also contain information 3591 needed to help the KDC or the client select the 3592 key needed for generating or decrypting the 3593 response. This form of the padata is useful for 3594 supporting the use of certain token cards with 3595 Kerberos. The details of such extensions are 3596 specified in separate documents. See [11] for 3597 additional uses of this field. 3598 3599padata-type 3600 The padata-type element of the padata field indi- 3601 cates the way that the padata-value element is to 3602 be interpreted. Negative values of padata-type 3603 are reserved for unregistered use; non-negative 3604 values are used for a registered interpretation of 3605 the element type. 3606 3607 3608req-body This field is a placeholder delimiting the extent 3609 of the remaining fields. If a checksum is to be 3610 calculated over the request, it is calculated over 3611 an encoding of the KDC-REQ-BODY sequence which is 3612 enclosed within the req-body field. 3613 3614 3615kdc-options 3616 This field appears in the KRB_AS_REQ and 3617 KRB_TGS_REQ requests to the KDC and indicates the 3618 flags that the client wants set on the tickets as 3619 well as other information that is to modify the 3620 behavior of the KDC. Where appropriate, the name 3621 of an option may be the same as the flag that is 3622 set by that option. Although in most case, the 3623 bit in the options field will be the same as that 3624 in the flags field, this is not guaranteed, so it 3625 is not acceptable to simply copy the options field 3626 to the flags field. There are various checks that 3627 must be made before honoring an option anyway. 3628 3629 The kdc_options field is a bit-field, where the 3630 selected options are indicated by the bit being 3631 set (1), and the unselected options and reserved 3632 fields being reset (0). The encoding of the bits 3633 is specified in section 5.2. The options are 3634 described in more detail above in section 2. The 3635 meanings of the options are: 3636 3637 3638 3639 3640Section 5.4.1. - 56 - Expires 11 January 1998 3641 3642 3643 3644 3645 Version 5 - Specification Revision 6 3646 3647 3648 Bit(s) Name Description 3649 0 RESERVED 3650 Reserved for future expansion of this 3651 field. 3652 3653 1 FORWARDABLE 3654 The FORWARDABLE option indicates that 3655 the ticket to be issued is to have its 3656 forwardable flag set. It may only be 3657 set on the initial request, or in a sub- 3658 sequent request if the ticket-granting 3659 ticket on which it is based is also for- 3660 wardable. 3661 3662 2 FORWARDED 3663 The FORWARDED option is only specified 3664 in a request to the ticket-granting 3665 server and will only be honored if the 3666 ticket-granting ticket in the request 3667 has its FORWARDABLE bit set. This 3668 option indicates that this is a request 3669 for forwarding. The address(es) of the 3670 host from which the resulting ticket is 3671 to be valid are included in the 3672 addresses field of the request. 3673 3674 3 PROXIABLE 3675 The PROXIABLE option indicates that the 3676 ticket to be issued is to have its prox- 3677 iable flag set. It may only be set on 3678 the initial request, or in a subsequent 3679 request if the ticket-granting ticket on 3680 which it is based is also proxiable. 3681 3682 4 PROXY 3683 The PROXY option indicates that this is 3684 a request for a proxy. This option will 3685 only be honored if the ticket-granting 3686 ticket in the request has its PROXIABLE 3687 bit set. The address(es) of the host 3688 from which the resulting ticket is to be 3689 valid are included in the addresses 3690 field of the request. 3691 3692 5 ALLOW-POSTDATE 3693 The ALLOW-POSTDATE option indicates that 3694 the ticket to be issued is to have its 3695 MAY-POSTDATE flag set. It may only be 3696 set on the initial request, or in a sub- 3697 sequent request if the ticket-granting 3698 ticket on which it is based also has its 3699 MAY-POSTDATE flag set. 3700 3701 3702 3703 3704 3705 3706 3707Section 5.4.1. - 57 - Expires 11 January 1998 3708 3709 3710 3711 3712 3713 3714 3715 Version 5 - Specification Revision 6 3716 3717 3718 6 POSTDATED 3719 The POSTDATED option indicates that this 3720 is a request for a postdated ticket. 3721 This option will only be honored if the 3722 ticket-granting ticket on which it is 3723 based has its MAY-POSTDATE flag set. 3724 The resulting ticket will also have its 3725 INVALID flag set, and that flag may be 3726 reset by a subsequent request to the KDC 3727 after the starttime in the ticket has 3728 been reached. 3729 3730 7 UNUSED 3731 This option is presently unused. 3732 3733 8 RENEWABLE 3734 The RENEWABLE option indicates that the 3735 ticket to be issued is to have its 3736 RENEWABLE flag set. It may only be set 3737 on the initial request, or when the 3738 ticket-granting ticket on which the 3739 request is based is also renewable. If 3740 this option is requested, then the rtime 3741 field in the request contains the 3742 desired absolute expiration time for the 3743 ticket. 3744 3745 9-13 UNUSED 3746 These options are presently unused. 3747 3748 14 REQUEST-ANONYMOUS 3749 The REQUEST-ANONYMOUS option indicates 3750 that the ticket to be issued is not to 3751 identify the user to which it was 3752 issued. Instead, the principal identif- 3753 ier is to be generic, as specified by 3754 the policy of the realm (e.g. usually 3755 anonymous@realm). The purpose of the 3756 ticket is only to securely distribute a 3757 session key, and not to identify the 3758 user. The ANONYMOUS flag on the ticket 3759 to be returned should be set. If the 3760 local realms policy does not permit 3761 anonymous credentials, the request is to 3762 be rejected. 3763 3764 15-25 RESERVED 3765 Reserved for future use. 3766 3767 26 DISABLE-TRANSITED-CHECK 3768 By default the KDC will check the 3769 transited field of a ticket-granting- 3770 ticket against the policy of the local 3771 realm before it will issue derivative 3772 tickets based on the ticket granting 3773 ticket. If this flag is set in the 3774 request, checking of the transited field 3775 is disabled. Tickets issued without the 3776 performance of this check will be noted 3777 by the reset (0) value of the 3778 TRANSITED-POLICY-CHECKED flag, 3779 indicating to the application server 3780 that the tranisted field must be checked 3781 locally. KDC's are encouraged but not 3782 required to honor the 3783 DISABLE-TRANSITED-CHECK option. 3784 3785 3786 3787Section 5.4.1. - 58 - Expires 11 January 1998 3788 3789 3790 3791 3792 3793 3794 3795 Version 5 - Specification Revision 6 3796 3797 3798 27 RENEWABLE-OK 3799 The RENEWABLE-OK option indicates that a 3800 renewable ticket will be acceptable if a 3801 ticket with the requested life cannot 3802 otherwise be provided. If a ticket with 3803 the requested life cannot be provided, 3804 then a renewable ticket may be issued 3805 with a renew-till equal to the the 3806 requested endtime. The value of the 3807 renew-till field may still be limited by 3808 local limits, or limits selected by the 3809 individual principal or server. 3810 3811 28 ENC-TKT-IN-SKEY 3812 This option is used only by the ticket- 3813 granting service. The ENC-TKT-IN-SKEY 3814 option indicates that the ticket for the 3815 end server is to be encrypted in the 3816 session key from the additional ticket- 3817 granting ticket provided. 3818 3819 29 RESERVED 3820 Reserved for future use. 3821 3822 30 RENEW 3823 This option is used only by the ticket- 3824 granting service. The RENEW option 3825 indicates that the present request is 3826 for a renewal. The ticket provided is 3827 encrypted in the secret key for the 3828 server on which it is valid. This 3829 option will only be honored if the 3830 ticket to be renewed has its RENEWABLE 3831 flag set and if the time in its renew- 3832 till field has not passed. The ticket 3833 to be renewed is passed in the padata 3834 field as part of the authentication 3835 header. 3836 3837 31 VALIDATE 3838 This option is used only by the ticket- 3839 granting service. The VALIDATE option 3840 indicates that the request is to vali- 3841 date a postdated ticket. It will only 3842 be honored if the ticket presented is 3843 postdated, presently has its INVALID 3844 flag set, and would be otherwise usable 3845 at this time. A ticket cannot be vali- 3846 dated before its starttime. The ticket 3847 presented for validation is encrypted in 3848 the key of the server for which it is 3849 valid and is passed in the padata field 3850 as part of the authentication header. 3851 3852cname and sname 3853 These fields are the same as those described for 3854 the ticket in section 5.3.1. sname may only be 3855 3856 3857Section 5.4.1. - 59 - Expires 11 January 1998 3858 3859 3860 3861 3862 3863 3864 3865 Version 5 - Specification Revision 6 3866 3867 3868 absent when the ENC-TKT-IN-SKEY option is speci- 3869 fied. If absent, the name of the server is taken 3870 from the name of the client in the ticket passed 3871 as additional-tickets. 3872 3873 3874enc-authorization-data 3875 The enc-authorization-data, if present (and it can 3876 only be present in the TGS_REQ form), is an encod- 3877 ing of the desired authorization-data encrypted 3878 under the sub-session key if present in the 3879 Authenticator, or alternatively from the session 3880 key in the ticket-granting ticket, both from the 3881 padata field in the KRB_AP_REQ. 3882 3883 3884realm This field specifies the realm part of the 3885 server's principal identifier. In the AS 3886 exchange, this is also the realm part of the 3887 client's principal identifier. 3888 3889 3890from This field is included in the KRB_AS_REQ and 3891 KRB_TGS_REQ ticket requests when the requested 3892 ticket is to be postdated. It specifies the 3893 desired start time for the requested ticket. 3894 3895 3896 3897till This field contains the expiration date requested 3898 by the client in a ticket request. It is option 3899 and if omitted the requested ticket is to have the 3900 maximum endtime permitted according to KDC policy 3901 for the parties to the authentication exchange as 3902 limited by expiration date of the ticket granting 3903 ticket or other preauthentication credentials. 3904 3905 3906rtime This field is the requested renew-till time sent 3907 from a client to the KDC in a ticket request. It 3908 is optional. 3909 3910 3911nonce This field is part of the KDC request and 3912 response. It it intended to hold a random number 3913 generated by the client. If the same number is 3914 included in the encrypted response from the KDC, 3915 it provides evidence that the response is fresh 3916 and has not been replayed by an attacker. Nonces 3917 must never be re-used. Ideally, it should be gen- 3918 erated randomly, but if the correct time is known, 3919 it may suffice[25]. 3920__________________________ 3921[25] Note, however, that if the time is used as the 3922 3923Section 5.4.1. - 60 - Expires 11 January 1998 3924 3925 3926 3927 3928 3929 3930 3931 Version 5 - Specification Revision 6 3932 3933 3934etype This field specifies the desired encryption algo- 3935 rithm to be used in the response. 3936 3937 3938addresses This field is included in the initial request for 3939 tickets, and optionally included in requests for 3940 additional tickets from the ticket-granting 3941 server. It specifies the addresses from which the 3942 requested ticket is to be valid. Normally it 3943 includes the addresses for the client's host. If 3944 a proxy is requested, this field will contain 3945 other addresses. The contents of this field are 3946 usually copied by the KDC into the caddr field of 3947 the resulting ticket. 3948 3949 3950additional-tickets 3951 Additional tickets may be optionally included in a 3952 request to the ticket-granting server. If the 3953 ENC-TKT-IN-SKEY option has been specified, then 3954 the session key from the additional ticket will be 3955 used in place of the server's key to encrypt the 3956 new ticket. If more than one option which 3957 requires additional tickets has been specified, 3958 then the additional tickets are used in the order 3959 specified by the ordering of the options bits (see 3960 kdc-options, above). 3961 3962 3963 The application code will be either ten (10) or twelve 3964(12) depending on whether the request is for an initial 3965ticket (AS-REQ) or for an additional ticket (TGS-REQ). 3966 3967 The optional fields (addresses, authorization-data and 3968additional-tickets) are only included if necessary to per- 3969form the operation specified in the kdc-options field. 3970 3971 It should be noted that in KRB_TGS_REQ, the protocol 3972version number appears twice and two different message types 3973appear: the KRB_TGS_REQ message contains these fields as 3974does the authentication header (KRB_AP_REQ) that is passed 3975in the padata field. 3976 39775.4.2. KRB_KDC_REP definition 3978 3979 The KRB_KDC_REP message format is used for the reply 3980from the KDC for either an initial (AS) request or a subse- 3981quent (TGS) request. There is no message type for 3982__________________________ 3983nonce, one must make sure that the workstation time is 3984monotonically increasing. If the time is ever reset 3985backwards, there is a small, but finite, probability 3986that a nonce will be reused. 3987 3988 3989 3990Section 5.4.2. - 61 - Expires 11 January 1998 3991 3992 3993 3994 3995 3996 3997 3998 Version 5 - Specification Revision 6 3999 4000 4001KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 4002KRB_TGS_REP. The key used to encrypt the ciphertext part of 4003the reply depends on the message type. For KRB_AS_REP, the 4004ciphertext is encrypted in the client's secret key, and the 4005client's key version number is included in the key version 4006number for the encrypted data. For KRB_TGS_REP, the cipher- 4007text is encrypted in the sub-session key from the Authenti- 4008cator, or if absent, the session key from the ticket- 4009granting ticket used in the request. In that case, no ver- 4010sion number will be present in the EncryptedData sequence. 4011 4012 The KRB_KDC_REP message contains the following fields: 4013 4014AS-REP ::= [APPLICATION 11] KDC-REP 4015TGS-REP ::= [APPLICATION 13] KDC-REP 4016 4017KDC-REP ::= SEQUENCE { 4018 pvno[0] INTEGER, 4019 msg-type[1] INTEGER, 4020 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 4021 crealm[3] Realm, 4022 cname[4] PrincipalName, 4023 ticket[5] Ticket, 4024 enc-part[6] EncryptedData 4025} 4026 4027 4028EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart 4029EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4030 4031 4032 4033EncKDCRepPart ::= SEQUENCE { 4034 key[0] EncryptionKey, 4035 last-req[1] LastReq, 4036 nonce[2] INTEGER, 4037 key-expiration[3] KerberosTime OPTIONAL, 4038 flags[4] TicketFlags, 4039 authtime[5] KerberosTime, 4040 starttime[6] KerberosTime OPTIONAL, 4041 endtime[7] KerberosTime, 4042 renew-till[8] KerberosTime OPTIONAL, 4043 srealm[9] Realm, 4044 sname[10] PrincipalName, 4045 caddr[11] HostAddresses OPTIONAL 4046} 4047 4048 4049pvno and msg-type 4050 These fields are described above in section 5.4.1. 4051 msg-type is either KRB_AS_REP or KRB_TGS_REP. 4052__________________________ 4053[27] An application code in the encrypted part of a 4054message provides an additional check that the message 4055was decrypted properly. 4056 4057 4058Section 5.4.2. - 62 - Expires 11 January 1998 4059 4060 4061 4062 4063 4064 4065 4066 Version 5 - Specification Revision 6 4067 4068 4069padata This field is described in detail in section 4070 5.4.1. One possible use for this field is to 4071 encode an alternate "mix-in" string to be used 4072 with a string-to-key algorithm (such as is 4073 described in section 6.3.2). This ability is use- 4074 ful to ease transitions if a realm name needs to 4075 change (e.g. when a company is acquired); in such 4076 a case all existing password-derived entries in 4077 the KDC database would be flagged as needing a 4078 special mix-in string until the next password 4079 change. 4080 4081 4082crealm, cname, srealm and sname 4083 These fields are the same as those described for 4084 the ticket in section 5.3.1. 4085 4086 4087ticket The newly-issued ticket, from section 5.3.1. 4088 4089 4090enc-part This field is a place holder for the ciphertext 4091 and related information that forms the encrypted 4092 part of a message. The description of the 4093 encrypted part of the message follows each appear- 4094 ance of this field. The encrypted part is encoded 4095 as described in section 6.1. 4096 4097 4098key This field is the same as described for the ticket 4099 in section 5.3.1. 4100 4101 4102last-req This field is returned by the KDC and specifies 4103 the time(s) of the last request by a principal. 4104 Depending on what information is available, this 4105 might be the last time that a request for a 4106 ticket-granting ticket was made, or the last time 4107 that a request based on a ticket-granting ticket 4108 was successful. It also might cover all servers 4109 for a realm, or just the particular server. Some 4110 implementations may display this information to 4111 the user to aid in discovering unauthorized use of 4112 one's identity. It is similar in spirit to the 4113 last login time displayed when logging into 4114 timesharing systems. 4115 4116 4117nonce This field is described above in section 5.4.1. 4118 4119 4120key-expiration 4121 The key-expiration field is part of the response 4122 from the KDC and specifies the time that the 4123 4124 4125Section 5.4.2. - 63 - Expires 11 January 1998 4126 4127 4128 4129 4130 4131 4132 4133 Version 5 - Specification Revision 6 4134 4135 4136 client's secret key is due to expire. The expira- 4137 tion might be the result of password aging or an 4138 account expiration. This field will usually be 4139 left out of the TGS reply since the response to 4140 the TGS request is encrypted in a session key and 4141 no client information need be retrieved from the 4142 KDC database. It is up to the application client 4143 (usually the login program) to take appropriate 4144 action (such as notifying the user) if the expira- 4145 tion time is imminent. 4146 4147 4148flags, authtime, starttime, endtime, renew-till and caddr 4149 These fields are duplicates of those found in the 4150 encrypted portion of the attached ticket (see sec- 4151 tion 5.3.1), provided so the client may verify 4152 they match the intended request and to assist in 4153 proper ticket caching. If the message is of type 4154 KRB_TGS_REP, the caddr field will only be filled 4155 in if the request was for a proxy or forwarded 4156 ticket, or if the user is substituting a subset of 4157 the addresses from the ticket granting ticket. If 4158 the client-requested addresses are not present or 4159 not used, then the addresses contained in the 4160 ticket will be the same as those included in the 4161 ticket-granting ticket. 4162 4163 41645.5. Client/Server (CS) message specifications 4165 4166 This section specifies the format of the messages used 4167for the authentication of the client to the application 4168server. 4169 41705.5.1. KRB_AP_REQ definition 4171 4172 The KRB_AP_REQ message contains the Kerberos protocol 4173version number, the message type KRB_AP_REQ, an options 4174field to indicate any options in use, and the ticket and 4175authenticator themselves. The KRB_AP_REQ message is often 4176referred to as the "authentication header". 4177 4178AP-REQ ::= [APPLICATION 14] SEQUENCE { 4179 pvno[0] INTEGER, 4180 msg-type[1] INTEGER, 4181 ap-options[2] APOptions, 4182 ticket[3] Ticket, 4183 authenticator[4] EncryptedData 4184} 4185 4186APOptions ::= BIT STRING { 4187 reserved(0), 4188 use-session-key(1), 4189 mutual-required(2) 4190 4191 4192Section 5.5.1. - 64 - Expires 11 January 1998 4193 4194 4195 4196 4197 4198 4199 4200 Version 5 - Specification Revision 6 4201 4202 4203} 4204 4205 4206pvno and msg-type 4207 These fields are described above in section 5.4.1. 4208 msg-type is KRB_AP_REQ. 4209 4210 4211ap-optionsThis field appears in the application request 4212 (KRB_AP_REQ) and affects the way the request is 4213 processed. It is a bit-field, where the selected 4214 options are indicated by the bit being set (1), 4215 and the unselected options and reserved fields 4216 being reset (0). The encoding of the bits is 4217 specified in section 5.2. The meanings of the 4218 options are: 4219 4220 Bit(s) Name Description 4221 4222 0 RESERVED 4223 Reserved for future expansion of this 4224 field. 4225 4226 1 USE-SESSION-KEY 4227 The USE-SESSION-KEY option indicates 4228 that the ticket the client is presenting 4229 to a server is encrypted in the session 4230 key from the server's ticket-granting 4231 ticket. When this option is not speci- 4232 fied, the ticket is encrypted in the 4233 server's secret key. 4234 4235 2 MUTUAL-REQUIRED 4236 The MUTUAL-REQUIRED option tells the 4237 server that the client requires mutual 4238 authentication, and that it must respond 4239 with a KRB_AP_REP message. 4240 4241 3-31 RESERVED 4242 Reserved for future use. 4243 4244 4245 4246ticket This field is a ticket authenticating the client 4247 to the server. 4248 4249 4250authenticator 4251 This contains the authenticator, which includes 4252 the client's choice of a subkey. Its encoding is 4253 described in section 5.3.2. 4254 42555.5.2. KRB_AP_REP definition 4256 4257 The KRB_AP_REP message contains the Kerberos protocol 4258version number, the message type, and an encrypted time- 4259stamp. The message is sent in in response to an application 4260request (KRB_AP_REQ) where the mutual authentication option 4261 4262 4263Section 5.5.2. - 65 - Expires 11 January 1998 4264 4265 4266 4267 4268 4269 4270 4271 Version 5 - Specification Revision 6 4272 4273 4274has been selected in the ap-options field. 4275 4276AP-REP ::= [APPLICATION 15] SEQUENCE { 4277 pvno[0] INTEGER, 4278 msg-type[1] INTEGER, 4279 enc-part[2] EncryptedData 4280} 4281 4282EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { 4283 ctime[0] KerberosTime, 4284 cusec[1] INTEGER, 4285 subkey[2] EncryptionKey OPTIONAL, 4286 seq-number[3] INTEGER OPTIONAL 4287} 4288 4289The encoded EncAPRepPart is encrypted in the shared session 4290key of the ticket. The optional subkey field can be used in 4291an application-arranged negotiation to choose a per associa- 4292tion session key. 4293 4294 4295pvno and msg-type 4296 These fields are described above in section 5.4.1. 4297 msg-type is KRB_AP_REP. 4298 4299 4300enc-part This field is described above in section 5.4.2. 4301 4302 4303ctime This field contains the current time on the 4304 client's host. 4305 4306 4307cusec This field contains the microsecond part of the 4308 client's timestamp. 4309 4310 4311subkey This field contains an encryption key which is to 4312 be used to protect this specific application ses- 4313 sion. See section 3.2.6 for specifics on how this 4314 field is used to negotiate a key. Unless an 4315 application specifies otherwise, if this field is 4316 left out, the sub-session key from the authentica- 4317 tor, or if also left out, the session key from the 4318 ticket will be used. 4319 4320 4321 4322__________________________ 4323[29] An application code in the encrypted part of a 4324message provides an additional check that the message 4325was decrypted properly. 4326 4327 4328 4329Section 5.5.2. - 66 - Expires 11 January 1998 4330 4331 4332 4333 4334 4335 4336 4337 Version 5 - Specification Revision 6 4338 4339 43405.5.3. Error message reply 4341 4342 If an error occurs while processing the application 4343request, the KRB_ERROR message will be sent in response. 4344See section 5.9.1 for the format of the error message. The 4345cname and crealm fields may be left out if the server cannot 4346determine their appropriate values from the corresponding 4347KRB_AP_REQ message. If the authenticator was decipherable, 4348the ctime and cusec fields will contain the values from it. 4349 43505.6. KRB_SAFE message specification 4351 4352 This section specifies the format of a message that can 4353be used by either side (client or server) of an application 4354to send a tamper-proof message to its peer. It presumes 4355that a session key has previously been exchanged (for exam- 4356ple, by using the KRB_AP_REQ/KRB_AP_REP messages). 4357 43585.6.1. KRB_SAFE definition 4359 4360 The KRB_SAFE message contains user data along with a 4361collision-proof checksum keyed with the last encryption key 4362negotiated via subkeys, or the session key if no negotiation 4363has occured. The message fields are: 4364 4365KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4366 pvno[0] INTEGER, 4367 msg-type[1] INTEGER, 4368 safe-body[2] KRB-SAFE-BODY, 4369 cksum[3] Checksum 4370} 4371 4372KRB-SAFE-BODY ::= SEQUENCE { 4373 user-data[0] OCTET STRING, 4374 timestamp[1] KerberosTime OPTIONAL, 4375 usec[2] INTEGER OPTIONAL, 4376 seq-number[3] INTEGER OPTIONAL, 4377 s-address[4] HostAddress OPTIONAL, 4378 r-address[5] HostAddress OPTIONAL 4379} 4380 4381 4382 4383 4384pvno and msg-type 4385 These fields are described above in section 5.4.1. 4386 msg-type is KRB_SAFE. 4387 4388 4389safe-body This field is a placeholder for the body of the 4390 KRB-SAFE message. It is to be encoded separately 4391 and then have the checksum computed over it, for 4392 use in the cksum field. 4393 4394 4395 4396Section 5.6.1. - 67 - Expires 11 January 1998 4397 4398 4399 4400 4401 4402 4403 4404 Version 5 - Specification Revision 6 4405 4406 4407cksum This field contains the checksum of the applica- 4408 tion data. Checksum details are described in sec- 4409 tion 6.4. The checksum is computed over the 4410 encoding of the KRB-SAFE-BODY sequence. 4411 4412 4413user-data This field is part of the KRB_SAFE and KRB_PRIV 4414 messages and contain the application specific data 4415 that is being passed from the sender to the reci- 4416 pient. 4417 4418 4419timestamp This field is part of the KRB_SAFE and KRB_PRIV 4420 messages. Its contents are the current time as 4421 known by the sender of the message. By checking 4422 the timestamp, the recipient of the message is 4423 able to make sure that it was recently generated, 4424 and is not a replay. 4425 4426 4427usec This field is part of the KRB_SAFE and KRB_PRIV 4428 headers. It contains the microsecond part of the 4429 timestamp. 4430 4431 4432seq-number 4433 This field is described above in section 5.3.2. 4434 4435 4436s-address This field specifies the address in use by the 4437 sender of the message. 4438 4439 4440r-address This field specifies the address in use by the 4441 recipient of the message. It may be omitted for 4442 some uses (such as broadcast protocols), but the 4443 recipient may arbitrarily reject such messages. 4444 This field along with s-address can be used to 4445 help detect messages which have been incorrectly 4446 or maliciously delivered to the wrong recipient. 4447 44485.7. KRB_PRIV message specification 4449 4450 This section specifies the format of a message that can 4451be used by either side (client or server) of an application 4452to securely and privately send a message to its peer. It 4453presumes that a session key has previously been exchanged 4454(for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 4455 44565.7.1. KRB_PRIV definition 4457 4458 The KRB_PRIV message contains user data encrypted in 4459the Session Key. The message fields are: 4460 4461__________________________ 4462[31] An application code in the encrypted part of a 4463 4464 4465 4466 4467 4468 4469 Version 5 - Specification Revision 6 4470 4471 4472 4473KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4474 pvno[0] INTEGER, 4475 msg-type[1] INTEGER, 4476 enc-part[3] EncryptedData 4477} 4478 4479EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { 4480 user-data[0] OCTET STRING, 4481 timestamp[1] KerberosTime OPTIONAL, 4482 usec[2] INTEGER OPTIONAL, 4483 seq-number[3] INTEGER OPTIONAL, 4484 s-address[4] HostAddress OPTIONAL, -- sender's addr 4485 r-address[5] HostAddress OPTIONAL -- recip's addr 4486} 4487 4488 4489 4490pvno and msg-type 4491 These fields are described above in section 5.4.1. 4492 msg-type is KRB_PRIV. 4493 4494 4495enc-part This field holds an encoding of the EncKrbPrivPart 4496 sequence encrypted under the session key[32]. 4497 This encrypted encoding is used for the enc-part 4498 field of the KRB-PRIV message. See section 6 for 4499 the format of the ciphertext. 4500 4501 4502user-data, timestamp, usec, s-address and r-address 4503 These fields are described above in section 5.6.1. 4504 4505 4506seq-number 4507 This field is described above in section 5.3.2. 4508 45095.8. KRB_CRED message specification 4510 4511 This section specifies the format of a message that can 4512be used to send Kerberos credentials from one principal to 4513__________________________ 4514message provides an additional check that the message 4515was decrypted properly. 4516[32] If supported by the encryption method in use, an 4517initialization vector may be passed to the encryption 4518procedure, in order to achieve proper cipher chaining. 4519The initialization vector might come from the last 4520block of the ciphertext from the previous KRB_PRIV mes- 4521sage, but it is the application's choice whether or not 4522to use such an initialization vector. If left out, the 4523default initialization vector for the encryption algo- 4524rithm will be used. 4525 4526 4527Section 5.8. - 69 - Expires 11 January 1998 4528 4529 4530 4531 4532 4533 4534 4535 Version 5 - Specification Revision 6 4536 4537 4538another. It is presented here to encourage a common mechan- 4539ism to be used by applications when forwarding tickets or 4540providing proxies to subordinate servers. It presumes that 4541a session key has already been exchanged perhaps by using 4542the KRB_AP_REQ/KRB_AP_REP messages. 4543 45445.8.1. KRB_CRED definition 4545 4546 The KRB_CRED message contains a sequence of tickets to 4547be sent and information needed to use the tickets, including 4548the session key from each. The information needed to use 4549the tickets is encrypted under an encryption key previously 4550exchanged or transferred alongside the KRB_CRED message. 4551The message fields are: 4552 4553KRB-CRED ::= [APPLICATION 22] SEQUENCE { 4554 pvno[0] INTEGER, 4555 msg-type[1] INTEGER, -- KRB_CRED 4556 tickets[2] SEQUENCE OF Ticket, 4557 enc-part[3] EncryptedData 4558} 4559 4560EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4561 ticket-info[0] SEQUENCE OF KrbCredInfo, 4562 nonce[1] INTEGER OPTIONAL, 4563 timestamp[2] KerberosTime OPTIONAL, 4564 usec[3] INTEGER OPTIONAL, 4565 s-address[4] HostAddress OPTIONAL, 4566 r-address[5] HostAddress OPTIONAL 4567} 4568 4569KrbCredInfo ::= SEQUENCE { 4570 key[0] EncryptionKey, 4571 prealm[1] Realm OPTIONAL, 4572 pname[2] PrincipalName OPTIONAL, 4573 flags[3] TicketFlags OPTIONAL, 4574 authtime[4] KerberosTime OPTIONAL, 4575 starttime[5] KerberosTime OPTIONAL, 4576 endtime[6] KerberosTime OPTIONAL 4577 renew-till[7] KerberosTime OPTIONAL, 4578 srealm[8] Realm OPTIONAL, 4579 sname[9] PrincipalName OPTIONAL, 4580 caddr[10] HostAddresses OPTIONAL 4581} 4582 4583 4584 4585 4586 4587pvno and msg-type 4588 These fields are described above in section 5.4.1. 4589 msg-type is KRB_CRED. 4590 4591 4592 4593 4594Section 5.8.1. - 70 - Expires 11 January 1998 4595 4596 4597 4598 4599 4600 4601 4602 Version 5 - Specification Revision 6 4603 4604 4605tickets 4606 These are the tickets obtained from the KDC 4607 specifically for use by the intended recipient. 4608 Successive tickets are paired with the correspond- 4609 ing KrbCredInfo sequence from the enc-part of the 4610 KRB-CRED message. 4611 4612 4613enc-part This field holds an encoding of the EncKrbCredPart 4614 sequence encrypted under the session key shared 4615 between the sender and the intended recipient. 4616 This encrypted encoding is used for the enc-part 4617 field of the KRB-CRED message. See section 6 for 4618 the format of the ciphertext. 4619 4620 4621nonce If practical, an application may require the 4622 inclusion of a nonce generated by the recipient of 4623 the message. If the same value is included as the 4624 nonce in the message, it provides evidence that 4625 the message is fresh and has not been replayed by 4626 an attacker. A nonce must never be re-used; it 4627 should be generated randomly by the recipient of 4628 the message and provided to the sender of the mes- 4629 sage in an application specific manner. 4630 4631 4632timestamp and usec 4633 4634 These fields specify the time that the KRB-CRED 4635 message was generated. The time is used to pro- 4636 vide assurance that the message is fresh. 4637 4638 4639s-address and r-address 4640 These fields are described above in section 5.6.1. 4641 They are used optionally to provide additional 4642 assurance of the integrity of the KRB-CRED mes- 4643 sage. 4644 4645 4646key This field exists in the corresponding ticket 4647 passed by the KRB-CRED message and is used to pass 4648 the session key from the sender to the intended 4649 recipient. The field's encoding is described in 4650 section 6.2. 4651 4652 The following fields are optional. If present, they 4653can be associated with the credentials in the remote ticket 4654file. If left out, then it is assumed that the recipient of 4655the credentials already knows their value. 4656 4657 4658prealm and pname 4659 4660 4661Section 5.8.1. - 71 - Expires 11 January 1998 4662 4663 4664 4665 4666 4667 4668 4669 Version 5 - Specification Revision 6 4670 4671 4672 The name and realm of the delegated principal 4673 identity. 4674 4675 4676flags, authtime, starttime, endtime, renew-till, srealm, 4677 sname, and caddr 4678 These fields contain the values of the correspond- 4679 ing fields from the ticket found in the ticket 4680 field. Descriptions of the fields are identical 4681 to the descriptions in the KDC-REP message. 4682 46835.9. Error message specification 4684 4685 This section specifies the format for the KRB_ERROR 4686message. The fields included in the message are intended to 4687return as much information as possible about an error. It 4688is not expected that all the information required by the 4689fields will be available for all types of errors. If the 4690appropriate information is not available when the message is 4691composed, the corresponding field will be left out of the 4692message. 4693 4694 Note that since the KRB_ERROR message is not protected 4695by any encryption, it is quite possible for an intruder to 4696synthesize or modify such a message. In particular, this 4697means that the client should not use any fields in this mes- 4698sage for security-critical purposes, such as setting a sys- 4699tem clock or generating a fresh authenticator. The message 4700can be useful, however, for advising a user on the reason 4701for some failure. 4702 47035.9.1. KRB_ERROR definition 4704 4705 The KRB_ERROR message consists of the following fields: 4706 4707KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 4708 pvno[0] INTEGER, 4709 msg-type[1] INTEGER, 4710 ctime[2] KerberosTime OPTIONAL, 4711 cusec[3] INTEGER OPTIONAL, 4712 stime[4] KerberosTime, 4713 susec[5] INTEGER, 4714 error-code[6] INTEGER, 4715 crealm[7] Realm OPTIONAL, 4716 cname[8] PrincipalName OPTIONAL, 4717 realm[9] Realm, -- Correct realm 4718 sname[10] PrincipalName, -- Correct name 4719 e-text[11] GeneralString OPTIONAL, 4720 e-data[12] OCTET STRING OPTIONAL, 4721 e-cksum[13] Checksum OPTIONAL 4722} 4723 4724 4725 4726 4727 4728Section 5.9.1. - 72 - Expires 11 January 1998 4729 4730 4731 4732 4733 4734 4735 4736 Version 5 - Specification Revision 6 4737 4738 4739pvno and msg-type 4740 These fields are described above in section 5.4.1. 4741 msg-type is KRB_ERROR. 4742 4743 4744ctime This field is described above in section 5.4.1. 4745 4746 4747 4748cusec This field is described above in section 5.5.2. 4749 4750 4751stime This field contains the current time on the 4752 server. It is of type KerberosTime. 4753 4754 4755susec This field contains the microsecond part of the 4756 server's timestamp. Its value ranges from 0 to 4757 999999. It appears along with stime. The two 4758 fields are used in conjunction to specify a rea- 4759 sonably accurate timestamp. 4760 4761 4762error-codeThis field contains the error code returned by 4763 Kerberos or the server when a request fails. To 4764 interpret the value of this field see the list of 4765 error codes in section 8. Implementations are 4766 encouraged to provide for national language sup- 4767 port in the display of error messages. 4768 4769 4770crealm, cname, srealm and sname 4771 These fields are described above in section 5.3.1. 4772 4773 4774e-text This field contains additional text to help 4775 explain the error code associated with the failed 4776 request (for example, it might include a principal 4777 name which was unknown). 4778 4779 4780e-data This field contains additional data about the 4781 error for use by the application to help it 4782 recover from or handle the error. If the error- 4783 code is KDC_ERR_PREAUTH_REQUIRED, then the e-data 4784 field will contain an encoding of a sequence of 4785 padata fields, each corresponding to an acceptable 4786 pre-authentication method and optionally contain- 4787 ing data for the method: 4788 4789 4790e-cksum This field contains an optional checksum for the 4791 KRB-ERROR message. The checksum is calculated 4792 over the Kerberos ASN.1 encoding of the KRB-ERROR 4793 4794 4795Section 5.9.1. - 73 - Expires 11 January 1998 4796 4797 4798 4799 4800 4801 4802 4803 Version 5 - Specification Revision 6 4804 4805 4806 message with the checksum absent. The checksum is 4807 then added to the KRB-ERROR structure and the mes- 4808 sage is re-encoded. The Checksum should be calcu- 4809 lated using the session key from the ticket grant- 4810 ing ticket or service ticket, where available. If 4811 the error is in response to a TGS or AP request, 4812 the checksum should be calculated uing the the 4813 session key from the client's ticket. If the 4814 error is in response to an AS request, then the 4815 checksum should be calulated using the client's 4816 secret key ONLY if there has been suitable preau- 4817 thentication to prove knowledge of the secret key 4818 by the client[33]. If a checksum can not be com- 4819 puted because the key to be used is not available, 4820 no checksum will be included. 4821 4822 METHOD-DATA ::= SEQUENCE of PA-DATA 4823 4824 4825 If the error-code is KRB_AP_ERR_METHOD, then the 4826 e-data field will contain an encoding of the fol- 4827 lowing sequence: 4828 4829 METHOD-DATA ::= SEQUENCE { 4830 method-type[0] INTEGER, 4831 method-data[1] OCTET STRING OPTIONAL 4832 } 4833 4834 method-type will indicate the required alternate 4835 method; method-data will contain any required 4836 additional information. 4837 4838 4839 48406. Encryption and Checksum Specifications 4841 4842The Kerberos protocols described in this document are 4843designed to use stream encryption ciphers, which can be 4844simulated using commonly available block encryption ciphers, 4845such as the Data Encryption Standard, [12] in conjunction 4846with block chaining and checksum methods [13]. Encryption 4847is used to prove the identities of the network entities par- 4848ticipating in message exchanges. The Key Distribution 4849Center for each realm is trusted by all principals 4850registered in that realm to store a secret key in confi- 4851dence. Proof of knowledge of this secret key is used to 4852verify the authenticity of a principal. 4853 4854 The KDC uses the principal's secret key (in the AS 4855__________________________ 4856[33] This prevents an attacker who generates an in- 4857correct AS request from obtaining verifiable plaintext 4858for use in an off-line password guessing attack. 4859 4860 4861Section 6. - 74 - Expires 11 January 1998 4862 4863 4864 4865 4866 4867 4868 4869 Version 5 - Specification Revision 6 4870 4871 4872exchange) or a shared session key (in the TGS exchange) to 4873encrypt responses to ticket requests; the ability to obtain 4874the secret key or session key implies the knowledge of the 4875appropriate keys and the identity of the KDC. The ability 4876of a principal to decrypt the KDC response and present a 4877Ticket and a properly formed Authenticator (generated with 4878the session key from the KDC response) to a service verifies 4879the identity of the principal; likewise the ability of the 4880service to extract the session key from the Ticket and prove 4881its knowledge thereof in a response verifies the identity of 4882the service. 4883 4884 The Kerberos protocols generally assume that the 4885encryption used is secure from cryptanalysis; however, in 4886some cases, the order of fields in the encrypted portions of 4887messages are arranged to minimize the effects of poorly 4888chosen keys. It is still important to choose good keys. If 4889keys are derived from user-typed passwords, those passwords 4890need to be well chosen to make brute force attacks more dif- 4891ficult. Poorly chosen keys still make easy targets for 4892intruders. 4893 4894 The following sections specify the encryption and 4895checksum mechanisms currently defined for Kerberos. The 4896encodings, chaining, and padding requirements for each are 4897described. For encryption methods, it is often desirable to 4898place random information (often referred to as a confounder) 4899at the start of the message. The requirements for a con- 4900founder are specified with each encryption mechanism. 4901 4902 Some encryption systems use a block-chaining method to 4903improve the the security characteristics of the ciphertext. 4904However, these chaining methods often don't provide an 4905integrity check upon decryption. Such systems (such as DES 4906in CBC mode) must be augmented with a checksum of the plain- 4907text which can be verified at decryption and used to detect 4908any tampering or damage. Such checksums should be good at 4909detecting burst errors in the input. If any damage is 4910detected, the decryption routine is expected to return an 4911error indicating the failure of an integrity check. Each 4912encryption type is expected to provide and verify an 4913appropriate checksum. The specification of each encryption 4914method sets out its checksum requirements. 4915 4916 Finally, where a key is to be derived from a user's 4917password, an algorithm for converting the password to a key 4918of the appropriate type is included. It is desirable for 4919the string to key function to be one-way, and for the map- 4920ping to be different in different realms. This is important 4921because users who are registered in more than one realm will 4922often use the same password in each, and it is desirable 4923that an attacker compromising the Kerberos server in one 4924realm not obtain or derive the user's key in another. 4925 4926 4927 4928Section 6. - 75 - Expires 11 January 1998 4929 4930 4931 4932 4933 4934 4935 4936 Version 5 - Specification Revision 6 4937 4938 4939 For an discussion of the integrity characteristics of 4940the candidate encryption and checksum methods considered for 4941Kerberos, the the reader is referred to [14]. 4942 49436.1. Encryption Specifications 4944 4945 The following ASN.1 definition describes all encrypted 4946messages. The enc-part field which appears in the unen- 4947crypted part of messages in section 5 is a sequence consist- 4948ing of an encryption type, an optional key version number, 4949and the ciphertext. 4950 4951 4952EncryptedData ::= SEQUENCE { 4953 etype[0] INTEGER, -- EncryptionType 4954 kvno[1] INTEGER OPTIONAL, 4955 cipher[2] OCTET STRING -- ciphertext 4956} 4957 4958 4959etype This field identifies which encryption algorithm 4960 was used to encipher the cipher. Detailed specif- 4961 ications for selected encryption types appear 4962 later in this section. 4963 4964 4965kvno This field contains the version number of the key 4966 under which data is encrypted. It is only present 4967 in messages encrypted under long lasting keys, 4968 such as principals' secret keys. 4969 4970 4971cipher This field contains the enciphered text, encoded 4972 as an OCTET STRING. 4973 4974 4975 The cipher field is generated by applying the specified 4976encryption algorithm to data composed of the message and 4977algorithm-specific inputs. Encryption mechanisms defined 4978for use with Kerberos must take sufficient measures to 4979guarantee the integrity of the plaintext, and we recommend 4980they also take measures to protect against precomputed dic- 4981tionary attacks. If the encryption algorithm is not itself 4982capable of doing so, the protections can often be enhanced 4983by adding a checksum and a confounder. 4984 4985 The suggested format for the data to be encrypted 4986includes a confounder, a checksum, the encoded plaintext, 4987and any necessary padding. The msg-seq field contains the 4988part of the protocol message described in section 5 which is 4989to be encrypted. The confounder, checksum, and padding are 4990all untagged and untyped, and their length is exactly suffi- 4991cient to hold the appropriate item. The type and length is 4992implicit and specified by the particular encryption type 4993 4994 4995Section 6.1. - 76 - Expires 11 January 1998 4996 4997 4998 4999 5000 5001 5002 5003 Version 5 - Specification Revision 6 5004 5005 5006being used (etype). The format for the data to be encrypted 5007is described in the following diagram: 5008 5009 +-----------+----------+-------------+-----+ 5010 |confounder | check | msg-seq | pad | 5011 +-----------+----------+-------------+-----+ 5012 5013The format cannot be described in ASN.1, but for those who 5014prefer an ASN.1-like notation: 5015 5016CipherText ::= ENCRYPTED SEQUENCE { 5017 confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, 5018 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 5019 msg-seq[2] MsgSequence, 5020 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 5021} 5022 5023 5024 One generates a random confounder of the appropriate 5025length, placing it in confounder; zeroes out check; calcu- 5026lates the appropriate checksum over confounder, check, and 5027msg-seq, placing the result in check; adds the necessary 5028padding; then encrypts using the specified encryption type 5029and the appropriate key. 5030 5031 Unless otherwise specified, a definition of an encryp- 5032tion algorithm that specifies a checksum, a length for the 5033confounder field, or an octet boundary for padding uses this 5034ciphertext format[36]. Those fields which are not specified 5035will be omitted. 5036 5037 In the interest of allowing all implementations using a 5038__________________________ 5039[35] In the above specification, UNTAGGED OCTET 5040STRING(length) is the notation for an octet string with 5041its tag and length removed. It is not a valid ASN.1 5042type. The tag bits and length must be removed from the 5043confounder since the purpose of the confounder is so 5044that the message starts with random data, but the tag 5045and its length are fixed. For other fields, the length 5046and tag would be redundant if they were included be- 5047cause they are specified by the encryption type. 5048[36] The ordering of the fields in the CipherText is 5049important. Additionally, messages encoded in this for- 5050mat must include a length as part of the msg-seq field. 5051This allows the recipient to verify that the message 5052has not been truncated. Without a length, an attacker 5053could use a chosen plaintext attack to generate a mes- 5054sage which could be truncated, while leaving the check- 5055sum intact. Note that if the msg-seq is an encoding of 5056an ASN.1 SEQUENCE or OCTET STRING, then the length is 5057part of that encoding. 5058 5059 5060 5061Section 6.1. - 77 - Expires 11 January 1998 5062 5063 5064 5065 5066 5067 5068 5069 Version 5 - Specification Revision 6 5070 5071 5072particular encryption type to communicate with all others 5073using that type, the specification of an encryption type 5074defines any checksum that is needed as part of the encryp- 5075tion process. If an alternative checksum is to be used, a 5076new encryption type must be defined. 5077 5078 Some cryptosystems require additional information 5079beyond the key and the data to be encrypted. For example, 5080DES, when used in cipher-block-chaining mode, requires an 5081initialization vector. If required, the description for 5082each encryption type must specify the source of such addi- 5083tional information. 5084 50856.2. Encryption Keys 5086 5087 The sequence below shows the encoding of an encryption 5088key: 5089 5090 EncryptionKey ::= SEQUENCE { 5091 keytype[0] INTEGER, 5092 keyvalue[1] OCTET STRING 5093 } 5094 5095 5096keytype This field specifies the type of encryption key 5097 that follows in the keyvalue field. It will 5098 almost always correspond to the encryption algo- 5099 rithm used to generate the EncryptedData, though 5100 more than one algorithm may use the same type of 5101 key (the mapping is many to one). This might hap- 5102 pen, for example, if the encryption algorithm uses 5103 an alternate checksum algorithm for an integrity 5104 check, or a different chaining mechanism. 5105 5106 5107keyvalue This field contains the key itself, encoded as an 5108 octet string. 5109 5110 All negative values for the encryption key type are 5111reserved for local use. All non-negative values are 5112reserved for officially assigned type fields and interpreta- 5113tions. 5114 51156.3. Encryption Systems 5116 51176.3.1. The NULL Encryption System (null) 5118 5119 If no encryption is in use, the encryption system is 5120said to be the NULL encryption system. In the NULL encryp- 5121tion system there is no checksum, confounder or padding. 5122The ciphertext is simply the plaintext. The NULL Key is 5123used by the null encryption system and is zero octets in 5124length, with keytype zero (0). 5125 5126 5127 5128Section 6.3.1. - 78 - Expires 11 January 1998 5129 5130 5131 5132 5133 5134 5135 5136 Version 5 - Specification Revision 6 5137 5138 51396.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) 5140 5141 The des-cbc-crc encryption mode encrypts information 5142under the Data Encryption Standard [12] using the cipher 5143block chaining mode [13]. A CRC-32 checksum (described in 5144ISO 3309 [15]) is applied to the confounder and message 5145sequence (msg-seq) and placed in the cksum field. DES 5146blocks are 8 bytes. As a result, the data to be encrypted 5147(the concatenation of confounder, checksum, and message) 5148must be padded to an 8 byte boundary before encryption. The 5149details of the encryption of this data are identical to 5150those for the des-cbc-md5 encryption mode. 5151 5152 Note that, since the CRC-32 checksum is not collision- 5153proof, an attacker could use a probabilistic chosen- 5154plaintext attack to generate a valid message even if a con- 5155founder is used [14]. The use of collision-proof checksums 5156is recommended for environments where such attacks represent 5157a significant threat. The use of the CRC-32 as the checksum 5158for ticket or authenticator is no longer mandated as an 5159interoperability requirement for Kerberos Version 5 Specifi- 5160cation 1 (See section 9.1 for specific details). 5161 5162 51636.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) 5164 5165 The des-cbc-md4 encryption mode encrypts information 5166under the Data Encryption Standard [12] using the cipher 5167block chaining mode [13]. An MD4 checksum (described in 5168[16]) is applied to the confounder and message sequence 5169(msg-seq) and placed in the cksum field. DES blocks are 8 5170bytes. As a result, the data to be encrypted (the concate- 5171nation of confounder, checksum, and message) must be padded 5172to an 8 byte boundary before encryption. The details of the 5173encryption of this data are identical to those for the des- 5174cbc-md5 encryption mode. 5175 5176 51776.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) 5178 5179 The des-cbc-md5 encryption mode encrypts information 5180under the Data Encryption Standard [12] using the cipher 5181block chaining mode [13]. An MD5 checksum (described in 5182[17].) is applied to the confounder and message sequence 5183(msg-seq) and placed in the cksum field. DES blocks are 8 5184bytes. As a result, the data to be encrypted (the concate- 5185nation of confounder, checksum, and message) must be padded 5186to an 8 byte boundary before encryption. 5187 5188 Plaintext and DES ciphtertext are encoded as 8-octet 5189blocks which are concatenated to make the 64-bit inputs for 5190the DES algorithms. The first octet supplies the 8 most 5191significant bits (with the octet's MSbit used as the DES 5192input block's MSbit, etc.), the second octet the next 8 5193 5194 5195Section 6.3.4. - 79 - Expires 11 January 1998 5196 5197 5198 5199 5200 5201 5202 5203 Version 5 - Specification Revision 6 5204 5205 5206bits, ..., and the eighth octet supplies the 8 least signi- 5207ficant bits. 5208 5209 Encryption under DES using cipher block chaining 5210requires an additional input in the form of an initializa- 5211tion vector. Unless otherwise specified, zero should be 5212used as the initialization vector. Kerberos' use of DES 5213requires an 8-octet confounder. 5214 5215 The DES specifications identify some "weak" and "semi- 5216weak" keys; those keys shall not be used for encrypting mes- 5217sages for use in Kerberos. Additionally, because of the way 5218that keys are derived for the encryption of checksums, keys 5219shall not be used that yield "weak" or "semi-weak" keys when 5220eXclusive-ORed with the constant F0F0F0F0F0F0F0F0. 5221 5222 A DES key is 8 octets of data, with keytype one (1). 5223This consists of 56 bits of key, and 8 parity bits (one per 5224octet). The key is encoded as a series of 8 octets written 5225in MSB-first order. The bits within the key are also 5226encoded in MSB order. For example, if the encryption key is 5227(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 5228where B1,B2,...,B56 are the key bits in MSB order, and 5229P1,P2,...,P8 are the parity bits, the first octet of the key 5230would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the 5231FIPS 81 introduction for reference.] 5232 5233 To generate a DES key from a text string (password), 5234the text string normally must have the realm and each com- 5235ponent of the principal's name appended[37], then padded 5236with ASCII nulls to an 8 byte boundary. This string is then 5237fan-folded and eXclusive-ORed with itself to form an 8 byte 5238DES key. The parity is corrected on the key, and it is used 5239to generate a DES CBC checksum on the initial string (with 5240the realm and name appended). Next, parity is corrected on 5241the CBC checksum. If the result matches a "weak" or "semi- 5242weak" key as described in the DES specification, it is 5243eXclusive-ORed with the constant 00000000000000F0. Finally, 5244the result is returned as the key. Pseudocode follows: 5245 5246 string_to_key(string,realm,name) { 5247 odd = 1; 5248 s = string + realm; 5249 for(each component in name) { 5250 s = s + component; 5251 } 5252 tempkey = NULL; 5253 pad(s); /* with nulls to 8 byte boundary */ 5254 for(8byteblock in s) { 5255__________________________ 5256[37] In some cases, it may be necessary to use a dif- 5257ferent "mix-in" string for compatibility reasons; see 5258the discussion of padata in section 5.4.2. 5259 5260 5261Section 6.3.4. - 80 - Expires 11 January 1998 5262 5263 5264 5265 5266 5267 5268 5269 Version 5 - Specification Revision 6 5270 5271 5272 if(odd == 0) { 5273 odd = 1; 5274 reverse(8byteblock) 5275 } 5276 else odd = 0; 5277 tempkey = tempkey XOR 8byteblock; 5278 } 5279 fixparity(tempkey); 5280 key = DES-CBC-check(s,tempkey); 5281 fixparity(key); 5282 if(is_weak_key_key(key)) 5283 key = key XOR 0xF0; 5284 return(key); 5285 } 5286 52876.3.5. Triple DES EDE in outer CBC mode with an SHA1 check- 5288sum (des3-cbc-sha1) 5289 5290 The des3-cbc-sha1 encryption encodes information using 5291three Data Encryption Standard transformations with three 5292DES keys. The first key is used to perform a DES ECB 5293encryption on an eight-octet data block using the first DES 5294key, followed by a DES ECB decryption of the result using 5295the second DES key, and a DES ECB encryption of the result 5296using the third DES key. Because DES blocks are 8 bytes, 5297the data to be encrypted (the concatenation of confounder, 5298checksum, and message) must first be padded to an 8 byte 5299boundary before encryption. To support the outer CBC mode, 5300the input is padded an eight-octet boundary. The first 8 5301octets of the data to be encrypted (the confounder) is 5302exclusive-ored with an initialization vector of zero and 5303then ECB encrypted using triple DES as described above. 5304Subsequent blocks of 8 octets are exclusive-ored with the 5305ciphertext produced by the encryption on the previous block 5306before ECB encryption. 5307 5308 An HMAC-SHA1 checksum (described in [18].) is applied 5309to the confounder and message sequence (msg-seq) and placed 5310in the cksum field. 5311 5312 Plaintext are encoded as 8-octet blocks which are con- 5313catenated to make the 64-bit inputs for the DES algorithms. 5314The first octet supplies the 8 most significant bits (with 5315the octet's MSbit used as the DES input block's MSbit, 5316etc.), the second octet the next 8 bits, ..., and the eighth 5317octet supplies the 8 least significant bits. 5318 5319 Encryption under Triple DES using cipher block chaining 5320requires an additional input in the form of an initializa- 5321tion vector. Unless otherwise specified, zero should be 5322used as the initialization vector. Kerberos' use of DES 5323requires an 8-octet confounder. 5324 5325 The DES specifications identify some "weak" and "semi- 5326 5327 5328Section 6.3.5. - 81 - Expires 11 January 1998 5329 5330 5331 5332 5333 5334 5335 5336 Version 5 - Specification Revision 6 5337 5338 5339weak" keys; those keys shall not be used for encrypting mes- 5340sages for use in Kerberos. Additionally, because of the way 5341that keys are derived for the encryption of checksums, keys 5342shall not be used that yield "weak" or "semi-weak" keys when 5343eXclusive-ORed with the constant F0F0F0F0F0F0F0F0. 5344 5345 A Triple DES key is 24 octets of data, with keytype 5346seven (7). This consists of 168 bits of key, and 24 parity 5347bits (one per octet). The key is encoded as a series of 24 5348octets written in MSB-first order, with the first 8 octets 5349treated as the first DES key, the second 8 octets as the 5350second key, and the third 8 octets the third DES key. The 5351bits within each key are also encoded in MSB order. For 5352example, if the encryption key is 5353(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 5354where B1,B2,...,B56 are the key bits in MSB order, and 5355P1,P2,...,P8 are the parity bits, the first octet of the key 5356would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the 5357FIPS 81 introduction for reference.] 5358 5359 To generate a DES key from a text string (password), 5360the text string normally must have the realm and each com- 5361ponent of the principal's name appended[38], 5362 5363 The input string (with any salt data appended to it) is 5364n-folded into a 24 octet (192 bit) string. To n-fold a 5365number X, replicate the input value to a length that is the 5366least common multiple of n and the length of X. Before each 5367repetition, the input X is rotated to the right by 13 bit 5368positions. The successive n-bit chunks are added together 5369using 1's-complement addition (addition with end-around 5370carry) to yield a n-bit result. (This transformation was 5371proposed by Richard Basch) 5372 5373 Each successive set of 8 octets is taken as a DES key, 5374and its parity is adjusted in the same manner as previously 5375described. If any of the three sets of 8 octets match a 5376"weak" or "semi-weak" key as described in the DES specifica- 5377tion, that chunk is eXclusive-ORed with the constant 537800000000000000F0. The resulting DES keys are then used in 5379sequence to perform a Triple-DES CBC encryption of the n- 5380folded input string (appended with any salt data), using a 5381zero initial vector. Parity, weak, and semi-weak keys are 5382once again corrected and the result is returned as the 24 5383octet key. 5384 5385 Pseudocode follows: 5386 5387 string_to_key(string,realm,name) { 5388__________________________ 5389[38] In some cases, it may be necessary to use a dif- 5390ferent "mix-in" string for compatibility reasons; see 5391the discussion of padata in section 5.4.2. 5392 5393 5394Section 6.3.5. - 82 - Expires 11 January 1998 5395 5396 5397 5398 5399 5400 5401 5402 Version 5 - Specification Revision 6 5403 5404 5405 s = string + realm; 5406 for(each component in name) { 5407 s = s + component; 5408 } 5409 tkey[24] = fold(s); 5410 fixparity(tkey); 5411 if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0; 5412 if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0; 5413 if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0; 5414 key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0); 5415 fixparity(key); 5416 if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0; 5417 if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0; 5418 if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0; 5419 return(key); 5420 } 5421 54226.4. Checksums 5423 5424 The following is the ASN.1 definition used for a check- 5425sum: 5426 5427 Checksum ::= SEQUENCE { 5428 cksumtype[0] INTEGER, 5429 checksum[1] OCTET STRING 5430 } 5431 5432 5433cksumtype This field indicates the algorithm used to gen- 5434 erate the accompanying checksum. 5435 5436checksum This field contains the checksum itself, encoded 5437 as an octet string. 5438 5439 Detailed specification of selected checksum types 5440appear later in this section. Negative values for the 5441checksum type are reserved for local use. All non-negative 5442values are reserved for officially assigned type fields and 5443interpretations. 5444 5445 Checksums used by Kerberos can be classified by two 5446properties: whether they are collision-proof, and whether 5447they are keyed. It is infeasible to find two plaintexts 5448which generate the same checksum value for a collision-proof 5449checksum. A key is required to perturb or initialize the 5450algorithm in a keyed checksum. To prevent message-stream 5451modification by an active attacker, unkeyed checksums should 5452only be used when the checksum and message will be subse- 5453quently encrypted (e.g. the checksums defined as part of the 5454encryption algorithms covered earlier in this section). 5455 5456 Collision-proof checksums can be made tamper-proof if 5457the checksum value is encrypted before inclusion in a mes- 5458sage. In such cases, the composition of the checksum and 5459 5460 5461Section 6.4. - 83 - Expires 11 January 1998 5462 5463 5464 5465 5466 5467 5468 5469 Version 5 - Specification Revision 6 5470 5471 5472the encryption algorithm must be considered a separate 5473checksum algorithm (e.g. RSA-MD5 encrypted using DES is a 5474new checksum algorithm of type RSA-MD5-DES). For most keyed 5475checksums, as well as for the encrypted forms of unkeyed 5476collision-proof checksums, Kerberos prepends a confounder 5477before the checksum is calculated. 5478 54796.4.1. The CRC-32 Checksum (crc32) 5480 5481 The CRC-32 checksum calculates a checksum based on a 5482cyclic redundancy check as described in ISO 3309 [15]. The 5483resulting checksum is four (4) octets in length. The CRC-32 5484is neither keyed nor collision-proof. The use of this 5485checksum is not recommended. An attacker using a proba- 5486bilistic chosen-plaintext attack as described in [14] might 5487be able to generate an alternative message that satisfies 5488the checksum. The use of collision-proof checksums is 5489recommended for environments where such attacks represent a 5490significant threat. 5491 54926.4.2. The RSA MD4 Checksum (rsa-md4) 5493 5494 The RSA-MD4 checksum calculates a checksum using the 5495RSA MD4 algorithm [16]. The algorithm takes as input an 5496input message of arbitrary length and produces as output a 5497128-bit (16 octet) checksum. RSA-MD4 is believed to be 5498collision-proof. 5499 55006.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4- 5501des) 5502 5503 The RSA-MD4-DES checksum calculates a keyed collision- 5504proof checksum by prepending an 8 octet confounder before 5505the text, applying the RSA MD4 checksum algorithm, and 5506encrypting the confounder and the checksum using DES in 5507cipher-block-chaining (CBC) mode using a variant of the key, 5508where the variant is computed by eXclusive-ORing the key 5509with the constant F0F0F0F0F0F0F0F0[39]. The initialization 5510vector should be zero. The resulting checksum is 24 octets 5511long (8 octets of which are redundant). This checksum is 5512tamper-proof and believed to be collision-proof. 5513 5514 The DES specifications identify some "weak keys" and 5515__________________________ 5516[39] A variant of the key is used to limit the use of a 5517key to a particular function, separating the functions 5518of generating a checksum from other encryption per- 5519formed using the session key. The constant 5520F0F0F0F0F0F0F0F0 was chosen because it maintains key 5521parity. The properties of DES precluded the use of the 5522complement. The same constant is used for similar pur- 5523pose in the Message Integrity Check in the Privacy 5524Enhanced Mail standard. 5525 5526 5527Section 6.4.3. - 84 - Expires 11 January 1998 5528 5529 5530 5531 5532 5533 5534 5535 Version 5 - Specification Revision 6 5536 5537 5538"semi-weak keys"; those keys shall not be used for generat- 5539ing RSA-MD4 checksums for use in Kerberos. 5540 5541 The format for the checksum is described in the follow- 5542ing diagram: 5543 5544+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5545| des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 5546+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5547 5548The format cannot be described in ASN.1, but for those who 5549prefer an ASN.1-like notation: 5550 5551rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 5552 confounder[0] UNTAGGED OCTET STRING(8), 5553 check[1] UNTAGGED OCTET STRING(16) 5554} 5555 5556 5557 55586.4.4. The RSA MD5 Checksum (rsa-md5) 5559 5560 The RSA-MD5 checksum calculates a checksum using the 5561RSA MD5 algorithm. [17]. The algorithm takes as input an 5562input message of arbitrary length and produces as output a 5563128-bit (16 octet) checksum. RSA-MD5 is believed to be 5564collision-proof. 5565 55666.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5- 5567des) 5568 5569 The RSA-MD5-DES checksum calculates a keyed collision- 5570proof checksum by prepending an 8 octet confounder before 5571the text, applying the RSA MD5 checksum algorithm, and 5572encrypting the confounder and the checksum using DES in 5573cipher-block-chaining (CBC) mode using a variant of the key, 5574where the variant is computed by eXclusive-ORing the key 5575with the constant F0F0F0F0F0F0F0F0. The initialization vec- 5576tor should be zero. The resulting checksum is 24 octets 5577long (8 octets of which are redundant). This checksum is 5578tamper-proof and believed to be collision-proof. 5579 5580 The DES specifications identify some "weak keys" and 5581"semi-weak keys"; those keys shall not be used for encrypt- 5582ing RSA-MD5 checksums for use in Kerberos. 5583 5584 The format for the checksum is described in the follow- 5585ing diagram: 5586 5587+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5588| des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 5589+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5590 5591The format cannot be described in ASN.1, but for those who 5592 5593 5594Section 6.4.5. - 85 - Expires 11 January 1998 5595 5596 5597 5598 5599 5600 5601 5602 Version 5 - Specification Revision 6 5603 5604 5605prefer an ASN.1-like notation: 5606 5607rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 5608 confounder[0] UNTAGGED OCTET STRING(8), 5609 check[1] UNTAGGED OCTET STRING(16) 5610} 5611 5612 56136.4.6. DES cipher-block chained checksum (des-mac) 5614 5615 The DES-MAC checksum is computed by prepending an 8 5616octet confounder to the plaintext, performing a DES CBC-mode 5617encryption on the result using the key and an initialization 5618vector of zero, taking the last block of the ciphertext, 5619prepending the same confounder and encrypting the pair using 5620DES in cipher-block-chaining (CBC) mode using a a variant of 5621the key, where the variant is computed by eXclusive-ORing 5622the key with the constant F0F0F0F0F0F0F0F0. The initializa- 5623tion vector should be zero. The resulting checksum is 128 5624bits (16 octets) long, 64 bits of which are redundant. This 5625checksum is tamper-proof and collision-proof. 5626 5627 The format for the checksum is described in the follow- 5628ing diagram: 5629 5630+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 5631| des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | 5632+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 5633 5634The format cannot be described in ASN.1, but for those who 5635prefer an ASN.1-like notation: 5636 5637des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 5638 confounder[0] UNTAGGED OCTET STRING(8), 5639 check[1] UNTAGGED OCTET STRING(8) 5640} 5641 5642 5643 The DES specifications identify some "weak" and "semi- 5644weak" keys; those keys shall not be used for generating 5645DES-MAC checksums for use in Kerberos, nor shall a key be 5646used whose variant is "weak" or "semi-weak". 5647 56486.4.7. RSA MD4 Cryptographic Checksum Using DES alternative 5649(rsa-md4-des-k) 5650 5651 The RSA-MD4-DES-K checksum calculates a keyed 5652collision-proof checksum by applying the RSA MD4 checksum 5653algorithm and encrypting the results using DES in cipher- 5654block-chaining (CBC) mode using a DES key as both key and 5655initialization vector. The resulting checksum is 16 octets 5656long. This checksum is tamper-proof and believed to be 5657collision-proof. Note that this checksum type is the old 5658method for encoding the RSA-MD4-DES checksum and it is no 5659 5660 5661Section 6.4.7. - 86 - Expires 11 January 1998 5662 5663 5664 5665 5666 5667 5668 5669 Version 5 - Specification Revision 6 5670 5671 5672longer recommended. 5673 56746.4.8. DES cipher-block chained checksum alternative (des- 5675mac-k) 5676 5677 The DES-MAC-K checksum is computed by performing a DES 5678CBC-mode encryption of the plaintext, and using the last 5679block of the ciphertext as the checksum value. It is keyed 5680with an encryption key and an initialization vector; any 5681uses which do not specify an additional initialization vec- 5682tor will use the key as both key and initialization vector. 5683The resulting checksum is 64 bits (8 octets) long. This 5684checksum is tamper-proof and collision-proof. Note that 5685this checksum type is the old method for encoding the DES- 5686MAC checksum and it is no longer recommended. 5687 5688 The DES specifications identify some "weak keys" and 5689"semi-weak keys"; those keys shall not be used for generat- 5690ing DES-MAC checksums for use in Kerberos. 5691 56927. Naming Constraints 5693 5694 56957.1. Realm Names 5696 5697 Although realm names are encoded as GeneralStrings and 5698although a realm can technically select any name it chooses, 5699interoperability across realm boundaries requires agreement 5700on how realm names are to be assigned, and what information 5701they imply. 5702 5703 To enforce these conventions, each realm must conform 5704to the conventions itself, and it must require that any 5705realms with which inter-realm keys are shared also conform 5706to the conventions and require the same from its neighbors. 5707 5708 Kerberos realm names are case sensitive. Realm names 5709that differ only in the case of the characters are not 5710equivalent. There are presently four styles of realm names: 5711domain, X500, other, and reserved. Examples of each style 5712follow: 5713 5714 domain: ATHENA.MIT.EDU (example) 5715 X500: C=US/O=OSF (example) 5716 other: NAMETYPE:rest/of.name=without-restrictions (example) 5717 reserved: reserved, but will not conflict with above 5718 5719 5720Domain names must look like domain names: they consist of 5721components separated by periods (.) and they contain neither 5722colons (:) nor slashes (/). Domain names must be converted 5723to upper case when used as realm names. 5724 5725 X.500 names contain an equal (=) and cannot contain a 5726 5727 5728Section 7.1. - 87 - Expires 11 January 1998 5729 5730 5731 5732 5733 5734 5735 5736 Version 5 - Specification Revision 6 5737 5738 5739colon (:) before the equal. The realm names for X.500 names 5740will be string representations of the names with components 5741separated by slashes. Leading and trailing slashes will not 5742be included. 5743 5744 Names that fall into the other category must begin with 5745a prefix that contains no equal (=) or period (.) and the 5746prefix must be followed by a colon (:) and the rest of the 5747name. All prefixes must be assigned before they may be 5748used. Presently none are assigned. 5749 5750 The reserved category includes strings which do not 5751fall into the first three categories. All names in this 5752category are reserved. It is unlikely that names will be 5753assigned to this category unless there is a very strong 5754argument for not using the "other" category. 5755 5756 These rules guarantee that there will be no conflicts 5757between the various name styles. The following additional 5758constraints apply to the assignment of realm names in the 5759domain and X.500 categories: the name of a realm for the 5760domain or X.500 formats must either be used by the organiza- 5761tion owning (to whom it was assigned) an Internet domain 5762name or X.500 name, or in the case that no such names are 5763registered, authority to use a realm name may be derived 5764from the authority of the parent realm. For example, if 5765there is no domain name for E40.MIT.EDU, then the adminis- 5766trator of the MIT.EDU realm can authorize the creation of a 5767realm with that name. 5768 5769 This is acceptable because the organization to which 5770the parent is assigned is presumably the organization 5771authorized to assign names to its children in the X.500 and 5772domain name systems as well. If the parent assigns a realm 5773name without also registering it in the domain name or X.500 5774hierarchy, it is the parent's responsibility to make sure 5775that there will not in the future exists a name identical to 5776the realm name of the child unless it is assigned to the 5777same entity as the realm name. 5778 5779 57807.2. Principal Names 5781 5782 As was the case for realm names, conventions are needed 5783to ensure that all agree on what information is implied by a 5784principal name. The name-type field that is part of the 5785principal name indicates the kind of information implied by 5786the name. The name-type should be treated as a hint. 5787Ignoring the name type, no two names can be the same (i.e. 5788at least one of the components, or the realm, must be dif- 5789ferent). This constraint may be eliminated in the future. 5790The following name types are defined: 5791 5792 name-type value meaning 5793 5794 5795Section 7.2. - 88 - Expires 11 January 1998 5796 5797 5798 5799 5800 5801 5802 5803 Version 5 - Specification Revision 6 5804 5805 5806 NT-UNKNOWN 0 Name type not known 5807 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) 5808 NT-SRV-INST 2 Service and other unique instance (krbtgt) 5809 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 5810 NT-SRV-XHST 4 Service with slash-separated host name components 5811 NT-UID 5 Unique ID 5812 5813 5814When a name implies no information other than its uniqueness 5815at a particular time the name type PRINCIPAL should be used. 5816The principal name type should be used for users, and it 5817might also be used for a unique server. If the name is a 5818unique machine generated ID that is guaranteed never to be 5819reassigned then the name type of UID should be used (note 5820that it is generally a bad idea to reassign names of any 5821type since stale entries might remain in access control 5822lists). 5823 5824 If the first component of a name identifies a service 5825and the remaining components identify an instance of the 5826service in a server specified manner, then the name type of 5827SRV-INST should be used. An example of this name type is 5828the Kerberos ticket-granting service whose name has a first 5829component of krbtgt and a second component identifying the 5830realm for which the ticket is valid. 5831 5832 If instance is a single component following the service 5833name and the instance identifies the host on which the 5834server is running, then the name type SRV-HST should be 5835used. This type is typically used for Internet services 5836such as telnet and the Berkeley R commands. If the separate 5837components of the host name appear as successive components 5838following the name of the service, then the name type SRV- 5839XHST should be used. This type might be used to identify 5840servers on hosts with X.500 names where the slash (/) might 5841otherwise be ambiguous. 5842 5843 A name type of UNKNOWN should be used when the form of 5844the name is not known. When comparing names, a name of type 5845UNKNOWN will match principals authenticated with names of 5846any type. A principal authenticated with a name of type 5847UNKNOWN, however, will only match other names of type UNK- 5848NOWN. 5849 5850 Names of any type with an initial component of "krbtgt" 5851are reserved for the Kerberos ticket granting service. See 5852section 8.2.3 for the form of such names. 5853 58547.2.1. Name of server principals 5855 5856 The principal identifier for a server on a host will 5857generally be composed of two parts: (1) the realm of the KDC 5858with which the server is registered, and (2) a two-component 5859 5860 5861Section 7.2.1. - 89 - Expires 11 January 1998 5862 5863 5864 5865 5866 5867 5868 5869 Version 5 - Specification Revision 6 5870 5871 5872name of type NT-SRV-HST if the host name is an Internet 5873domain name or a multi-component name of type NT-SRV-XHST if 5874the name of the host is of a form such as X.500 that allows 5875slash (/) separators. The first component of the two- or 5876multi-component name will identify the service and the 5877latter components will identify the host. Where the name of 5878the host is not case sensitive (for example, with Internet 5879domain names) the name of the host must be lower case. If 5880specified by the application protocol for services such as 5881telnet and the Berkeley R commands which run with system 5882privileges, the first component may be the string "host" 5883instead of a service specific identifier. When a host has 5884an official name and one or more aliases, the official name 5885of the host must be used when constructing the name of the 5886server principal. 5887 58888. Constants and other defined values 5889 5890 58918.1. Host address types 5892 5893 All negative values for the host address type are 5894reserved for local use. All non-negative values are 5895reserved for officially assigned type fields and interpreta- 5896tions. 5897 5898 The values of the types for the following addresses are 5899chosen to match the defined address family constants in the 5900Berkeley Standard Distributions of Unix. They can be found 5901in <sys/socket.h> with symbolic names AF_xxx (where xxx is 5902an abbreviation of the address family name). 5903 5904 5905Internet addresses 5906 5907 Internet addresses are 32-bit (4-octet) quantities, 5908encoded in MSB order. The type of internet addresses is two 5909(2). 5910 5911CHAOSnet addresses 5912 5913 CHAOSnet addresses are 16-bit (2-octet) quantities, 5914encoded in MSB order. The type of CHAOSnet addresses is 5915five (5). 5916 5917ISO addresses 5918 5919 ISO addresses are variable-length. The type of ISO 5920addresses is seven (7). 5921 5922Xerox Network Services (XNS) addresses 5923 5924 XNS addresses are 48-bit (6-octet) quantities, encoded 5925in MSB order. The type of XNS addresses is six (6). 5926 5927 5928Section 8.1. - 90 - Expires 11 January 1998 5929 5930 5931 5932 5933 5934 5935 5936 Version 5 - Specification Revision 6 5937 5938 5939AppleTalk Datagram Delivery Protocol (DDP) addresses 5940 5941 AppleTalk DDP addresses consist of an 8-bit node number 5942and a 16-bit network number. The first octet of the address 5943is the node number; the remaining two octets encode the net- 5944work number in MSB order. The type of AppleTalk DDP 5945addresses is sixteen (16). 5946 5947DECnet Phase IV addresses 5948 5949 DECnet Phase IV addresses are 16-bit addresses, encoded 5950in LSB order. The type of DECnet Phase IV addresses is 5951twelve (12). 5952 59538.2. KDC messages 5954 59558.2.1. IP transport 5956 5957 When contacting a Kerberos server (KDC) for a 5958KRB_KDC_REQ request using UDP IP transport, the client shall 5959send a UDP datagram containing only an encoding of the 5960request to port 88 (decimal) at the KDC's IP address; the 5961KDC will respond with a reply datagram containing only an 5962encoding of the reply message (either a KRB_ERROR or a 5963KRB_KDC_REP) to the sending port at the sender's IP address. 5964 5965 Kerberos servers supporting IP transport must accept 5966UDP requests on port 88 (decimal). Servers may also accept 5967TCP requests on port 88 (decimal). When the KRB_KDC_REQ 5968message is sent to the KDC by TCP, a new connection will be 5969established for each authentication exchange and the 5970KRB_KDC_REP or KRB_ERROR message will be returned to the 5971client on the TCP stream that was established for the 5972request. The connection will be broken after the reply has 5973been received (or upon time-out). Care must be taken in 5974managing TCP/IP connections with the KDC to prevent denial 5975of service attacks based on the number of TCP/IP connections 5976with the KDC that remain open. 5977 59788.2.2. OSI transport 5979 5980 During authentication of an OSI client to an OSI 5981server, the mutual authentication of an OSI server to an OSI 5982client, the transfer of credentials from an OSI client to an 5983OSI server, or during exchange of private or integrity 5984checked messages, Kerberos protocol messages may be treated 5985as opaque objects and the type of the authentication mechan- 5986ism will be: 5987 5988OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5), 5989 kerberosv5(2)} 5990 5991Depending on the situation, the opaque object will be an 5992authentication header (KRB_AP_REQ), an authentication reply 5993(KRB_AP_REP), a safe message (KRB_SAFE), a private message 5994 5995 5996Section 8.2.2. - 91 - Expires 11 January 1998 5997 5998 5999 6000 6001 6002 6003 6004 Version 5 - Specification Revision 6 6005 6006 6007(KRB_PRIV), or a credentials message (KRB_CRED). The opaque 6008data contains an application code as specified in the ASN.1 6009description for each message. The application code may be 6010used by Kerberos to determine the message type. 6011 60128.2.3. Name of the TGS 6013 6014 The principal identifier of the ticket-granting service 6015shall be composed of three parts: (1) the realm of the KDC 6016issuing the TGS ticket (2) a two-part name of type NT-SRV- 6017INST, with the first part "krbtgt" and the second part the 6018name of the realm which will accept the ticket-granting 6019ticket. For example, a ticket-granting ticket issued by the 6020ATHENA.MIT.EDU realm to be used to get tickets from the 6021ATHENA.MIT.EDU KDC has a principal identifier of 6022"ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") 6023(name). A ticket-granting ticket issued by the 6024ATHENA.MIT.EDU realm to be used to get tickets from the 6025MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" 6026(realm), ("krbtgt", "MIT.EDU") (name). 6027 6028 60298.3. Protocol constants and associated values 6030 6031The following tables list constants used in the protocol and defines their 6032meanings. 6033 6034Encryption type etype value block size minimum pad size confounder size 6035NULL 0 1 0 0 6036des-cbc-crc 1 8 4 8 6037des-cbc-md4 2 8 0 8 6038des-cbc-md5 3 8 0 8 6039<reserved> 4 6040des3-cbc-md5 5 8 0 8 6041<reserved> 6 6042des3-cbc-sha1 7 8 0 8 6043sign-dsa-generate 8 (pkinit) 6044encrypt-rsa-priv 9 (pkinit) 6045encrypt-rsa-pub 10 (pkinit) 6046ENCTYPE_PK_CROSS 48 (reserved for pkcross) 6047<reserved> 0x8003 6048 6049Checksum type sumtype value checksum size 6050CRC32 1 4 6051rsa-md4 2 16 6052rsa-md4-des 3 24 6053des-mac 4 16 6054des-mac-k 5 8 6055rsa-md4-des-k 6 16 6056rsa-md5 7 16 6057rsa-md5-des 8 24 6058rsa-md5-des3 9 24 6059hmac-sha1-des3 10 20 (I had this as 10, is it 12) 6060 6061 6062Section 8.3. - 92 - Expires 11 January 1998 6063 6064 6065 6066 6067 6068 6069 6070 Version 5 - Specification Revision 6 6071 6072 6073padata type padata-type value 6074 6075PA-TGS-REQ 1 6076PA-ENC-TIMESTAMP 2 6077PA-PW-SALT 3 6078<reserved> 4 6079PA-ENC-UNIX-TIME 5 6080PA-SANDIA-SECUREID 6 6081PA-SESAME 7 6082PA-OSF-DCE 8 6083PA-CYBERSAFE-SECUREID 9 6084PA-AFS3-SALT 10 6085PA-ETYPE-INFO 11 6086SAM-CHALLENGE 12 (sam/otp) 6087SAM-RESPONSE 13 (sam/otp) 6088PA-PK-AS-REQ 14 (pkinit) 6089PA-PK-AS-REP 15 (pkinit) 6090PA-PK-AS-SIGN 16 (pkinit) 6091PA-PK-KEY-REQ 17 (pkinit) 6092PA-PK-KEY-REP 18 (pkinit) 6093 6094authorization data type ad-type value 6095reserved values 0-63 6096OSF-DCE 64 6097SESAME 65 6098 6099alternate authentication type method-type value 6100reserved values 0-63 6101ATT-CHALLENGE-RESPONSE 64 6102 6103transited encoding type tr-type value 6104DOMAIN-X500-COMPRESS 1 6105reserved values all others 6106 6107 6108 6109Label Value Meaning or MIT code 6110 6111pvno 5 current Kerberos protocol version number 6112 6113message types 6114 6115KRB_AS_REQ 10 Request for initial authentication 6116KRB_AS_REP 11 Response to KRB_AS_REQ request 6117KRB_TGS_REQ 12 Request for authentication based on TGT 6118KRB_TGS_REP 13 Response to KRB_TGS_REQ request 6119KRB_AP_REQ 14 application request to server 6120KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 6121KRB_SAFE 20 Safe (checksummed) application message 6122KRB_PRIV 21 Private (encrypted) application message 6123KRB_CRED 22 Private (encrypted) message to forward credentials 6124KRB_ERROR 30 Error response 6125 6126 6127Section 8.3. - 93 - Expires 11 January 1998 6128 6129 6130 6131 6132 6133 6134 6135 Version 5 - Specification Revision 6 6136 6137 6138name types 6139 6140KRB_NT_UNKNOWN 0 Name type not known 6141KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 6142KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 6143KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 6144KRB_NT_SRV_XHST 4 Service with host as remaining components 6145KRB_NT_UID 5 Unique ID 6146 6147error codes 6148 6149KDC_ERR_NONE 0 No error 6150KDC_ERR_NAME_EXP 1 Client's entry in database has expired 6151KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 6152KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported 6153KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 6154KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 6155KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 6156KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 6157KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 6158KDC_ERR_NULL_KEY 9 The client or server has a null key 6159KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 6160KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 6161KDC_ERR_POLICY 12 KDC policy rejects request 6162KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 6163KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 6164KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 6165KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 6166KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 6167KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 6168KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 6169KDC_ERR_TGT_REVOKED 20 TGT has been revoked 6170KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 6171KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 6172KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset 6173KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 6174KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired- 6175KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 6176KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 6177KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 6178KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 6179KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 6180KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 6181KRB_AP_ERR_REPEAT 34 Request is a replay 6182KRB_AP_ERR_NOT_US 35 The ticket isn't for us 6183KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 6184KRB_AP_ERR_SKEW 37 Clock skew too great 6185KRB_AP_ERR_BADADDR 38 Incorrect net address 6186KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 6187KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 6188KRB_AP_ERR_MODIFIED 41 Message stream modified 6189KRB_AP_ERR_BADORDER 42 Message out of order 6190KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 6191KRB_AP_ERR_NOKEY 45 Service key not available 6192KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 6193KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 6194KRB_AP_ERR_METHOD 48 Alternative authentication method required 6195KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 6196 6197 6198 6199Section 8.3. - 94 - Expires 11 January 1998 6200 6201 6202 6203 6204 6205 6206 6207 Version 5 - Specification Revision 6 6208 6209 6210KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 6211KRB_ERR_GENERIC 60 Generic error (description in e-text) 6212KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 6213KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 6214KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 6215KDC_ERROR_INVALID_SIG 64 (pkinit) 6216KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 6217 6218 62199. Interoperability requirements 6220 6221 Version 5 of the Kerberos protocol supports a myriad of 6222options. Among these are multiple encryption and checksum 6223types, alternative encoding schemes for the transited field, 6224optional mechanisms for pre-authentication, the handling of 6225tickets with no addresses, options for mutual authentica- 6226tion, user to user authentication, support for proxies, for- 6227warding, postdating, and renewing tickets, the format of 6228realm names, and the handling of authorization data. 6229 6230 In order to ensure the interoperability of realms, it 6231is necessary to define a minimal configuration which must be 6232supported by all implementations. This minimal configura- 6233tion is subject to change as technology does. For example, 6234if at some later date it is discovered that one of the 6235required encryption or checksum algorithms is not secure, it 6236will be replaced. 6237 62389.1. Specification 1 6239 6240 This section defines the first specification of these 6241options. Implementations which are configured in this way 6242can be said to support Kerberos Version 5 Specification 1 6243(5.1). 6244 6245Encryption and checksum methods 6246 6247The following encryption and checksum mechanisms must be 6248supported. Implementations may support other mechanisms as 6249well, but the additional mechanisms may only be used when 6250communicating with principals known to also support them: 6251This list is to be determined. 6252Encryption: DES-CBC-MD5 6253Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 6254 6255 6256__________________________ 6257- This error carries additional information in the e- 6258data field. The contents of the e-data field for this 6259message is described in section 5.9.1. 6260 6261 6262 6263Section 9.1. - 95 - Expires 11 January 1998 6264 6265 6266 6267 6268 6269 6270 6271 Version 5 - Specification Revision 6 6272 6273 6274Realm Names 6275 6276All implementations must understand hierarchical realms in 6277both the Internet Domain and the X.500 style. When a ticket 6278granting ticket for an unknown realm is requested, the KDC 6279must be able to determine the names of the intermediate 6280realms between the KDCs realm and the requested realm. 6281 6282Transited field encoding 6283 6284DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be 6285supported. Alternative encodings may be supported, but they 6286may be used only when that encoding is supported by ALL 6287intermediate realms. 6288 6289Pre-authentication methods 6290 6291The TGS-REQ method must be supported. The TGS-REQ method is 6292not used on the initial request. The PA-ENC-TIMESTAMP 6293method must be supported by clients but whether it is 6294enabled by default may be determined on a realm by realm 6295basis. If not used in the initial request and the error 6296KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC- 6297TIMESTAMP as an acceptable method, the client should retry 6298the initial request using the PA-ENC-TIMESTAMP pre- 6299authentication method. Servers need not support the PA- 6300ENC-TIMESTAMP method, but if not supported the server should 6301ignore the presence of PA-ENC-TIMESTAMP pre-authentication 6302in a request. 6303 6304Mutual authentication 6305 6306Mutual authentication (via the KRB_AP_REP message) must be 6307supported. 6308 6309 6310Ticket addresses and flags 6311 6312All KDC's must pass on tickets that carry no addresses (i.e. 6313if a TGT contains no addresses, the KDC will return deriva- 6314tive tickets), but each realm may set its own policy for 6315issuing such tickets, and each application server will set 6316its own policy with respect to accepting them. 6317 6318 Proxies and forwarded tickets must be supported. Indi- 6319vidual realms and application servers can set their own pol- 6320icy on when such tickets will be accepted. 6321 6322 All implementations must recognize renewable and post- 6323dated tickets, but need not actually implement them. If 6324these options are not supported, the starttime and endtime 6325in the ticket shall specify a ticket's entire useful life. 6326When a postdated ticket is decoded by a server, all imple- 6327mentations shall make the presence of the postdated flag 6328 6329 6330Section 9.1. - 96 - Expires 11 January 1998 6331 6332 6333 6334 6335 6336 6337 6338 Version 5 - Specification Revision 6 6339 6340 6341visible to the calling server. 6342 6343User-to-user authentication 6344 6345Support for user to user authentication (via the ENC-TKT- 6346IN-SKEY KDC option) must be provided by implementations, but 6347individual realms may decide as a matter of policy to reject 6348such requests on a per-principal or realm-wide basis. 6349 6350Authorization data 6351 6352Implementations must pass all authorization data subfields 6353from ticket-granting tickets to any derivative tickets 6354unless directed to suppress a subfield as part of the defin- 6355ition of that registered subfield type (it is never 6356incorrect to pass on a subfield, and no registered subfield 6357types presently specify suppression at the KDC). 6358 6359 Implementations must make the contents of any authori- 6360zation data subfields available to the server when a ticket 6361is used. Implementations are not required to allow clients 6362to specify the contents of the authorization data fields. 6363 63649.2. Recommended KDC values 6365 6366Following is a list of recommended values for a KDC imple- 6367mentation, based on the list of suggested configuration con- 6368stants (see section 4.4). 6369 6370minimum lifetime 5 minutes 6371 6372maximum renewable lifetime1 week 6373 6374maximum ticket lifetime1 day 6375 6376empty addresses only when suitable restrictions appear 6377 in authorization data 6378 6379proxiable, etc. Allowed. 6380 6381 6382 6383 6384 6385 6386 6387 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397Section 9.2. - 97 - Expires 11 January 1998 6398 6399 6400 6401 6402 6403 6404 6405 Version 5 - Specification Revision 6 6406 6407 640810. REFERENCES 6409 6410 6411 64121. B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- 6413 cation Service for Computer Networks," IEEE Communica- 6414 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). 6415 64162. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 6417 Saltzer, Section E.2.1: Kerberos Authentication and 6418 Authorization System, M.I.T. Project Athena, Cambridge, 6419 Massachusetts (December 21, 1987). 6420 64213. J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 6422 beros: An Authentication Service for Open Network Sys- 6423 tems," pp. 191-202 in Usenix Conference Proceedings, 6424 Dallas, Texas (February, 1988). 6425 64264. Roger M. Needham and Michael D. Schroeder, "Using 6427 Encryption for Authentication in Large Networks of Com- 6428 puters," Communications of the ACM, Vol. 21(12), 6429 pp. 993-999 (December, 1978). 6430 64315. Dorothy E. Denning and Giovanni Maria Sacco, "Time- 6432 stamps in Key Distribution Protocols," Communications 6433 of the ACM, Vol. 24(8), pp. 533-536 (August 1981). 6434 64356. John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 6436 "The Evolution of the Kerberos Authentication Service," 6437 in an IEEE Computer Society Text soon to be published 6438 (June 1992). 6439 64407. B. Clifford Neuman, "Proxy-Based Authorization and 6441 Accounting for Distributed Systems," in Proceedings of 6442 the 13th International Conference on Distributed Com- 6443 puting Systems, Pittsburgh, PA (May, 1993). 6444 64458. Don Davis and Ralph Swick, "Workstation Services and 6446 Kerberos Authentication at Project Athena," Technical 6447 Memorandum TM-424, MIT Laboratory for Computer Science 6448 (February 1990). 6449 64509. P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 6451 merfeld, and K. Raeburn, Section E.1: Service Manage- 6452 ment System, M.I.T. Project Athena, Cambridge, Mas- 6453 sachusetts (1987). 6454 645510. CCITT, Recommendation X.509: The Directory Authentica- 6456 tion Framework, December 1988. 6457 645811. J. Pato, Using Pre-Authentication to Avoid Password 6459 Guessing Attacks, Open Software Foundation DCE Request 6460 for Comments 26 (December 1992). 6461 6462 6463 6464Section 10. - 98 - Expires 11 January 1998 6465 6466 6467 6468 6469 6470 6471 6472 Version 5 - Specification Revision 6 6473 6474 647512. National Bureau of Standards, U.S. Department of Com- 6476 merce, "Data Encryption Standard," Federal Information 6477 Processing Standards Publication 46, Washington, DC 6478 (1977). 6479 648013. National Bureau of Standards, U.S. Department of Com- 6481 merce, "DES Modes of Operation," Federal Information 6482 Processing Standards Publication 81, Springfield, VA 6483 (December 1980). 6484 648514. Stuart G. Stubblebine and Virgil D. Gligor, "On Message 6486 Integrity in Cryptographic Protocols," in Proceedings 6487 of the IEEE Symposium on Research in Security and 6488 Privacy, Oakland, California (May 1992). 6489 649015. International Organization for Standardization, "ISO 6491 Information Processing Systems - Data Communication - 6492 High-Level Data Link Control Procedure - Frame Struc- 6493 ture," IS 3309 (October 1984). 3rd Edition. 6494 649516. R. Rivest, "The MD4 Message Digest Algorithm," RFC 6496 1320, MIT Laboratory for Computer Science (April 6497 1992). 6498 649917. R. Rivest, "The MD5 Message Digest Algorithm," RFC 6500 1321, MIT Laboratory for Computer Science (April 6501 1992). 6502 650318. H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- 6504 Hashing for Message Authentication," Working Draft 6505 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 6506 6507 6508 6509 6510 6511 6512 6513 6514 6515 6516 6517 6518 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531Section 10. - 99 - Expires 11 January 1998 6532 6533 6534 6535 6536 6537 6538 6539 Version 5 - Specification Revision 6 6540 6541 6542A. Pseudo-code for protocol processing 6543 6544 This appendix provides pseudo-code describing how the 6545messages are to be constructed and interpreted by clients 6546and servers. 6547 6548A.1. KRB_AS_REQ generation 6549 request.pvno := protocol version; /* pvno = 5 */ 6550 request.msg-type := message type; /* type = KRB_AS_REQ */ 6551 6552 if(pa_enc_timestamp_required) then 6553 request.padata.padata-type = PA-ENC-TIMESTAMP; 6554 get system_time; 6555 padata-body.patimestamp,pausec = system_time; 6556 encrypt padata-body into request.padata.padata-value 6557 using client.key; /* derived from password */ 6558 endif 6559 6560 body.kdc-options := users's preferences; 6561 body.cname := user's name; 6562 body.realm := user's realm; 6563 body.sname := service's name; /* usually "krbtgt", "localrealm" */ 6564 if (body.kdc-options.POSTDATED is set) then 6565 body.from := requested starting time; 6566 else 6567 omit body.from; 6568 endif 6569 body.till := requested end time; 6570 if (body.kdc-options.RENEWABLE is set) then 6571 body.rtime := requested final renewal time; 6572 endif 6573 body.nonce := random_nonce(); 6574 body.etype := requested etypes; 6575 if (user supplied addresses) then 6576 body.addresses := user's addresses; 6577 else 6578 omit body.addresses; 6579 endif 6580 omit body.enc-authorization-data; 6581 request.req-body := body; 6582 6583 kerberos := lookup(name of local kerberos server (or servers)); 6584 send(packet,kerberos); 6585 6586 wait(for response); 6587 if (timed_out) then 6588 retry or use alternate server; 6589 endif 6590 6591A.2. KRB_AS_REQ verification and KRB_AS_REP generation 6592 decode message into req; 6593 6594 client := lookup(req.cname,req.realm); 6595 server := lookup(req.sname,req.realm); 6596 6597 6598Section A.2. - 100 - Expires 11 January 1998 6599 6600 6601 6602 6603 6604 6605 6606 Version 5 - Specification Revision 6 6607 6608 6609 6610 get system_time; 6611 kdc_time := system_time.seconds; 6612 6613 if (!client) then 6614 /* no client in Database */ 6615 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 6616 endif 6617 if (!server) then 6618 /* no server in Database */ 6619 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 6620 endif 6621 6622 if(client.pa_enc_timestamp_required and 6623 pa_enc_timestamp not present) then 6624 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 6625 endif 6626 6627 if(pa_enc_timestamp present) then 6628 decrypt req.padata-value into decrypted_enc_timestamp 6629 using client.key; 6630 using auth_hdr.authenticator.subkey; 6631 if (decrypt_error()) then 6632 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6633 if(decrypted_enc_timestamp is not within allowable skew) then 6634 error_out(KDC_ERR_PREAUTH_FAILED); 6635 endif 6636 if(decrypted_enc_timestamp and usec is replay) 6637 error_out(KDC_ERR_PREAUTH_FAILED); 6638 endif 6639 add decrypted_enc_timestamp and usec to replay cache; 6640 endif 6641 6642 use_etype := first supported etype in req.etypes; 6643 6644 if (no support for req.etypes) then 6645 error_out(KDC_ERR_ETYPE_NOSUPP); 6646 endif 6647 6648 new_tkt.vno := ticket version; /* = 5 */ 6649 new_tkt.sname := req.sname; 6650 new_tkt.srealm := req.srealm; 6651 reset all flags in new_tkt.flags; 6652 6653 /* It should be noted that local policy may affect the */ 6654 /* processing of any of these flags. For example, some */ 6655 /* realms may refuse to issue renewable tickets */ 6656 6657 if (req.kdc-options.FORWARDABLE is set) then 6658 set new_tkt.flags.FORWARDABLE; 6659 endif 6660 if (req.kdc-options.PROXIABLE is set) then 6661 set new_tkt.flags.PROXIABLE; 6662 endif 6663 6664 6665Section A.2. - 101 - Expires 11 January 1998 6666 6667 6668 6669 6670 6671 6672 6673 Version 5 - Specification Revision 6 6674 6675 6676 if (req.kdc-options.ALLOW-POSTDATE is set) then 6677 set new_tkt.flags.MAY-POSTDATE; 6678 endif 6679 if ((req.kdc-options.RENEW is set) or 6680 (req.kdc-options.VALIDATE is set) or 6681 (req.kdc-options.PROXY is set) or 6682 (req.kdc-options.FORWARDED is set) or 6683 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 6684 error_out(KDC_ERR_BADOPTION); 6685 endif 6686 6687 new_tkt.session := random_session_key(); 6688 new_tkt.cname := req.cname; 6689 new_tkt.crealm := req.crealm; 6690 new_tkt.transited := empty_transited_field(); 6691 6692 new_tkt.authtime := kdc_time; 6693 6694 if (req.kdc-options.POSTDATED is set) then 6695 if (against_postdate_policy(req.from)) then 6696 error_out(KDC_ERR_POLICY); 6697 endif 6698 set new_tkt.flags.POSTDATED; 6699 set new_tkt.flags.INVALID; 6700 new_tkt.starttime := req.from; 6701 else 6702 omit new_tkt.starttime; /* treated as authtime when omitted */ 6703 endif 6704 if (req.till = 0) then 6705 till := infinity; 6706 else 6707 till := req.till; 6708 endif 6709 6710 new_tkt.endtime := min(till, 6711 new_tkt.starttime+client.max_life, 6712 new_tkt.starttime+server.max_life, 6713 new_tkt.starttime+max_life_for_realm); 6714 6715 if ((req.kdc-options.RENEWABLE-OK is set) and 6716 (new_tkt.endtime < req.till)) then 6717 /* we set the RENEWABLE option for later processing */ 6718 set req.kdc-options.RENEWABLE; 6719 req.rtime := req.till; 6720 endif 6721 6722 if (req.rtime = 0) then 6723 rtime := infinity; 6724 else 6725 rtime := req.rtime; 6726 endif 6727 6728 if (req.kdc-options.RENEWABLE is set) then 6729 set new_tkt.flags.RENEWABLE; 6730 6731 6732Section A.2. - 102 - Expires 11 January 1998 6733 6734 6735 6736 6737 6738 6739 6740 Version 5 - Specification Revision 6 6741 6742 6743 new_tkt.renew-till := min(rtime, 6744 new_tkt.starttime+client.max_rlife, 6745 new_tkt.starttime+server.max_rlife, 6746 new_tkt.starttime+max_rlife_for_realm); 6747 else 6748 omit new_tkt.renew-till; /* only present if RENEWABLE */ 6749 endif 6750 6751 if (req.addresses) then 6752 new_tkt.caddr := req.addresses; 6753 else 6754 omit new_tkt.caddr; 6755 endif 6756 6757 new_tkt.authorization_data := empty_authorization_data(); 6758 6759 encode to-be-encrypted part of ticket into OCTET STRING; 6760 new_tkt.enc-part := encrypt OCTET STRING 6761 using etype_for_key(server.key), server.key, server.p_kvno; 6762 6763 6764 /* Start processing the response */ 6765 6766 resp.pvno := 5; 6767 resp.msg-type := KRB_AS_REP; 6768 resp.cname := req.cname; 6769 resp.crealm := req.realm; 6770 resp.ticket := new_tkt; 6771 6772 resp.key := new_tkt.session; 6773 resp.last-req := fetch_last_request_info(client); 6774 resp.nonce := req.nonce; 6775 resp.key-expiration := client.expiration; 6776 resp.flags := new_tkt.flags; 6777 6778 resp.authtime := new_tkt.authtime; 6779 resp.starttime := new_tkt.starttime; 6780 resp.endtime := new_tkt.endtime; 6781 6782 if (new_tkt.flags.RENEWABLE) then 6783 resp.renew-till := new_tkt.renew-till; 6784 endif 6785 6786 resp.realm := new_tkt.realm; 6787 resp.sname := new_tkt.sname; 6788 6789 resp.caddr := new_tkt.caddr; 6790 6791 encode body of reply into OCTET STRING; 6792 6793 resp.enc-part := encrypt OCTET STRING 6794 using use_etype, client.key, client.p_kvno; 6795 send(resp); 6796 6797 6798 6799Section A.2. - 103 - Expires 11 January 1998 6800 6801 6802 6803 6804 6805 6806 6807 Version 5 - Specification Revision 6 6808 6809 6810A.3. KRB_AS_REP verification 6811 decode response into resp; 6812 6813 if (resp.msg-type = KRB_ERROR) then 6814 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 6815 set pa_enc_timestamp_required; 6816 goto KRB_AS_REQ; 6817 endif 6818 process_error(resp); 6819 return; 6820 endif 6821 6822 /* On error, discard the response, and zero the session key */ 6823 /* from the response immediately */ 6824 6825 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 6826 resp.padata); 6827 unencrypted part of resp := decode of decrypt of resp.enc-part 6828 using resp.enc-part.etype and key; 6829 zero(key); 6830 6831 if (common_as_rep_tgs_rep_checks fail) then 6832 destroy resp.key; 6833 return error; 6834 endif 6835 6836 if near(resp.princ_exp) then 6837 print(warning message); 6838 endif 6839 save_for_later(ticket,session,client,server,times,flags); 6840 6841A.4. KRB_AS_REP and KRB_TGS_REP common checks 6842 if (decryption_error() or 6843 (req.cname != resp.cname) or 6844 (req.realm != resp.crealm) or 6845 (req.sname != resp.sname) or 6846 (req.realm != resp.realm) or 6847 (req.nonce != resp.nonce) or 6848 (req.addresses != resp.caddr)) then 6849 destroy resp.key; 6850 return KRB_AP_ERR_MODIFIED; 6851 endif 6852 6853 /* make sure no flags are set that shouldn't be, and that all that */ 6854 /* should be are set */ 6855 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 6856 destroy resp.key; 6857 return KRB_AP_ERR_MODIFIED; 6858 endif 6859 6860 if ((req.from = 0) and 6861 (resp.starttime is not within allowable skew)) then 6862 destroy resp.key; 6863 return KRB_AP_ERR_SKEW; 6864 6865 6866Section A.4. - 104 - Expires 11 January 1998 6867 6868 6869 6870 6871 6872 6873 6874 Version 5 - Specification Revision 6 6875 6876 6877 endif 6878 if ((req.from != 0) and (req.from != resp.starttime)) then 6879 destroy resp.key; 6880 return KRB_AP_ERR_MODIFIED; 6881 endif 6882 if ((req.till != 0) and (resp.endtime > req.till)) then 6883 destroy resp.key; 6884 return KRB_AP_ERR_MODIFIED; 6885 endif 6886 6887 if ((req.kdc-options.RENEWABLE is set) and 6888 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 6889 destroy resp.key; 6890 return KRB_AP_ERR_MODIFIED; 6891 endif 6892 if ((req.kdc-options.RENEWABLE-OK is set) and 6893 (resp.flags.RENEWABLE) and 6894 (req.till != 0) and 6895 (resp.renew-till > req.till)) then 6896 destroy resp.key; 6897 return KRB_AP_ERR_MODIFIED; 6898 endif 6899 6900A.5. KRB_TGS_REQ generation 6901 /* Note that make_application_request might have to recursivly */ 6902 /* call this routine to get the appropriate ticket-granting ticket */ 6903 6904 request.pvno := protocol version; /* pvno = 5 */ 6905 request.msg-type := message type; /* type = KRB_TGS_REQ */ 6906 6907 body.kdc-options := users's preferences; 6908 /* If the TGT is not for the realm of the end-server */ 6909 /* then the sname will be for a TGT for the end-realm */ 6910 /* and the realm of the requested ticket (body.realm) */ 6911 /* will be that of the TGS to which the TGT we are */ 6912 /* sending applies */ 6913 body.sname := service's name; 6914 body.realm := service's realm; 6915 6916 if (body.kdc-options.POSTDATED is set) then 6917 body.from := requested starting time; 6918 else 6919 omit body.from; 6920 endif 6921 body.till := requested end time; 6922 if (body.kdc-options.RENEWABLE is set) then 6923 body.rtime := requested final renewal time; 6924 endif 6925 body.nonce := random_nonce(); 6926 body.etype := requested etypes; 6927 if (user supplied addresses) then 6928 body.addresses := user's addresses; 6929 else 6930 omit body.addresses; 6931 6932 6933Section A.5. - 105 - Expires 11 January 1998 6934 6935 6936 6937 6938 6939 6940 6941 Version 5 - Specification Revision 6 6942 6943 6944 endif 6945 6946 body.enc-authorization-data := user-supplied data; 6947 if (body.kdc-options.ENC-TKT-IN-SKEY) then 6948 body.additional-tickets_ticket := second TGT; 6949 endif 6950 6951 request.req-body := body; 6952 check := generate_checksum (req.body,checksumtype); 6953 6954 request.padata[0].padata-type := PA-TGS-REQ; 6955 request.padata[0].padata-value := create a KRB_AP_REQ using 6956 the TGT and checksum 6957 6958 /* add in any other padata as required/supplied */ 6959 6960 kerberos := lookup(name of local kerberose server (or servers)); 6961 send(packet,kerberos); 6962 6963 wait(for response); 6964 if (timed_out) then 6965 retry or use alternate server; 6966 endif 6967 6968A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 6969 /* note that reading the application request requires first 6970 determining the server for which a ticket was issued, and choosing the 6971 correct key for decryption. The name of the server appears in the 6972 plaintext part of the ticket. */ 6973 6974 if (no KRB_AP_REQ in req.padata) then 6975 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 6976 endif 6977 verify KRB_AP_REQ in req.padata; 6978 6979 /* Note that the realm in which the Kerberos server is operating is 6980 determined by the instance from the ticket-granting ticket. The realm 6981 in the ticket-granting ticket is the realm under which the ticket 6982 granting ticket was issued. It is possible for a single Kerberos 6983 server to support more than one realm. */ 6984 6985 auth_hdr := KRB_AP_REQ; 6986 tgt := auth_hdr.ticket; 6987 6988 if (tgt.sname is not a TGT for local realm and is not req.sname) then 6989 error_out(KRB_AP_ERR_NOT_US); 6990 6991 realm := realm_tgt_is_for(tgt); 6992 6993 decode remainder of request; 6994 6995 if (auth_hdr.authenticator.cksum is missing) then 6996 error_out(KRB_AP_ERR_INAPP_CKSUM); 6997 endif 6998 6999 7000Section A.6. - 106 - Expires 11 January 1998 7001 7002 7003 7004 7005 7006 7007 7008 Version 5 - Specification Revision 6 7009 7010 7011 if (auth_hdr.authenticator.cksum type is not supported) then 7012 error_out(KDC_ERR_SUMTYPE_NOSUPP); 7013 endif 7014 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 7015 error_out(KRB_AP_ERR_INAPP_CKSUM); 7016 endif 7017 7018 set computed_checksum := checksum(req); 7019 if (computed_checksum != auth_hdr.authenticatory.cksum) then 7020 error_out(KRB_AP_ERR_MODIFIED); 7021 endif 7022 7023 server := lookup(req.sname,realm); 7024 7025 if (!server) then 7026 if (is_foreign_tgt_name(server)) then 7027 server := best_intermediate_tgs(server); 7028 else 7029 /* no server in Database */ 7030 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 7031 endif 7032 endif 7033 7034 session := generate_random_session_key(); 7035 7036 7037 use_etype := first supported etype in req.etypes; 7038 7039 if (no support for req.etypes) then 7040 error_out(KDC_ERR_ETYPE_NOSUPP); 7041 endif 7042 7043 new_tkt.vno := ticket version; /* = 5 */ 7044 new_tkt.sname := req.sname; 7045 new_tkt.srealm := realm; 7046 reset all flags in new_tkt.flags; 7047 7048 /* It should be noted that local policy may affect the */ 7049 /* processing of any of these flags. For example, some */ 7050 /* realms may refuse to issue renewable tickets */ 7051 7052 new_tkt.caddr := tgt.caddr; 7053 resp.caddr := NULL; /* We only include this if they change */ 7054 if (req.kdc-options.FORWARDABLE is set) then 7055 if (tgt.flags.FORWARDABLE is reset) then 7056 error_out(KDC_ERR_BADOPTION); 7057 endif 7058 set new_tkt.flags.FORWARDABLE; 7059 endif 7060 if (req.kdc-options.FORWARDED is set) then 7061 if (tgt.flags.FORWARDABLE is reset) then 7062 error_out(KDC_ERR_BADOPTION); 7063 endif 7064 set new_tkt.flags.FORWARDED; 7065 7066 7067Section A.6. - 107 - Expires 11 January 1998 7068 7069 7070 7071 7072 7073 7074 7075 Version 5 - Specification Revision 6 7076 7077 7078 new_tkt.caddr := req.addresses; 7079 resp.caddr := req.addresses; 7080 endif 7081 if (tgt.flags.FORWARDED is set) then 7082 set new_tkt.flags.FORWARDED; 7083 endif 7084 7085 if (req.kdc-options.PROXIABLE is set) then 7086 if (tgt.flags.PROXIABLE is reset) 7087 error_out(KDC_ERR_BADOPTION); 7088 endif 7089 set new_tkt.flags.PROXIABLE; 7090 endif 7091 if (req.kdc-options.PROXY is set) then 7092 if (tgt.flags.PROXIABLE is reset) then 7093 error_out(KDC_ERR_BADOPTION); 7094 endif 7095 set new_tkt.flags.PROXY; 7096 new_tkt.caddr := req.addresses; 7097 resp.caddr := req.addresses; 7098 endif 7099 7100 if (req.kdc-options.ALLOW-POSTDATE is set) then 7101 if (tgt.flags.MAY-POSTDATE is reset) 7102 error_out(KDC_ERR_BADOPTION); 7103 endif 7104 set new_tkt.flags.MAY-POSTDATE; 7105 endif 7106 if (req.kdc-options.POSTDATED is set) then 7107 if (tgt.flags.MAY-POSTDATE is reset) then 7108 error_out(KDC_ERR_BADOPTION); 7109 endif 7110 set new_tkt.flags.POSTDATED; 7111 set new_tkt.flags.INVALID; 7112 if (against_postdate_policy(req.from)) then 7113 error_out(KDC_ERR_POLICY); 7114 endif 7115 new_tkt.starttime := req.from; 7116 endif 7117 7118 7119 if (req.kdc-options.VALIDATE is set) then 7120 if (tgt.flags.INVALID is reset) then 7121 error_out(KDC_ERR_POLICY); 7122 endif 7123 if (tgt.starttime > kdc_time) then 7124 error_out(KRB_AP_ERR_NYV); 7125 endif 7126 if (check_hot_list(tgt)) then 7127 error_out(KRB_AP_ERR_REPEAT); 7128 endif 7129 tkt := tgt; 7130 reset new_tkt.flags.INVALID; 7131 endif 7132 7133 7134Section A.6. - 108 - Expires 11 January 1998 7135 7136 7137 7138 7139 7140 7141 7142 Version 5 - Specification Revision 6 7143 7144 7145 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 7146 and those already processed) is set) then 7147 error_out(KDC_ERR_BADOPTION); 7148 endif 7149 7150 new_tkt.authtime := tgt.authtime; 7151 7152 if (req.kdc-options.RENEW is set) then 7153 /* Note that if the endtime has already passed, the ticket would */ 7154 /* have been rejected in the initial authentication stage, so */ 7155 /* there is no need to check again here */ 7156 if (tgt.flags.RENEWABLE is reset) then 7157 error_out(KDC_ERR_BADOPTION); 7158 endif 7159 if (tgt.renew-till >= kdc_time) then 7160 error_out(KRB_AP_ERR_TKT_EXPIRED); 7161 endif 7162 tkt := tgt; 7163 new_tkt.starttime := kdc_time; 7164 old_life := tgt.endttime - tgt.starttime; 7165 new_tkt.endtime := min(tgt.renew-till, 7166 new_tkt.starttime + old_life); 7167 else 7168 new_tkt.starttime := kdc_time; 7169 if (req.till = 0) then 7170 till := infinity; 7171 else 7172 till := req.till; 7173 endif 7174 new_tkt.endtime := min(till, 7175 new_tkt.starttime+client.max_life, 7176 new_tkt.starttime+server.max_life, 7177 new_tkt.starttime+max_life_for_realm, 7178 tgt.endtime); 7179 7180 if ((req.kdc-options.RENEWABLE-OK is set) and 7181 (new_tkt.endtime < req.till) and 7182 (tgt.flags.RENEWABLE is set) then 7183 /* we set the RENEWABLE option for later processing */ 7184 set req.kdc-options.RENEWABLE; 7185 req.rtime := min(req.till, tgt.renew-till); 7186 endif 7187 endif 7188 7189 if (req.rtime = 0) then 7190 rtime := infinity; 7191 else 7192 rtime := req.rtime; 7193 endif 7194 7195 if ((req.kdc-options.RENEWABLE is set) and 7196 (tgt.flags.RENEWABLE is set)) then 7197 set new_tkt.flags.RENEWABLE; 7198 new_tkt.renew-till := min(rtime, 7199 7200 7201Section A.6. - 109 - Expires 11 January 1998 7202 7203 7204 7205 7206 7207 7208 7209 Version 5 - Specification Revision 6 7210 7211 7212 new_tkt.starttime+client.max_rlife, 7213 new_tkt.starttime+server.max_rlife, 7214 new_tkt.starttime+max_rlife_for_realm, 7215 tgt.renew-till); 7216 else 7217 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 7218 endif 7219 if (req.enc-authorization-data is present) then 7220 decrypt req.enc-authorization-data into decrypted_authorization_data 7221 using auth_hdr.authenticator.subkey; 7222 if (decrypt_error()) then 7223 error_out(KRB_AP_ERR_BAD_INTEGRITY); 7224 endif 7225 endif 7226 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 7227 decrypted_authorization_data; 7228 7229 new_tkt.key := session; 7230 new_tkt.crealm := tgt.crealm; 7231 new_tkt.cname := req.auth_hdr.ticket.cname; 7232 7233 if (realm_tgt_is_for(tgt) := tgt.realm) then 7234 /* tgt issued by local realm */ 7235 new_tkt.transited := tgt.transited; 7236 else 7237 /* was issued for this realm by some other realm */ 7238 if (tgt.transited.tr-type not supported) then 7239 error_out(KDC_ERR_TRTYPE_NOSUPP); 7240 endif 7241 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 7242 endif 7243 7244 encode encrypted part of new_tkt into OCTET STRING; 7245 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 7246 if (server not specified) then 7247 server = req.second_ticket.client; 7248 endif 7249 if ((req.second_ticket is not a TGT) or 7250 (req.second_ticket.client != server)) then 7251 error_out(KDC_ERR_POLICY); 7252 endif 7253 7254 new_tkt.enc-part := encrypt OCTET STRING using 7255 using etype_for_key(second-ticket.key), second-ticket.key; 7256 else 7257 new_tkt.enc-part := encrypt OCTET STRING 7258 using etype_for_key(server.key), server.key, server.p_kvno; 7259 endif 7260 7261 resp.pvno := 5; 7262 resp.msg-type := KRB_TGS_REP; 7263 resp.crealm := tgt.crealm; 7264 resp.cname := tgt.cname; 7265 7266 7267 7268Section A.6. - 110 - Expires 11 January 1998 7269 7270 7271 7272 7273 7274 7275 7276 Version 5 - Specification Revision 6 7277 7278 7279 resp.ticket := new_tkt; 7280 7281 resp.key := session; 7282 resp.nonce := req.nonce; 7283 resp.last-req := fetch_last_request_info(client); 7284 resp.flags := new_tkt.flags; 7285 7286 resp.authtime := new_tkt.authtime; 7287 resp.starttime := new_tkt.starttime; 7288 resp.endtime := new_tkt.endtime; 7289 7290 omit resp.key-expiration; 7291 7292 resp.sname := new_tkt.sname; 7293 resp.realm := new_tkt.realm; 7294 7295 if (new_tkt.flags.RENEWABLE) then 7296 resp.renew-till := new_tkt.renew-till; 7297 endif 7298 7299 7300 encode body of reply into OCTET STRING; 7301 7302 if (req.padata.authenticator.subkey) 7303 resp.enc-part := encrypt OCTET STRING using use_etype, 7304 req.padata.authenticator.subkey; 7305 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 7306 7307 send(resp); 7308 7309A.7. KRB_TGS_REP verification 7310 decode response into resp; 7311 7312 if (resp.msg-type = KRB_ERROR) then 7313 process_error(resp); 7314 return; 7315 endif 7316 7317 /* On error, discard the response, and zero the session key from 7318 the response immediately */ 7319 7320 if (req.padata.authenticator.subkey) 7321 unencrypted part of resp := decode of decrypt of resp.enc-part 7322 using resp.enc-part.etype and subkey; 7323 else unencrypted part of resp := decode of decrypt of resp.enc-part 7324 using resp.enc-part.etype and tgt's session key; 7325 if (common_as_rep_tgs_rep_checks fail) then 7326 destroy resp.key; 7327 return error; 7328 endif 7329 7330 check authorization_data as necessary; 7331 save_for_later(ticket,session,client,server,times,flags); 7332 7333 7334 7335Section A.7. - 111 - Expires 11 January 1998 7336 7337 7338 7339 7340 7341 7342 7343 Version 5 - Specification Revision 6 7344 7345 7346A.8. Authenticator generation 7347 body.authenticator-vno := authenticator vno; /* = 5 */ 7348 body.cname, body.crealm := client name; 7349 if (supplying checksum) then 7350 body.cksum := checksum; 7351 endif 7352 get system_time; 7353 body.ctime, body.cusec := system_time; 7354 if (selecting sub-session key) then 7355 select sub-session key; 7356 body.subkey := sub-session key; 7357 endif 7358 if (using sequence numbers) then 7359 select initial sequence number; 7360 body.seq-number := initial sequence; 7361 endif 7362 7363A.9. KRB_AP_REQ generation 7364 obtain ticket and session_key from cache; 7365 7366 packet.pvno := protocol version; /* 5 */ 7367 packet.msg-type := message type; /* KRB_AP_REQ */ 7368 7369 if (desired(MUTUAL_AUTHENTICATION)) then 7370 set packet.ap-options.MUTUAL-REQUIRED; 7371 else 7372 reset packet.ap-options.MUTUAL-REQUIRED; 7373 endif 7374 if (using session key for ticket) then 7375 set packet.ap-options.USE-SESSION-KEY; 7376 else 7377 reset packet.ap-options.USE-SESSION-KEY; 7378 endif 7379 packet.ticket := ticket; /* ticket */ 7380 generate authenticator; 7381 encode authenticator into OCTET STRING; 7382 encrypt OCTET STRING into packet.authenticator using session_key; 7383 7384A.10. KRB_AP_REQ verification 7385 receive packet; 7386 if (packet.pvno != 5) then 7387 either process using other protocol spec 7388 or error_out(KRB_AP_ERR_BADVERSION); 7389 endif 7390 if (packet.msg-type != KRB_AP_REQ) then 7391 error_out(KRB_AP_ERR_MSG_TYPE); 7392 endif 7393 if (packet.ticket.tkt_vno != 5) then 7394 either process using other protocol spec 7395 or error_out(KRB_AP_ERR_BADVERSION); 7396 endif 7397 if (packet.ap_options.USE-SESSION-KEY is set) then 7398 retrieve session key from ticket-granting ticket for 7399 packet.ticket.{sname,srealm,enc-part.etype}; 7400 7401 7402Section A.10. - 112 - Expires 11 January 1998 7403 7404 7405 7406 7407 7408 7409 7410 Version 5 - Specification Revision 6 7411 7412 7413 else 7414 retrieve service key for 7415 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 7416 endif 7417 if (no_key_available) then 7418 if (cannot_find_specified_skvno) then 7419 error_out(KRB_AP_ERR_BADKEYVER); 7420 else 7421 error_out(KRB_AP_ERR_NOKEY); 7422 endif 7423 endif 7424 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 7425 if (decryption_error()) then 7426 error_out(KRB_AP_ERR_BAD_INTEGRITY); 7427 endif 7428 decrypt packet.authenticator into decr_authenticator 7429 using decr_ticket.key; 7430 if (decryption_error()) then 7431 error_out(KRB_AP_ERR_BAD_INTEGRITY); 7432 endif 7433 if (decr_authenticator.{cname,crealm} != 7434 decr_ticket.{cname,crealm}) then 7435 error_out(KRB_AP_ERR_BADMATCH); 7436 endif 7437 if (decr_ticket.caddr is present) then 7438 if (sender_address(packet) is not in decr_ticket.caddr) then 7439 error_out(KRB_AP_ERR_BADADDR); 7440 endif 7441 elseif (application requires addresses) then 7442 error_out(KRB_AP_ERR_BADADDR); 7443 endif 7444 if (not in_clock_skew(decr_authenticator.ctime, 7445 decr_authenticator.cusec)) then 7446 error_out(KRB_AP_ERR_SKEW); 7447 endif 7448 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 7449 error_out(KRB_AP_ERR_REPEAT); 7450 endif 7451 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 7452 get system_time; 7453 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 7454 (decr_ticket.flags.INVALID is set)) then 7455 /* it hasn't yet become valid */ 7456 error_out(KRB_AP_ERR_TKT_NYV); 7457 endif 7458 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 7459 error_out(KRB_AP_ERR_TKT_EXPIRED); 7460 endif 7461 /* caller must check decr_ticket.flags for any pertinent details */ 7462 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 7463 7464A.11. KRB_AP_REP generation 7465 packet.pvno := protocol version; /* 5 */ 7466 packet.msg-type := message type; /* KRB_AP_REP */ 7467 7468 7469Section A.11. - 113 - Expires 11 January 1998 7470 7471 7472 7473 7474 7475 7476 7477 Version 5 - Specification Revision 6 7478 7479 7480 body.ctime := packet.ctime; 7481 body.cusec := packet.cusec; 7482 if (selecting sub-session key) then 7483 select sub-session key; 7484 body.subkey := sub-session key; 7485 endif 7486 if (using sequence numbers) then 7487 select initial sequence number; 7488 body.seq-number := initial sequence; 7489 endif 7490 7491 encode body into OCTET STRING; 7492 7493 select encryption type; 7494 encrypt OCTET STRING into packet.enc-part; 7495 7496A.12. KRB_AP_REP verification 7497 receive packet; 7498 if (packet.pvno != 5) then 7499 either process using other protocol spec 7500 or error_out(KRB_AP_ERR_BADVERSION); 7501 endif 7502 if (packet.msg-type != KRB_AP_REP) then 7503 error_out(KRB_AP_ERR_MSG_TYPE); 7504 endif 7505 cleartext := decrypt(packet.enc-part) using ticket's session key; 7506 if (decryption_error()) then 7507 error_out(KRB_AP_ERR_BAD_INTEGRITY); 7508 endif 7509 if (cleartext.ctime != authenticator.ctime) then 7510 error_out(KRB_AP_ERR_MUT_FAIL); 7511 endif 7512 if (cleartext.cusec != authenticator.cusec) then 7513 error_out(KRB_AP_ERR_MUT_FAIL); 7514 endif 7515 if (cleartext.subkey is present) then 7516 save cleartext.subkey for future use; 7517 endif 7518 if (cleartext.seq-number is present) then 7519 save cleartext.seq-number for future verifications; 7520 endif 7521 return(AUTHENTICATION_SUCCEEDED); 7522 7523A.13. KRB_SAFE generation 7524 collect user data in buffer; 7525 7526 /* assemble packet: */ 7527 packet.pvno := protocol version; /* 5 */ 7528 packet.msg-type := message type; /* KRB_SAFE */ 7529 7530 body.user-data := buffer; /* DATA */ 7531 if (using timestamp) then 7532 get system_time; 7533 body.timestamp, body.usec := system_time; 7534 7535 7536Section A.13. - 114 - Expires 11 January 1998 7537 7538 7539 7540 7541 7542 7543 7544 Version 5 - Specification Revision 6 7545 7546 7547 endif 7548 if (using sequence numbers) then 7549 body.seq-number := sequence number; 7550 endif 7551 body.s-address := sender host addresses; 7552 if (only one recipient) then 7553 body.r-address := recipient host address; 7554 endif 7555 checksum.cksumtype := checksum type; 7556 compute checksum over body; 7557 checksum.checksum := checksum value; /* checksum.checksum */ 7558 packet.cksum := checksum; 7559 packet.safe-body := body; 7560 7561A.14. KRB_SAFE verification 7562 receive packet; 7563 if (packet.pvno != 5) then 7564 either process using other protocol spec 7565 or error_out(KRB_AP_ERR_BADVERSION); 7566 endif 7567 if (packet.msg-type != KRB_SAFE) then 7568 error_out(KRB_AP_ERR_MSG_TYPE); 7569 endif 7570 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 7571 error_out(KRB_AP_ERR_INAPP_CKSUM); 7572 endif 7573 if (safe_priv_common_checks_ok(packet)) then 7574 set computed_checksum := checksum(packet.body); 7575 if (computed_checksum != packet.checksum) then 7576 error_out(KRB_AP_ERR_MODIFIED); 7577 endif 7578 return (packet, PACKET_IS_GENUINE); 7579 else 7580 return common_checks_error; 7581 endif 7582 7583A.15. KRB_SAFE and KRB_PRIV common checks 7584 if (packet.s-address != O/S_sender(packet)) then 7585 /* O/S report of sender not who claims to have sent it */ 7586 error_out(KRB_AP_ERR_BADADDR); 7587 endif 7588 if ((packet.r-address is present) and 7589 (packet.r-address != local_host_address)) then 7590 /* was not sent to proper place */ 7591 error_out(KRB_AP_ERR_BADADDR); 7592 endif 7593 if (((packet.timestamp is present) and 7594 (not in_clock_skew(packet.timestamp,packet.usec))) or 7595 (packet.timestamp is not present and timestamp expected)) then 7596 error_out(KRB_AP_ERR_SKEW); 7597 endif 7598 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 7599 error_out(KRB_AP_ERR_REPEAT); 7600 endif 7601 7602 7603Section A.15. - 115 - Expires 11 January 1998 7604 7605 7606 7607 7608 7609 7610 7611 Version 5 - Specification Revision 6 7612 7613 7614 if (((packet.seq-number is present) and 7615 ((not in_sequence(packet.seq-number)))) or 7616 (packet.seq-number is not present and sequence expected)) then 7617 error_out(KRB_AP_ERR_BADORDER); 7618 endif 7619 if (packet.timestamp not present and packet.seq-number not present) then 7620 error_out(KRB_AP_ERR_MODIFIED); 7621 endif 7622 7623 save_identifier(packet.{timestamp,usec,s-address}, 7624 sender_principal(packet)); 7625 7626 return PACKET_IS_OK; 7627 7628A.16. KRB_PRIV generation 7629 collect user data in buffer; 7630 7631 /* assemble packet: */ 7632 packet.pvno := protocol version; /* 5 */ 7633 packet.msg-type := message type; /* KRB_PRIV */ 7634 7635 packet.enc-part.etype := encryption type; 7636 7637 body.user-data := buffer; 7638 if (using timestamp) then 7639 get system_time; 7640 body.timestamp, body.usec := system_time; 7641 endif 7642 if (using sequence numbers) then 7643 body.seq-number := sequence number; 7644 endif 7645 body.s-address := sender host addresses; 7646 if (only one recipient) then 7647 body.r-address := recipient host address; 7648 endif 7649 7650 encode body into OCTET STRING; 7651 7652 select encryption type; 7653 encrypt OCTET STRING into packet.enc-part.cipher; 7654 7655 7656A.17. KRB_PRIV verification 7657 receive packet; 7658 if (packet.pvno != 5) then 7659 either process using other protocol spec 7660 or error_out(KRB_AP_ERR_BADVERSION); 7661 endif 7662 if (packet.msg-type != KRB_PRIV) then 7663 error_out(KRB_AP_ERR_MSG_TYPE); 7664 endif 7665 7666 cleartext := decrypt(packet.enc-part) using negotiated key; 7667 if (decryption_error()) then 7668 7669 7670Section A.17. - 116 - Expires 11 January 1998 7671 7672 7673 7674 7675 7676 7677 7678 Version 5 - Specification Revision 6 7679 7680 7681 error_out(KRB_AP_ERR_BAD_INTEGRITY); 7682 endif 7683 7684 if (safe_priv_common_checks_ok(cleartext)) then 7685 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 7686 else 7687 return common_checks_error; 7688 endif 7689 7690A.18. KRB_CRED generation 7691 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 7692 7693 /* assemble packet: */ 7694 packet.pvno := protocol version; /* 5 */ 7695 packet.msg-type := message type; /* KRB_CRED */ 7696 7697 for (tickets[n] in tickets to be forwarded) do 7698 packet.tickets[n] = tickets[n].ticket; 7699 done 7700 7701 packet.enc-part.etype := encryption type; 7702 7703 for (ticket[n] in tickets to be forwarded) do 7704 body.ticket-info[n].key = tickets[n].session; 7705 body.ticket-info[n].prealm = tickets[n].crealm; 7706 body.ticket-info[n].pname = tickets[n].cname; 7707 body.ticket-info[n].flags = tickets[n].flags; 7708 body.ticket-info[n].authtime = tickets[n].authtime; 7709 body.ticket-info[n].starttime = tickets[n].starttime; 7710 body.ticket-info[n].endtime = tickets[n].endtime; 7711 body.ticket-info[n].renew-till = tickets[n].renew-till; 7712 body.ticket-info[n].srealm = tickets[n].srealm; 7713 body.ticket-info[n].sname = tickets[n].sname; 7714 body.ticket-info[n].caddr = tickets[n].caddr; 7715 done 7716 7717 get system_time; 7718 body.timestamp, body.usec := system_time; 7719 7720 if (using nonce) then 7721 body.nonce := nonce; 7722 endif 7723 7724 if (using s-address) then 7725 body.s-address := sender host addresses; 7726 endif 7727 if (limited recipients) then 7728 body.r-address := recipient host address; 7729 endif 7730 7731 encode body into OCTET STRING; 7732 7733 select encryption type; 7734 encrypt OCTET STRING into packet.enc-part.cipher 7735 7736 7737Section A.18. - 117 - Expires 11 January 1998 7738 7739 7740 7741 7742 7743 7744 7745 Version 5 - Specification Revision 6 7746 7747 7748 using negotiated encryption key; 7749 7750 7751A.19. KRB_CRED verification 7752 receive packet; 7753 if (packet.pvno != 5) then 7754 either process using other protocol spec 7755 or error_out(KRB_AP_ERR_BADVERSION); 7756 endif 7757 if (packet.msg-type != KRB_CRED) then 7758 error_out(KRB_AP_ERR_MSG_TYPE); 7759 endif 7760 7761 cleartext := decrypt(packet.enc-part) using negotiated key; 7762 if (decryption_error()) then 7763 error_out(KRB_AP_ERR_BAD_INTEGRITY); 7764 endif 7765 if ((packet.r-address is present or required) and 7766 (packet.s-address != O/S_sender(packet)) then 7767 /* O/S report of sender not who claims to have sent it */ 7768 error_out(KRB_AP_ERR_BADADDR); 7769 endif 7770 if ((packet.r-address is present) and 7771 (packet.r-address != local_host_address)) then 7772 /* was not sent to proper place */ 7773 error_out(KRB_AP_ERR_BADADDR); 7774 endif 7775 if (not in_clock_skew(packet.timestamp,packet.usec)) then 7776 error_out(KRB_AP_ERR_SKEW); 7777 endif 7778 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 7779 error_out(KRB_AP_ERR_REPEAT); 7780 endif 7781 if (packet.nonce is required or present) and 7782 (packet.nonce != expected-nonce) then 7783 error_out(KRB_AP_ERR_MODIFIED); 7784 endif 7785 7786 for (ticket[n] in tickets that were forwarded) do 7787 save_for_later(ticket[n],key[n],principal[n], 7788 server[n],times[n],flags[n]); 7789 return 7790 7791A.20. KRB_ERROR generation 7792 7793 /* assemble packet: */ 7794 packet.pvno := protocol version; /* 5 */ 7795 packet.msg-type := message type; /* KRB_ERROR */ 7796 7797 get system_time; 7798 packet.stime, packet.susec := system_time; 7799 packet.realm, packet.sname := server name; 7800 7801 if (client time available) then 7802 7803 7804Section A.20. - 118 - Expires 11 January 1998 7805 7806 7807 7808 7809 7810 7811 7812 Version 5 - Specification Revision 6 7813 7814 7815 packet.ctime, packet.cusec := client_time; 7816 endif 7817 packet.error-code := error code; 7818 if (client name available) then 7819 packet.cname, packet.crealm := client name; 7820 endif 7821 if (error text available) then 7822 packet.e-text := error text; 7823 endif 7824 if (error data available) then 7825 packet.e-data := error data; 7826 endif 7827 7828 7829 7830 7831 7832 7833 7834 7835 7836 7837 7838 7839 7840 7841 7842 7843 7844 7845 7846 7847 7848 7849 7850 7851 7852 7853 7854 7855 7856 7857 7858 7859 7860 7861 7862 7863 7864 7865 7866 7867 7868 7869 7870 7871 - 119 - Expires 11 January 1998 7872 7873 7874 7875 7876 7877 7878 7879 Version 5 - Specification Revision 6 7880 7881 7882 7883 7884 7885 7886 7887 7888 7889 7890 7891 7892 7893 7894 7895 7896 7897 7898 7899 7900 7901 7902 7903 7904 7905 7906 7907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 7921 7922 7923 7924 7925 7926 7927 7928 7929 7930 7931 7932 7933 7934 7935 7936 7937 7938 - cxx - Expires 11 January 1998 7939 7940 7941 7942 7943 7944 7945 7946 7947 7948 7949 Table of Contents 7950 7951 7952 7953 7954Overview .............................................. 2 7955 7956Background ............................................ 2 7957 79581. Introduction ....................................... 3 7959 79601.1. Cross-Realm Operation ............................ 5 7961 79621.2. Authorization .................................... 6 7963 79641.3. Environmental assumptions ........................ 7 7965 79661.4. Glossary of terms ................................ 8 7967 79682. Ticket flag uses and requests ...................... 10 7969 79702.1. Initial and pre-authenticated tickets ............ 10 7971 79722.2. Invalid tickets .................................. 11 7973 79742.3. Renewable tickets ................................ 11 7975 79762.4. Postdated tickets ................................ 12 7977 79782.5. Proxiable and proxy tickets ...................... 12 7979 79802.6. Forwardable tickets .............................. 13 7981 79822.7. Other KDC options ................................ 14 7983 79843. Message Exchanges .................................. 14 7985 79863.1. The Authentication Service Exchange .............. 14 7987 79883.1.1. Generation of KRB_AS_REQ message ............... 16 7989 79903.1.2. Receipt of KRB_AS_REQ message .................. 16 7991 79923.1.3. Generation of KRB_AS_REP message ............... 16 7993 79943.1.4. Generation of KRB_ERROR message ................ 19 7995 79963.1.5. Receipt of KRB_AS_REP message .................. 19 7997 79983.1.6. Receipt of KRB_ERROR message ................... 19 7999 80003.2. The Client/Server Authentication Exchange ........ 19 8001 80023.2.1. The KRB_AP_REQ message ......................... 20 8003 8004 8005 - i - Expires 11 January 1998 8006 8007 8008 8009 8010 8011 8012 8013 Version 5 - Specification Revision 6 8014 8015 80163.2.2. Generation of a KRB_AP_REQ message ............. 20 8017 80183.2.3. Receipt of KRB_AP_REQ message .................. 21 8019 80203.2.4. Generation of a KRB_AP_REP message ............. 23 8021 80223.2.5. Receipt of KRB_AP_REP message .................. 23 8023 80243.2.6. Using the encryption key ....................... 24 8025 80263.3. The Ticket-Granting Service (TGS) Exchange ....... 25 8027 80283.3.1. Generation of KRB_TGS_REQ message .............. 26 8029 80303.3.2. Receipt of KRB_TGS_REQ message ................. 27 8031 80323.3.3. Generation of KRB_TGS_REP message .............. 28 8033 80343.3.3.1. Checking for revoked tickets ................. 30 8035 80363.3.3.2. Encoding the transited field ................. 30 8037 80383.3.4. Receipt of KRB_TGS_REP message ................. 32 8039 80403.4. The KRB_SAFE Exchange ............................ 32 8041 80423.4.1. Generation of a KRB_SAFE message ............... 32 8043 80443.4.2. Receipt of KRB_SAFE message .................... 33 8045 80463.5. The KRB_PRIV Exchange ............................ 34 8047 80483.5.1. Generation of a KRB_PRIV message ............... 34 8049 80503.5.2. Receipt of KRB_PRIV message .................... 34 8051 80523.6. The KRB_CRED Exchange ............................ 35 8053 80543.6.1. Generation of a KRB_CRED message ............... 35 8055 80563.6.2. Receipt of KRB_CRED message .................... 35 8057 80584. The Kerberos Database .............................. 36 8059 80604.1. Database contents ................................ 36 8061 80624.2. Additional fields ................................ 37 8063 80644.3. Frequently Changing Fields ....................... 38 8065 80664.4. Site Constants ................................... 39 8067 80685. Message Specifications ............................. 39 8069 8070 8071 8072 - ii - Expires 11 January 1998 8073 8074 8075 8076 8077 8078 8079 8080 Version 5 - Specification Revision 6 8081 8082 80835.1. ASN.1 Distinguished Encoding Representation ...... 39 8084 80855.2. ASN.1 Base Definitions ........................... 40 8086 80875.3. Tickets and Authenticators ....................... 43 8088 80895.3.1. Tickets ........................................ 43 8090 80915.3.2. Authenticators ................................. 52 8092 80935.4. Specifications for the AS and TGS exchanges ...... 54 8094 80955.4.1. KRB_KDC_REQ definition ......................... 54 8096 80975.4.2. KRB_KDC_REP definition ......................... 61 8098 80995.5. Client/Server (CS) message specifications ........ 64 8100 81015.5.1. KRB_AP_REQ definition .......................... 64 8102 81035.5.2. KRB_AP_REP definition .......................... 65 8104 81055.5.3. Error message reply ............................ 67 8106 81075.6. KRB_SAFE message specification ................... 67 8108 81095.6.1. KRB_SAFE definition ............................ 67 8110 81115.7. KRB_PRIV message specification ................... 68 8112 81135.7.1. KRB_PRIV definition ............................ 68 8114 81155.8. KRB_CRED message specification ................... 69 8116 81175.8.1. KRB_CRED definition ............................ 70 8118 81195.9. Error message specification ...................... 72 8120 81215.9.1. KRB_ERROR definition ........................... 72 8122 81236. Encryption and Checksum Specifications ............. 74 8124 81256.1. Encryption Specifications ........................ 76 8126 81276.2. Encryption Keys .................................. 78 8128 81296.3. Encryption Systems ............................... 78 8130 81316.3.1. The NULL Encryption System (null) .............. 78 8132 81336.3.2. DES in CBC mode with a CRC-32 checksum (des- 8134cbc-crc) .............................................. 79 8135 81366.3.3. DES in CBC mode with an MD4 checksum (des- 8137 8138 8139 - iii - Expires 11 January 1998 8140 8141 8142 8143 8144 8145 8146 8147 Version 5 - Specification Revision 6 8148 8149 8150cbc-md4) .............................................. 79 8151 81526.3.4. DES in CBC mode with an MD5 checksum (des- 8153cbc-md5) .............................................. 79 8154 81556.3.5. Triple DES EDE in outer CBC mode with an SHA1 8156checksum (des3-cbc-sha1) .............................. 81 8157 81586.4. Checksums ........................................ 83 8159 81606.4.1. The CRC-32 Checksum (crc32) .................... 84 8161 81626.4.2. The RSA MD4 Checksum (rsa-md4) ................. 84 8163 81646.4.3. RSA MD4 Cryptographic Checksum Using DES 8165(rsa-md4-des) ......................................... 84 8166 81676.4.4. The RSA MD5 Checksum (rsa-md5) ................. 85 8168 81696.4.5. RSA MD5 Cryptographic Checksum Using DES 8170(rsa-md5-des) ......................................... 85 8171 81726.4.6. DES cipher-block chained checksum (des-mac) 8173 81746.4.7. RSA MD4 Cryptographic Checksum Using DES 8175alternative (rsa-md4-des-k) ........................... 86 8176 81776.4.8. DES cipher-block chained checksum alternative 8178(des-mac-k) ........................................... 87 8179 81807. Naming Constraints ................................. 87 8181 81827.1. Realm Names ...................................... 87 8183 81847.2. Principal Names .................................. 88 8185 81867.2.1. Name of server principals ...................... 89 8187 81888. Constants and other defined values ................. 90 8189 81908.1. Host address types ............................... 90 8191 81928.2. KDC messages ..................................... 91 8193 81948.2.1. IP transport ................................... 91 8195 81968.2.2. OSI transport .................................. 91 8197 81988.2.3. Name of the TGS ................................ 92 8199 82008.3. Protocol constants and associated values ......... 92 8201 82029. Interoperability requirements ...................... 95 8203 8204 8205 8206 - iv - Expires 11 January 1998 8207 8208 8209 8210 8211 8212 8213 8214 Version 5 - Specification Revision 6 8215 8216 82179.1. Specification 1 .................................. 95 8218 82199.2. Recommended KDC values ........................... 97 8220 822110. REFERENCES ........................................ 98 8222 8223A. Pseudo-code for protocol processing ................ 100 8224 8225A.1. KRB_AS_REQ generation ............................ 100 8226 8227A.2. KRB_AS_REQ verification and KRB_AS_REP genera- 8228tion .................................................. 100 8229 8230A.3. KRB_AS_REP verification .......................... 104 8231 8232A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 104 8233 8234A.5. KRB_TGS_REQ generation ........................... 105 8235 8236A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen- 8237eration ............................................... 106 8238 8239A.7. KRB_TGS_REP verification ......................... 111 8240 8241A.8. Authenticator generation ......................... 112 8242 8243A.9. KRB_AP_REQ generation ............................ 112 8244 8245A.10. KRB_AP_REQ verification ......................... 112 8246 8247A.11. KRB_AP_REP generation ........................... 113 8248 8249A.12. KRB_AP_REP verification ......................... 114 8250 8251A.13. KRB_SAFE generation ............................. 114 8252 8253A.14. KRB_SAFE verification ........................... 115 8254 8255A.15. KRB_SAFE and KRB_PRIV common checks ............. 115 8256 8257A.16. KRB_PRIV generation ............................. 116 8258 8259A.17. KRB_PRIV verification ........................... 116 8260 8261A.18. KRB_CRED generation ............................. 117 8262 8263A.19. KRB_CRED verification ........................... 118 8264 8265A.20. KRB_ERROR generation ............................ 118 8266 8267 8268 8269 8270 8271 8272 8273 - v - Expires 11 January 1998 8274 8275 8276 8277 8278