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