1INTERNET-DRAFT Clifford Neuman 2Obsoletes: 1510 USC-ISI 3 Tom Yu 4 Sam Hartman 5 Ken Raeburn 6 MIT 7 February 15, 2004 8 Expires 15 August, 2004 9 10 The Kerberos Network Authentication Service (V5) 11 12STATUS OF THIS MEMO 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 24 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 30 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 34 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 35 36 The distribution of this memo is unlimited. It is filed as draft- 37 ietf-krb-wg-kerberos-clarifications-05.txt, and expires 15 August 38 2004. Please send comments to: ietf-krb-wg@anl.gov 39 40ABSTRACT 41 42 This document provides an overview and specification of Version 5 of 43 the Kerberos protocol, and updates RFC1510 to clarify aspects of the 44 protocol and its intended use that require more detailed or clearer 45 explanation than was provided in RFC1510. This document is intended 46 to provide a detailed description of the protocol, suitable for 47 implementation, together with descriptions of the appropriate use of 48 protocol messages and fields within those messages. 49 50 51 52February 2004 [Page 1] 53 54 55 56 57 58Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 59 60 61OVERVIEW 62 63 This document describes the concepts and model upon which the 64 Kerberos network authentication system is based. It also specifies 65 Version 5 of the Kerberos protocol. The motivations, goals, 66 assumptions, and rationale behind most design decisions are treated 67 cursorily; they are more fully described in a paper available in IEEE 68 communications [NT94] and earlier in the Kerberos portion of the 69 Athena Technical Plan [MNSS87]. 70 71 This document is not intended to describe Kerberos to the end user, 72 system administrator, or application developer. Higher level papers 73 describing Version 5 of the Kerberos system [NT94] and documenting 74 version 4 [SNS88], are available elsewhere. 75 76BACKGROUND 77 78 The Kerberos model is based in part on Needham and Schroeder's 79 trusted third-party authentication protocol [NS78] and on 80 modifications suggested by Denning and Sacco [DS81]. The original 81 design and implementation of Kerberos Versions 1 through 4 was the 82 work of two former Project Athena staff members, Steve Miller of 83 Digital Equipment Corporation and Clifford Neuman (now at the 84 Information Sciences Institute of the University of Southern 85 California), along with Jerome Saltzer, Technical Director of Project 86 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 87 members of Project Athena have also contributed to the work on 88 Kerberos. 89 90 Version 5 of the Kerberos protocol (described in this document) has 91 evolved from Version 4 based on new requirements and desires for 92 features not available in Version 4. The design of Version 5 of the 93 Kerberos protocol was led by Clifford Neuman and John Kohl with much 94 input from the community. The development of the MIT reference 95 implementation was led at MIT by John Kohl and Theodore Ts'o, with 96 help and contributed code from many others. Since RFC1510 was issued, 97 extensions and revisions to the protocol have been proposed by many 98 individuals. Some of these proposals are reflected in this document. 99 Where such changes involved significant effort, the document cites 100 the contribution of the proposer. 101 102 Reference implementations of both version 4 and version 5 of Kerberos 103 are publicly available and commercial implementations have been 104 developed and are widely used. Details on the differences between 105 Kerberos Versions 4 and 5 can be found in [KNT94]. 106 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119. 110 111 112February 2004 [Page 2] 113 114 115 116 117 118Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 119 120 121 Table of Contents 122 123 124 1251. Introduction ................................................... 7 1261.1. Cross-realm operation ........................................ 9 1271.2. Choosing a principal with which to communicate ............... 10 1281.3. Authorization ................................................ 11 1291.4. Extending Kerberos Without Breaking Interoperability ......... 12 1301.4.1. Compatibility with RFC 1510 ................................ 12 1311.4.2. Sending Extensible Messages ................................ 13 1321.5. Environmental assumptions .................................... 14 1331.6. Glossary of terms ............................................ 14 1342. Ticket flag uses and requests .................................. 17 1352.1. Initial, pre-authenticated, and hardware authenticated 136 tickets ..................................................... 18 1372.2. Invalid tickets .............................................. 18 1382.3. Renewable tickets ............................................ 18 1392.4. Postdated tickets ............................................ 19 1402.5. Proxiable and proxy tickets .................................. 20 1412.6. Forwardable tickets .......................................... 21 1422.7. Transited Policy Checking .................................... 21 1432.8. OK as Delegate ............................................... 22 1442.9. Other KDC options ............................................ 23 1452.9.1. Renewable-OK ............................................... 23 1462.9.2. ENC-TKT-IN-SKEY ............................................ 23 1472.9.3. Passwordless Hardware Authentication ....................... 23 1483. Message Exchanges .............................................. 23 1493.1. The Authentication Service Exchange .......................... 23 1503.1.1. Generation of KRB_AS_REQ message ........................... 25 1513.1.2. Receipt of KRB_AS_REQ message .............................. 25 1523.1.3. Generation of KRB_AS_REP message ........................... 25 1533.1.4. Generation of KRB_ERROR message ............................ 28 1543.1.5. Receipt of KRB_AS_REP message .............................. 28 1553.1.6. Receipt of KRB_ERROR message ............................... 29 1563.2. The Client/Server Authentication Exchange .................... 30 1573.2.1. The KRB_AP_REQ message ..................................... 30 1583.2.2. Generation of a KRB_AP_REQ message ......................... 30 1593.2.3. Receipt of KRB_AP_REQ message .............................. 31 1603.2.4. Generation of a KRB_AP_REP message ......................... 33 1613.2.5. Receipt of KRB_AP_REP message .............................. 33 1623.2.6. Using the encryption key ................................... 34 1633.3. The Ticket-Granting Service (TGS) Exchange ................... 34 1643.3.1. Generation of KRB_TGS_REQ message .......................... 36 1653.3.2. Receipt of KRB_TGS_REQ message ............................. 37 166 167 168 169February 2004 [Page 3] 170 171 172 173 174 175Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 176 177 1783.3.3. Generation of KRB_TGS_REP message .......................... 38 1793.3.3.1. Checking for revoked tickets ............................. 40 1803.3.3.2. Encoding the transited field ............................. 41 1813.3.4. Receipt of KRB_TGS_REP message ............................. 42 1823.4. The KRB_SAFE Exchange ........................................ 43 1833.4.1. Generation of a KRB_SAFE message ........................... 43 1843.4.2. Receipt of KRB_SAFE message ................................ 43 1853.5. The KRB_PRIV Exchange ........................................ 44 1863.5.1. Generation of a KRB_PRIV message ........................... 45 1873.5.2. Receipt of KRB_PRIV message ................................ 45 1883.6. The KRB_CRED Exchange ........................................ 46 1893.6.1. Generation of a KRB_CRED message ........................... 46 1903.6.2. Receipt of KRB_CRED message ................................ 47 1913.7. User-to-User Authentication Exchanges ........................ 47 1924. Encryption and Checksum Specifications ......................... 49 1935. Message Specifications ......................................... 50 1945.1. Specific Compatibility Notes on ASN.1 ........................ 52 1955.1.1. ASN.1 Distinguished Encoding Rules ......................... 52 1965.1.2. Optional Integer Fields .................................... 52 1975.1.3. Empty SEQUENCE OF Types .................................... 52 1985.1.4. Unrecognized Tag Numbers ................................... 53 1995.1.5. Tag Numbers Greater Than 30 ................................ 53 2005.2. Basic Kerberos Types ......................................... 53 2015.2.1. KerberosString ............................................. 53 2025.2.2. Realm and PrincipalName .................................... 55 2035.2.3. KerberosTime ............................................... 56 2045.2.4. Constrained Integer types .................................. 56 2055.2.5. HostAddress and HostAddresses .............................. 57 2065.2.6. AuthorizationData .......................................... 57 2075.2.6.1. IF-RELEVANT .............................................. 59 2085.2.6.2. KDCIssued ................................................ 59 2095.2.6.3. AND-OR ................................................... 60 2105.2.6.4. MANDATORY-FOR-KDC ........................................ 60 2115.2.7. PA-DATA .................................................... 61 2125.2.7.1. PA-TGS-REQ ............................................... 62 2135.2.7.2. Encrypted Timestamp Pre-authentication ................... 62 2145.2.7.3. PA-PW-SALT ............................................... 62 2155.2.7.4. PA-ETYPE-INFO ............................................ 63 2165.2.7.5. PA-ETYPE-INFO2 ........................................... 63 2175.2.8. KerberosFlags .............................................. 64 2185.2.9. Cryptosystem-related Types ................................. 65 2195.3. Tickets ...................................................... 67 2205.4. Specifications for the AS and TGS exchanges .................. 74 2215.4.1. KRB_KDC_REQ definition ..................................... 74 2225.4.2. KRB_KDC_REP definition ..................................... 82 2235.5. Client/Server (CS) message specifications .................... 85 2245.5.1. KRB_AP_REQ definition ...................................... 85 2255.5.2. KRB_AP_REP definition ...................................... 89 226 227 228 229February 2004 [Page 4] 230 231 232 233 234 235Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 236 237 2385.5.3. Error message reply ........................................ 90 2395.6. KRB_SAFE message specification ............................... 90 2405.6.1. KRB_SAFE definition ........................................ 90 2415.7. KRB_PRIV message specification ............................... 92 2425.7.1. KRB_PRIV definition ........................................ 92 2435.8. KRB_CRED message specification ............................... 92 2445.8.1. KRB_CRED definition ........................................ 93 2455.9. Error message specification .................................. 95 2465.9.1. KRB_ERROR definition ....................................... 95 2475.10. Application Tag Numbers ..................................... 97 2486. Naming Constraints ............................................. 98 2496.1. Realm Names .................................................. 98 2506.2. Principal Names .............................................. 99 2516.2.1. Name of server principals .................................. 101 2527. Constants and other defined values ............................. 101 2537.1. Host address types ........................................... 101 2547.2. KDC messaging - IP Transports ................................ 103 2557.2.1. UDP/IP transport ........................................... 103 2567.2.2. TCP/IP transport ........................................... 103 2577.2.3. KDC Discovery on IP Networks ............................... 104 2587.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ....... 105 2597.2.3.2. Specifying KDC Location information with DNS SRV 260 records ..................................................... 105 2617.2.3.3. KDC Discovery for Domain Style Realm Names on IP 262 Networks .................................................... 106 2637.3. Name of the TGS .............................................. 106 2647.4. OID arc for KerberosV5 ....................................... 106 2657.5. Protocol constants and associated values ..................... 106 2667.5.1. Key usage numbers .......................................... 107 2677.5.2. PreAuthentication Data Types 268 ............................................................. 108 2697.5.3. Address Types 270 ............................................................. 109 2717.5.4. Authorization Data Types 272 ............................................................. 109 2737.5.5. Transited Encoding Types 274 ............................................................. 109 2757.5.6. Protocol Version Number 276 ............................................................. 110 2777.5.7. Kerberos Message Types 278 ............................................................. 110 2797.5.8. Name Types 280 ............................................................. 110 2817.5.9. Error Codes 282 ............................................................. 110 2838. Interoperability requirements .................................. 112 2848.1. Specification 2 .............................................. 112 2858.2. Recommended KDC values ....................................... 115 286 287 288 289February 2004 [Page 5] 290 291 292 293 294 295Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 296 297 2989. IANA considerations ............................................ 115 29910. Security Considerations ....................................... 116 30011. Author's Addresses ............................................ 120 30112. Acknowledgements .............................................. 121 30213. REFERENCES .................................................... 122 30313.1 NORMATIVE REFERENCES ......................................... 122 30413.2 INFORMATIVE REFERENCES ....................................... 123 30514. Copyright Statement ........................................... 124 30615. Intellectual Property ......................................... 125 307A. ASN.1 module ................................................... 125 308B. Changes since RFC-1510 ......................................... 133 309END NOTES ......................................................... 136 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349February 2004 [Page 6] 350 351 352 353Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 354 355 3561. Introduction 357 358 Kerberos provides a means of verifying the identities of 359 principals, (e.g. a workstation user or a network server) on an 360 open (unprotected) network. This is accomplished without relying 361 on assertions by the host operating system, without basing trust 362 on host addresses, without requiring physical security of all the 363 hosts on the network, and under the assumption that packets 364 traveling along the network can be read, modified, and inserted at 365 will[1]. Kerberos performs authentication under these conditions 366 as a trusted third-party authentication service by using 367 conventional (shared secret key [2]) cryptography. Kerberos 368 extensions (outside the scope of this document) can provide for 369 the use of public key cryptography during certain phases of the 370 authentication protocol [@RFCE: if PKINIT advances concurrently 371 include reference to the RFC here]. Such extensions support 372 Kerberos authentication for users registered with public key 373 certification authorities and provide certain benefits of public 374 key cryptography in situations where they are needed. 375 376 The basic Kerberos authentication process proceeds as follows: A 377 client sends a request to the authentication server (AS) 378 requesting "credentials" for a given server. The AS responds with 379 these credentials, encrypted in the client's key. The credentials 380 consist of a "ticket" for the server and a temporary encryption 381 key (often called a "session key"). The client transmits the 382 ticket (which contains the client's identity and a copy of the 383 session key, all encrypted in the server's key) to the server. The 384 session key (now shared by the client and server) is used to 385 authenticate the client, and may optionally be used to 386 authenticate the server. It may also be used to encrypt further 387 communication between the two parties or to exchange a separate 388 sub-session key to be used to encrypt further communication. 389 390 Implementation of the basic protocol consists of one or more 391 authentication servers running on physically secure hosts. The 392 authentication servers maintain a database of principals (i.e., 393 users and servers) and their secret keys. Code libraries provide 394 encryption and implement the Kerberos protocol. In order to add 395 authentication to its transactions, a typical network application 396 adds calls to the Kerberos library directly or through the Generic 397 Security Services Application Programming Interface, GSSAPI, 398 described in separate document [ref to GSSAPI RFC]. These calls 399 result in the transmission of the necessary messages to achieve 400 authentication. 401 402 The Kerberos protocol consists of several sub-protocols (or 403 exchanges). There are two basic methods by which a client can ask 404 405 406 407February 2004 [Page 7] 408 409 410 411 412 413Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 414 415 416 a Kerberos server for credentials. In the first approach, the 417 client sends a cleartext request for a ticket for the desired 418 server to the AS. The reply is sent encrypted in the client's 419 secret key. Usually this request is for a ticket-granting ticket 420 (TGT) which can later be used with the ticket-granting server 421 (TGS). In the second method, the client sends a request to the 422 TGS. The client uses the TGT to authenticate itself to the TGS in 423 the same manner as if it were contacting any other application 424 server that requires Kerberos authentication. The reply is 425 encrypted in the session key from the TGT. Though the protocol 426 specification describes the AS and the TGS as separate servers, 427 they are implemented in practice as different protocol entry 428 points within a single Kerberos server. 429 430 Once obtained, credentials may be used to verify the identity of 431 the principals in a transaction, to ensure the integrity of 432 messages exchanged between them, or to preserve privacy of the 433 messages. The application is free to choose whatever protection 434 may be necessary. 435 436 To verify the identities of the principals in a transaction, the 437 client transmits the ticket to the application server. Since the 438 ticket is sent "in the clear" (parts of it are encrypted, but this 439 encryption doesn't thwart replay) and might be intercepted and 440 reused by an attacker, additional information is sent to prove 441 that the message originated with the principal to whom the ticket 442 was issued. This information (called the authenticator) is 443 encrypted in the session key, and includes a timestamp. The 444 timestamp proves that the message was recently generated and is 445 not a replay. Encrypting the authenticator in the session key 446 proves that it was generated by a party possessing the session 447 key. Since no one except the requesting principal and the server 448 know the session key (it is never sent over the network in the 449 clear) this guarantees the identity of the client. 450 451 The integrity of the messages exchanged between principals can 452 also be guaranteed using the session key (passed in the ticket and 453 contained in the credentials). This approach provides detection of 454 both replay attacks and message stream modification attacks. It is 455 accomplished by generating and transmitting a collision-proof 456 checksum (elsewhere called a hash or digest function) of the 457 client's message, keyed with the session key. Privacy and 458 integrity of the messages exchanged between principals can be 459 secured by encrypting the data to be passed using the session key 460 contained in the ticket or the sub-session key found in the 461 authenticator. 462 463 The authentication exchanges mentioned above require read-only 464 465 466 467February 2004 [Page 8] 468 469 470 471 472 473Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 474 475 476 access to the Kerberos database. Sometimes, however, the entries 477 in the database must be modified, such as when adding new 478 principals or changing a principal's key. This is done using a 479 protocol between a client and a third Kerberos server, the 480 Kerberos Administration Server (KADM). There is also a protocol 481 for maintaining multiple copies of the Kerberos database. Neither 482 of these protocols are described in this document. 483 4841.1. Cross-realm operation 485 486 The Kerberos protocol is designed to operate across organizational 487 boundaries. A client in one organization can be authenticated to a 488 server in another. Each organization wishing to run a Kerberos 489 server establishes its own "realm". The name of the realm in which 490 a client is registered is part of the client's name, and can be 491 used by the end-service to decide whether to honor a request. 492 493 By establishing "inter-realm" keys, the administrators of two 494 realms can allow a client authenticated in the local realm to 495 prove its identity to servers in other realms[3]. The exchange of 496 inter-realm keys (a separate key may be used for each direction) 497 registers the ticket-granting service of each realm as a principal 498 in the other realm. A client is then able to obtain a ticket- 499 granting ticket for the remote realm's ticket-granting service 500 from its local realm. When that ticket-granting ticket is used, 501 the remote ticket-granting service uses the inter-realm key (which 502 usually differs from its own normal TGS key) to decrypt the 503 ticket-granting ticket, and is thus certain that it was issued by 504 the client's own TGS. Tickets issued by the remote ticket-granting 505 service will indicate to the end-service that the client was 506 authenticated from another realm. 507 508 A realm is said to communicate with another realm if the two 509 realms share an inter-realm key, or if the local realm shares an 510 inter-realm key with an intermediate realm that communicates with 511 the remote realm. An authentication path is the sequence of 512 intermediate realms that are transited in communicating from one 513 realm to another. 514 515 Realms may be organized hierarchically. Each realm shares a key 516 with its parent and a different key with each child. If an inter- 517 realm key is not directly shared by two realms, the hierarchical 518 organization allows an authentication path to be easily 519 constructed. If a hierarchical organization is not used, it may be 520 necessary to consult a database in order to construct an 521 authentication path between realms. 522 523 Although realms are typically hierarchical, intermediate realms 524 525 526 527February 2004 [Page 9] 528 529 530 531 532 533Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 534 535 536 may be bypassed to achieve cross-realm authentication through 537 alternate authentication paths (these might be established to make 538 communication between two realms more efficient). It is important 539 for the end-service to know which realms were transited when 540 deciding how much faith to place in the authentication process. To 541 facilitate this decision, a field in each ticket contains the 542 names of the realms that were involved in authenticating the 543 client. 544 545 The application server is ultimately responsible for accepting or 546 rejecting authentication and SHOULD check the transited field. The 547 application server may choose to rely on the KDC for the 548 application server's realm to check the transited field. The 549 application server's KDC will set the TRANSITED-POLICY-CHECKED 550 flag in this case. The KDCs for intermediate realms may also check 551 the transited field as they issue ticket-granting tickets for 552 other realms, but they are encouraged not to do so. A client may 553 request that the KDCs not check the transited field by setting the 554 DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this flag. 555 5561.2. Choosing a principal with which to communicate 557 558 The Kerberos protocol provides the means for verifying (subject to 559 the assumptions in 1.5) that the entity with which one 560 communicates is the same entity that was registered with the KDC 561 using the claimed identity (principal name). It is still necessary 562 to determine whether that identity corresponds to the entity with 563 which one intends to communicate. 564 565 When appropriate data has been exchanged in advance, this 566 determination may be performed syntactically by the application 567 based on the application protocol specification, information 568 provided by the user, and configuration files. For example, the 569 server principal name (including realm) for a telnet server might 570 be derived from the user specified host name (from the telnet 571 command line), the "host/" prefix specified in the application 572 protocol specification, and a mapping to a Kerberos realm derived 573 syntactically from the domain part of the specified hostname and 574 information from the local Kerberos realms database. 575 576 One can also rely on trusted third parties to make this 577 determination, but only when the data obtained from the third 578 party is suitably integrity protected while resident on the third 579 party server and when transmitted. Thus, for example, one should 580 not rely on an unprotected domain name system record to map a host 581 alias to the primary name of a server, accepting the primary name 582 as the party one intends to contact, since an attacker can modify 583 the mapping and impersonate the party with which one intended to 584 585 586 587February 2004 [Page 10] 588 589 590 591 592 593Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 594 595 596 communicate. 597 598 Implementations of Kerberos and protocols based on Kerberos MUST 599 NOT use insecure DNS queries to canonicalize the hostname 600 components of the service principal names (i.e. MUST NOT use 601 insecure DNS queries to map one name to another to determine the 602 host part of the principal name with which one is to communicate). 603 In an environment without secure name service, application authors 604 MAY append a statically configured domain name to unqualified 605 hostnames before passing the name to the security mechanisms, but 606 should do no more than that. Secure name service facilities, if 607 available, might be trusted for hostname canonicalization, but 608 such canonicalization by the client SHOULD NOT be required by KDC 609 implementations. 610 611 Implementation note: Many current implementations do some degree 612 of canonicalization of the provided service name, often using DNS 613 even though it creates security problems. However there is no 614 consistency among implementations about whether the service name 615 is case folded to lower case or whether reverse resolution is 616 used. To maximize interoperability and security, applications 617 SHOULD provide security mechanisms with names which result from 618 folding the user-entered name to lower case, without performing 619 any other modifications or canonicalization. 620 6211.3. Authorization 622 623 As an authentication service, Kerberos provides a means of 624 verifying the identity of principals on a network. Authentication 625 is usually useful primarily as a first step in the process of 626 authorization, determining whether a client may use a service, 627 which objects the client is allowed to access, and the type of 628 access allowed for each. Kerberos does not, by itself, provide 629 authorization. Possession of a client ticket for a service 630 provides only for authentication of the client to that service, 631 and in the absence of a separate authorization procedure, it 632 should not be considered by an application as authorizing the use 633 of that service. 634 635 Such separate authorization methods MAY be implemented as 636 application specific access control functions and may utilize 637 files on the application server, or on separately issued 638 authorization credentials such as those based on proxies [Neu93], 639 or on other authorization services. Separately authenticated 640 authorization credentials MAY be embedded in a ticket's 641 authorization data when encapsulated by the KDC-issued 642 authorization data element. 643 644 645 646 647February 2004 [Page 11] 648 649 650 651 652 653Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 654 655 656 Applications should not accept the mere issuance of a service 657 ticket by the Kerberos server (even by a modified Kerberos server) 658 as granting authority to use the service, since such applications 659 may become vulnerable to the bypass of this authorization check in 660 an environment if they interoperate with other KDCs or where other 661 options for application authentication are provided. 662 6631.4. Extending Kerberos Without Breaking Interoperability 664 665 As the deployed base of Kerberos implementations grows, extending 666 Kerberos becomes more important. Unfortunately some extensions to 667 the existing Kerberos protocol create interoperability issues 668 because of uncertainty regarding the treatment of certain 669 extensibility options by some implementations. This section 670 includes guidelines that will enable future implementations to 671 maintain interoperability. 672 673 Kerberos provides a general mechanism for protocol extensibility. 674 Some protocol messages contain typed holes -- sub-messages that 675 contain an octet-string along with an integer that defines how to 676 interpret the octet-string. The integer types are registered 677 centrally, but can be used both for vendor extensions and for 678 extensions standardized through the IETF. 679 680 In this document, the word "extension" means an extension by 681 defining a new type to insert into an existing typed hole in a 682 protocol message. It does not mean extension by addition of new 683 fields to ASN.1 types, unless explicitly indicated otherwise in 684 the text. 685 6861.4.1. Compatibility with RFC 1510 687 688 It is important to note that existing Kerberos message formats can 689 not be readily extended by adding fields to the ASN.1 types. 690 Sending additional fields often results in the entire message 691 being discarded without an error indication. Future versions of 692 this specification will provide guidelines to ensure that ASN.1 693 fields can be added without creating an interoperability problem. 694 695 In the meantime, all new or modified implementations of Kerberos 696 that receive an unknown message extension SHOULD preserve the 697 encoding of the extension but otherwise ignore the presence of the 698 extension. Recipients MUST NOT decline a request simply because an 699 extension is present. 700 701 There is one exception to this rule. If an unknown authorization 702 data element type is received by a server other than the ticket 703 granting service either in an AP-REQ or in a ticket contained in 704 705 706 707February 2004 [Page 12] 708 709 710 711 712 713Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 714 715 716 an AP-REQ, then authentication MUST fail. One of the primary uses 717 of authorization data is to restrict the use of the ticket. If the 718 service cannot determine whether the restriction applies to that 719 service then a security weakness may result if the ticket can be 720 used for that service. Authorization elements that are optional 721 SHOULD be enclosed in the AD-IF-RELEVANT element. 722 723 The ticket granting service MUST ignore but propagate to 724 derivative tickets any unknown authorization data types, unless 725 those data types are embedded in a MANDATORY-FOR-KDC element, in 726 which case the request will be rejected. This behavior is 727 appropriate because requiring that the ticket granting service 728 understand unknown authorization data types would require that KDC 729 software be upgraded to understand new application-level 730 restrictions before applications used these restrictions, 731 decreasing the utility of authorization data as a mechanism for 732 restricting the use of tickets. No security problem is created 733 because services to which the tickets are issued will verify the 734 authorization data. 735 736 Implementation note: Many RFC 1510 implementations ignore unknown 737 authorization data elements. Depending on these implementations to 738 honor authorization data restrictions may create a security 739 weakness. 740 7411.4.2. Sending Extensible Messages 742 743 Care must be taken to ensure that old implementations can 744 understand messages sent to them even if they do not understand an 745 extension that is used. Unless the sender knows an extension is 746 supported, the extension cannot change the semantics of the core 747 message or previously defined extensions. 748 749 For example, an extension including key information necessary to 750 decrypt the encrypted part of a KDC-REP could only be used in 751 situations where the recipient was known to support the extension. 752 Thus when designing such extensions it is important to provide a 753 way for the recipient to notify the sender of support for the 754 extension. For example in the case of an extension that changes 755 the KDC-REP reply key, the client could indicate support for the 756 extension by including a padata element in the AS-REQ sequence. 757 The KDC should only use the extension if this padata element is 758 present in the AS-REQ. Even if policy requires the use of the 759 extension, it is better to return an error indicating that the 760 extension is required than to use the extension when the recipient 761 may not support it; debugging why implementations do not 762 interoperate is easier when errors are returned. 763 764 765 766 767February 2004 [Page 13] 768 769 770 771 772 773Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 774 775 7761.5. Environmental assumptions 777 778 Kerberos imposes a few assumptions on the environment in which it 779 can properly function: 780 781 * "Denial of service" attacks are not solved with Kerberos. There 782 are places in the protocols where an intruder can prevent an 783 application from participating in the proper authentication steps. 784 Detection and solution of such attacks (some of which can appear 785 to be not-uncommon "normal" failure modes for the system) is 786 usually best left to the human administrators and users. 787 788 * Principals MUST keep their secret keys secret. If an intruder 789 somehow steals a principal's key, it will be able to masquerade as 790 that principal or impersonate any server to the legitimate 791 principal. 792 793 * "Password guessing" attacks are not solved by Kerberos. If a user 794 chooses a poor password, it is possible for an attacker to 795 successfully mount an offline dictionary attack by repeatedly 796 attempting to decrypt, with successive entries from a dictionary, 797 messages obtained which are encrypted under a key derived from the 798 user's password. 799 800 * Each host on the network MUST have a clock which is "loosely 801 synchronized" to the time of the other hosts; this synchronization 802 is used to reduce the bookkeeping needs of application servers 803 when they do replay detection. The degree of "looseness" can be 804 configured on a per-server basis, but is typically on the order of 805 5 minutes. If the clocks are synchronized over the network, the 806 clock synchronization protocol MUST itself be secured from network 807 attackers. 808 809 * Principal identifiers are not recycled on a short-term basis. A 810 typical mode of access control will use access control lists 811 (ACLs) to grant permissions to particular principals. If a stale 812 ACL entry remains for a deleted principal and the principal 813 identifier is reused, the new principal will inherit rights 814 specified in the stale ACL entry. By not re-using principal 815 identifiers, the danger of inadvertent access is removed. 816 8171.6. Glossary of terms 818 819 Below is a list of terms used throughout this document. 820 821 Authentication 822 Verifying the claimed identity of a principal. 823 824 825 826 827February 2004 [Page 14] 828 829 830 831 832 833Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 834 835 836 Authentication header 837 A record containing a Ticket and an Authenticator to be presented 838 to a server as part of the authentication process. 839 840 Authentication path 841 A sequence of intermediate realms transited in the authentication 842 process when communicating from one realm to another. 843 844 Authenticator 845 A record containing information that can be shown to have been 846 recently generated using the session key known only by the client 847 and server. 848 849 Authorization 850 The process of determining whether a client may use a service, 851 which objects the client is allowed to access, and the type of 852 access allowed for each. 853 854 Capability 855 A token that grants the bearer permission to access an object or 856 service. In Kerberos, this might be a ticket whose use is 857 restricted by the contents of the authorization data field, but 858 which lists no network addresses, together with the session key 859 necessary to use the ticket. 860 861 Ciphertext 862 The output of an encryption function. Encryption transforms 863 plaintext into ciphertext. 864 865 Client 866 A process that makes use of a network service on behalf of a user. 867 Note that in some cases a Server may itself be a client of some 868 other server (e.g. a print server may be a client of a file 869 server). 870 871 Credentials 872 A ticket plus the secret session key necessary to successfully use 873 that ticket in an authentication exchange. 874 875 Encryption Type (etype) 876 When associated with encrypted data, an encryption type identifies 877 the algorithm used to encrypt the data and is used to select the 878 appropriate algorithm for decrypting the data. Encryption type 879 tags are communicated in other messages to enumerate algorithms 880 that are desired, supported, preferred, or allowed to be used for 881 encryption of data between parties. This preference is combined 882 with local information and policy to select an algorithm to be 883 used. 884 885 886 887February 2004 [Page 15] 888 889 890 891 892 893Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 894 895 896 KDC 897 Key Distribution Center, a network service that supplies tickets 898 and temporary session keys; or an instance of that service or the 899 host on which it runs. The KDC services both initial ticket and 900 ticket-granting ticket requests. The initial ticket portion is 901 sometimes referred to as the Authentication Server (or service). 902 The ticket-granting ticket portion is sometimes referred to as the 903 ticket-granting server (or service). 904 905 Kerberos 906 The name given to the Project Athena's authentication service, the 907 protocol used by that service, or the code used to implement the 908 authentication service. The name is adopted from the three-headed 909 dog which guards Hades. 910 911 Key Version Number (kvno) 912 A tag associated with encrypted data identifies which key was used 913 for encryption when a long lived key associated with a principal 914 changes over time. It is used during the transition to a new key 915 so that the party decrypting a message can tell whether the data 916 was encrypted using the old or the new key. 917 918 Plaintext 919 The input to an encryption function or the output of a decryption 920 function. Decryption transforms ciphertext into plaintext. 921 922 Principal 923 A named client or server entity that participates in a network 924 communication, with one name that is considered canonical. 925 926 Principal identifier 927 The canonical name used to uniquely identify each different 928 principal. 929 930 Seal 931 To encipher a record containing several fields in such a way that 932 the fields cannot be individually replaced without either 933 knowledge of the encryption key or leaving evidence of tampering. 934 935 Secret key 936 An encryption key shared by a principal and the KDC, distributed 937 outside the bounds of the system, with a long lifetime. In the 938 case of a human user's principal, the secret key MAY be derived 939 from a password. 940 941 Server 942 A particular Principal which provides a resource to network 943 clients. The server is sometimes referred to as the Application 944 945 946 947February 2004 [Page 16] 948 949 950 951 952 953Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 954 955 956 Server. 957 958 Service 959 A resource provided to network clients; often provided by more 960 than one server (for example, remote file service). 961 962 Session key 963 A temporary encryption key used between two principals, with a 964 lifetime limited to the duration of a single login "session". In 965 the Kerberos system, a session key is generated by the KDC. The 966 session key is distinct from the sub-session key, described next.. 967 968 Sub-session key 969 A temporary encryption key used between two principals, selected 970 and exchanged by the principals using the session key, and with a 971 lifetime limited to the duration of a single association. The sub- 972 session key is also referred to as the subkey. 973 974 Ticket 975 A record that helps a client authenticate itself to a server; it 976 contains the client's identity, a session key, a timestamp, and 977 other information, all sealed using the server's secret key. It 978 only serves to authenticate a client when presented along with a 979 fresh Authenticator. 980 981 9822. Ticket flag uses and requests 983 984 Each Kerberos ticket contains a set of flags which are used to 985 indicate attributes of that ticket. Most flags may be requested by 986 a client when the ticket is obtained; some are automatically 987 turned on and off by a Kerberos server as required. The following 988 sections explain what the various flags mean and give examples of 989 reasons to use them. With the exception of the INVALID flag 990 clients MUST ignore ticket flags that are not recognized. KDCs 991 MUST ignore KDC options that are not recognized. Some 992 implementations of RFC 1510 are known to reject unknown KDC 993 options, so clients may need to resend a request without new KDC 994 options if the request was rejected when sent with options added 995 since RFC 1510. Since new KDCs will ignore unknown options, 996 clients MUST confirm that the ticket returned by the KDC meets 997 their needs. 998 999 Note that it is not, in general, possible to determine whether an 1000 option was not honored because it was not understood or because it 1001 was rejected either through configuration or policy. When adding a 1002 new option to the Kerberos protocol, designers should consider 1003 whether the distinction is important for their option. In cases 1004 1005 1006 1007February 2004 [Page 17] 1008 1009 1010 1011 1012 1013Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1014 1015 1016 where it is, a mechanism for the KDC to return an indication that 1017 the option was understood but rejected needs to be provided in the 1018 specification of the option. Often in such cases, the mechanism 1019 needs to be broad enough to permit an error or reason to be 1020 returned. 1021 10222.1. Initial, pre-authenticated, and hardware authenticated tickets 1023 1024 The INITIAL flag indicates that a ticket was issued using the AS 1025 protocol, rather than issued based on a ticket-granting ticket. 1026 Application servers that want to require the demonstrated 1027 knowledge of a client's secret key (e.g. a password-changing 1028 program) can insist that this flag be set in any tickets they 1029 accept, and thus be assured that the client's key was recently 1030 presented to the application client. 1031 1032 The PRE-AUTHENT and HW-AUTHENT flags provide additional 1033 information about the initial authentication, regardless of 1034 whether the current ticket was issued directly (in which case 1035 INITIAL will also be set) or issued on the basis of a ticket- 1036 granting ticket (in which case the INITIAL flag is clear, but the 1037 PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 1038 ticket-granting ticket). 1039 10402.2. Invalid tickets 1041 1042 The INVALID flag indicates that a ticket is invalid. Application 1043 servers MUST reject tickets which have this flag set. A postdated 1044 ticket will be issued in this form. Invalid tickets MUST be 1045 validated by the KDC before use, by presenting them to the KDC in 1046 a TGS request with the VALIDATE option specified. The KDC will 1047 only validate tickets after their starttime has passed. The 1048 validation is required so that postdated tickets which have been 1049 stolen before their starttime can be rendered permanently invalid 1050 (through a hot-list mechanism) (see section 3.3.3.1). 1051 10522.3. Renewable tickets 1053 1054 Applications may desire to hold tickets which can be valid for 1055 long periods of time. However, this can expose their credentials 1056 to potential theft for equally long periods, and those stolen 1057 credentials would be valid until the expiration time of the 1058 ticket(s). Simply using short-lived tickets and obtaining new ones 1059 periodically would require the client to have long-term access to 1060 its secret key, an even greater risk. Renewable tickets can be 1061 used to mitigate the consequences of theft. Renewable tickets have 1062 two "expiration times": the first is when the current instance of 1063 the ticket expires, and the second is the latest permissible value 1064 1065 1066 1067February 2004 [Page 18] 1068 1069 1070 1071 1072 1073Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1074 1075 1076 for an individual expiration time. An application client must 1077 periodically (i.e. before it expires) present a renewable ticket 1078 to the KDC, with the RENEW option set in the KDC request. The KDC 1079 will issue a new ticket with a new session key and a later 1080 expiration time. All other fields of the ticket are left 1081 unmodified by the renewal process. When the latest permissible 1082 expiration time arrives, the ticket expires permanently. At each 1083 renewal, the KDC MAY consult a hot-list to determine if the ticket 1084 had been reported stolen since its last renewal; it will refuse to 1085 renew such stolen tickets, and thus the usable lifetime of stolen 1086 tickets is reduced. 1087 1088 The RENEWABLE flag in a ticket is normally only interpreted by the 1089 ticket-granting service (discussed below in section 3.3). It can 1090 usually be ignored by application servers. However, some 1091 particularly careful application servers MAY disallow renewable 1092 tickets. 1093 1094 If a renewable ticket is not renewed by its expiration time, the 1095 KDC will not renew the ticket. The RENEWABLE flag is reset by 1096 default, but a client MAY request it be set by setting the 1097 RENEWABLE option in the KRB_AS_REQ message. If it is set, then the 1098 renew-till field in the ticket contains the time after which the 1099 ticket may not be renewed. 1100 11012.4. Postdated tickets 1102 1103 Applications may occasionally need to obtain tickets for use much 1104 later, e.g. a batch submission system would need tickets to be 1105 valid at the time the batch job is serviced. However, it is 1106 dangerous to hold valid tickets in a batch queue, since they will 1107 be on-line longer and more prone to theft. Postdated tickets 1108 provide a way to obtain these tickets from the KDC at job 1109 submission time, but to leave them "dormant" until they are 1110 activated and validated by a further request of the KDC. If a 1111 ticket theft were reported in the interim, the KDC would refuse to 1112 validate the ticket, and the thief would be foiled. 1113 1114 The MAY-POSTDATE flag in a ticket is normally only interpreted by 1115 the ticket-granting service. It can be ignored by application 1116 servers. This flag MUST be set in a ticket-granting ticket in 1117 order to issue a postdated ticket based on the presented ticket. 1118 It is reset by default; it MAY be requested by a client by setting 1119 the ALLOW-POSTDATE option in the KRB_AS_REQ message. This flag 1120 does not allow a client to obtain a postdated ticket-granting 1121 ticket; postdated ticket-granting tickets can only by obtained by 1122 requesting the postdating in the KRB_AS_REQ message. The life 1123 (endtime-starttime) of a postdated ticket will be the remaining 1124 1125 1126 1127February 2004 [Page 19] 1128 1129 1130 1131 1132 1133Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1134 1135 1136 life of the ticket-granting ticket at the time of the request, 1137 unless the RENEWABLE option is also set, in which case it can be 1138 the full life (endtime-starttime) of the ticket-granting ticket. 1139 The KDC MAY limit how far in the future a ticket may be postdated. 1140 1141 The POSTDATED flag indicates that a ticket has been postdated. The 1142 application server can check the authtime field in the ticket to 1143 see when the original authentication occurred. Some services MAY 1144 choose to reject postdated tickets, or they may only accept them 1145 within a certain period after the original authentication. When 1146 the KDC issues a POSTDATED ticket, it will also be marked as 1147 INVALID, so that the application client MUST present the ticket to 1148 the KDC to be validated before use. 1149 11502.5. Proxiable and proxy tickets 1151 1152 At times it may be necessary for a principal to allow a service to 1153 perform an operation on its behalf. The service must be able to 1154 take on the identity of the client, but only for a particular 1155 purpose. A principal can allow a service to take on the 1156 principal's identity for a particular purpose by granting it a 1157 proxy. 1158 1159 The process of granting a proxy using the proxy and proxiable 1160 flags is used to provide credentials for use with specific 1161 services. Though conceptually also a proxy, users wishing to 1162 delegate their identity in a form usable for all purpose MUST use 1163 the ticket forwarding mechanism described in the next section to 1164 forward a ticket-granting ticket. 1165 1166 The PROXIABLE flag in a ticket is normally only interpreted by the 1167 ticket-granting service. It can be ignored by application servers. 1168 When set, this flag tells the ticket-granting server that it is OK 1169 to issue a new ticket (but not a ticket-granting ticket) with a 1170 different network address based on this ticket. This flag is set 1171 if requested by the client on initial authentication. By default, 1172 the client will request that it be set when requesting a ticket- 1173 granting ticket, and reset when requesting any other ticket. 1174 1175 This flag allows a client to pass a proxy to a server to perform a 1176 remote request on its behalf (e.g. a print service client can give 1177 the print server a proxy to access the client's files on a 1178 particular file server in order to satisfy a print request). 1179 1180 In order to complicate the use of stolen credentials, Kerberos 1181 tickets are usually valid from only those network addresses 1182 specifically included in the ticket[4]. When granting a proxy, the 1183 client MUST specify the new network address from which the proxy 1184 1185 1186 1187February 2004 [Page 20] 1188 1189 1190 1191 1192 1193Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1194 1195 1196 is to be used, or indicate that the proxy is to be issued for use 1197 from any address. 1198 1199 The PROXY flag is set in a ticket by the TGS when it issues a 1200 proxy ticket. Application servers MAY check this flag and at 1201 their option they MAY require additional authentication from the 1202 agent presenting the proxy in order to provide an audit trail. 1203 12042.6. Forwardable tickets 1205 1206 Authentication forwarding is an instance of a proxy where the 1207 service that is granted is complete use of the client's identity. 1208 An example where it might be used is when a user logs in to a 1209 remote system and wants authentication to work from that system as 1210 if the login were local. 1211 1212 The FORWARDABLE flag in a ticket is normally only interpreted by 1213 the ticket-granting service. It can be ignored by application 1214 servers. The FORWARDABLE flag has an interpretation similar to 1215 that of the PROXIABLE flag, except ticket-granting tickets may 1216 also be issued with different network addresses. This flag is 1217 reset by default, but users MAY request that it be set by setting 1218 the FORWARDABLE option in the AS request when they request their 1219 initial ticket-granting ticket. 1220 1221 This flag allows for authentication forwarding without requiring 1222 the user to enter a password again. If the flag is not set, then 1223 authentication forwarding is not permitted, but the same result 1224 can still be achieved if the user engages in the AS exchange 1225 specifying the requested network addresses and supplies a 1226 password. 1227 1228 The FORWARDED flag is set by the TGS when a client presents a 1229 ticket with the FORWARDABLE flag set and requests a forwarded 1230 ticket by specifying the FORWARDED KDC option and supplying a set 1231 of addresses for the new ticket. It is also set in all tickets 1232 issued based on tickets with the FORWARDED flag set. Application 1233 servers may choose to process FORWARDED tickets differently than 1234 non-FORWARDED tickets. 1235 1236 If addressless tickets are forwarded from one system to another, 1237 clients SHOULD still use this option to obtain a new TGT in order 1238 to have different session keys on the different systems. 1239 12402.7. Transited Policy Checking 1241 1242 In Kerberos, the application server is ultimately responsible for 1243 accepting or rejecting authentication and SHOULD check that only 1244 1245 1246 1247February 2004 [Page 21] 1248 1249 1250 1251 1252 1253Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1254 1255 1256 suitably trusted KDCs are relied upon to authenticate a principal. 1257 The transited field in the ticket identifies which realms (and 1258 thus which KDCs) were involved in the authentication process and 1259 an application server would normally check this field. If any of 1260 these are untrusted to authenticate the indicated client principal 1261 (probably determined by a realm-based policy), the authentication 1262 attempt MUST be rejected. The presence of trusted KDCs in this 1263 list does not provide any guarantee; an untrusted KDC may have 1264 fabricated the list. 1265 1266 While the end server ultimately decides whether authentication is 1267 valid, the KDC for the end server's realm MAY apply a realm 1268 specific policy for validating the transited field and accepting 1269 credentials for cross-realm authentication. When the KDC applies 1270 such checks and accepts such cross-realm authentication it will 1271 set the TRANSITED-POLICY-CHECKED flag in the service tickets it 1272 issues based on the cross-realm TGT. A client MAY request that the 1273 KDCs not check the transited field by setting the DISABLE- 1274 TRANSITED-CHECK flag. KDCs are encouraged but not required to 1275 honor this flag. 1276 1277 Application servers MUST either do the transited-realm checks 1278 themselves, or reject cross-realm tickets without TRANSITED- 1279 POLICY-CHECKED set. 1280 12812.8. OK as Delegate 1282 1283 For some applications a client may need to delegate authority to a 1284 server to act on its behalf in contacting other services. This 1285 requires that the client forward credentials to an intermediate 1286 server. The ability for a client to obtain a service ticket to a 1287 server conveys no information to the client about whether the 1288 server should be trusted to accept delegated credentials. The OK- 1289 AS-DELEGATE provides a way for a KDC to communicate local realm 1290 policy to a client regarding whether an intermediate server is 1291 trusted to accept such credentials. 1292 1293 The copy of the ticket flags in the encrypted part of the KDC 1294 reply may have the OK-AS-DELEGATE flag set to indicates to the 1295 client that the server specified in the ticket has been determined 1296 by policy of the realm to be a suitable recipient of delegation. 1297 A client can use the presence of this flag to help it make a 1298 decision whether to delegate credentials (either grant a proxy or 1299 a forwarded ticket-granting ticket) to this server. It is 1300 acceptable to ignore the value of this flag. When setting this 1301 flag, an administrator should consider the security and placement 1302 of the server on which the service will run, as well as whether 1303 the service requires the use of delegated credentials. 1304 1305 1306 1307February 2004 [Page 22] 1308 1309 1310 1311 1312 1313Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1314 1315 13162.9. Other KDC options 1317 1318 There are three additional options which MAY be set in a client's 1319 request of the KDC. 1320 13212.9.1. Renewable-OK 1322 1323 The RENEWABLE-OK option indicates that the client will accept a 1324 renewable ticket if a ticket with the requested life cannot 1325 otherwise be provided. If a ticket with the requested life cannot 1326 be provided, then the KDC MAY issue a renewable ticket with a 1327 renew-till equal to the requested endtime. The value of the renew- 1328 till field MAY still be adjusted by site-determined limits or 1329 limits imposed by the individual principal or server. 1330 13312.9.2. ENC-TKT-IN-SKEY 1332 1333 In its basic form the Kerberos protocol supports authentication in 1334 a client-server 1335 setting and is not well suited to authentication in a peer-to- 1336 peer environment because the long term key of the user does not 1337 remain on the workstation after initial login. Authentication of 1338 such peers may be supported by Kerberos in its user-to-user 1339 variant. The ENC-TKT-IN-SKEY option supports user-to-user 1340 authentication by allowing the KDC to issue a service ticket 1341 encrypted using the session key from another ticket-granting 1342 ticket issued to another user. The ENC-TKT-IN-SKEY option is 1343 honored only by the ticket-granting service. It indicates that the 1344 ticket to be issued for the end server is to be encrypted in the 1345 session key from the additional second ticket-granting ticket 1346 provided with the request. See section 3.3.3 for specific details. 1347 13482.9.3. Passwordless Hardware Authentication 1349 1350 The OPT-HARDWARE-AUTH option indicates that the client wishes to 1351 use some form of hardware authentication instead of or in addition 1352 to the client's password or other long-lived encryption key. OPT- 1353 HARDWARE-AUTH is honored only by the authentication service. If 1354 supported and allowed by policy, the KDC will return an errorcode 1355 KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to 1356 perform such authentication. 1357 13583. Message Exchanges 1359 1360 The following sections describe the interactions between network 1361 clients and servers and the messages involved in those exchanges. 1362 13633.1. The Authentication Service Exchange 1364 1365 1366 1367February 2004 [Page 23] 1368 1369 1370 1371 1372 1373Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1374 1375 1376 Summary 1377 1378 Message direction Message type Section 1379 1. Client to Kerberos KRB_AS_REQ 5.4.1 1380 2. Kerberos to client KRB_AS_REP or 5.4.2 1381 KRB_ERROR 5.9.1 1382 1383 The Authentication Service (AS) Exchange between the client and 1384 the Kerberos Authentication Server is initiated by a client when 1385 it wishes to obtain authentication credentials for a given server 1386 but currently holds no credentials. In its basic form, the 1387 client's secret key is used for encryption and decryption. This 1388 exchange is typically used at the initiation of a login session to 1389 obtain credentials for a Ticket-Granting Server which will 1390 subsequently be used to obtain credentials for other servers (see 1391 section 3.3) without requiring further use of the client's secret 1392 key. This exchange is also used to request credentials for 1393 services which must not be mediated through the Ticket-Granting 1394 Service, but rather require a principal's secret key, such as the 1395 password-changing service[5]. This exchange does not by itself 1396 provide any assurance of the identity of the user[6]. 1397 1398 The exchange consists of two messages: KRB_AS_REQ from the client 1399 to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for 1400 these messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 1401 1402 In the request, the client sends (in cleartext) its own identity 1403 and the identity of the server for which it is requesting 1404 credentials, other information about the credentials it is 1405 requesting, and a randomly generated nonce which can be used to 1406 detect replays, and to associate replies with the matching 1407 requests. This nonce MUST be generated randomly by the client and 1408 remembered for checking against the nonce in the expected reply. 1409 The response, KRB_AS_REP, contains a ticket for the client to 1410 present to the server, and a session key that will be shared by 1411 the client and the server. The session key and additional 1412 information are encrypted in the client's secret key. The 1413 encrypted part of the KRB_AS_REP message also contains the nonce 1414 which MUST be matched with the nonce from the KRB_AS_REQ message. 1415 1416 Without pre-authentication, the authentication server does not 1417 know whether the client is actually the principal named in the 1418 request. It simply sends a reply without knowing or caring whether 1419 they are the same. This is acceptable because nobody but the 1420 principal whose identity was given in the request will be able to 1421 use the reply. Its critical information is encrypted in that 1422 principal's key. However, an attacker can send a KRB_AS_REQ 1423 message to get known plaintext in order to attack the principal's 1424 1425 1426 1427February 2004 [Page 24] 1428 1429 1430 1431 1432 1433Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1434 1435 1436 key. Especially if the key is based on a password, this may create 1437 a security exposure. So, the initial request supports an optional 1438 field that can be used to pass additional information that might 1439 be needed for the initial exchange. This field SHOULD be used for 1440 pre-authentication as described in sections 3.1.1 and 5.2.7. 1441 1442 Various errors can occur; these are indicated by an error response 1443 (KRB_ERROR) instead of the KRB_AS_REP response. The error message 1444 is not encrypted. The KRB_ERROR message contains information which 1445 can be used to associate it with the message to which it replies. 1446 The contents of the KRB_ERROR message are not integrity-protected. 1447 As such, the client cannot detect replays, fabrications or 1448 modifications. A solution to this problem will be included in a 1449 future version of the protocol. 1450 14513.1.1. Generation of KRB_AS_REQ message 1452 1453 The client may specify a number of options in the initial request. 1454 Among these options are whether pre-authentication is to be 1455 performed; whether the requested ticket is to be renewable, 1456 proxiable, or forwardable; whether it should be postdated or allow 1457 postdating of derivative tickets; and whether a renewable ticket 1458 will be accepted in lieu of a non-renewable ticket if the 1459 requested ticket expiration date cannot be satisfied by a non- 1460 renewable ticket (due to configuration constraints). 1461 1462 The client prepares the KRB_AS_REQ message and sends it to the 1463 KDC. 1464 14653.1.2. Receipt of KRB_AS_REQ message 1466 1467 If all goes well, processing the KRB_AS_REQ message will result in 1468 the creation of a ticket for the client to present to the server. 1469 The format for the ticket is described in section 5.3. 1470 1471 Because Kerberos can run over unreliable transports such as UDP, 1472 the KDC MUST be prepared to retransmit responses in case they are 1473 lost. If a KDC receives a request identical to one it has recently 1474 successfully processed, the KDC MUST respond with a KRB_AS_REP 1475 message rather than a replay error. In order to reduce ciphertext 1476 given to a potential attacker, KDCs MAY send the same response 1477 generated when the request was first handled. KDCs MUST obey this 1478 replay behavior even if the actual transport in use is reliable. 1479 14803.1.3. Generation of KRB_AS_REP message 1481 1482 The authentication server looks up the client and server 1483 principals named in the KRB_AS_REQ in its database, extracting 1484 1485 1486 1487February 2004 [Page 25] 1488 1489 1490 1491 1492 1493Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1494 1495 1496 their respective keys. If the requested client principal named in 1497 the request is not known because it doesn't exist in the KDC's 1498 principal database, then an error message with a 1499 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 1500 1501 If required, the server pre-authenticates the request, and if the 1502 pre-authentication check fails, an error message with the code 1503 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is 1504 required, but was not present in the request, an error message 1505 with the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD- 1506 DATA object will be stored in the e-data field of the KRB-ERROR 1507 message to specify which pre-authentication mechanisms are 1508 acceptable. Usually this will include PA-ETYPE-INFO and/or PA- 1509 ETYPE-INFO2 elements as described below. If the server cannot 1510 accommodate any encryption type requested by the client, an error 1511 message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the 1512 KDC generates a 'random' session key[7]. 1513 1514 When responding to an AS request, if there are multiple encryption 1515 keys registered for a client in the Kerberos database, then the 1516 etype field from the AS request is used by the KDC to select the 1517 encryption method to be used to protect the encrypted part of the 1518 KRB_AS_REP message which is sent to the client. If there is more 1519 than one supported strong encryption type in the etype list, the 1520 KDC SHOULD use the first valid strong etype for which an 1521 encryption key is available. 1522 1523 When the user's key is generated from a password or pass phrase, 1524 the string-to-key function for the particular encryption key type 1525 is used, as specified in [@KCRYPTO]. The salt value and additional 1526 parameters for the string-to-key function have default values 1527 (specified by section 4 and by the encryption mechanism 1528 specification, respectively) that may be overridden by pre- 1529 authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA- 1530 ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of 1531 the resulting key only, these values should not be changed for 1532 password-based keys except when changing the principal's key. 1533 1534 When the AS server is to include pre-authentication data in a KRB- 1535 ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE- 1536 INFO, if the etype field of the client's AS-REQ lists at least one 1537 "newer" encryption type. Otherwise (when the etype field of the 1538 client's AS-REQ does not list any "newer" encryption types) it 1539 MUST send both, PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an 1540 entry for each enctype). A "newer" enctype is any enctype first 1541 officially specified concurrently with or subsequent to the issue 1542 of this RFC. The enctypes DES, 3DES or RC4 and any defined in 1543 [RFC1510] are not "newer" enctypes. 1544 1545 1546 1547February 2004 [Page 26] 1548 1549 1550 1551 1552 1553Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1554 1555 1556 It is not possible to reliably generate a user's key given a pass 1557 phrase without contacting the KDC, since it will not be known 1558 whether alternate salt or parameter values are required. 1559 1560 The KDC will attempt to assign the type of the random session key 1561 from the list of methods in the etype field. The KDC will select 1562 the appropriate type using the list of methods provided together 1563 with information from the Kerberos database indicating acceptable 1564 encryption methods for the application server. The KDC will not 1565 issue tickets with a weak session key encryption type. 1566 1567 If the requested start time is absent, indicates a time in the 1568 past, or is within the window of acceptable clock skew for the KDC 1569 and the POSTDATE option has not been specified, then the start 1570 time of the ticket is set to the authentication server's current 1571 time. If it indicates a time in the future beyond the acceptable 1572 clock skew, but the POSTDATED option has not been specified then 1573 the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the 1574 requested start time is checked against the policy of the local 1575 realm (the administrator might decide to prohibit certain types or 1576 ranges of postdated tickets), and if acceptable, the ticket's 1577 start time is set as requested and the INVALID flag is set in the 1578 new ticket. The postdated ticket MUST be validated before use by 1579 presenting it to the KDC after the start time has been reached. 1580 1581 The expiration time of the ticket will be set to the earlier of 1582 the requested endtime and a time determined by local policy, 1583 possibly determined using realm or principal specific factors. For 1584 example, the expiration time MAY be set to the earliest of the 1585 following: 1586 1587 * The expiration time (endtime) requested in the KRB_AS_REQ 1588 message. 1589 1590 * The ticket's start time plus the maximum allowable lifetime 1591 associated with the client principal from the authentication 1592 server's database. 1593 1594 * The ticket's start time plus the maximum allowable lifetime 1595 associated with the server principal. 1596 1597 * The ticket's start time plus the maximum lifetime set by the 1598 policy of the local realm. 1599 1600 If the requested expiration time minus the start time (as determined 1601 above) is less than a site-determined minimum lifetime, an error 1602 message with code KDC_ERR_NEVER_VALID is returned. If the requested 1603 expiration time for the ticket exceeds what was determined as above, 1604 1605 1606 1607February 2004 [Page 27] 1608 1609 1610 1611 1612 1613Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1614 1615 1616 and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' 1617 flag is set in the new ticket, and the renew-till value is set as if 1618 the 'RENEWABLE' option were requested (the field and option names are 1619 described fully in section 5.4.1). 1620 1621 If the RENEWABLE option has been requested or if the RENEWABLE-OK 1622 option has been set and a renewable ticket is to be issued, then the 1623 renew-till field MAY be set to the earliest of: 1624 1625 * Its requested value. 1626 1627 * The start time of the ticket plus the minimum of the two 1628 maximum renewable lifetimes associated with the principals' 1629 database entries. 1630 1631 * The start time of the ticket plus the maximum renewable 1632 lifetime set by the policy of the local realm. 1633 1634 The flags field of the new ticket will have the following options set 1635 if they have been requested and if the policy of the local realm 1636 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. 1637 If the new ticket is postdated (the start time is in the future), its 1638 INVALID flag will also be set. 1639 1640 If all of the above succeed, the server will encrypt the ciphertext 1641 part of the ticket using the encryption key extracted from the server 1642 principal's record in the Kerberos database using the encryption type 1643 associated with the server principal's key (this choice is NOT 1644 affected by the etype field in the request). It then formats a 1645 KRB_AS_REP message (see section 5.4.2), copying the addresses in the 1646 request into the caddr of the response, placing any required pre- 1647 authentication data into the padata of the response, and encrypts the 1648 ciphertext part in the client's key using an acceptable encryption 1649 method requested in the etype field of the request, or in some key 1650 specified by pre-authentication mechanisms being used. 1651 16523.1.4. Generation of KRB_ERROR message 1653 1654 Several errors can occur, and the Authentication Server responds 1655 by returning an error message, KRB_ERROR, to the client, with the 1656 error-code and e-text fields set to appropriate values. The error 1657 message contents and details are described in Section 5.9.1. 1658 16593.1.5. Receipt of KRB_AS_REP message 1660 1661 If the reply message type is KRB_AS_REP, then the client verifies 1662 that the cname and crealm fields in the cleartext portion of the 1663 reply match what it requested. If any padata fields are present, 1664 1665 1666 1667February 2004 [Page 28] 1668 1669 1670 1671 1672 1673Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1674 1675 1676 they may be used to derive the proper secret key to decrypt the 1677 message. The client decrypts the encrypted part of the response 1678 using its secret key, verifies that the nonce in the encrypted 1679 part matches the nonce it supplied in its request (to detect 1680 replays). It also verifies that the sname and srealm in the 1681 response match those in the request (or are otherwise expected 1682 values), and that the host address field is also correct. It then 1683 stores the ticket, session key, start and expiration times, and 1684 other information for later use. The last-req field (and the 1685 deprecated key-expiration field) from the encrypted part of the 1686 response MAY be checked to notify the user of impending key 1687 expiration. This enables the client program to suggest remedial 1688 action, such as a password change. 1689 1690 Upon validation of the KRB_AS_REP message (by checking the 1691 returned nonce against that sent in the KRB_AS_REQ message) the 1692 client knows that the current time on the KDC is that read from 1693 the authtime field of the encrypted part of the reply. The client 1694 can optionally use this value for clock synchronization in 1695 subsequent messages by recording with the ticket the difference 1696 (offset) between the authtime value and the local clock. This 1697 offset can then be used by the same user to adjust the time read 1698 from the system clock when generating messages [DGT96]. 1699 1700 This technique MUST be used when adjusting for clock skew instead 1701 of directly changing the system clock because the KDC reply is 1702 only authenticated to the user whose secret key was used, but not 1703 to the system or workstation. If the clock were adjusted, an 1704 attacker colluding with a user logging into a workstation could 1705 agree on a password, resulting in a KDC reply that would be 1706 correctly validated even though it did not originate from a KDC 1707 trusted by the workstation. 1708 1709 Proper decryption of the KRB_AS_REP message is not sufficient for 1710 the host to verify the identity of the user; the user and an 1711 attacker could cooperate to generate a KRB_AS_REP format message 1712 which decrypts properly but is not from the proper KDC. If the 1713 host wishes to verify the identity of the user, it MUST require 1714 the user to present application credentials which can be verified 1715 using a securely-stored secret key for the host. If those 1716 credentials can be verified, then the identity of the user can be 1717 assured. 1718 17193.1.6. Receipt of KRB_ERROR message 1720 1721 If the reply message type is KRB_ERROR, then the client interprets 1722 it as an error and performs whatever application-specific tasks 1723 are necessary to recover. 1724 1725 1726 1727February 2004 [Page 29] 1728 1729 1730 1731 1732 1733Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1734 1735 17363.2. The Client/Server Authentication Exchange 1737 1738 Summary 1739 Message direction Message type Section 1740 Client to Application server KRB_AP_REQ 5.5.1 1741 [optional] Application server to client KRB_AP_REP or 5.5.2 1742 KRB_ERROR 5.9.1 1743 1744 The client/server authentication (CS) exchange is used by network 1745 applications to authenticate the client to the server and vice 1746 versa. The client MUST have already acquired credentials for the 1747 server using the AS or TGS exchange. 1748 17493.2.1. The KRB_AP_REQ message 1750 1751 The KRB_AP_REQ contains authentication information which SHOULD be 1752 part of the first message in an authenticated transaction. It 1753 contains a ticket, an authenticator, and some additional 1754 bookkeeping information (see section 5.5.1 for the exact format). 1755 The ticket by itself is insufficient to authenticate a client, 1756 since tickets are passed across the network in cleartext[8], so 1757 the authenticator is used to prevent invalid replay of tickets by 1758 proving to the server that the client knows the session key of the 1759 ticket and thus is entitled to use the ticket. The KRB_AP_REQ 1760 message is referred to elsewhere as the 'authentication header.' 1761 17623.2.2. Generation of a KRB_AP_REQ message 1763 1764 When a client wishes to initiate authentication to a server, it 1765 obtains (either through a credentials cache, the AS exchange, or 1766 the TGS exchange) a ticket and session key for the desired 1767 service. The client MAY re-use any tickets it holds until they 1768 expire. To use a ticket the client constructs a new Authenticator 1769 from the system time, its name, and optionally an application 1770 specific checksum, an initial sequence number to be used in 1771 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used 1772 in negotiations for a session key unique to this particular 1773 session. Authenticators MAY NOT be re-used and SHOULD be rejected 1774 if replayed to a server[9]. If a sequence number is to be 1775 included, it SHOULD be randomly chosen so that even after many 1776 messages have been exchanged it is not likely to collide with 1777 other sequence numbers in use. 1778 1779 The client MAY indicate a requirement of mutual authentication or 1780 the use of a session-key based ticket (for user-to-user 1781 authentication - see section 3.7) by setting the appropriate 1782 flag(s) in the ap-options field of the message. 1783 1784 1785 1786 1787February 2004 [Page 30] 1788 1789 1790 1791 1792 1793Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1794 1795 1796 The Authenticator is encrypted in the session key and combined 1797 with the ticket to form the KRB_AP_REQ message which is then sent 1798 to the end server along with any additional application-specific 1799 information. 1800 18013.2.3. Receipt of KRB_AP_REQ message 1802 1803 Authentication is based on the server's current time of day 1804 (clocks MUST be loosely synchronized), the authenticator, and the 1805 ticket. Several errors are possible. If an error occurs, the 1806 server is expected to reply to the client with a KRB_ERROR 1807 message. This message MAY be encapsulated in the application 1808 protocol if its raw form is not acceptable to the protocol. The 1809 format of error messages is described in section 5.9.1. 1810 1811 The algorithm for verifying authentication information is as 1812 follows. If the message type is not KRB_AP_REQ, the server returns 1813 the KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the 1814 Ticket in the KRB_AP_REQ is not one the server can use (e.g., it 1815 indicates an old key, and the server no longer possesses a copy of 1816 the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the 1817 USE-SESSION-KEY flag is set in the ap-options field, it indicates 1818 to the server that user-to-user authentication is in use, and that 1819 the ticket is encrypted in the session key from the server's 1820 ticket-granting ticket rather than in the server's secret key. See 1821 section 3.7 for a more complete description of the effect of user- 1822 to-user authentication on all messages in the Kerberos protocol. 1823 1824 Since it is possible for the server to be registered in multiple 1825 realms, with different keys in each, the srealm field in the 1826 unencrypted portion of the ticket in the KRB_AP_REQ is used to 1827 specify which secret key the server should use to decrypt that 1828 ticket. The KRB_AP_ERR_NOKEY error code is returned if the server 1829 doesn't have the proper key to decipher the ticket. 1830 1831 The ticket is decrypted using the version of the server's key 1832 specified by the ticket. If the decryption routines detect a 1833 modification of the ticket (each encryption system MUST provide 1834 safeguards to detect modified ciphertext), the 1835 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that 1836 different keys were used to encrypt and decrypt). 1837 1838 The authenticator is decrypted using the session key extracted 1839 from the decrypted ticket. If decryption shows it to have been 1840 modified, the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name 1841 and realm of the client from the ticket are compared against the 1842 same fields in the authenticator. If they don't match, the 1843 KRB_AP_ERR_BADMATCH error is returned; this normally is caused by 1844 1845 1846 1847February 2004 [Page 31] 1848 1849 1850 1851 1852 1853Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1854 1855 1856 a client error or attempted attack. The addresses in the ticket 1857 (if any) are then searched for an address matching the operating- 1858 system reported address of the client. If no match is found or the 1859 server insists on ticket addresses but none are present in the 1860 ticket, the KRB_AP_ERR_BADADDR error is returned. If the local 1861 (server) time and the client time in the authenticator differ by 1862 more than the allowable clock skew (e.g., 5 minutes), the 1863 KRB_AP_ERR_SKEW error is returned. 1864 1865 Unless the application server provides its own suitable means to 1866 protect against replay (for example, a challenge-response sequence 1867 initiated by the server after authentication, or use of a server- 1868 generated encryption subkey), the server MUST utilize a replay 1869 cache to remember any authenticator presented within the allowable 1870 clock skew. Careful analysis of the application protocol and 1871 implementation is recommended before eliminating this cache. The 1872 replay cache will store at least the server name, along with the 1873 client name, time and microsecond fields from the recently-seen 1874 authenticators and if a matching tuple is found, the 1875 KRB_AP_ERR_REPEAT error is returned [10]. If a server loses track 1876 of authenticators presented within the allowable clock skew, it 1877 MUST reject all requests until the clock skew interval has passed, 1878 providing assurance that any lost or replayed authenticators will 1879 fall outside the allowable clock skew and can no longer be 1880 successfully replayed [11]. 1881 1882 Implementation note: If a client generates multiple requests to 1883 the KDC with the same timestamp, including the microsecond field, 1884 all but the first of the requests received will be rejected as 1885 replays. This might happen, for example, if the resolution of the 1886 client's clock is too coarse. Client implementations SHOULD 1887 ensure that the timestamps are not reused, possibly by 1888 incrementing the microseconds field in the time stamp when the 1889 clock returns the same time for multiple requests. 1890 1891 If multiple servers (for example, different services on one 1892 machine, or a single service implemented on multiple machines) 1893 share a service principal (a practice we do not recommend in 1894 general, but acknowledge will be used in some cases), they MUST 1895 either share this replay cache, or the application protocol MUST 1896 be designed so as to eliminate the need for it. Note that this 1897 applies to all of the services, if any of the application 1898 protocols does not have replay protection built in; an 1899 authenticator used with such a service could later be replayed to 1900 a different service with the same service principal but no replay 1901 protection, if the former doesn't record the authenticator 1902 information in the common replay cache. 1903 1904 1905 1906 1907February 2004 [Page 32] 1908 1909 1910 1911 1912 1913Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1914 1915 1916 If a sequence number is provided in the authenticator, the server 1917 saves it for later use in processing KRB_SAFE and/or KRB_PRIV 1918 messages. If a subkey is present, the server either saves it for 1919 later use or uses it to help generate its own choice for a subkey 1920 to be returned in a KRB_AP_REP message. 1921 1922 The server computes the age of the ticket: local (server) time 1923 minus the start time inside the Ticket. If the start time is later 1924 than the current time by more than the allowable clock skew or if 1925 the INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV 1926 error is returned. Otherwise, if the current time is later than 1927 end time by more than the allowable clock skew, the 1928 KRB_AP_ERR_TKT_EXPIRED error is returned. 1929 1930 If all these checks succeed without an error, the server is 1931 assured that the client possesses the credentials of the principal 1932 named in the ticket and thus, the client has been authenticated to 1933 the server. 1934 1935 Passing these checks provides only authentication of the named 1936 principal; it does not imply authorization to use the named 1937 service. Applications MUST make a separate authorization decision 1938 based upon the authenticated name of the user, the requested 1939 operation, local access control information such as that contained 1940 in a .k5login or .k5users file, and possibly a separate 1941 distributed authorization service. 1942 19433.2.4. Generation of a KRB_AP_REP message 1944 1945 Typically, a client's request will include both the authentication 1946 information and its initial request in the same message, and the 1947 server need not explicitly reply to the KRB_AP_REQ. However, if 1948 mutual authentication (not only authenticating the client to the 1949 server, but also the server to the client) is being performed, the 1950 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options 1951 field, and a KRB_AP_REP message is required in response. As with 1952 the error message, this message MAY be encapsulated in the 1953 application protocol if its "raw" form is not acceptable to the 1954 application's protocol. The timestamp and microsecond field used 1955 in the reply MUST be the client's timestamp and microsecond field 1956 (as provided in the authenticator) [12]. If a sequence number is 1957 to be included, it SHOULD be randomly chosen as described above 1958 for the authenticator. A subkey MAY be included if the server 1959 desires to negotiate a different subkey. The KRB_AP_REP message is 1960 encrypted in the session key extracted from the ticket. 1961 19623.2.5. Receipt of KRB_AP_REP message 1963 1964 1965 1966 1967February 2004 [Page 33] 1968 1969 1970 1971 1972 1973Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1974 1975 1976 If a KRB_AP_REP message is returned, the client uses the session 1977 key from the credentials obtained for the server [13] to decrypt 1978 the message, and verifies that the timestamp and microsecond 1979 fields match those in the Authenticator it sent to the server. If 1980 they match, then the client is assured that the server is genuine. 1981 The sequence number and subkey (if present) are retained for later 1982 use. 1983 19843.2.6. Using the encryption key 1985 1986 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client 1987 and server share an encryption key which can be used by the 1988 application. In some cases, the use of this session key will be 1989 implicit in the protocol; in others the method of use must be 1990 chosen from several alternatives. The actual encryption key to be 1991 used for KRB_PRIV, KRB_SAFE, or other application-specific uses 1992 MAY be chosen by the application based on the session key from the 1993 ticket and subkeys in the KRB_AP_REP message and the authenticator 1994 [14]. To mitigate the effect of failures in random number 1995 generation on the client it is strongly encouraged that any key 1996 derived by an application for subsequent use include the full key 1997 entropy derived from the KDC generated session key carried in the 1998 ticket. We leave the protocol negotiations of how to use the key 1999 (e.g. selecting an encryption or checksum type) to the application 2000 programmer; the Kerberos protocol does not constrain the 2001 implementation options, but an example of how this might be done 2002 follows. 2003 2004 One way that an application may choose to negotiate a key to be 2005 used for subsequent integrity and privacy protection is for the 2006 client to propose a key in the subkey field of the authenticator. 2007 The server can then choose a key using the proposed key from the 2008 client as input, returning the new subkey in the subkey field of 2009 the application reply. This key could then be used for subsequent 2010 communication. 2011 2012 With both the one-way and mutual authentication exchanges, the 2013 peers should take care not to send sensitive information to each 2014 other without proper assurances. In particular, applications that 2015 require privacy or integrity SHOULD use the KRB_AP_REP response 2016 from the server to client to assure both client and server of 2017 their peer's identity. If an application protocol requires privacy 2018 of its messages, it can use the KRB_PRIV message (section 3.5). 2019 The KRB_SAFE message (section 3.4) can be used to assure 2020 integrity. 2021 20223.3. The Ticket-Granting Service (TGS) Exchange 2023 2024 2025 2026 2027February 2004 [Page 34] 2028 2029 2030 2031 2032 2033Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2034 2035 2036 Summary 2037 Message direction Message type Section 2038 1. Client to Kerberos KRB_TGS_REQ 5.4.1 2039 2. Kerberos to client KRB_TGS_REP or 5.4.2 2040 KRB_ERROR 5.9.1 2041 2042 The TGS exchange between a client and the Kerberos Ticket-Granting 2043 Server is initiated by a client when it wishes to obtain 2044 authentication credentials for a given server (which might be 2045 registered in a remote realm), when it wishes to renew or validate 2046 an existing ticket, or when it wishes to obtain a proxy ticket. In 2047 the first case, the client must already have acquired a ticket for 2048 the Ticket-Granting Service using the AS exchange (the ticket- 2049 granting ticket is usually obtained when a client initially 2050 authenticates to the system, such as when a user logs in). The 2051 message format for the TGS exchange is almost identical to that 2052 for the AS exchange. The primary difference is that encryption 2053 and decryption in the TGS exchange does not take place under the 2054 client's key. Instead, the session key from the ticket-granting 2055 ticket or renewable ticket, or sub-session key from an 2056 Authenticator is used. As is the case for all application servers, 2057 expired tickets are not accepted by the TGS, so once a renewable 2058 or ticket-granting ticket expires, the client must use a separate 2059 exchange to obtain valid tickets. 2060 2061 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) 2062 from the client to the Kerberos Ticket-Granting Server, and a 2063 reply (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes 2064 information authenticating the client plus a request for 2065 credentials. The authentication information consists of the 2066 authentication header (KRB_AP_REQ) which includes the client's 2067 previously obtained ticket-granting, renewable, or invalid ticket. 2068 In the ticket-granting ticket and proxy cases, the request MAY 2069 include one or more of: a list of network addresses, a collection 2070 of typed authorization data to be sealed in the ticket for 2071 authorization use by the application server, or additional tickets 2072 (the use of which are described later). The TGS reply 2073 (KRB_TGS_REP) contains the requested credentials, encrypted in the 2074 session key from the ticket-granting ticket or renewable ticket, 2075 or if present, in the sub-session key from the Authenticator (part 2076 of the authentication header). The KRB_ERROR message contains an 2077 error code and text explaining what went wrong. The KRB_ERROR 2078 message is not encrypted. The KRB_TGS_REP message contains 2079 information which can be used to detect replays, and to associate 2080 it with the message to which it replies. The KRB_ERROR message 2081 also contains information which can be used to associate it with 2082 the message to which it replies. The same comments about integrity 2083 protection of KRB_ERROR messages mentioned in section 3.1 apply to 2084 2085 2086 2087February 2004 [Page 35] 2088 2089 2090 2091 2092 2093Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2094 2095 2096 the TGS exchange. 2097 20983.3.1. Generation of KRB_TGS_REQ message 2099 2100 Before sending a request to the ticket-granting service, the 2101 client MUST determine in which realm the application server is 2102 believed to be registered [15]. If the client knows the service 2103 principal name and realm and it does not already possess a ticket- 2104 granting ticket for the appropriate realm, then one must be 2105 obtained. This is first attempted by requesting a ticket-granting 2106 ticket for the destination realm from a Kerberos server for which 2107 the client possesses a ticket-granting ticket (using the 2108 KRB_TGS_REQ message recursively). The Kerberos server MAY return a 2109 TGT for the desired realm in which case one can proceed. 2110 Alternatively, the Kerberos server MAY return a TGT for a realm 2111 which is 'closer' to the desired realm (further along the standard 2112 hierarchical path between the client's realm and the requested 2113 realm server's realm). It should be noted in this case that 2114 misconfiguration of the Kerberos servers may cause loops in the 2115 resulting authentication path, which the client should be careful 2116 to detect and avoid. 2117 2118 If the Kerberos server returns a TGT for a 'closer' realm other 2119 than the desired realm, the client MAY use local policy 2120 configuration to verify that the authentication path used is an 2121 acceptable one. Alternatively, a client MAY choose its own 2122 authentication path, rather than relying on the Kerberos server to 2123 select one. In either case, any policy or configuration 2124 information used to choose or validate authentication paths, 2125 whether by the Kerberos server or client, MUST be obtained from a 2126 trusted source. 2127 2128 When a client obtains a ticket-granting ticket that is 'closer' to 2129 the destination realm, the client MAY cache this ticket and reuse 2130 it in future KRB-TGS exchanges with services in the 'closer' 2131 realm. However, if the client were to obtain a ticket-granting 2132 ticket for the 'closer' realm by starting at the initial KDC 2133 rather than as part of obtaining another ticket, then a shorter 2134 path to the 'closer' realm might be used. This shorter path may be 2135 desirable because fewer intermediate KDCs would know the session 2136 key of the ticket involved. For this reason, clients SHOULD 2137 evaluate whether they trust the realms transited in obtaining the 2138 'closer' ticket when making a decision to use the ticket in 2139 future. 2140 2141 Once the client obtains a ticket-granting ticket for the 2142 appropriate realm, it determines which Kerberos servers serve that 2143 realm, and contacts one. The list might be obtained through a 2144 2145 2146 2147February 2004 [Page 36] 2148 2149 2150 2151 2152 2153Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2154 2155 2156 configuration file or network service or it MAY be generated from 2157 the name of the realm; as long as the secret keys exchanged by 2158 realms are kept secret, only denial of service results from using 2159 a false Kerberos server. 2160 2161 As in the AS exchange, the client MAY specify a number of options 2162 in the KRB_TGS_REQ message. One of these options is the ENC-TKT- 2163 IN-SKEY option used for user-to-user authentication. An overview 2164 of user-to-user authentication can be found in section 3.7. When 2165 generating the KRB_TGS_REQ message, this option indicates that the 2166 client is including a ticket-granting ticket obtained from the 2167 application server in the additional tickets field of the request 2168 and that the KDC SHOULD encrypt the ticket for the application 2169 server using the session key from this additional ticket, instead 2170 of using a server key from the principal database. 2171 2172 The client prepares the KRB_TGS_REQ message, providing an 2173 authentication header as an element of the padata field, and 2174 including the same fields as used in the KRB_AS_REQ message along 2175 with several optional fields: the enc-authorizatfion-data field 2176 for application server use and additional tickets required by some 2177 options. 2178 2179 In preparing the authentication header, the client can select a 2180 sub-session key under which the response from the Kerberos server 2181 will be encrypted [16]. If the sub-session key is not specified, 2182 the session key from the ticket-granting ticket will be used. If 2183 the enc-authorization-data is present, it MUST be encrypted in the 2184 sub-session key, if present, from the authenticator portion of the 2185 authentication header, or if not present, using the session key 2186 from the ticket-granting ticket. 2187 2188 Once prepared, the message is sent to a Kerberos server for the 2189 destination realm. 2190 21913.3.2. Receipt of KRB_TGS_REQ message 2192 2193 The KRB_TGS_REQ message is processed in a manner similar to the 2194 KRB_AS_REQ message, but there are many additional checks to be 2195 performed. First, the Kerberos server MUST determine which server 2196 the accompanying ticket is for and it MUST select the appropriate 2197 key to decrypt it. For a normal KRB_TGS_REQ message, it will be 2198 for the ticket granting service, and the TGS's key will be used. 2199 If the TGT was issued by another realm, then the appropriate 2200 inter-realm key MUST be used. If the accompanying ticket is not a 2201 ticket-granting ticket for the current realm, but is for an 2202 application server in the current realm, the RENEW, VALIDATE, or 2203 PROXY options are specified in the request, and the server for 2204 2205 2206 2207February 2004 [Page 37] 2208 2209 2210 2211 2212 2213Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2214 2215 2216 which a ticket is requested is the server named in the 2217 accompanying ticket, then the KDC will decrypt the ticket in the 2218 authentication header using the key of the server for which it was 2219 issued. If no ticket can be found in the padata field, the 2220 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 2221 2222 Once the accompanying ticket has been decrypted, the user-supplied 2223 checksum in the Authenticator MUST be verified against the 2224 contents of the request, and the message rejected if the checksums 2225 do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the 2226 checksum is not collision-proof (with an error code of 2227 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, 2228 the KDC_ERR_SUMTYPE_NOSUPP error is returned. If the 2229 authorization-data are present, they are decrypted using the sub- 2230 session key from the Authenticator. 2231 2232 If any of the decryptions indicate failed integrity checks, the 2233 KRB_AP_ERR_BAD_INTEGRITY error is returned. 2234 2235 As discussed in section 3.1.2, the KDC MUST send a valid 2236 KRB_TGS_REP message if it receives a KRB_TGS_REQ message identical 2237 to one it has recently processed. However, if the authenticator is 2238 a replay, but the rest of the request is not identical, then the 2239 KDC SHOULD return KRB_AP_ERR_REPEAT. 2240 22413.3.3. Generation of KRB_TGS_REP message 2242 2243 The KRB_TGS_REP message shares its format with the KRB_AS_REP 2244 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The 2245 detailed specification is in section 5.4.2. 2246 2247 The response will include a ticket for the requested server or for 2248 a ticket granting server of an intermediate KDC to be contacted to 2249 obtain the requested ticket. The Kerberos database is queried to 2250 retrieve the record for the appropriate server (including the key 2251 with which the ticket will be encrypted). If the request is for a 2252 ticket-granting ticket for a remote realm, and if no key is shared 2253 with the requested realm, then the Kerberos server will select the 2254 realm 'closest' to the requested realm with which it does share a 2255 key, and use that realm instead. This is the only case where the 2256 response for the KDC will be for a different server than that 2257 requested by the client. 2258 2259 By default, the address field, the client's name and realm, the 2260 list of transited realms, the time of initial authentication, the 2261 expiration time, and the authorization data of the newly-issued 2262 ticket will be copied from the ticket-granting ticket (TGT) or 2263 renewable ticket. If the transited field needs to be updated, but 2264 2265 2266 2267February 2004 [Page 38] 2268 2269 2270 2271 2272 2273Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2274 2275 2276 the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP 2277 error is returned. 2278 2279 If the request specifies an endtime, then the endtime of the new 2280 ticket is set to the minimum of (a) that request, (b) the endtime 2281 from the TGT, and (c) the starttime of the TGT plus the minimum of 2282 the maximum life for the application server and the maximum life 2283 for the local realm (the maximum life for the requesting principal 2284 was already applied when the TGT was issued). If the new ticket is 2285 to be a renewal, then the endtime above is replaced by the minimum 2286 of (a) the value of the renew_till field of the ticket and (b) the 2287 starttime for the new ticket plus the life (endtime-starttime) of 2288 the old ticket. 2289 2290 If the FORWARDED option has been requested, then the resulting 2291 ticket will contain the addresses specified by the client. This 2292 option will only be honored if the FORWARDABLE flag is set in the 2293 TGT. The PROXY option is similar; the resulting ticket will 2294 contain the addresses specified by the client. It will be honored 2295 only if the PROXIABLE flag in the TGT is set. The PROXY option 2296 will not be honored on requests for additional ticket-granting 2297 tickets. 2298 2299 If the requested start time is absent, indicates a time in the 2300 past, or is within the window of acceptable clock skew for the KDC 2301 and the POSTDATE option has not been specified, then the start 2302 time of the ticket is set to the authentication server's current 2303 time. If it indicates a time in the future beyond the acceptable 2304 clock skew, but the POSTDATED option has not been specified or the 2305 MAY-POSTDATE flag is not set in the TGT, then the error 2306 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket- 2307 granting ticket has the MAY-POSTDATE flag set, then the resulting 2308 ticket will be postdated and the requested starttime is checked 2309 against the policy of the local realm. If acceptable, the ticket's 2310 start time is set as requested, and the INVALID flag is set. The 2311 postdated ticket MUST be validated before use by presenting it to 2312 the KDC after the starttime has been reached. However, in no case 2313 may the starttime, endtime, or renew-till time of a newly-issued 2314 postdated ticket extend beyond the renew-till time of the ticket- 2315 granting ticket. 2316 2317 If the ENC-TKT-IN-SKEY option has been specified and an additional 2318 ticket has been included in the request, it indicates that the 2319 client is using user- to-user authentication to prove its identity 2320 to a server that does not have access to a persistent key. Section 2321 3.7 describes the affect of this option on the entire Kerberos 2322 protocol. When generating the KRB_TGS_REP message, this option in 2323 the KRB_TGS_REQ message tells the KDC to decrypt the additional 2324 2325 2326 2327February 2004 [Page 39] 2328 2329 2330 2331 2332 2333Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2334 2335 2336 ticket using the key for the server to which the additional ticket 2337 was issued and verify that it is a ticket-granting ticket. If the 2338 name of the requested server is missing from the request, the name 2339 of the client in the additional ticket will be used. Otherwise the 2340 name of the requested server will be compared to the name of the 2341 client in the additional ticket and if different, the request will 2342 be rejected. If the request succeeds, the session key from the 2343 additional ticket will be used to encrypt the new ticket that is 2344 issued instead of using the key of the server for which the new 2345 ticket will be used. 2346 2347 If the name of the server in the ticket that is presented to the 2348 KDC as part of the authentication header is not that of the 2349 ticket-granting server itself, the server is registered in the 2350 realm of the KDC, and the RENEW option is requested, then the KDC 2351 will verify that the RENEWABLE flag is set in the ticket, that the 2352 INVALID flag is not set in the ticket, and that the renew_till 2353 time is still in the future. If the VALIDATE option is requested, 2354 the KDC will check that the starttime has passed and the INVALID 2355 flag is set. If the PROXY option is requested, then the KDC will 2356 check that the PROXIABLE flag is set in the ticket. If the tests 2357 succeed, and the ticket passes the hotlist check described in the 2358 next section, the KDC will issue the appropriate new ticket. 2359 2360 The ciphertext part of the response in the KRB_TGS_REP message is 2361 encrypted in the sub-session key from the Authenticator, if 2362 present, or the session key from the ticket-granting ticket. It is 2363 not encrypted using the client's secret key. Furthermore, the 2364 client's key's expiration date and the key version number fields 2365 are left out since these values are stored along with the client's 2366 database record, and that record is not needed to satisfy a 2367 request based on a ticket-granting ticket. 2368 23693.3.3.1. Checking for revoked tickets 2370 2371 Whenever a request is made to the ticket-granting server, the 2372 presented ticket(s) is(are) checked against a hot-list of tickets 2373 which have been canceled. This hot-list might be implemented by 2374 storing a range of issue timestamps for 'suspect tickets'; if a 2375 presented ticket had an authtime in that range, it would be 2376 rejected. In this way, a stolen ticket-granting ticket or 2377 renewable ticket cannot be used to gain additional tickets 2378 (renewals or otherwise) once the theft has been reported to the 2379 KDC for the realm in which the server resides. Any normal ticket 2380 obtained before it was reported stolen will still be valid 2381 (because they require no interaction with the KDC), but only until 2382 their normal expiration time. If TGT's have been issued for cross- 2383 realm authentication, use of the cross-realm TGT will not be 2384 2385 2386 2387February 2004 [Page 40] 2388 2389 2390 2391 2392 2393Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2394 2395 2396 affected unless the hot-list is propagated to the KDCs for the 2397 realms for which such cross-realm tickets were issued. 2398 23993.3.3.2. Encoding the transited field 2400 2401 If the identity of the server in the TGT that is presented to the 2402 KDC as part of the authentication header is that of the ticket- 2403 granting service, but the TGT was issued from another realm, the 2404 KDC will look up the inter-realm key shared with that realm and 2405 use that key to decrypt the ticket. If the ticket is valid, then 2406 the KDC will honor the request, subject to the constraints 2407 outlined above in the section describing the AS exchange. The 2408 realm part of the client's identity will be taken from the ticket- 2409 granting ticket. The name of the realm that issued the ticket- 2410 granting ticket, if it is not the realm of the client principal, 2411 will be added to the transited field of the ticket to be issued. 2412 This is accomplished by reading the transited field from the 2413 ticket-granting ticket (which is treated as an unordered set of 2414 realm names), adding the new realm to the set, then constructing 2415 and writing out its encoded (shorthand) form (this may involve a 2416 rearrangement of the existing encoding). 2417 2418 Note that the ticket-granting service does not add the name of its 2419 own realm. Instead, its responsibility is to add the name of the 2420 previous realm. This prevents a malicious Kerberos server from 2421 intentionally leaving out its own name (it could, however, omit 2422 other realms' names). 2423 2424 The names of neither the local realm nor the principal's realm are 2425 to be included in the transited field. They appear elsewhere in 2426 the ticket and both are known to have taken part in authenticating 2427 the principal. Since the endpoints are not included, both local 2428 and single-hop inter-realm authentication result in a transited 2429 field that is empty. 2430 2431 Because the name of each realm transited is added to this field, 2432 it might potentially be very long. To decrease the length of this 2433 field, its contents are encoded. The initially supported encoding 2434 is optimized for the normal case of inter-realm communication: a 2435 hierarchical arrangement of realms using either domain or X.500 2436 style realm names. This encoding (called DOMAIN-X500-COMPRESS) is 2437 now described. 2438 2439 Realm names in the transited field are separated by a ",". The 2440 ",", "\", trailing "."s, and leading spaces (" ") are special 2441 characters, and if they are part of a realm name, they MUST be 2442 quoted in the transited field by preceding them with a "\". 2443 2444 2445 2446 2447February 2004 [Page 41] 2448 2449 2450 2451 2452 2453Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2454 2455 2456 A realm name ending with a "." is interpreted as being prepended 2457 to the previous realm. For example, we can encode traversal of 2458 EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and 2459 CS.WASHINGTON.EDU as: 2460 2461 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 2462 2463 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, 2464 that they would not be included in this field, and we would have: 2465 2466 "EDU,MIT.,WASHINGTON.EDU" 2467 2468 A realm name beginning with a "/" is interpreted as being appended 2469 to the previous realm. For the purpose of appending, the realm 2470 preceding the first listed realm is considered to be the null 2471 realm (""). If a realm name beginning with a "/" is to stand by 2472 itself, then it SHOULD be preceded by a space (" "). For example, 2473 we can encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and 2474 /COM/DEC as: 2475 2476 "/COM,/HP,/APOLLO, /COM/DEC". 2477 2478 Like the example above, if /COM/HP/APOLLO and /COM/DEC are 2479 endpoints, they would not be included in this field, and we would 2480 have: 2481 2482 "/COM,/HP" 2483 2484 A null subfield preceding or following a "," indicates that all 2485 realms between the previous realm and the next realm have been 2486 traversed. For the purpose of interpreting null subfields, the 2487 client's realm is considered to precede those in the transited 2488 field, and the server's realm is considered to follow them. Thus, 2489 "," means that all realms along the path between the client and 2490 the server have been traversed. ",EDU, /COM," means that all 2491 realms from the client's realm up to EDU (in a domain style 2492 hierarchy) have been traversed, and that everything from /COM down 2493 to the server's realm in an X.500 style has also been traversed. 2494 This could occur if the EDU realm in one hierarchy shares an 2495 inter-realm key directly with the /COM realm in another hierarchy. 2496 24973.3.4. Receipt of KRB_TGS_REP message 2498 2499 When the KRB_TGS_REP is received by the client, it is processed in 2500 the same manner as the KRB_AS_REP processing described above. The 2501 primary difference is that the ciphertext part of the response 2502 must be decrypted using the sub-session key from the 2503 Authenticator, if it was specified in the request, or the session 2504 2505 2506 2507February 2004 [Page 42] 2508 2509 2510 2511 2512 2513Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2514 2515 2516 key from the ticket-granting ticket, rather than the client's 2517 secret key. The server name returned in the reply is the true 2518 principal name of the service. 2519 25203.4. The KRB_SAFE Exchange 2521 2522 The KRB_SAFE message MAY be used by clients requiring the ability 2523 to detect modifications of messages they exchange. It achieves 2524 this by including a keyed collision-proof checksum of the user 2525 data and some control information. The checksum is keyed with an 2526 encryption key (usually the last key negotiated via subkeys, or 2527 the session key if no negotiation has occurred). 2528 25293.4.1. Generation of a KRB_SAFE message 2530 2531 When an application wishes to send a KRB_SAFE message, it collects 2532 its data and the appropriate control information and computes a 2533 checksum over them. The checksum algorithm should be the keyed 2534 checksum mandated to be implemented along with the crypto system 2535 used for the sub-session or session key. The checksum is generated 2536 using the sub-session key if present or the session key. Some 2537 implementations use a different checksum algorithm for the 2538 KRB_SAFE messages but doing so in a interoperable manner is not 2539 always possible. 2540 2541 The control information for the KRB_SAFE message includes both a 2542 timestamp and a sequence number. The designer of an application 2543 using the KRB_SAFE message MUST choose at least one of the two 2544 mechanisms. This choice SHOULD be based on the needs of the 2545 application protocol. 2546 2547 Sequence numbers are useful when all messages sent will be 2548 received by one's peer. Connection state is presently required to 2549 maintain the session key, so maintaining the next sequence number 2550 should not present an additional problem. 2551 2552 If the application protocol is expected to tolerate lost messages 2553 without them being resent, the use of the timestamp is the 2554 appropriate replay detection mechanism. Using timestamps is also 2555 the appropriate mechanism for multi-cast protocols where all of 2556 one's peers share a common sub-session key, but some messages will 2557 be sent to a subset of one's peers. 2558 2559 After computing the checksum, the client then transmits the 2560 information and checksum to the recipient in the message format 2561 specified in section 5.6.1. 2562 25633.4.2. Receipt of KRB_SAFE message 2564 2565 2566 2567February 2004 [Page 43] 2568 2569 2570 2571 2572 2573Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2574 2575 2576 When an application receives a KRB_SAFE message, it verifies it as 2577 follows. If any error occurs, an error code is reported for use 2578 by the application. 2579 2580 The message is first checked by verifying that the protocol 2581 version and type fields match the current version and KRB_SAFE, 2582 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2583 KRB_AP_ERR_MSG_TYPE error. The application verifies that the 2584 checksum used is a collision-proof keyed checksum that uses keys 2585 compatible with the sub-session or session key as appropriate (or 2586 with the application key derived from the session or sub-session 2587 keys), and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is 2588 generated. The sender's address MUST be included in the control 2589 information; the recipient verifies that the operating system's 2590 report of the sender's address matches the sender's address in the 2591 message, and (if a recipient address is specified or the recipient 2592 requires an address) that one of the recipient's addresses appears 2593 as the recipient's address in the message. To work with network 2594 address translation, senders MAY use the directional address type 2595 specified in section 8.1 for the sender address and not include 2596 recipient addresses. A failed match for either case generates a 2597 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 2598 sequence number fields are checked. If timestamp and usec are 2599 expected and not present, or they are present but not current, the 2600 KRB_AP_ERR_SKEW error is generated. Timestamps are not required to 2601 be strictly ordered; they are only required to be in the skew 2602 window. If the server name, along with the client name, time and 2603 microsecond fields from the Authenticator match any recently-seen 2604 (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is 2605 generated. If an incorrect sequence number is included, or a 2606 sequence number is expected but not present, the 2607 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp 2608 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED 2609 error is generated. Finally, the checksum is computed over the 2610 data and control information, and if it doesn't match the received 2611 checksum, a KRB_AP_ERR_MODIFIED error is generated. 2612 2613 If all the checks succeed, the application is assured that the 2614 message was generated by its peer and was not modified in transit. 2615 2616 Implementations SHOULD accept any checksum algorithm they 2617 implement that both have adequate security and that have keys 2618 compatible with the sub-session or session key. Unkeyed or non- 2619 collision-proof checksums are not suitable for this use. 2620 26213.5. The KRB_PRIV Exchange 2622 2623 The KRB_PRIV message MAY be used by clients requiring 2624 2625 2626 2627February 2004 [Page 44] 2628 2629 2630 2631 2632 2633Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2634 2635 2636 confidentiality and the ability to detect modifications of 2637 exchanged messages. It achieves this by encrypting the messages 2638 and adding control information. 2639 26403.5.1. Generation of a KRB_PRIV message 2641 2642 When an application wishes to send a KRB_PRIV message, it collects 2643 its data and the appropriate control information (specified in 2644 section 5.7.1) and encrypts them under an encryption key (usually 2645 the last key negotiated via subkeys, or the session key if no 2646 negotiation has occurred). As part of the control information, the 2647 client MUST choose to use either a timestamp or a sequence number 2648 (or both); see the discussion in section 3.4.1 for guidelines on 2649 which to use. After the user data and control information are 2650 encrypted, the client transmits the ciphertext and some 'envelope' 2651 information to the recipient. 2652 26533.5.2. Receipt of KRB_PRIV message 2654 2655 When an application receives a KRB_PRIV message, it verifies it as 2656 follows. If any error occurs, an error code is reported for use 2657 by the application. 2658 2659 The message is first checked by verifying that the protocol 2660 version and type fields match the current version and KRB_PRIV, 2661 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2662 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2663 ciphertext and processes the resultant plaintext. If decryption 2664 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY 2665 error is generated. 2666 2667 The sender's address MUST be included in the control information; 2668 the recipient verifies that the operating system's report of the 2669 sender's address matches the sender's address in the message. If 2670 a recipient address is specified or the recipient requires an 2671 address then one of the recipient's addresses MUST also appear as 2672 the recipient's address in the message. Where a sender's or 2673 receiver's address might not otherwise match the address in a 2674 message because of network address translation, an application MAY 2675 be written to use addresses of the directional address type in 2676 place of the actual network address. 2677 2678 A failed match for either case generates a KRB_AP_ERR_BADADDR 2679 error. To work with network address translation, implementations 2680 MAY use the directional address type defined in section 7.1 for 2681 the sender address and include no recipient address. 2682 2683 Then the timestamp and usec and/or the sequence number fields are 2684 2685 2686 2687February 2004 [Page 45] 2688 2689 2690 2691 2692 2693Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2694 2695 2696 checked. If timestamp and usec are expected and not present, or 2697 they are present but not current, the KRB_AP_ERR_SKEW error is 2698 generated. If the server name, along with the client name, time 2699 and microsecond fields from the Authenticator match any recently- 2700 seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an 2701 incorrect sequence number is included, or a sequence number is 2702 expected but not present, the KRB_AP_ERR_BADORDER error is 2703 generated. If neither a time-stamp and usec or a sequence number 2704 is present, a KRB_AP_ERR_MODIFIED error is generated. 2705 2706 If all the checks succeed, the application can assume the message 2707 was generated by its peer, and was securely transmitted (without 2708 intruders able to see the unencrypted contents). 2709 27103.6. The KRB_CRED Exchange 2711 2712 The KRB_CRED message MAY be used by clients requiring the ability 2713 to send Kerberos credentials from one host to another. It achieves 2714 this by sending the tickets together with encrypted data 2715 containing the session keys and other information associated with 2716 the tickets. 2717 27183.6.1. Generation of a KRB_CRED message 2719 2720 When an application wishes to send a KRB_CRED message it first 2721 (using the KRB_TGS exchange) obtains credentials to be sent to the 2722 remote host. It then constructs a KRB_CRED message using the 2723 ticket or tickets so obtained, placing the session key needed to 2724 use each ticket in the key field of the corresponding KrbCredInfo 2725 sequence of the encrypted part of the KRB_CRED message. 2726 2727 Other information associated with each ticket and obtained during 2728 the KRB_TGS exchange is also placed in the corresponding 2729 KrbCredInfo sequence in the encrypted part of the KRB_CRED 2730 message. The current time and, if specifically required by the 2731 application the nonce, s-address, and r-address fields, are placed 2732 in the encrypted part of the KRB_CRED message which is then 2733 encrypted under an encryption key previously exchanged in the 2734 KRB_AP exchange (usually the last key negotiated via subkeys, or 2735 the session key if no negotiation has occurred). 2736 2737 Implementation note: When constructing a KRB_CRED message for 2738 inclusion in a GSSAPI initial context token, the MIT 2739 implementation of Kerberos will not encrypt the KRB_CRED message 2740 if the session key is a DES or triple DES key. For 2741 interoperability with MIT, the Microsoft implementation will not 2742 encrypt the KRB_CRED in a GSSAPI token if it is using a DES 2743 session key. Starting at version 1.2.5, MIT Kerberos can receive 2744 2745 2746 2747February 2004 [Page 46] 2748 2749 2750 2751 2752 2753Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2754 2755 2756 and decode either encrypted or unencrypted KRB_CRED tokens in the 2757 GSSAPI exchange. The Heimdal implementation of Kerberos can also 2758 accept either encrypted or unencrypted KRB_CRED messages. Since 2759 the KRB_CRED message in a GSSAPI token is encrypted in the 2760 authenticator, the MIT behavior does not present a security 2761 problem, although it is a violation of the Kerberos specification. 2762 27633.6.2. Receipt of KRB_CRED message 2764 2765 When an application receives a KRB_CRED message, it verifies it. 2766 If any error occurs, an error code is reported for use by the 2767 application. The message is verified by checking that the protocol 2768 version and type fields match the current version and KRB_CRED, 2769 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2770 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2771 ciphertext and processes the resultant plaintext. If decryption 2772 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY 2773 error is generated. 2774 2775 If present or required, the recipient MAY verify that the 2776 operating system's report of the sender's address matches the 2777 sender's address in the message, and that one of the recipient's 2778 addresses appears as the recipient's address in the message. The 2779 address check does not provide any added security, since the 2780 address if present has already been checked in the KRB_AP_REQ 2781 message and there is not any benefit to be gained by an attacker 2782 in reflecting a KRB_CRED message back to its originator. Thus, the 2783 recipient MAY ignore the address even if present in order to work 2784 better in NAT environments. A failed match for either case 2785 generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the 2786 address check as the KRB_CRED message cannot generally be 2787 reflected back to the originator. The timestamp and usec fields 2788 (and the nonce field if required) are checked next. If the 2789 timestamp and usec are not present, or they are present but not 2790 current, the KRB_AP_ERR_SKEW error is generated. 2791 2792 If all the checks succeed, the application stores each of the new 2793 tickets in its credentials cache together with the session key and 2794 other information in the corresponding KrbCredInfo sequence from 2795 the encrypted part of the KRB_CRED message. 2796 27973.7. User-to-User Authentication Exchanges 2798 2799 User-to-User authentication provides a method to perform 2800 authentication when the verifier does not have a access to long 2801 term service key. This might be the case when running a server 2802 (for example a window server) as a user on a workstation. In such 2803 cases, the server may have access to the ticket-granting ticket 2804 2805 2806 2807February 2004 [Page 47] 2808 2809 2810 2811 2812 2813Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2814 2815 2816 obtained when the user logged in to the workstation, but because 2817 the server is running as an unprivileged user it might not have 2818 access to system keys. Similar situations may arise when running 2819 peer-to-peer applications. 2820 2821 Summary 2822 Message direction Message type Sections 2823 0. Message from application server Not Specified 2824 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 2825 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 2826 KRB_ERROR 5.9.1 2827 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 2828 2829 To address this problem, the Kerberos protocol allows the client 2830 to request that the ticket issued by the KDC be encrypted using a 2831 session key from a ticket-granting ticket issued to the party that 2832 will verify the authentication. This ticket-granting ticket must 2833 be obtained from the verifier by means of an exchange external to 2834 the Kerberos protocol, usually as part of the application 2835 protocol. This message is shown in the summary above as message 0. 2836 Note that because the ticket-granting ticket is encrypted in the 2837 KDC's secret key, it can not be used for authentication without 2838 possession of the corresponding secret key. Furthermore, because 2839 the verifier does not reveal the corresponding secret key, 2840 providing a copy of the verifier's ticket-granting ticket does not 2841 allow impersonation of the verifier. 2842 2843 Message 0 in the table above represents an application specific 2844 negotiation between the client and server, at the end of which 2845 both have determined that they will use user-to-user 2846 authentication and the client has obtained the server's TGT. 2847 2848 Next, the client includes the server's TGT as an additional ticket 2849 in its KRB_TGS_REQ request to the KDC (message 1 in the table 2850 above) and specifies the ENC-TKT-IN-SKEY option in its request. 2851 2852 If validated according to the instructions in 3.3.3, the 2853 application ticket returned to the client (message 2 in the table 2854 above) will be encrypted using the session key from the additional 2855 ticket and the client will note this when it uses or stores the 2856 application ticket. 2857 2858 When contacting the server using a ticket obtained for user-to- 2859 user authentication (message 3 in the table above), the client 2860 MUST specify the USE-SESSION-KEY flag in the ap-options field. 2861 This tells the application server to use the session key 2862 associated with its ticket-granting ticket to decrypt the server 2863 ticket provided in the application request. 2864 2865 2866 2867February 2004 [Page 48] 2868 2869 2870 2871 2872 2873Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2874 2875 28764. Encryption and Checksum Specifications 2877 2878 The Kerberos protocols described in this document are designed to 2879 encrypt messages of arbitrary sizes, using stream or block 2880 encryption ciphers. Encryption is used to prove the identities of 2881 the network entities participating in message exchanges. The Key 2882 Distribution Center for each realm is trusted by all principals 2883 registered in that realm to store a secret key in confidence. 2884 Proof of knowledge of this secret key is used to verify the 2885 authenticity of a principal. 2886 2887 The KDC uses the principal's secret key (in the AS exchange) or a 2888 shared session key (in the TGS exchange) to encrypt responses to 2889 ticket requests; the ability to obtain the secret key or session 2890 key implies the knowledge of the appropriate keys and the identity 2891 of the KDC. The ability of a principal to decrypt the KDC response 2892 and present a Ticket and a properly formed Authenticator 2893 (generated with the session key from the KDC response) to a 2894 service verifies the identity of the principal; likewise the 2895 ability of the service to extract the session key from the Ticket 2896 and prove its knowledge thereof in a response verifies the 2897 identity of the service. 2898 2899 [@KCRYPTO] defines a framework for defining encryption and 2900 checksum mechanisms for use with Kerberos. It also defines several 2901 such mechanisms, and more may be added in future updates to that 2902 document. 2903 2904 The string-to-key operation provided by [@KCRYPTO] is used to 2905 produce a long-term key for a principal (generally for a user). 2906 The default salt string, if none is provided via pre- 2907 authentication data, is the concatenation of the principal's realm 2908 and name components, in order, with no separators. Unless 2909 otherwise indicated, the default string-to-key opaque parameter 2910 set as defined in [@KCRYPTO] is used. 2911 2912 Encrypted data, keys and checksums are transmitted using the 2913 EncryptedData, EncryptionKey and Checksum data objects defined in 2914 section 5.2.9. The encryption, decryption, and checksum operations 2915 described in this document use the corresponding encryption, 2916 decryption, and get_mic operations described in [@KCRYPTO], with 2917 implicit "specific key" generation using the "key usage" values 2918 specified in the description of each EncryptedData or Checksum 2919 object to vary the key for each operation. Note that in some 2920 cases, the value to be used is dependent on the method of choosing 2921 the key or the context of the message. 2922 2923 Key usages are unsigned 32 bit integers; zero is not permitted. 2924 2925 2926 2927February 2004 [Page 49] 2928 2929 2930 2931 2932 2933Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2934 2935 2936 The key usage values for encrypting or checksumming Kerberos 2937 messages are indicated in section 5 along with the message 2938 definitions. Key usage values 512-1023 are reserved for uses 2939 internal to a Kerberos implementation. (For example, seeding a 2940 pseudo-random number generator with a value produced by encrypting 2941 something with a session key and a key usage value not used for 2942 any other purpose.) Key usage values between 1024 and 2047 2943 (inclusive) are reserved for application use; applications SHOULD 2944 use even values for encryption and odd values for checksums within 2945 this range. Key usage values are also summarized in a table in 2946 section 7.5.1. 2947 2948 There might exist other documents which define protocols in terms 2949 of the RFC1510 encryption types or checksum types. Such documents 2950 would not know about key usages. In order that these 2951 specifications continue to be meaningful until they are updated, 2952 if no key usage values are specified then key usages 1024 and 1025 2953 must be used to derive keys for encryption and checksums, 2954 respectively (this does not apply to protocols that do their own 2955 encryption independent of this framework, directly using the key 2956 resulting from the Kerberos authentication exchange.) New 2957 protocols defined in terms of the Kerberos encryption and checksum 2958 types SHOULD use their own key usage values. 2959 2960 Unless otherwise indicated, no cipher state chaining is done from 2961 one encryption operation to another. 2962 2963 Implementation note: While not recommended, some application 2964 protocols will continue to use the key data directly, even if only 2965 in currently existing protocol specifications. An implementation 2966 intended to support general Kerberos applications may therefore 2967 need to make key data available, as well as the attributes and 2968 operations described in [@KCRYPTO]. One of the more common 2969 reasons for directly performing encryption is direct control over 2970 negotiation and selection of a "sufficiently strong" encryption 2971 algorithm (in the context of a given application). While Kerberos 2972 does not directly provide a facility for negotiating encryption 2973 types between the application client and server, there are 2974 approaches for using Kerberos to facilitate this negotiation - for 2975 example, a client may request only "sufficiently strong" session 2976 key types from the KDC and expect that any type returned by the 2977 KDC will be understood and supported by the application server. 2978 29795. Message Specifications 2980 2981 NOTE: The ASN.1 collected here should be identical to the contents 2982 of Appendix A. In case of conflict, the contents of Appendix A 2983 shall take precedence. 2984 2985 2986 2987February 2004 [Page 50] 2988 2989 2990 2991 2992 2993Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2994 2995 2996 The Kerberos protocol is defined here in terms of Abstract Syntax 2997 Notation One (ASN.1) [X680], which provides a syntax for 2998 specifying both the abstract layout of protocol messages as well 2999 as their encodings. Implementors not utilizing an existing ASN.1 3000 compiler or support library are cautioned to thoroughly understand 3001 the actual ASN.1 specification to ensure correct implementation 3002 behavior, as there is more complexity in the notation than is 3003 immediately obvious, and some tutorials and guides to ASN.1 are 3004 misleading or erroneous. 3005 3006 Note that in several places, there have been changes here from RFC 3007 1510 that change the abstract types. This is in part to address 3008 widespread assumptions that various implementors have made, in 3009 some cases resulting in unintentional violations of the ASN.1 3010 standard. These are clearly flagged where they occur. The 3011 differences between the abstract types in RFC 1510 and abstract 3012 types in this document can cause incompatible encodings to be 3013 emitted when certain encoding rules, e.g. the Packed Encoding 3014 Rules (PER), are used. This theoretical incompatibility should not 3015 be relevant for Kerberos, since Kerberos explicitly specifies the 3016 use of the Distinguished Encoding Rules (DER). It might be an 3017 issue for protocols wishing to use Kerberos types with other 3018 encoding rules. (This practice is not recommended.) With very few 3019 exceptions (most notably the usages of BIT STRING), the encodings 3020 resulting from using the DER remain identical between the types 3021 defined in RFC 1510 and the types defined in this document. 3022 3023 The type definitions in this section assume an ASN.1 module 3024 definition of the following form: 3025 3026 KerberosV5Spec2 { 3027 iso(1) identified-organization(3) dod(6) internet(1) 3028 security(5) kerberosV5(2) modules(4) krb5spec2(2) 3029 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 3030 3031 -- rest of definitions here 3032 3033 END 3034 3035 This specifies that the tagging context for the module will be 3036 explicit and non-automatic. 3037 3038 Note that in some other publications [RFC1510] [RFC1964], the 3039 "dod" portion of the object identifier is erroneously specified as 3040 having the value "5". In the case of RFC 1964, use of the 3041 "correct" OID value would result in a change in the wire protocol; 3042 therefore, it remains unchanged for now. 3043 3044 3045 3046 3047February 2004 [Page 51] 3048 3049 3050 3051 3052 3053Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3054 3055 3056 Note that elsewhere in this document, nomenclature for various 3057 message types is inconsistent, but largely follows C language 3058 conventions, including use of underscore (_) characters and all- 3059 caps spelling of names intended to be numeric constants. Also, in 3060 some places, identifiers (especially ones referring to constants) 3061 are written in all-caps in order to distinguish them from 3062 surrounding explanatory text. 3063 3064 The ASN.1 notation does not permit underscores in identifiers, so 3065 in actual ASN.1 definitions, underscores are replaced with hyphens 3066 (-). Additionally, structure member names and defined values in 3067 ASN.1 MUST begin with a lowercase letter, while type names MUST 3068 begin with an uppercase letter. 3069 30705.1. Specific Compatibility Notes on ASN.1 3071 3072 For compatibility purposes, implementors should heed the following 3073 specific notes regarding the use of ASN.1 in Kerberos. These notes 3074 do not describe deviations from standard usage of ASN.1. The 3075 purpose of these notes is to instead describe some historical 3076 quirks and non-compliance of various implementations, as well as 3077 historical ambiguities, which, while being valid ASN.1, can lead 3078 to confusion during implementation. 3079 30805.1.1. ASN.1 Distinguished Encoding Rules 3081 3082 The encoding of Kerberos protocol messages shall obey the 3083 Distinguished Encoding Rules (DER) of ASN.1 as described in 3084 [X690]. Some implementations (believed to be primarily ones 3085 derived from DCE 1.1 and earlier) are known to use the more 3086 general Basic Encoding Rules (BER); in particular, these 3087 implementations send indefinite encodings of lengths. 3088 Implementations MAY accept such encodings in the interests of 3089 backwards compatibility, though implementors are warned that 3090 decoding fully-general BER is fraught with peril. 3091 30925.1.2. Optional Integer Fields 3093 3094 Some implementations do not internally distinguish between an 3095 omitted optional integer value and a transmitted value of zero. 3096 The places in the protocol where this is relevant include various 3097 microseconds fields, nonces, and sequence numbers. Implementations 3098 SHOULD treat omitted optional integer values as having been 3099 transmitted with a value of zero, if the application is expecting 3100 this. 3101 31025.1.3. Empty SEQUENCE OF Types 3103 3104 3105 3106 3107February 2004 [Page 52] 3108 3109 3110 3111 3112 3113Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3114 3115 3116 There are places in the protocol where a message contains a 3117 SEQUENCE OF type as an optional member. This can result in an 3118 encoding that contains an empty SEQUENCE OF encoding. The Kerberos 3119 protocol does not semantically distinguish between an absent 3120 optional SEQUENCE OF type and a present optional but empty 3121 SEQUENCE OF type. Implementations SHOULD NOT send empty SEQUENCE 3122 OF encodings that are marked OPTIONAL, but SHOULD accept them as 3123 being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax 3124 describing Kerberos messages, instances of these problematic 3125 optional SEQUENCE OF types are indicated with a comment. 3126 31275.1.4. Unrecognized Tag Numbers 3128 3129 Future revisions to this protocol may include new message types 3130 with different APPLICATION class tag numbers. Such revisions 3131 should protect older implementations by only sending the message 3132 types to parties that are known to understand them, e.g. by means 3133 of a flag bit set by the receiver in a preceding request. In the 3134 interest of robust error handling, implementations SHOULD 3135 gracefully handle receiving a message with an unrecognized tag 3136 anyway, and return an error message if appropriate. 3137 3138 In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the 3139 incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT 3140 respond to messages received with an unknown tag over UDP 3141 transport in order to avoid denial of service attacks. For non- 3142 KDC applications, the Kerberos implementation typically indicates 3143 an error to the application which takes appropriate steps based on 3144 the application protocol. 3145 31465.1.5. Tag Numbers Greater Than 30 3147 3148 A naive implementation of a DER ASN.1 decoder may experience 3149 problems with ASN.1 tag numbers greater than 30, due to such tag 3150 numbers being encoded using more than one byte. Future revisions 3151 of this protocol may utilize tag numbers greater than 30, and 3152 implementations SHOULD be prepared to gracefully return an error, 3153 if appropriate, if they do not recognize the tag. 3154 31555.2. Basic Kerberos Types 3156 3157 This section defines a number of basic types that are potentially 3158 used in multiple Kerberos protocol messages. 3159 31605.2.1. KerberosString 3161 3162 The original specification of the Kerberos protocol in RFC 1510 3163 uses GeneralString in numerous places for human-readable string 3164 3165 3166 3167February 2004 [Page 53] 3168 3169 3170 3171 3172 3173Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3174 3175 3176 data. Historical implementations of Kerberos cannot utilize the 3177 full power of GeneralString. This ASN.1 type requires the use of 3178 designation and invocation escape sequences as specified in 3179 ISO-2022/ECMA-35 [ISO-2022/ECMA-35] to switch character sets, and 3180 the default character set that is designated as G0 is the 3181 ISO-646/ECMA-6 [ISO-646,ECMA-6] International Reference Version 3182 (IRV) (aka U.S. ASCII), which mostly works. 3183 3184 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) 3185 and two Control-function code elements (C0..C1). DER prohibits the 3186 designation of character sets as any but the G0 and C0 sets. 3187 Unfortunately, this seems to have the side effect of prohibiting 3188 the use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any 3189 other character-sets that utilize a 96-character set, since it is 3190 prohibited by ISO-2022/ECMA-35 to designate them as the G0 code 3191 element. This side effect is being investigated in the ASN.1 3192 standards community. 3193 3194 In practice, many implementations treat GeneralStrings as if they 3195 were 8-bit strings of whichever character set the implementation 3196 defaults to, without regard for correct usage of character-set 3197 designation escape sequences. The default character set is often 3198 determined by the current user's operating system dependent 3199 locale. At least one major implementation places unescaped UTF-8 3200 encoded Unicode characters in the GeneralString. This failure to 3201 adhere to the GeneralString specifications results in 3202 interoperability issues when conflicting character encodings are 3203 utilized by the Kerberos clients, services, and KDC. 3204 3205 This unfortunate situation is the result of improper documentation 3206 of the restrictions of the ASN.1 GeneralString type in prior 3207 Kerberos specifications. 3208 3209 The new (post-RFC 1510) type KerberosString, defined below, is a 3210 GeneralString that is constrained to only contain characters in 3211 IA5String 3212 3213 KerberosString ::= GeneralString (IA5String) 3214 3215 In general, US-ASCII control characters should not be used in 3216 KerberosString. Control characters SHOULD NOT be used in principal 3217 names or realm names. 3218 3219 For compatibility, implementations MAY choose to accept 3220 GeneralString values that contain characters other than those 3221 permitted by IA5String, but they should be aware that character 3222 set designation codes will likely be absent, and that the encoding 3223 should probably be treated as locale-specific in almost every way. 3224 3225 3226 3227February 2004 [Page 54] 3228 3229 3230 3231 3232 3233Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3234 3235 3236 Implementations MAY also choose to emit GeneralString values that 3237 are beyond those permitted by IA5String, but should be aware that 3238 doing so is extraordinarily risky from an interoperability 3239 perspective. 3240 3241 Some existing implementations use GeneralString to encode 3242 unescaped locale-specific characters. This is a violation of the 3243 ASN.1 standard. Most of these implementations encode US-ASCII in 3244 the left-hand half, so as long the implementation transmits only 3245 US-ASCII, the ASN.1 standard is not violated in this regard. As 3246 soon as such an implementation encodes unescaped locale-specific 3247 characters with the high bit set, it violates the ASN.1 standard. 3248 3249 Other implementations have been known to use GeneralString to 3250 contain a UTF-8 encoding. This also violates the ASN.1 standard, 3251 since UTF-8 is a different encoding, not a 94 or 96 character "G" 3252 set as defined by ISO 2022. It is believed that these 3253 implementations do not even use the ISO 2022 escape sequence to 3254 change the character encoding. Even if implementations were to 3255 announce the change of encoding by using that escape sequence, the 3256 ASN.1 standard prohibits the use of any escape sequences other 3257 than those used to designate/invoke "G" or "C" sets allowed by 3258 GeneralString. 3259 3260 Future revisions to this protocol will almost certainly allow for 3261 a more interoperable representation of principal names, probably 3262 including UTF8String. 3263 3264 Note that applying a new constraint to a previously unconstrained 3265 type constitutes creation of a new ASN.1 type. In this particular 3266 case, the change does not result in a changed encoding under DER. 3267 32685.2.2. Realm and PrincipalName 3269 3270 Realm ::= KerberosString 3271 3272 PrincipalName ::= SEQUENCE { 3273 name-type [0] Int32, 3274 name-string [1] SEQUENCE OF KerberosString 3275 } 3276 3277 Kerberos realm names are encoded as KerberosStrings. Realms shall 3278 not contain a character with the code 0 (the US-ASCII NUL). Most 3279 realms will usually consist of several components separated by 3280 periods (.), in the style of Internet Domain Names, or separated 3281 by slashes (/) in the style of X.500 names. Acceptable forms for 3282 realm names are specified in section 6.1.. A PrincipalName is a 3283 typed sequence of components consisting of the following sub- 3284 3285 3286 3287February 2004 [Page 55] 3288 3289 3290 3291 3292 3293Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3294 3295 3296 fields: 3297 3298 name-type 3299 This field specifies the type of name that follows. Pre-defined 3300 values for this field are specified in section 6.2. The name-type 3301 SHOULD be treated as a hint. Ignoring the name type, no two names 3302 can be the same (i.e. at least one of the components, or the 3303 realm, must be different). 3304 3305 name-string 3306 This field encodes a sequence of components that form a name, each 3307 component encoded as a KerberosString. Taken together, a 3308 PrincipalName and a Realm form a principal identifier. Most 3309 PrincipalNames will have only a few components (typically one or 3310 two). 3311 33125.2.3. KerberosTime 3313 3314 KerberosTime ::= GeneralizedTime -- with no fractional seconds 3315 3316 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 3317 KerberosTime value shall not include any fractional portions of 3318 the seconds. As required by the DER, it further shall not include 3319 any separators, and it shall specify the UTC time zone (Z). 3320 Example: The only valid format for UTC time 6 minutes, 27 seconds 3321 after 9 pm on 6 November 1985 is 19851106210627Z. 3322 33235.2.4. Constrained Integer types 3324 3325 Some integer members of types SHOULD be constrained to values 3326 representable in 32 bits, for compatibility with reasonable 3327 implementation limits. 3328 3329 Int32 ::= INTEGER (-2147483648..2147483647) 3330 -- signed values representable in 32 bits 3331 3332 UInt32 ::= INTEGER (0..4294967295) 3333 -- unsigned 32 bit values 3334 3335 Microseconds ::= INTEGER (0..999999) 3336 -- microseconds 3337 3338 While this results in changes to the abstract types from the RFC 3339 1510 version, the encoding in DER should be unaltered. Historical 3340 implementations were typically limited to 32-bit integer values 3341 anyway, and assigned numbers SHOULD fall in the space of integer 3342 values representable in 32 bits in order to promote 3343 interoperability anyway. 3344 3345 3346 3347February 2004 [Page 56] 3348 3349 3350 3351 3352 3353Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3354 3355 3356 There are several integer fields in messages that are constrained 3357 to fixed values. 3358 3359 pvno 3360 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always 3361 the constant integer 5. There is no easy way to make this field 3362 into a useful protocol version number, so its value is fixed. 3363 3364 msg-type 3365 this integer field is usually identical to the application tag 3366 number of the containing message type. 3367 33685.2.5. HostAddress and HostAddresses 3369 3370 HostAddress ::= SEQUENCE { 3371 addr-type [0] Int32, 3372 address [1] OCTET STRING 3373 } 3374 3375 -- NOTE: HostAddresses is always used as an OPTIONAL field and 3376 -- should not be empty. 3377 HostAddresses -- NOTE: subtly different from rfc1510, 3378 -- but has a value mapping and encodes the same 3379 ::= SEQUENCE OF HostAddress 3380 3381 The host address encodings consists of two fields: 3382 3383 addr-type 3384 This field specifies the type of address that follows. Pre-defined 3385 values for this field are specified in section 7.5.3. 3386 3387 address 3388 This field encodes a single address of type addr-type. 3389 33905.2.6. AuthorizationData 3391 3392 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 3393 -- should not be empty. 3394 AuthorizationData ::= SEQUENCE OF SEQUENCE { 3395 ad-type [0] Int32, 3396 ad-data [1] OCTET STRING 3397 } 3398 3399 ad-data 3400 This field contains authorization data to be interpreted according 3401 to the value of the corresponding ad-type field. 3402 3403 ad-type 3404 3405 3406 3407February 2004 [Page 57] 3408 3409 3410 3411 3412 3413Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3414 3415 3416 This field specifies the format for the ad-data subfield. All 3417 negative values are reserved for local use. Non-negative values 3418 are reserved for registered use. 3419 3420 Each sequence of type and data is referred to as an authorization 3421 element. Elements MAY be application specific, however, there is a 3422 common set of recursive elements that should be understood by all 3423 implementations. These elements contain other elements embedded 3424 within them, and the interpretation of the encapsulating element 3425 determines which of the embedded elements must be interpreted, and 3426 which may be ignored. 3427 3428 These common authorization data elements are recursively defined, 3429 meaning the ad-data for these types will itself contain a sequence of 3430 authorization data whose interpretation is affected by the 3431 encapsulating element. Depending on the meaning of the encapsulating 3432 element, the encapsulated elements may be ignored, might be 3433 interpreted as issued directly by the KDC, or they might be stored in 3434 a separate plaintext part of the ticket. The types of the 3435 encapsulating elements are specified as part of the Kerberos 3436 specification because the behavior based on these values should be 3437 understood across implementations whereas other elements need only be 3438 understood by the applications which they affect. 3439 3440 Authorization data elements are considered critical if present in a 3441 ticket or authenticator. Unless encapsulated in a known authorization 3442 data element amending the criticality of the elements it contains, if 3443 an unknown authorization data element type is received by a server 3444 either in an AP-REQ or in a ticket contained in an AP-REQ, then 3445 authentication MUST fail. Authorization data is intended to restrict 3446 the use of a ticket. If the service cannot determine whether the 3447 restriction applies to that service then a security weakness may 3448 result if the ticket can be used for that service. Authorization 3449 elements that are optional can be enclosed in AD-IF-RELEVANT element. 3450 3451 In the definitions that follow, the value of the ad-type for the 3452 element will be specified as the least significant part of the 3453 subsection number, and the value of the ad-data will be as shown in 3454 the ASN.1 structure that follows the subsection heading. 3455 3456 contents of ad-data ad-type 3457 3458 DER encoding of AD-IF-RELEVANT 1 3459 3460 DER encoding of AD-KDCIssued 4 3461 3462 DER encoding of AD-AND-OR 5 3463 3464 3465 3466 3467February 2004 [Page 58] 3468 3469 3470 3471 3472 3473Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3474 3475 3476 DER encoding of AD-MANDATORY-FOR-KDC 8 3477 34785.2.6.1. IF-RELEVANT 3479 3480 AD-IF-RELEVANT ::= AuthorizationData 3481 3482 AD elements encapsulated within the if-relevant element are 3483 intended for interpretation only by application servers that 3484 understand the particular ad-type of the embedded element. 3485 Application servers that do not understand the type of an element 3486 embedded within the if-relevant element MAY ignore the 3487 uninterpretable element. This element promotes interoperability 3488 across implementations which may have local extensions for 3489 authorization. The ad-type for AD-IF-RELEVANT is (1). 3490 34915.2.6.2. KDCIssued 3492 3493 AD-KDCIssued ::= SEQUENCE { 3494 ad-checksum [0] Checksum, 3495 i-realm [1] Realm OPTIONAL, 3496 i-sname [2] PrincipalName OPTIONAL, 3497 elements [3] AuthorizationData 3498 } 3499 3500 ad-checksum 3501 A cryptographic checksum computed over the DER encoding of the 3502 AuthorizationData in the "elements" field, keyed with the session 3503 key. Its checksumtype is the mandatory checksum type for the 3504 encryption type of the session key, and its key usage value is 19. 3505 3506 i-realm, i-sname 3507 The name of the issuing principal if different from the KDC 3508 itself. This field would be used when the KDC can verify the 3509 authenticity of elements signed by the issuing principal and it 3510 allows this KDC to notify the application server of the validity 3511 of those elements. 3512 3513 elements 3514 A sequence of authorization data elements issued by the KDC. 3515 3516 The KDC-issued ad-data field is intended to provide a means for 3517 Kerberos principal credentials to embed within themselves privilege 3518 attributes and other mechanisms for positive authorization, 3519 amplifying the privileges of the principal beyond what can be done 3520 using a credentials without such an a-data element. 3521 3522 This can not be provided without this element because the definition 3523 of the authorization-data field allows elements to be added at will 3524 3525 3526 3527February 2004 [Page 59] 3528 3529 3530 3531 3532 3533Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3534 3535 3536 by the bearer of a TGT at the time that they request service tickets 3537 and elements may also be added to a delegated ticket by inclusion in 3538 the authenticator. 3539 3540 For KDC-issued elements this is prevented because the elements are 3541 signed by the KDC by including a checksum encrypted using the 3542 server's key (the same key used to encrypt the ticket - or a key 3543 derived from that key). Elements encapsulated with in the KDC-issued 3544 element MUST be ignored by the application server if this 3545 "signature" is not present. Further, elements encapsulated within 3546 this element from a ticket-granting ticket MAY be interpreted by the 3547 KDC, and used as a basis according to policy for including new signed 3548 elements within derivative tickets, but they will not be copied to a 3549 derivative ticket directly. If they are copied directly to a 3550 derivative ticket by a KDC that is not aware of this element, the 3551 signature will not be correct for the application ticket elements, 3552 and the field will be ignored by the application server. 3553 3554 This element and the elements it encapsulates MAY be safely ignored 3555 by applications, application servers, and KDCs that do not implement 3556 this element. 3557 3558 The ad-type for AD-KDC-ISSUED is (4). 3559 35605.2.6.3. AND-OR 3561 3562 AD-AND-OR ::= SEQUENCE { 3563 condition-count [0] INTEGER, 3564 elements [1] AuthorizationData 3565 } 3566 3567 3568 When restrictive AD elements are encapsulated within the and-or 3569 element, the and-or element is considered satisfied if and only if 3570 at least the number of encapsulated elements specified in 3571 condition-count are satisfied. Therefore, this element MAY be 3572 used to implement an "or" operation by setting the condition-count 3573 field to 1, and it MAY specify an "and" operation by setting the 3574 condition count to the number of embedded elements. Application 3575 servers that do not implement this element MUST reject tickets 3576 that contain authorization data elements of this type. 3577 3578 The ad-type for AD-AND-OR is (5). 3579 35805.2.6.4. MANDATORY-FOR-KDC 3581 3582 AD-MANDATORY-FOR-KDC ::= AuthorizationData 3583 3584 3585 3586 3587February 2004 [Page 60] 3588 3589 3590 3591 3592 3593Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3594 3595 3596 AD elements encapsulated within the mandatory-for-kdc element are 3597 to be interpreted by the KDC. KDCs that do not understand the type 3598 of an element embedded within the mandatory-for-kdc element MUST 3599 reject the request. 3600 3601 The ad-type for AD-MANDATORY-FOR-KDC is (8). 3602 36035.2.7. PA-DATA 3604 3605 Historically, PA-DATA have been known as "pre-authentication 3606 data", meaning that they were used to augment the initial 3607 authentication with the KDC. Since that time, they have also been 3608 used as a typed hole with which to extend protocol exchanges with 3609 the KDC. 3610 3611 PA-DATA ::= SEQUENCE { 3612 -- NOTE: first tag is [1], not [0] 3613 padata-type [1] Int32, 3614 padata-value [2] OCTET STRING -- might be encoded AP-REQ 3615 } 3616 3617 padata-type 3618 indicates the way that the padata-value element is to be 3619 interpreted. Negative values of padata-type are reserved for 3620 unregistered use; non-negative values are used for a registered 3621 interpretation of the element type. 3622 3623 padata-value 3624 Usually contains the DER encoding of another type; the padata-type 3625 field identifies which type is encoded here. 3626 3627 padata-type name contents of padata-value 3628 3629 1 pa-tgs-req DER encoding of AP-REQ 3630 3631 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 3632 3633 3 pa-pw-salt salt (not ASN.1 encoded) 3634 3635 11 pa-etype-info DER encoding of ETYPE-INFO 3636 3637 19 pa-etype-info2 DER encoding of ETYPE-INFO2 3638 3639 This field MAY also contain information needed by certain 3640 extensions to the Kerberos protocol. For example, it might be used 3641 to initially verify the identity of a client before any response 3642 is returned. 3643 3644 3645 3646 3647February 2004 [Page 61] 3648 3649 3650 3651 3652 3653Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3654 3655 3656 The padata field can also contain information needed to help the 3657 KDC or the client select the key needed for generating or 3658 decrypting the response. This form of the padata is useful for 3659 supporting the use of certain token cards with Kerberos. The 3660 details of such extensions are specified in separate documents. 3661 See [Pat92] for additional uses of this field. 3662 36635.2.7.1. PA-TGS-REQ 3664 3665 In the case of requests for additional tickets (KRB_TGS_REQ), 3666 padata-value will contain an encoded AP-REQ. The checksum in the 3667 authenticator (which MUST be collision-proof) is to be computed 3668 over the KDC-REQ-BODY encoding. 3669 36705.2.7.2. Encrypted Timestamp Pre-authentication 3671 3672 There are pre-authentication types that may be used to pre- 3673 authenticate a client by means of an encrypted timestamp. 3674 3675 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 3676 3677 PA-ENC-TS-ENC ::= SEQUENCE { 3678 patimestamp [0] KerberosTime -- client's time --, 3679 pausec [1] Microseconds OPTIONAL 3680 } 3681 3682 Patimestamp contains the client's time, and pausec contains the 3683 microseconds, which MAY be omitted if a client will not generate 3684 more than one request per second. The ciphertext (padata-value) 3685 consists of the PA-ENC-TS-ENC encoding, encrypted using the 3686 client's secret key and a key usage value of 1. 3687 3688 This pre-authentication type was not present in RFC 1510, but many 3689 implementations support it. 3690 36915.2.7.3. PA-PW-SALT 3692 3693 The padata-value for this pre-authentication type contains the 3694 salt for the string-to-key to be used by the client to obtain the 3695 key for decrypting the encrypted part of an AS-REP message. 3696 Unfortunately, for historical reasons, the character set to be 3697 used is unspecified and probably locale-specific. 3698 3699 This pre-authentication type was not present in RFC 1510, but many 3700 implementations support it. It is necessary in any case where the 3701 salt for the string-to-key algorithm is not the default. 3702 3703 In the trivial example, a zero-length salt string is very 3704 3705 3706 3707February 2004 [Page 62] 3708 3709 3710 3711 3712 3713Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3714 3715 3716 commonplace for realms that have converted their principal 3717 databases from Kerberos 4. 3718 3719 A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message 3720 that requests additional pre-authentication. Implementation note: 3721 some KDC implementations issue an erroneous PA-PW-SALT when 3722 issuing a KRB-ERROR message that requests additional pre- 3723 authentication. Therefore, clients SHOULD ignore a PA-PW-SALT 3724 accompanying a KRB-ERROR message that requests additional pre- 3725 authentication. As noted in section 3.1.3, a KDC MUST NOT send 3726 PA-PW-SALT when the client's AS-REQ includes at least one "newer" 3727 etype. 3728 37295.2.7.4. PA-ETYPE-INFO 3730 3731 The ETYPE-INFO pre-authentication type is sent by the KDC in a 3732 KRB-ERROR indicating a requirement for additional pre- 3733 authentication. It is usually used to notify a client of which key 3734 to use for the encryption of an encrypted timestamp for the 3735 purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. 3736 It MAY also be sent in an AS-REP to provide information to the 3737 client about which key salt to use for the string-to-key to be 3738 used by the client to obtain the key for decrypting the encrypted 3739 part the AS-REP. 3740 3741 ETYPE-INFO-ENTRY ::= SEQUENCE { 3742 etype [0] Int32, 3743 salt [1] OCTET STRING OPTIONAL 3744 } 3745 3746 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 3747 3748 The salt, like that of PA-PW-SALT, is also completely unspecified 3749 with respect to character set and is probably locale-specific. 3750 3751 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one 3752 ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part 3753 in the AS-REP. 3754 3755 This pre-authentication type was not present in RFC 1510, but many 3756 implementations that support encrypted timestamps for pre- 3757 authentication need to support ETYPE-INFO as well. As noted in 3758 section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's 3759 AS-REQ includes at least one "newer" etype. 3760 37615.2.7.5. PA-ETYPE-INFO2 3762 3763 The ETYPE-INFO2 pre-authentication type is sent by the KDC in a 3764 3765 3766 3767February 2004 [Page 63] 3768 3769 3770 3771 3772 3773Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3774 3775 3776 KRB-ERROR indicating a requirement for additional pre- 3777 authentication. It is usually used to notify a client of which key 3778 to use for the encryption of an encrypted timestamp for the 3779 purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. 3780 It MAY also be sent in an AS-REP to provide information to the 3781 client about which key salt to use for the string-to-key to be 3782 used by the client to obtain the key for decrypting the encrypted 3783 part the AS-REP. 3784 3785 ETYPE-INFO2-ENTRY ::= SEQUENCE { 3786 etype [0] Int32, 3787 salt [1] KerberosString OPTIONAL, 3788 s2kparams [2] OCTET STRING OPTIONAL 3789 } 3790 3791 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 3792 3793 The type of the salt is KerberosString, but existing installations 3794 might have locale-specific characters stored in salt strings, and 3795 implementors MAY choose to handle them. 3796 3797 The interpretation of s2kparams is specified in the cryptosystem 3798 description associated with the etype. Each cryptosystem has a 3799 default interpretation of s2kparams that will hold if that element 3800 is omitted from the encoding of ETYPE-INFO2-ENTRY. 3801 3802 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one 3803 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part 3804 in the AS-REP. 3805 3806 The preferred ordering of the "hint" pre-authentication data that 3807 affect client key selection is: ETYPE-INFO2, followed by ETYPE- 3808 INFO, followed by PW-SALT. As noted in section 3.1.3, a KDC MUST 3809 NOT send ETYPE-INFO or PW-SALT when the client's AS-REQ includes 3810 at least one "newer" etype. 3811 3812 The ETYPE-INFO2 pre-authentication type was not present in RFC 3813 1510. 3814 38155.2.8. KerberosFlags 3816 3817 For several message types, a specific constrained bit string type, 3818 KerberosFlags, is used. 3819 3820 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 3821 -- shall be sent, but no fewer than 32 3822 3823 Compatibility note: the following paragraphs describe a change 3824 3825 3826 3827February 2004 [Page 64] 3828 3829 3830 3831 3832 3833Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3834 3835 3836 from the RFC1510 description of bit strings that would result in 3837 incompatility in the case of an implementation that strictly 3838 conformed to ASN.1 DER and RFC1510. 3839 3840 ASN.1 bit strings have multiple uses. The simplest use of a bit 3841 string is to contain a vector of bits, with no particular meaning 3842 attached to individual bits. This vector of bits is not 3843 necessarily a multiple of eight bits long. The use in Kerberos of 3844 a bit string as a compact boolean vector wherein each element has 3845 a distinct meaning poses some problems. The natural notation for a 3846 compact boolean vector is the ASN.1 "NamedBit" notation, and the 3847 DER require that encodings of a bit string using "NamedBit" 3848 notation exclude any trailing zero bits. This truncation is easy 3849 to neglect, especially given C language implementations that 3850 naturally choose to store boolean vectors as 32 bit integers. 3851 3852 For example, if the notation for KDCOptions were to include the 3853 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be 3854 encoded had only the "forwardable" (bit number one) bit set, the 3855 DER encoding MUST include only two bits: the first reserved bit 3856 ("reserved", bit number zero, value zero) and the one-valued bit 3857 (bit number one) for "forwardable". 3858 3859 Most existing implementations of Kerberos unconditionally send 32 3860 bits on the wire when encoding bit strings used as boolean 3861 vectors. This behavior violates the ASN.1 syntax used for flag 3862 values in RFC 1510, but occurs on such a widely installed base 3863 that the protocol description is being modified to accommodate it. 3864 3865 Consequently, this document removes the "NamedBit" notations for 3866 individual bits, relegating them to comments. The size constraint 3867 on the KerberosFlags type requires that at least 32 bits be 3868 encoded at all times, though a lenient implementation MAY choose 3869 to accept fewer than 32 bits and to treat the missing bits as set 3870 to zero. 3871 3872 Currently, no uses of KerberosFlags specify more than 32 bits 3873 worth of flags, although future revisions of this document may do 3874 so. When more than 32 bits are to be transmitted in a 3875 KerberosFlags value, future revisions to this document will likely 3876 specify that the smallest number of bits needed to encode the 3877 highest-numbered one-valued bit should be sent. This is somewhat 3878 similar to the DER encoding of a bit string that is declared with 3879 the "NamedBit" notation. 3880 38815.2.9. Cryptosystem-related Types 3882 3883 Many Kerberos protocol messages contain an EncryptedData as a 3884 3885 3886 3887February 2004 [Page 65] 3888 3889 3890 3891 3892 3893Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3894 3895 3896 container for arbitrary encrypted data, which is often the 3897 encrypted encoding of another data type. Fields within 3898 EncryptedData assist the recipient in selecting a key with which 3899 to decrypt the enclosed data. 3900 3901 EncryptedData ::= SEQUENCE { 3902 etype [0] Int32 -- EncryptionType --, 3903 kvno [1] UInt32 OPTIONAL, 3904 cipher [2] OCTET STRING -- ciphertext 3905 } 3906 3907 etype 3908 This field identifies which encryption algorithm was used to 3909 encipher the cipher. 3910 3911 kvno 3912 This field contains the version number of the key under which data 3913 is encrypted. It is only present in messages encrypted under long 3914 lasting keys, such as principals' secret keys. 3915 3916 cipher 3917 This field contains the enciphered text, encoded as an OCTET 3918 STRING. (Note that the encryption mechanisms defined in 3919 [@KCRYPTO] MUST incorporate integrity protection as well, so no 3920 additional checksum is required.) 3921 3922 The EncryptionKey type is the means by which cryptographic keys used 3923 for encryption are transferred. 3924 3925 EncryptionKey ::= SEQUENCE { 3926 keytype [0] Int32 -- actually encryption type --, 3927 keyvalue [1] OCTET STRING 3928 } 3929 3930 keytype 3931 This field specifies the encryption type of the encryption key 3932 that follows in the keyvalue field. While its name is "keytype", 3933 it actually specifies an encryption type. Previously, multiple 3934 cryptosystems that performed encryption differently but were 3935 capable of using keys with the same characteristics were permitted 3936 to share an assigned number to designate the type of key; this 3937 usage is now deprecated. 3938 3939 keyvalue 3940 This field contains the key itself, encoded as an octet string. 3941 3942 Messages containing cleartext data to be authenticated will usually 3943 do so by using a member of type Checksum. Most instances of Checksum 3944 3945 3946 3947February 2004 [Page 66] 3948 3949 3950 3951 3952 3953Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3954 3955 3956 use a keyed hash, though exceptions will be noted. 3957 3958 Checksum ::= SEQUENCE { 3959 cksumtype [0] Int32, 3960 checksum [1] OCTET STRING 3961 } 3962 3963 cksumtype 3964 This field indicates the algorithm used to generate the 3965 accompanying checksum. 3966 3967 checksum 3968 This field contains the checksum itself, encoded as an octet 3969 string. 3970 3971 See section 4 for a brief description of the use of encryption and 3972 checksums in Kerberos. 3973 39745.3. Tickets 3975 3976 This section describes the format and encryption parameters for 3977 tickets and authenticators. When a ticket or authenticator is 3978 included in a protocol message it is treated as an opaque object. 3979 A ticket is a record that helps a client authenticate to a 3980 service. A Ticket contains the following information: 3981 3982 Ticket ::= [APPLICATION 1] SEQUENCE { 3983 tkt-vno [0] INTEGER (5), 3984 realm [1] Realm, 3985 sname [2] PrincipalName, 3986 enc-part [3] EncryptedData -- EncTicketPart 3987 } 3988 3989 -- Encrypted part of ticket 3990 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 3991 flags [0] TicketFlags, 3992 key [1] EncryptionKey, 3993 crealm [2] Realm, 3994 cname [3] PrincipalName, 3995 transited [4] TransitedEncoding, 3996 authtime [5] KerberosTime, 3997 starttime [6] KerberosTime OPTIONAL, 3998 endtime [7] KerberosTime, 3999 renew-till [8] KerberosTime OPTIONAL, 4000 caddr [9] HostAddresses OPTIONAL, 4001 authorization-data [10] AuthorizationData OPTIONAL 4002 } 4003 4004 4005 4006 4007February 2004 [Page 67] 4008 4009 4010 4011 4012 4013Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4014 4015 4016 -- encoded Transited field 4017 TransitedEncoding ::= SEQUENCE { 4018 tr-type [0] Int32 -- must be registered --, 4019 contents [1] OCTET STRING 4020 } 4021 4022 TicketFlags ::= KerberosFlags 4023 -- reserved(0), 4024 -- forwardable(1), 4025 -- forwarded(2), 4026 -- proxiable(3), 4027 -- proxy(4), 4028 -- may-postdate(5), 4029 -- postdated(6), 4030 -- invalid(7), 4031 -- renewable(8), 4032 -- initial(9), 4033 -- pre-authent(10), 4034 -- hw-authent(11), 4035 -- the following are new since 1510 4036 -- transited-policy-checked(12), 4037 -- ok-as-delegate(13) 4038 4039 tkt-vno 4040 This field specifies the version number for the ticket format. 4041 This document describes version number 5. 4042 4043 realm 4044 This field specifies the realm that issued a ticket. It also 4045 serves to identify the realm part of the server's principal 4046 identifier. Since a Kerberos server can only issue tickets for 4047 servers within its realm, the two will always be identical. 4048 4049 sname 4050 This field specifies all components of the name part of the 4051 server's identity, including those parts that identify a specific 4052 instance of a service. 4053 4054 enc-part 4055 This field holds the encrypted encoding of the EncTicketPart 4056 sequence. It is encrypted in the key shared by Kerberos and the 4057 end server (the server's secret key), using a key usage value of 4058 2. 4059 4060 flags 4061 This field indicates which of various options were used or 4062 requested when the ticket was issued. The meanings of the flags 4063 are: 4064 4065 4066 4067February 2004 [Page 68] 4068 4069 4070 4071 4072 4073Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4074 4075 4076 Bit(s) Name Description 4077 4078 0 reserved Reserved for future expansion of this 4079 field. 4080 4081 The FORWARDABLE flag is normally only 4082 interpreted by the TGS, and can be 4083 ignored by end servers. When set, this 4084 1 forwardable flag tells the ticket-granting server 4085 that it is OK to issue a new 4086 ticket-granting ticket with a 4087 different network address based on the 4088 presented ticket. 4089 4090 When set, this flag indicates that the 4091 ticket has either been forwarded or 4092 2 forwarded was issued based on authentication 4093 involving a forwarded ticket-granting 4094 ticket. 4095 4096 The PROXIABLE flag is normally only 4097 interpreted by the TGS, and can be 4098 ignored by end servers. The PROXIABLE 4099 flag has an interpretation identical 4100 3 proxiable to that of the FORWARDABLE flag, 4101 except that the PROXIABLE flag tells 4102 the ticket-granting server that only 4103 non-ticket-granting tickets may be 4104 issued with different network 4105 addresses. 4106 4107 4 proxy When set, this flag indicates that a 4108 ticket is a proxy. 4109 4110 The MAY-POSTDATE flag is normally only 4111 interpreted by the TGS, and can be 4112 5 may-postdate ignored by end servers. This flag 4113 tells the ticket-granting server that 4114 a post-dated ticket MAY be issued 4115 based on this ticket-granting ticket. 4116 4117 This flag indicates that this ticket 4118 has been postdated. The end-service 4119 6 postdated can check the authtime field to see 4120 when the original authentication 4121 occurred. 4122 4123 This flag indicates that a ticket is 4124 4125 4126 4127February 2004 [Page 69] 4128 4129 4130 4131 4132 4133Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4134 4135 4136 invalid, and it must be validated by 4137 7 invalid the KDC before use. Application 4138 servers must reject tickets which have 4139 this flag set. 4140 4141 The RENEWABLE flag is normally only 4142 interpreted by the TGS, and can 4143 usually be ignored by end servers 4144 8 renewable (some particularly careful servers MAY 4145 disallow renewable tickets). A 4146 renewable ticket can be used to obtain 4147 a replacement ticket that expires at a 4148 later date. 4149 4150 This flag indicates that this ticket 4151 9 initial was issued using the AS protocol, and 4152 not issued based on a ticket-granting 4153 ticket. 4154 4155 This flag indicates that during 4156 initial authentication, the client was 4157 authenticated by the KDC before a 4158 10 pre-authent ticket was issued. The strength of the 4159 pre-authentication method is not 4160 indicated, but is acceptable to the 4161 KDC. 4162 4163 This flag indicates that the protocol 4164 employed for initial authentication 4165 required the use of hardware expected 4166 11 hw-authent to be possessed solely by the named 4167 client. The hardware authentication 4168 method is selected by the KDC and the 4169 strength of the method is not 4170 indicated. 4171 4172 This flag indicates that the KDC for 4173 the realm has checked the transited 4174 field against a realm defined policy 4175 for trusted certifiers. If this flag 4176 is reset (0), then the application 4177 server must check the transited field 4178 itself, and if unable to do so it must 4179 reject the authentication. If the flag 4180 12 transited- is set (1) then the application server 4181 policy-checked MAY skip its own validation of the 4182 transited field, relying on the 4183 validation performed by the KDC. At 4184 4185 4186 4187February 2004 [Page 70] 4188 4189 4190 4191 4192 4193Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4194 4195 4196 its option the application server MAY 4197 still apply its own validation based 4198 on a separate policy for acceptance. 4199 4200 This flag is new since RFC 1510. 4201 4202 This flag indicates that the server 4203 (not the client) specified in the 4204 ticket has been determined by policy 4205 of the realm to be a suitable 4206 recipient of delegation. A client can 4207 use the presence of this flag to help 4208 it make a decision whether to delegate 4209 credentials (either grant a proxy or a 4210 forwarded ticket-granting ticket) to 4211 13 ok-as-delegate this server. The client is free to 4212 ignore the value of this flag. When 4213 setting this flag, an administrator 4214 should consider the Security and 4215 placement of the server on which the 4216 service will run, as well as whether 4217 the service requires the use of 4218 delegated credentials. 4219 4220 This flag is new since RFC 1510. 4221 4222 14-31 reserved Reserved for future use. 4223 4224 key 4225 This field exists in the ticket and the KDC response and is used 4226 to pass the session key from Kerberos to the application server 4227 and the client. 4228 4229 crealm 4230 This field contains the name of the realm in which the client is 4231 registered and in which initial authentication took place. 4232 4233 cname 4234 This field contains the name part of the client's principal 4235 identifier. 4236 4237 transited 4238 This field lists the names of the Kerberos realms that took part 4239 in authenticating the user to whom this ticket was issued. It does 4240 not specify the order in which the realms were transited. See 4241 section 3.3.3.2 for details on how this field encodes the 4242 traversed realms. When the names of CA's are to be embedded in 4243 the transited field (as specified for some extensions to the 4244 4245 4246 4247February 2004 [Page 71] 4248 4249 4250 4251 4252 4253Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4254 4255 4256 protocol), the X.500 names of the CA's SHOULD be mapped into items 4257 in the transited field using the mapping defined by RFC2253. 4258 4259 authtime 4260 This field indicates the time of initial authentication for the 4261 named principal. It is the time of issue for the original ticket 4262 on which this ticket is based. It is included in the ticket to 4263 provide additional information to the end service, and to provide 4264 the necessary information for implementation of a `hot list' 4265 service at the KDC. An end service that is particularly paranoid 4266 could refuse to accept tickets for which the initial 4267 authentication occurred "too far" in the past. This field is also 4268 returned as part of the response from the KDC. When returned as 4269 part of the response to initial authentication (KRB_AS_REP), this 4270 is the current time on the Kerberos server. It is NOT recommended 4271 that this time value be used to adjust the workstation's clock 4272 since the workstation cannot reliably determine that such a 4273 KRB_AS_REP actually came from the proper KDC in a timely manner. 4274 4275 4276 starttime 4277 4278 This field in the ticket specifies the time after which the ticket 4279 is valid. Together with endtime, this field specifies the life of 4280 the ticket. If the starttime field is absent from the ticket, then 4281 the authtime field SHOULD be used in its place to determine the 4282 life of the ticket. 4283 4284 endtime 4285 This field contains the time after which the ticket will not be 4286 honored (its expiration time). Note that individual services MAY 4287 place their own limits on the life of a ticket and MAY reject 4288 tickets which have not yet expired. As such, this is really an 4289 upper bound on the expiration time for the ticket. 4290 4291 renew-till 4292 This field is only present in tickets that have the RENEWABLE flag 4293 set in the flags field. It indicates the maximum endtime that may 4294 be included in a renewal. It can be thought of as the absolute 4295 expiration time for the ticket, including all renewals. 4296 4297 caddr 4298 This field in a ticket contains zero (if omitted) or more (if 4299 present) host addresses. These are the addresses from which the 4300 ticket can be used. If there are no addresses, the ticket can be 4301 used from any location. The decision by the KDC to issue or by the 4302 end server to accept addressless tickets is a policy decision and 4303 is left to the Kerberos and end-service administrators; they MAY 4304 4305 4306 4307February 2004 [Page 72] 4308 4309 4310 4311 4312 4313Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4314 4315 4316 refuse to issue or accept such tickets. Because of the wide 4317 deployment of network address translation, it is recommended that 4318 policy allow the issue and acceptance of such tickets. 4319 4320 Network addresses are included in the ticket to make it harder for 4321 an attacker to use stolen credentials. Because the session key is 4322 not sent over the network in cleartext, credentials can't be 4323 stolen simply by listening to the network; an attacker has to gain 4324 access to the session key (perhaps through operating system 4325 security breaches or a careless user's unattended session) to make 4326 use of stolen tickets. 4327 4328 It is important to note that the network address from which a 4329 connection is received cannot be reliably determined. Even if it 4330 could be, an attacker who has compromised the client's workstation 4331 could use the credentials from there. Including the network 4332 addresses only makes it more difficult, not impossible, for an 4333 attacker to walk off with stolen credentials and then use them 4334 from a "safe" location. 4335 4336 authorization-data 4337 The authorization-data field is used to pass authorization data 4338 from the principal on whose behalf a ticket was issued to the 4339 application service. If no authorization data is included, this 4340 field will be left out. Experience has shown that the name of this 4341 field is confusing, and that a better name for this field would be 4342 restrictions. Unfortunately, it is not possible to change the name 4343 of this field at this time. 4344 4345 This field contains restrictions on any authority obtained on the 4346 basis of authentication using the ticket. It is possible for any 4347 principal in possession of credentials to add entries to the 4348 authorization data field since these entries further restrict what 4349 can be done with the ticket. Such additions can be made by 4350 specifying the additional entries when a new ticket is obtained 4351 during the TGS exchange, or they MAY be added during chained 4352 delegation using the authorization data field of the 4353 authenticator. 4354 4355 Because entries may be added to this field by the holder of 4356 credentials, except when an entry is separately authenticated by 4357 encapsulation in the KDC-issued element, it is not allowable for 4358 the presence of an entry in the authorization data field of a 4359 ticket to amplify the privileges one would obtain from using a 4360 ticket. 4361 4362 The data in this field may be specific to the end service; the 4363 field will contain the names of service specific objects, and the 4364 4365 4366 4367February 2004 [Page 73] 4368 4369 4370 4371 4372 4373Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4374 4375 4376 rights to those objects. The format for this field is described in 4377 section 5.2.6. Although Kerberos is not concerned with the format 4378 of the contents of the sub-fields, it does carry type information 4379 (ad-type). 4380 4381 By using the authorization_data field, a principal is able to 4382 issue a proxy that is valid for a specific purpose. For example, a 4383 client wishing to print a file can obtain a file server proxy to 4384 be passed to the print server. By specifying the name of the file 4385 in the authorization_data field, the file server knows that the 4386 print server can only use the client's rights when accessing the 4387 particular file to be printed. 4388 4389 A separate service providing authorization or certifying group 4390 membership may be built using the authorization-data field. In 4391 this case, the entity granting authorization (not the authorized 4392 entity), may obtain a ticket in its own name (e.g. the ticket is 4393 issued in the name of a privilege server), and this entity adds 4394 restrictions on its own authority and delegates the restricted 4395 authority through a proxy to the client. The client would then 4396 present this authorization credential to the application server 4397 separately from the authentication exchange. Alternatively, such 4398 authorization credentials MAY be embedded in the ticket 4399 authenticating the authorized entity, when the authorization is 4400 separately authenticated using the KDC-issued authorization data 4401 element (see 5.2.6.2). 4402 4403 Similarly, if one specifies the authorization-data field of a 4404 proxy and leaves the host addresses blank, the resulting ticket 4405 and session key can be treated as a capability. See [Neu93] for 4406 some suggested uses of this field. 4407 4408 The authorization-data field is optional and does not have to be 4409 included in a ticket. 4410 44115.4. Specifications for the AS and TGS exchanges 4412 4413 This section specifies the format of the messages used in the 4414 exchange between the client and the Kerberos server. The format of 4415 possible error messages appears in section 5.9.1. 4416 44175.4.1. KRB_KDC_REQ definition 4418 4419 The KRB_KDC_REQ message has no application tag number of its own. 4420 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, 4421 which each have an application tag, depending on whether the 4422 request is for an initial ticket or an additional ticket. In 4423 either case, the message is sent from the client to the KDC to 4424 4425 4426 4427February 2004 [Page 74] 4428 4429 4430 4431 4432 4433Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4434 4435 4436 request credentials for a service. 4437 4438 The message fields are: 4439 4440 AS-REQ ::= [APPLICATION 10] KDC-REQ 4441 4442 TGS-REQ ::= [APPLICATION 12] KDC-REQ 4443 4444 KDC-REQ ::= SEQUENCE { 4445 -- NOTE: first tag is [1], not [0] 4446 pvno [1] INTEGER (5) , 4447 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 4448 padata [3] SEQUENCE OF PA-DATA OPTIONAL 4449 -- NOTE: not empty --, 4450 req-body [4] KDC-REQ-BODY 4451 } 4452 4453 KDC-REQ-BODY ::= SEQUENCE { 4454 kdc-options [0] KDCOptions, 4455 cname [1] PrincipalName OPTIONAL 4456 -- Used only in AS-REQ --, 4457 realm [2] Realm 4458 -- Server's realm 4459 -- Also client's in AS-REQ --, 4460 sname [3] PrincipalName OPTIONAL, 4461 from [4] KerberosTime OPTIONAL, 4462 till [5] KerberosTime, 4463 rtime [6] KerberosTime OPTIONAL, 4464 nonce [7] UInt32, 4465 etype [8] SEQUENCE OF Int32 -- EncryptionType 4466 -- in preference order --, 4467 addresses [9] HostAddresses OPTIONAL, 4468 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 4469 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 4470 -- NOTE: not empty 4471 } 4472 4473 KDCOptions ::= KerberosFlags 4474 -- reserved(0), 4475 -- forwardable(1), 4476 -- forwarded(2), 4477 -- proxiable(3), 4478 -- proxy(4), 4479 -- allow-postdate(5), 4480 -- postdated(6), 4481 -- unused7(7), 4482 -- renewable(8), 4483 -- unused9(9), 4484 4485 4486 4487February 2004 [Page 75] 4488 4489 4490 4491 4492 4493Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4494 4495 4496 -- unused10(10), 4497 -- opt-hardware-auth(11), 4498 -- unused12(12), 4499 -- unused13(13), 4500 -- 15 is reserved for canonicalize 4501 -- unused15(15), 4502 -- 26 was unused in 1510 4503 -- disable-transited-check(26), 4504 -- 4505 -- renewable-ok(27), 4506 -- enc-tkt-in-skey(28), 4507 -- renew(30), 4508 -- validate(31) 4509 4510 The fields in this message are: 4511 4512 pvno 4513 This field is included in each message, and specifies the protocol 4514 version number. This document specifies protocol version 5. 4515 4516 msg-type 4517 This field indicates the type of a protocol message. It will 4518 almost always be the same as the application identifier associated 4519 with a message. It is included to make the identifier more readily 4520 accessible to the application. For the KDC-REQ message, this type 4521 will be KRB_AS_REQ or KRB_TGS_REQ. 4522 4523 padata 4524 Contains pre-authentication data. Requests for additional tickets 4525 (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. 4526 4527 The padata (pre-authentication data) field contains a sequence of 4528 authentication information which may be needed before credentials 4529 can be issued or decrypted. 4530 4531 req-body 4532 This field is a placeholder delimiting the extent of the remaining 4533 fields. If a checksum is to be calculated over the request, it is 4534 calculated over an encoding of the KDC-REQ-BODY sequence which is 4535 enclosed within the req-body field. 4536 4537 kdc-options 4538 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to 4539 the KDC and indicates the flags that the client wants set on the 4540 tickets as well as other information that is to modify the 4541 behavior of the KDC. Where appropriate, the name of an option may 4542 be the same as the flag that is set by that option. Although in 4543 most case, the bit in the options field will be the same as that 4544 4545 4546 4547February 2004 [Page 76] 4548 4549 4550 4551 4552 4553Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4554 4555 4556 in the flags field, this is not guaranteed, so it is not 4557 acceptable to simply copy the options field to the flags field. 4558 There are various checks that must be made before honoring an 4559 option anyway. 4560 4561 The kdc_options field is a bit-field, where the selected options 4562 are indicated by the bit being set (1), and the unselected options 4563 and reserved fields being reset (0). The encoding of the bits is 4564 specified in section 5.2. The options are described in more detail 4565 above in section 2. The meanings of the options are: 4566 4567 Bits Name Description 4568 4569 0 RESERVED Reserved for future expansion of 4570 this field. 4571 4572 The FORWARDABLE option indicates 4573 that the ticket to be issued is to 4574 have its forwardable flag set. It 4575 1 FORWARDABLE may only be set on the initial 4576 request, or in a subsequent request 4577 if the ticket-granting ticket on 4578 which it is based is also 4579 forwardable. 4580 4581 The FORWARDED option is only 4582 specified in a request to the 4583 ticket-granting server and will only 4584 be honored if the ticket-granting 4585 ticket in the request has its 4586 2 FORWARDED FORWARDABLE bit set. This option 4587 indicates that this is a request for 4588 forwarding. The address(es) of the 4589 host from which the resulting ticket 4590 is to be valid are included in the 4591 addresses field of the request. 4592 4593 The PROXIABLE option indicates that 4594 the ticket to be issued is to have 4595 its proxiable flag set. It may only 4596 3 PROXIABLE be set on the initial request, or in 4597 a subsequent request if the 4598 ticket-granting ticket on which it 4599 is based is also proxiable. 4600 4601 The PROXY option indicates that this 4602 is a request for a proxy. This 4603 option will only be honored if the 4604 4605 4606 4607February 2004 [Page 77] 4608 4609 4610 4611 4612 4613Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4614 4615 4616 ticket-granting ticket in the 4617 4 PROXY request has its PROXIABLE bit set. 4618 The address(es) of the host from 4619 which the resulting ticket is to be 4620 valid are included in the addresses 4621 field of the request. 4622 4623 The ALLOW-POSTDATE option indicates 4624 that the ticket to be issued is to 4625 have its MAY-POSTDATE flag set. It 4626 5 ALLOW-POSTDATE may only be set on the initial 4627 request, or in a subsequent request 4628 if the ticket-granting ticket on 4629 which it is based also has its 4630 MAY-POSTDATE flag set. 4631 4632 The POSTDATED option indicates that 4633 this is a request for a postdated 4634 ticket. This option will only be 4635 honored if the ticket-granting 4636 ticket on which it is based has its 4637 6 POSTDATED MAY-POSTDATE flag set. The resulting 4638 ticket will also have its INVALID 4639 flag set, and that flag may be reset 4640 by a subsequent request to the KDC 4641 after the starttime in the ticket 4642 has been reached. 4643 4644 7 RESERVED This option is presently unused. 4645 4646 The RENEWABLE option indicates that 4647 the ticket to be issued is to have 4648 its RENEWABLE flag set. It may only 4649 be set on the initial request, or 4650 when the ticket-granting ticket on 4651 8 RENEWABLE which the request is based is also 4652 renewable. If this option is 4653 requested, then the rtime field in 4654 the request contains the desired 4655 absolute expiration time for the 4656 ticket. 4657 4658 9 RESERVED Reserved for PK-Cross 4659 4660 10 RESERVED Reserved for future use. 4661 4662 11 RESERVED Reserved for opt-hardware-auth. 4663 4664 4665 4666 4667February 2004 [Page 78] 4668 4669 4670 4671 4672 4673Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4674 4675 4676 12-25 RESERVED Reserved for future use. 4677 4678 By default the KDC will check the 4679 transited field of a 4680 ticket-granting-ticket against the 4681 policy of the local realm before it 4682 will issue derivative tickets based 4683 on the ticket-granting ticket. If 4684 this flag is set in the request, 4685 checking of the transited field is 4686 disabled. Tickets issued without the 4687 26 DISABLE-TRANSITED-CHECK performance of this check will be 4688 noted by the reset (0) value of the 4689 TRANSITED-POLICY-CHECKED flag, 4690 indicating to the application server 4691 that the tranisted field must be 4692 checked locally. KDCs are 4693 encouraged but not required to honor 4694 the DISABLE-TRANSITED-CHECK option. 4695 4696 This flag is new since RFC 1510 4697 4698 The RENEWABLE-OK option indicates 4699 that a renewable ticket will be 4700 acceptable if a ticket with the 4701 requested life cannot otherwise be 4702 provided. If a ticket with the 4703 requested life cannot be provided, 4704 27 RENEWABLE-OK then a renewable ticket may be 4705 issued with a renew-till equal to 4706 the requested endtime. The value 4707 of the renew-till field may still be 4708 limited by local limits, or limits 4709 selected by the individual principal 4710 or server. 4711 4712 This option is used only by the 4713 ticket-granting service. The 4714 ENC-TKT-IN-SKEY option indicates 4715 28 ENC-TKT-IN-SKEY that the ticket for the end server 4716 is to be encrypted in the session 4717 key from the additional 4718 ticket-granting ticket provided. 4719 4720 29 RESERVED Reserved for future use. 4721 4722 This option is used only by the 4723 ticket-granting service. The RENEW 4724 4725 4726 4727February 2004 [Page 79] 4728 4729 4730 4731 4732 4733Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4734 4735 4736 option indicates that the present 4737 request is for a renewal. The ticket 4738 provided is encrypted in the secret 4739 key for the server on which it is 4740 30 RENEW valid. This option will only be 4741 honored if the ticket to be renewed 4742 has its RENEWABLE flag set and if 4743 the time in its renew-till field has 4744 not passed. The ticket to be renewed 4745 is passed in the padata field as 4746 part of the authentication header. 4747 4748 This option is used only by the 4749 ticket-granting service. The 4750 VALIDATE option indicates that the 4751 request is to validate a postdated 4752 ticket. It will only be honored if 4753 the ticket presented is postdated, 4754 presently has its INVALID flag set, 4755 31 VALIDATE and would be otherwise usable at 4756 this time. A ticket cannot be 4757 validated before its starttime. The 4758 ticket presented for validation is 4759 encrypted in the key of the server 4760 for which it is valid and is passed 4761 in the padata field as part of the 4762 authentication header. 4763 cname and sname 4764 These fields are the same as those described for the ticket in 4765 section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY 4766 option is specified. If absent, the name of the server is taken 4767 from the name of the client in the ticket passed as additional- 4768 tickets. 4769 4770 enc-authorization-data 4771 The enc-authorization-data, if present (and it can only be present 4772 in the TGS_REQ form), is an encoding of the desired authorization- 4773 data encrypted under the sub-session key if present in the 4774 Authenticator, or alternatively from the session key in the 4775 ticket-granting ticket (both the Authenticator and ticket-granting 4776 ticket come from the padata field in the KRB_TGS_REQ). The key 4777 usage value used when encrypting is 5 if a sub-session key is 4778 used, or 4 if the session key is used. 4779 4780 realm 4781 This field specifies the realm part of the server's principal 4782 identifier. In the AS exchange, this is also the realm part of the 4783 client's principal identifier. 4784 4785 4786 4787February 2004 [Page 80] 4788 4789 4790 4791 4792 4793Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4794 4795 4796 from 4797 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 4798 requests when the requested ticket is to be postdated. It 4799 specifies the desired start time for the requested ticket. If this 4800 field is omitted then the KDC SHOULD use the current time instead. 4801 4802 till 4803 This field contains the expiration date requested by the client in 4804 a ticket request. It is not optional, but if the requested endtime 4805 is "19700101000000Z", the requested ticket is to have the maximum 4806 endtime permitted according to KDC policy. Implementation note: 4807 This special timestamp corresponds to a UNIX time_t value of zero 4808 on most systems. 4809 4810 rtime 4811 This field is the requested renew-till time sent from a client to 4812 the KDC in a ticket request. It is optional. 4813 4814 nonce 4815 This field is part of the KDC request and response. It is intended 4816 to hold a random number generated by the client. If the same 4817 number is included in the encrypted response from the KDC, it 4818 provides evidence that the response is fresh and has not been 4819 replayed by an attacker. Nonces MUST NEVER be reused. 4820 4821 etype 4822 This field specifies the desired encryption algorithm to be used 4823 in the response. 4824 4825 addresses 4826 This field is included in the initial request for tickets, and 4827 optionally included in requests for additional tickets from the 4828 ticket-granting server. It specifies the addresses from which the 4829 requested ticket is to be valid. Normally it includes the 4830 addresses for the client's host. If a proxy is requested, this 4831 field will contain other addresses. The contents of this field are 4832 usually copied by the KDC into the caddr field of the resulting 4833 ticket. 4834 4835 additional-tickets 4836 Additional tickets MAY be optionally included in a request to the 4837 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 4838 specified, then the session key from the additional ticket will be 4839 used in place of the server's key to encrypt the new ticket. When 4840 the ENC-TKT-IN-SKEY option is used for user-to-user 4841 authentication, this additional ticket MAY be a TGT issued by the 4842 local realm or an inter-realm TGT issued for the current KDC's 4843 realm by a remote KDC. If more than one option which requires 4844 4845 4846 4847February 2004 [Page 81] 4848 4849 4850 4851 4852 4853Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4854 4855 4856 additional tickets has been specified, then the additional tickets 4857 are used in the order specified by the ordering of the options 4858 bits (see kdc-options, above). 4859 4860 The application tag number will be either ten (10) or twelve (12) 4861 depending on whether the request is for an initial ticket (AS-REQ) or 4862 for an additional ticket (TGS-REQ). 4863 4864 The optional fields (addresses, authorization-data and additional- 4865 tickets) are only included if necessary to perform the operation 4866 specified in the kdc-options field. 4867 4868 It should be noted that in KRB_TGS_REQ, the protocol version number 4869 appears twice and two different message types appear: the KRB_TGS_REQ 4870 message contains these fields as does the authentication header 4871 (KRB_AP_REQ) that is passed in the padata field. 4872 48735.4.2. KRB_KDC_REP definition 4874 4875 The KRB_KDC_REP message format is used for the reply from the KDC 4876 for either an initial (AS) request or a subsequent (TGS) request. 4877 There is no message type for KRB_KDC_REP. Instead, the type will 4878 be either KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the 4879 ciphertext part of the reply depends on the message type. For 4880 KRB_AS_REP, the ciphertext is encrypted in the client's secret 4881 key, and the client's key version number is included in the key 4882 version number for the encrypted data. For KRB_TGS_REP, the 4883 ciphertext is encrypted in the sub-session key from the 4884 Authenticator, or if absent, the session key from the ticket- 4885 granting ticket used in the request. In that case, no version 4886 number will be present in the EncryptedData sequence. 4887 4888 The KRB_KDC_REP message contains the following fields: 4889 4890 AS-REP ::= [APPLICATION 11] KDC-REP 4891 4892 TGS-REP ::= [APPLICATION 13] KDC-REP 4893 4894 KDC-REP ::= SEQUENCE { 4895 pvno [0] INTEGER (5), 4896 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 4897 padata [2] SEQUENCE OF PA-DATA OPTIONAL 4898 -- NOTE: not empty --, 4899 crealm [3] Realm, 4900 cname [4] PrincipalName, 4901 ticket [5] Ticket, 4902 enc-part [6] EncryptedData 4903 -- EncASRepPart or EncTGSRepPart, 4904 4905 4906 4907February 2004 [Page 82] 4908 4909 4910 4911 4912 4913Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4914 4915 4916 -- as appropriate 4917 } 4918 4919 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 4920 4921 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4922 4923 EncKDCRepPart ::= SEQUENCE { 4924 key [0] EncryptionKey, 4925 last-req [1] LastReq, 4926 nonce [2] UInt32, 4927 key-expiration [3] KerberosTime OPTIONAL, 4928 flags [4] TicketFlags, 4929 authtime [5] KerberosTime, 4930 starttime [6] KerberosTime OPTIONAL, 4931 endtime [7] KerberosTime, 4932 renew-till [8] KerberosTime OPTIONAL, 4933 srealm [9] Realm, 4934 sname [10] PrincipalName, 4935 caddr [11] HostAddresses OPTIONAL 4936 } 4937 4938 LastReq ::= SEQUENCE OF SEQUENCE { 4939 lr-type [0] Int32, 4940 lr-value [1] KerberosTime 4941 } 4942 4943 pvno and msg-type 4944 These fields are described above in section 5.4.1. msg-type is 4945 either KRB_AS_REP or KRB_TGS_REP. 4946 4947 padata 4948 This field is described in detail in section 5.4.1. One possible 4949 use for this field is to encode an alternate "salt" string to be 4950 used with a string-to-key algorithm. This ability is useful to 4951 ease transitions if a realm name needs to change (e.g. when a 4952 company is acquired); in such a case all existing password-derived 4953 entries in the KDC database would be flagged as needing a special 4954 salt string until the next password change. 4955 4956 crealm, cname, srealm and sname 4957 These fields are the same as those described for the ticket in 4958 section 5.3. 4959 4960 ticket 4961 The newly-issued ticket, from section 5.3. 4962 4963 enc-part 4964 4965 4966 4967February 2004 [Page 83] 4968 4969 4970 4971 4972 4973Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4974 4975 4976 This field is a place holder for the ciphertext and related 4977 information that forms the encrypted part of a message. The 4978 description of the encrypted part of the message follows each 4979 appearance of this field. 4980 4981 The key usage value for encrypting this field is 3 in an AS-REP 4982 message, using the client's long-term key or another key selected 4983 via pre-authentication mechanisms. In a TGS-REP message, the key 4984 usage value is 8 if the TGS session key is used, or 9 if a TGS 4985 authenticator subkey is used. 4986 4987 Compatibility note: Some implementations unconditionally send an 4988 encrypted EncTGSRepPart (application tag number 26) in this field 4989 regardless of whether the reply is a AS-REP or a TGS-REP. In the 4990 interests of compatibility, implementors MAY relax the check on 4991 the tag number of the decrypted ENC-PART. 4992 4993 key 4994 This field is the same as described for the ticket in section 5.3. 4995 4996 last-req 4997 This field is returned by the KDC and specifies the time(s) of the 4998 last request by a principal. Depending on what information is 4999 available, this might be the last time that a request for a 5000 ticket-granting ticket was made, or the last time that a request 5001 based on a ticket-granting ticket was successful. It also might 5002 cover all servers for a realm, or just the particular server. Some 5003 implementations MAY display this information to the user to aid in 5004 discovering unauthorized use of one's identity. It is similar in 5005 spirit to the last login time displayed when logging into 5006 timesharing systems. 5007 5008 lr-type 5009 This field indicates how the following lr-value field is to be 5010 interpreted. Negative values indicate that the information 5011 pertains only to the responding server. Non-negative values 5012 pertain to all servers for the realm. 5013 5014 If the lr-type field is zero (0), then no information is 5015 conveyed by the lr-value subfield. If the absolute value of the 5016 lr-type field is one (1), then the lr-value subfield is the 5017 time of last initial request for a TGT. If it is two (2), then 5018 the lr-value subfield is the time of last initial request. If 5019 it is three (3), then the lr-value subfield is the time of 5020 issue for the newest ticket-granting ticket used. If it is four 5021 (4), then the lr-value subfield is the time of the last 5022 renewal. If it is five (5), then the lr-value subfield is the 5023 time of last request (of any type). If it is (6), then the lr- 5024 5025 5026 5027February 2004 [Page 84] 5028 5029 5030 5031 5032 5033Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5034 5035 5036 value subfield is the time when the password will expire. If 5037 it is (7), then the lr-value subfield is the time when the 5038 account will expire. 5039 5040 lr-value 5041 This field contains the time of the last request. The time MUST 5042 be interpreted according to the contents of the accompanying 5043 lr-type subfield. 5044 5045 nonce 5046 This field is described above in section 5.4.1. 5047 5048 key-expiration 5049 The key-expiration field is part of the response from the KDC and 5050 specifies the time that the client's secret key is due to expire. 5051 The expiration might be the result of password aging or an account 5052 expiration. If present, it SHOULD be set to the earliest of the 5053 user's key expiration and account expiration. The use of this 5054 field is deprecated and the last-req field SHOULD be used to 5055 convey this information instead. This field will usually be left 5056 out of the TGS reply since the response to the TGS request is 5057 encrypted in a session key and no client information need be 5058 retrieved from the KDC database. It is up to the application 5059 client (usually the login program) to take appropriate action 5060 (such as notifying the user) if the expiration time is imminent. 5061 5062 flags, authtime, starttime, endtime, renew-till and caddr 5063 These fields are duplicates of those found in the encrypted 5064 portion of the attached ticket (see section 5.3), provided so the 5065 client MAY verify they match the intended request and to assist in 5066 proper ticket caching. If the message is of type KRB_TGS_REP, the 5067 caddr field will only be filled in if the request was for a proxy 5068 or forwarded ticket, or if the user is substituting a subset of 5069 the addresses from the ticket-granting ticket. If the client- 5070 requested addresses are not present or not used, then the 5071 addresses contained in the ticket will be the same as those 5072 included in the ticket-granting ticket. 5073 50745.5. Client/Server (CS) message specifications 5075 5076 This section specifies the format of the messages used for the 5077 authentication of the client to the application server. 5078 50795.5.1. KRB_AP_REQ definition 5080 5081 The KRB_AP_REQ message contains the Kerberos protocol version 5082 number, the message type KRB_AP_REQ, an options field to indicate 5083 any options in use, and the ticket and authenticator themselves. 5084 5085 5086 5087February 2004 [Page 85] 5088 5089 5090 5091 5092 5093Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5094 5095 5096 The KRB_AP_REQ message is often referred to as the 'authentication 5097 header'. 5098 5099 AP-REQ ::= [APPLICATION 14] SEQUENCE { 5100 pvno [0] INTEGER (5), 5101 msg-type [1] INTEGER (14), 5102 ap-options [2] APOptions, 5103 ticket [3] Ticket, 5104 authenticator [4] EncryptedData -- Authenticator 5105 } 5106 5107 APOptions ::= KerberosFlags 5108 -- reserved(0), 5109 -- use-session-key(1), 5110 -- mutual-required(2) 5111 5112 pvno and msg-type 5113 These fields are described above in section 5.4.1. msg-type is 5114 KRB_AP_REQ. 5115 5116 ap-options 5117 This field appears in the application request (KRB_AP_REQ) and 5118 affects the way the request is processed. It is a bit-field, where 5119 the selected options are indicated by the bit being set (1), and 5120 the unselected options and reserved fields being reset (0). The 5121 encoding of the bits is specified in section 5.2. The meanings of 5122 the options are: 5123 5124 Bit(s) Name Description 5125 5126 0 reserved Reserved for future expansion of this field. 5127 5128 The USE-SESSION-KEY option indicates that the 5129 ticket the client is presenting to a server 5130 1 use-session-key is encrypted in the session key from the 5131 server's ticket-granting ticket. When this 5132 option is not specified, the ticket is 5133 encrypted in the server's secret key. 5134 5135 The MUTUAL-REQUIRED option tells the server 5136 2 mutual-required that the client requires mutual 5137 authentication, and that it must respond with 5138 a KRB_AP_REP message. 5139 5140 3-31 reserved Reserved for future use. 5141 5142 ticket 5143 This field is a ticket authenticating the client to the server. 5144 5145 5146 5147February 2004 [Page 86] 5148 5149 5150 5151 5152 5153Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5154 5155 5156 authenticator 5157 This contains the encrypted authenticator, which includes the 5158 client's choice of a subkey. 5159 5160 The encrypted authenticator is included in the AP-REQ; it certifies 5161 to a server that the sender has recent knowledge of the encryption 5162 key in the accompanying ticket, to help the server detect replays. It 5163 also assists in the selection of a "true session key" to use with the 5164 particular session. The DER encoding of the following is encrypted 5165 in the ticket's session key, with a key usage value of 11 in normal 5166 application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field 5167 of a TGS-REQ exchange (see section 5.4.1): 5168 5169 -- Unencrypted authenticator 5170 Authenticator ::= [APPLICATION 2] SEQUENCE { 5171 authenticator-vno [0] INTEGER (5), 5172 crealm [1] Realm, 5173 cname [2] PrincipalName, 5174 cksum [3] Checksum OPTIONAL, 5175 cusec [4] Microseconds, 5176 ctime [5] KerberosTime, 5177 subkey [6] EncryptionKey OPTIONAL, 5178 seq-number [7] UInt32 OPTIONAL, 5179 authorization-data [8] AuthorizationData OPTIONAL 5180 } 5181 5182 authenticator-vno 5183 This field specifies the version number for the format of the 5184 authenticator. This document specifies version 5. 5185 5186 crealm and cname 5187 These fields are the same as those described for the ticket in 5188 section 5.3. 5189 5190 cksum 5191 This field contains a checksum of the application data that 5192 accompanies the KRB_AP_REQ, computed using a key usage value of 10 5193 in normal application exchanges, or 6 when used in the TGS-REQ PA- 5194 TGS-REQ AP-DATA field. 5195 5196 cusec 5197 This field contains the microsecond part of the client's 5198 timestamp. Its value (before encryption) ranges from 0 to 999999. 5199 It often appears along with ctime. The two fields are used 5200 together to specify a reasonably accurate timestamp. 5201 5202 ctime 5203 This field contains the current time on the client's host. 5204 5205 5206 5207February 2004 [Page 87] 5208 5209 5210 5211 5212 5213Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5214 5215 5216 subkey 5217 This field contains the client's choice for an encryption key 5218 which is to be used to protect this specific application session. 5219 Unless an application specifies otherwise, if this field is left 5220 out the session key from the ticket will be used. 5221 5222 seq-number 5223 This optional field includes the initial sequence number to be 5224 used by the KRB_PRIV or KRB_SAFE messages when sequence numbers 5225 are used to detect replays (It may also be used by application 5226 specific messages). When included in the authenticator this field 5227 specifies the initial sequence number for messages from the client 5228 to the server. When included in the AP-REP message, the initial 5229 sequence number is that for messages from the server to the 5230 client. When used in KRB_PRIV or KRB_SAFE messages, it is 5231 incremented by one after each message is sent. Sequence numbers 5232 fall in the range of 0 through 2^32 - 1 and wrap to zero following 5233 the value 2^32 - 1. 5234 5235 For sequence numbers to adequately support the detection of 5236 replays they SHOULD be non-repeating, even across connection 5237 boundaries. The initial sequence number SHOULD be random and 5238 uniformly distributed across the full space of possible sequence 5239 numbers, so that it cannot be guessed by an attacker and so that 5240 it and the successive sequence numbers do not repeat other 5241 sequences. In the event that more than 2^32 messages are to be 5242 generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying 5243 SHOULD be performed before sequence numbers are reused with the 5244 same encryption key. 5245 5246 Implmentation note: historically, some implementations transmit 5247 signed twos-complement numbers for sequence numbers. In the 5248 interests of compatibility, implementations MAY accept the 5249 equivalent negative number where a positive number greater than 5250 2^31 - 1 is expected. 5251 5252 Implementation note: as noted before, some implementations omit 5253 the optional sequence number when its value would be zero. 5254 Implementations MAY accept an omitted sequence number when 5255 expecting a value of zero, and SHOULD NOT transmit an 5256 Authenticator with a initial sequence number of zero. 5257 5258 authorization-data 5259 This field is the same as described for the ticket in section 5.3. 5260 It is optional and will only appear when additional restrictions 5261 are to be placed on the use of a ticket, beyond those carried in 5262 the ticket itself. 5263 5264 5265 5266 5267February 2004 [Page 88] 5268 5269 5270 5271 5272 5273Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5274 5275 52765.5.2. KRB_AP_REP definition 5277 5278 The KRB_AP_REP message contains the Kerberos protocol version 5279 number, the message type, and an encrypted time-stamp. The message 5280 is sent in response to an application request (KRB_AP_REQ) where 5281 the mutual authentication option has been selected in the ap- 5282 options field. 5283 5284 AP-REP ::= [APPLICATION 15] SEQUENCE { 5285 pvno [0] INTEGER (5), 5286 msg-type [1] INTEGER (15), 5287 enc-part [2] EncryptedData -- EncAPRepPart 5288 } 5289 5290 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 5291 ctime [0] KerberosTime, 5292 cusec [1] Microseconds, 5293 subkey [2] EncryptionKey OPTIONAL, 5294 seq-number [3] UInt32 OPTIONAL 5295 } 5296 5297 The encoded EncAPRepPart is encrypted in the shared session key of 5298 the ticket. The optional subkey field can be used in an 5299 application-arranged negotiation to choose a per association 5300 session key. 5301 5302 pvno and msg-type 5303 These fields are described above in section 5.4.1. msg-type is 5304 KRB_AP_REP. 5305 5306 enc-part 5307 This field is described above in section 5.4.2. It is computed 5308 with a key usage value of 12. 5309 5310 ctime 5311 This field contains the current time on the client's host. 5312 5313 cusec 5314 This field contains the microsecond part of the client's 5315 timestamp. 5316 5317 subkey 5318 This field contains an encryption key which is to be used to 5319 protect this specific application session. See section 3.2.6 for 5320 specifics on how this field is used to negotiate a key. Unless an 5321 application specifies otherwise, if this field is left out, the 5322 sub-session key from the authenticator, or if also left out, the 5323 session key from the ticket will be used. 5324 5325 5326 5327February 2004 [Page 89] 5328 5329 5330 5331 5332 5333Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5334 5335 5336 seq-number 5337 This field is described above in section 5.3.2. 5338 53395.5.3. Error message reply 5340 5341 If an error occurs while processing the application request, the 5342 KRB_ERROR message will be sent in response. See section 5.9.1 for 5343 the format of the error message. The cname and crealm fields MAY 5344 be left out if the server cannot determine their appropriate 5345 values from the corresponding KRB_AP_REQ message. If the 5346 authenticator was decipherable, the ctime and cusec fields will 5347 contain the values from it. 5348 53495.6. KRB_SAFE message specification 5350 5351 This section specifies the format of a message that can be used by 5352 either side (client or server) of an application to send a tamper- 5353 proof message to its peer. It presumes that a session key has 5354 previously been exchanged (for example, by using the 5355 KRB_AP_REQ/KRB_AP_REP messages). 5356 53575.6.1. KRB_SAFE definition 5358 5359 The KRB_SAFE message contains user data along with a collision- 5360 proof checksum keyed with the last encryption key negotiated via 5361 subkeys, or the session key if no negotiation has occurred. The 5362 message fields are: 5363 5364 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 5365 pvno [0] INTEGER (5), 5366 msg-type [1] INTEGER (20), 5367 safe-body [2] KRB-SAFE-BODY, 5368 cksum [3] Checksum 5369 } 5370 5371 KRB-SAFE-BODY ::= SEQUENCE { 5372 user-data [0] OCTET STRING, 5373 timestamp [1] KerberosTime OPTIONAL, 5374 usec [2] Microseconds OPTIONAL, 5375 seq-number [3] UInt32 OPTIONAL, 5376 s-address [4] HostAddress, 5377 r-address [5] HostAddress OPTIONAL 5378 } 5379 5380 pvno and msg-type 5381 These fields are described above in section 5.4.1. msg-type is 5382 KRB_SAFE. 5383 5384 5385 5386 5387February 2004 [Page 90] 5388 5389 5390 5391 5392 5393Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5394 5395 5396 safe-body 5397 This field is a placeholder for the body of the KRB-SAFE message. 5398 5399 cksum 5400 This field contains the checksum of the application data, computed 5401 with a key usage value of 15. 5402 5403 The checksum is computed over the encoding of the KRB-SAFE 5404 sequence. First, the cksum is set to a type zero, zero-length 5405 value and the checksum is computed over the encoding of the KRB- 5406 SAFE sequence, then the checksum is set to the result of that 5407 computation, and finally the KRB-SAFE sequence is encoded again. 5408 This method, while different than the one specified in RFC 1510, 5409 corresponds to existing practice. 5410 5411 user-data 5412 This field is part of the KRB_SAFE and KRB_PRIV messages and 5413 contain the application specific data that is being passed from 5414 the sender to the recipient. 5415 5416 timestamp 5417 This field is part of the KRB_SAFE and KRB_PRIV messages. Its 5418 contents are the current time as known by the sender of the 5419 message. By checking the timestamp, the recipient of the message 5420 is able to make sure that it was recently generated, and is not a 5421 replay. 5422 5423 usec 5424 This field is part of the KRB_SAFE and KRB_PRIV headers. It 5425 contains the microsecond part of the timestamp. 5426 5427 seq-number 5428 This field is described above in section 5.3.2. 5429 5430 s-address 5431 Sender's address. 5432 5433 This field specifies the address in use by the sender of the 5434 message. 5435 5436 r-address 5437 This field specifies the address in use by the recipient of the 5438 message. It MAY be omitted for some uses (such as broadcast 5439 protocols), but the recipient MAY arbitrarily reject such 5440 messages. This field, along with s-address, can be used to help 5441 detect messages which have been incorrectly or maliciously 5442 delivered to the wrong recipient. 5443 5444 5445 5446 5447February 2004 [Page 91] 5448 5449 5450 5451 5452 5453Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5454 5455 54565.7. KRB_PRIV message specification 5457 5458 This section specifies the format of a message that can be used by 5459 either side (client or server) of an application to securely and 5460 privately send a message to its peer. It presumes that a session 5461 key has previously been exchanged (for example, by using the 5462 KRB_AP_REQ/KRB_AP_REP messages). 5463 54645.7.1. KRB_PRIV definition 5465 5466 The KRB_PRIV message contains user data encrypted in the Session 5467 Key. The message fields are: 5468 5469 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 5470 pvno [0] INTEGER (5), 5471 msg-type [1] INTEGER (21), 5472 -- NOTE: there is no [2] tag 5473 enc-part [3] EncryptedData -- EncKrbPrivPart 5474 } 5475 5476 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 5477 user-data [0] OCTET STRING, 5478 timestamp [1] KerberosTime OPTIONAL, 5479 usec [2] Microseconds OPTIONAL, 5480 seq-number [3] UInt32 OPTIONAL, 5481 s-address [4] HostAddress -- sender's addr --, 5482 r-address [5] HostAddress OPTIONAL -- recip's addr 5483 } 5484 5485 pvno and msg-type 5486 These fields are described above in section 5.4.1. msg-type is 5487 KRB_PRIV. 5488 5489 enc-part 5490 This field holds an encoding of the EncKrbPrivPart sequence 5491 encrypted under the session key, with a key usage value of 13. 5492 This encrypted encoding is used for the enc-part field of the KRB- 5493 PRIV message. 5494 5495 user-data, timestamp, usec, s-address and r-address 5496 These fields are described above in section 5.6.1. 5497 5498 seq-number 5499 This field is described above in section 5.3.2. 5500 55015.8. KRB_CRED message specification 5502 5503 This section specifies the format of a message that can be used to 5504 5505 5506 5507February 2004 [Page 92] 5508 5509 5510 5511 5512 5513Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5514 5515 5516 send Kerberos credentials from one principal to another. It is 5517 presented here to encourage a common mechanism to be used by 5518 applications when forwarding tickets or providing proxies to 5519 subordinate servers. It presumes that a session key has already 5520 been exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP 5521 messages. 5522 55235.8.1. KRB_CRED definition 5524 5525 The KRB_CRED message contains a sequence of tickets to be sent and 5526 information needed to use the tickets, including the session key 5527 from each. The information needed to use the tickets is encrypted 5528 under an encryption key previously exchanged or transferred 5529 alongside the KRB_CRED message. The message fields are: 5530 5531 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 5532 pvno [0] INTEGER (5), 5533 msg-type [1] INTEGER (22), 5534 tickets [2] SEQUENCE OF Ticket, 5535 enc-part [3] EncryptedData -- EncKrbCredPart 5536 } 5537 5538 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 5539 ticket-info [0] SEQUENCE OF KrbCredInfo, 5540 nonce [1] UInt32 OPTIONAL, 5541 timestamp [2] KerberosTime OPTIONAL, 5542 usec [3] Microseconds OPTIONAL, 5543 s-address [4] HostAddress OPTIONAL, 5544 r-address [5] HostAddress OPTIONAL 5545 } 5546 5547 KrbCredInfo ::= SEQUENCE { 5548 key [0] EncryptionKey, 5549 prealm [1] Realm OPTIONAL, 5550 pname [2] PrincipalName OPTIONAL, 5551 flags [3] TicketFlags OPTIONAL, 5552 authtime [4] KerberosTime OPTIONAL, 5553 starttime [5] KerberosTime OPTIONAL, 5554 endtime [6] KerberosTime OPTIONAL, 5555 renew-till [7] KerberosTime OPTIONAL, 5556 srealm [8] Realm OPTIONAL, 5557 sname [9] PrincipalName OPTIONAL, 5558 caddr [10] HostAddresses OPTIONAL 5559 } 5560 5561 pvno and msg-type 5562 These fields are described above in section 5.4.1. msg-type is 5563 KRB_CRED. 5564 5565 5566 5567February 2004 [Page 93] 5568 5569 5570 5571 5572 5573Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5574 5575 5576 tickets 5577 These are the tickets obtained from the KDC specifically for use 5578 by the intended recipient. Successive tickets are paired with the 5579 corresponding KrbCredInfo sequence from the enc-part of the KRB- 5580 CRED message. 5581 5582 enc-part 5583 This field holds an encoding of the EncKrbCredPart sequence 5584 encrypted under the session key shared between the sender and the 5585 intended recipient, with a key usage value of 14. This encrypted 5586 encoding is used for the enc-part field of the KRB-CRED message. 5587 5588 Implementation note: implementations of certain applications, most 5589 notably certain implementations of the Kerberos GSS-API mechanism, 5590 do not separately encrypt the contents of the EncKrbCredPart of 5591 the KRB-CRED message when sending it. In the case of those GSS- 5592 API mechanisms, this is not a security vulnerability, as the 5593 entire KRB-CRED message is itself embedded in an encrypted 5594 message. 5595 5596 nonce 5597 If practical, an application MAY require the inclusion of a nonce 5598 generated by the recipient of the message. If the same value is 5599 included as the nonce in the message, it provides evidence that 5600 the message is fresh and has not been replayed by an attacker. A 5601 nonce MUST NEVER be reused. 5602 5603 timestamp and usec 5604 These fields specify the time that the KRB-CRED message was 5605 generated. The time is used to provide assurance that the message 5606 is fresh. 5607 5608 s-address and r-address 5609 These fields are described above in section 5.6.1. They are used 5610 optionally to provide additional assurance of the integrity of the 5611 KRB-CRED message. 5612 5613 key 5614 This field exists in the corresponding ticket passed by the KRB- 5615 CRED message and is used to pass the session key from the sender 5616 to the intended recipient. The field's encoding is described in 5617 section 5.2.9. 5618 5619 The following fields are optional. If present, they can be associated 5620 with the credentials in the remote ticket file. If left out, then it 5621 is assumed that the recipient of the credentials already knows their 5622 value. 5623 5624 5625 5626 5627February 2004 [Page 94] 5628 5629 5630 5631 5632 5633Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5634 5635 5636 prealm and pname 5637 The name and realm of the delegated principal identity. 5638 5639 flags, authtime, starttime, endtime, renew-till, srealm, sname, and 5640 caddr 5641 These fields contain the values of the corresponding fields from 5642 the ticket found in the ticket field. Descriptions of the fields 5643 are identical to the descriptions in the KDC-REP message. 5644 56455.9. Error message specification 5646 5647 This section specifies the format for the KRB_ERROR message. The 5648 fields included in the message are intended to return as much 5649 information as possible about an error. It is not expected that 5650 all the information required by the fields will be available for 5651 all types of errors. If the appropriate information is not 5652 available when the message is composed, the corresponding field 5653 will be left out of the message. 5654 5655 Note that since the KRB_ERROR message is not integrity protected, 5656 it is quite possible for an intruder to synthesize or modify such 5657 a message. In particular, this means that the client SHOULD NOT 5658 use any fields in this message for security-critical purposes, 5659 such as setting a system clock or generating a fresh 5660 authenticator. The message can be useful, however, for advising a 5661 user on the reason for some failure. 5662 56635.9.1. KRB_ERROR definition 5664 5665 The KRB_ERROR message consists of the following fields: 5666 5667 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 5668 pvno [0] INTEGER (5), 5669 msg-type [1] INTEGER (30), 5670 ctime [2] KerberosTime OPTIONAL, 5671 cusec [3] Microseconds OPTIONAL, 5672 stime [4] KerberosTime, 5673 susec [5] Microseconds, 5674 error-code [6] Int32, 5675 crealm [7] Realm OPTIONAL, 5676 cname [8] PrincipalName OPTIONAL, 5677 realm [9] Realm -- service realm --, 5678 sname [10] PrincipalName -- service name --, 5679 e-text [11] KerberosString OPTIONAL, 5680 e-data [12] OCTET STRING OPTIONAL 5681 } 5682 5683 pvno and msg-type 5684 5685 5686 5687February 2004 [Page 95] 5688 5689 5690 5691 5692 5693Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5694 5695 5696 These fields are described above in section 5.4.1. msg-type is 5697 KRB_ERROR. 5698 5699 ctime 5700 This field is described above in section 5.5.2. 5701 5702 cusec 5703 This field is described above in section 5.5.2. 5704 5705 stime 5706 This field contains the current time on the server. It is of type 5707 KerberosTime. 5708 5709 susec 5710 This field contains the microsecond part of the server's 5711 timestamp. Its value ranges from 0 to 999999. It appears along 5712 with stime. The two fields are used in conjunction to specify a 5713 reasonably accurate timestamp. 5714 5715 error-code 5716 This field contains the error code returned by Kerberos or the 5717 server when a request fails. To interpret the value of this field 5718 see the list of error codes in section 7.5.9. Implementations are 5719 encouraged to provide for national language support in the display 5720 of error messages. 5721 5722 crealm, cname, realm and sname 5723 These fields are described above in section 5.3. 5724 5725 e-text 5726 This field contains additional text to help explain the error code 5727 associated with the failed request (for example, it might include 5728 a principal name which was unknown). 5729 5730 e-data 5731 This field contains additional data about the error for use by the 5732 application to help it recover from or handle the error. If the 5733 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 5734 contain an encoding of a sequence of padata fields, each 5735 corresponding to an acceptable pre-authentication method and 5736 optionally containing data for the method: 5737 5738 METHOD-DATA ::= SEQUENCE OF PA-DATA 5739 5740 For error codes defined in this document other than 5741 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field 5742 are implementation-defined. Similarly, for future error codes, the 5743 format and contents of the e-data field are implementation-defined 5744 5745 5746 5747February 2004 [Page 96] 5748 5749 5750 5751 5752 5753Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5754 5755 5756 unless specified. Whether defined by the implementation or in a 5757 future document, the e-data field MAY take the form of TYPED-DATA: 5758 5759 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5760 data-type [0] INTEGER, 5761 data-value [1] OCTET STRING OPTIONAL 5762 } 5763 57645.10. Application Tag Numbers 5765 5766 The following table lists the application class tag numbers used 5767 by various data types defined in this section. 5768 5769 Tag Number(s) Type Name Comments 5770 5771 0 unused 5772 5773 1 Ticket PDU 5774 5775 2 Authenticator non-PDU 5776 5777 3 EncTicketPart non-PDU 5778 5779 4-9 unused 5780 5781 10 AS-REQ PDU 5782 5783 11 AS-REP PDU 5784 5785 12 TGS-REQ PDU 5786 5787 13 TGS-REP PDU 5788 5789 14 AP-REQ PDU 5790 5791 15 AP-REP PDU 5792 5793 16 RESERVED16 TGT-REQ (for user-to-user) 5794 5795 17 RESERVED17 TGT-REP (for user-to-user) 5796 5797 18-19 unused 5798 5799 20 KRB-SAFE PDU 5800 5801 21 KRB-PRIV PDU 5802 5803 22 KRB-CRED PDU 5804 5805 5806 5807February 2004 [Page 97] 5808 5809 5810 5811 5812 5813Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5814 5815 5816 23-24 unused 5817 5818 25 EncASRepPart non-PDU 5819 5820 26 EncTGSRepPart non-PDU 5821 5822 27 EncApRepPart non-PDU 5823 5824 28 EncKrbPrivPart non-PDU 5825 5826 29 EncKrbCredPart non-PDU 5827 5828 30 KRB-ERROR PDU 5829 5830 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above 5831 are the only ASN.1 types intended as top-level types of the 5832 Kerberos protocol, and are the only types that may be used as 5833 elements in another protocol that makes use of Kerberos. 5834 58356. Naming Constraints 5836 58376.1. Realm Names 5838 5839 Although realm names are encoded as GeneralStrings and although a 5840 realm can technically select any name it chooses, interoperability 5841 across realm boundaries requires agreement on how realm names are 5842 to be assigned, and what information they imply. 5843 5844 To enforce these conventions, each realm MUST conform to the 5845 conventions itself, and it MUST require that any realms with which 5846 inter-realm keys are shared also conform to the conventions and 5847 require the same from its neighbors. 5848 5849 Kerberos realm names are case sensitive. Realm names that differ 5850 only in the case of the characters are not equivalent. There are 5851 presently three styles of realm names: domain, X500, and other. 5852 Examples of each style follow: 5853 5854 domain: ATHENA.MIT.EDU 5855 X500: C=US/O=OSF 5856 other: NAMETYPE:rest/of.name=without-restrictions 5857 5858 Domain style realm names MUST look like domain names: they consist 5859 of components separated by periods (.) and they contain neither 5860 colons (:) nor slashes (/). Though domain names themselves are 5861 case insensitive, in order for realms to match, the case must 5862 match as well. When establishing a new realm name based on an 5863 internet domain name it is recommended by convention that the 5864 5865 5866 5867February 2004 [Page 98] 5868 5869 5870 5871 5872 5873Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5874 5875 5876 characters be converted to upper case. 5877 5878 X.500 names contain an equal (=) and cannot contain a colon (:) 5879 before the equal. The realm names for X.500 names will be string 5880 representations of the names with components separated by slashes. 5881 Leading and trailing slashes will not be included. Note that the 5882 slash separator is consistent with Kerberos implementations based 5883 on RFC1510, but it is different from the separator recommended in 5884 RFC2253. 5885 5886 Names that fall into the other category MUST begin with a prefix 5887 that contains no equal (=) or period (.) and the prefix MUST be 5888 followed by a colon (:) and the rest of the name. All prefixes 5889 expect those beginning with used. Presently none are assigned. 5890 5891 The reserved category includes strings which do not fall into the 5892 first three categories. All names in this category are reserved. 5893 It is unlikely that names will be assigned to this category unless 5894 there is a very strong argument for not using the 'other' 5895 category. 5896 5897 These rules guarantee that there will be no conflicts between the 5898 various name styles. The following additional constraints apply to 5899 the assignment of realm names in the domain and X.500 categories: 5900 the name of a realm for the domain or X.500 formats must either be 5901 used by the organization owning (to whom it was assigned) an 5902 Internet domain name or X.500 name, or in the case that no such 5903 names are registered, authority to use a realm name MAY be derived 5904 from the authority of the parent realm. For example, if there is 5905 no domain name for E40.MIT.EDU, then the administrator of the 5906 MIT.EDU realm can authorize the creation of a realm with that 5907 name. 5908 5909 This is acceptable because the organization to which the parent is 5910 assigned is presumably the organization authorized to assign names 5911 to its children in the X.500 and domain name systems as well. If 5912 the parent assigns a realm name without also registering it in the 5913 domain name or X.500 hierarchy, it is the parent's responsibility 5914 to make sure that there will not in the future exist a name 5915 identical to the realm name of the child unless it is assigned to 5916 the same entity as the realm name. 5917 59186.2. Principal Names 5919 5920 As was the case for realm names, conventions are needed to ensure 5921 that all agree on what information is implied by a principal name. 5922 The name-type field that is part of the principal name indicates 5923 the kind of information implied by the name. The name-type SHOULD 5924 5925 5926 5927February 2004 [Page 99] 5928 5929 5930 5931 5932 5933Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5934 5935 5936 be treated only as a hint to interpreting the meaning of a name. 5937 It is not significant when checking for equivalence. Principal 5938 names that differ only in the name-type identify the same 5939 principal. The name type does not partition the name space. 5940 Ignoring the name type, no two names can be the same (i.e. at 5941 least one of the components, or the realm, MUST be different). The 5942 following name types are defined: 5943 5944 name-type value meaning 5945 5946 name types 5947 5948 NT-UNKNOWN 0 Name type not known 5949 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5950 NT-SRV-INST 2 Service and other unique instance (krbtgt) 5951 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 5952 NT-SRV-XHST 4 Service with host as remaining components 5953 NT-UID 5 Unique ID 5954 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5955 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 5956 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 5957 5958 When a name implies no information other than its uniqueness at a 5959 particular time the name type PRINCIPAL SHOULD be used. The 5960 principal name type SHOULD be used for users, and it might also be 5961 used for a unique server. If the name is a unique machine 5962 generated ID that is guaranteed never to be reassigned then the 5963 name type of UID SHOULD be used (note that it is generally a bad 5964 idea to reassign names of any type since stale entries might 5965 remain in access control lists). 5966 5967 If the first component of a name identifies a service and the 5968 remaining components identify an instance of the service in a 5969 server specified manner, then the name type of SRV-INST SHOULD be 5970 used. An example of this name type is the Kerberos ticket-granting 5971 service whose name has a first component of krbtgt and a second 5972 component identifying the realm for which the ticket is valid. 5973 5974 If the first component of a name identifies a service and there is 5975 a single component following the service name identifying the 5976 instance as the host on which the server is running, then the name 5977 type SRV-HST SHOULD be used. This type is typically used for 5978 Internet services such as telnet and the Berkeley R commands. If 5979 the separate components of the host name appear as successive 5980 components following the name of the service, then the name type 5981 SRV-XHST SHOULD be used. This type might be used to identify 5982 servers on hosts with X.500 names where the slash (/) might 5983 otherwise be ambiguous. 5984 5985 5986 5987February 2004 [Page 100] 5988 5989 5990 5991 5992 5993Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5994 5995 5996 A name type of NT-X500-PRINCIPAL SHOULD be used when a name from 5997 an X.509 certificate is translated into a Kerberos name. The 5998 encoding of the X.509 name as a Kerberos principal shall conform 5999 to the encoding rules specified in RFC 2253. 6000 6001 A name type of SMTP allows a name to be of a form that resembles a 6002 SMTP email name. This name, including an "@" and a domain name, is 6003 used as the one component of the principal name. 6004 6005 A name type of UNKNOWN SHOULD be used when the form of the name is 6006 not known. When comparing names, a name of type UNKNOWN will match 6007 principals authenticated with names of any type. A principal 6008 authenticated with a name of type UNKNOWN, however, will only 6009 match other names of type UNKNOWN. 6010 6011 Names of any type with an initial component of 'krbtgt' are 6012 reserved for the Kerberos ticket granting service. See section 7.3 6013 for the form of such names. 6014 60156.2.1. Name of server principals 6016 6017 The principal identifier for a server on a host will generally be 6018 composed of two parts: (1) the realm of the KDC with which the 6019 server is registered, and (2) a two-component name of type NT-SRV- 6020 HST if the host name is an Internet domain name or a multi- 6021 component name of type NT-SRV-XHST if the name of the host is of a 6022 form such as X.500 that allows slash (/) separators. The first 6023 component of the two- or multi-component name will identify the 6024 service and the latter components will identify the host. Where 6025 the name of the host is not case sensitive (for example, with 6026 Internet domain names) the name of the host MUST be lower case. If 6027 specified by the application protocol for services such as telnet 6028 and the Berkeley R commands which run with system privileges, the 6029 first component MAY be the string 'host' instead of a service 6030 specific identifier. 6031 60327. Constants and other defined values 6033 60347.1. Host address types 6035 6036 All negative values for the host address type are reserved for 6037 local use. All non-negative values are reserved for officially 6038 assigned type fields and interpretations. 6039 6040 Internet (IPv4) Addresses 6041 6042 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded 6043 in MSB order. The IPv4 loopback address SHOULD NOT appear in a 6044 6045 6046 6047February 2004 [Page 101] 6048 6049 6050 6051 6052 6053Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6054 6055 6056 Kerberos packet. The type of IPv4 addresses is two (2). 6057 6058 Internet (IPv6) Addresses 6059 6060 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, 6061 encoded in MSB order. The type of IPv6 addresses is twenty-four 6062 (24). The following addresses MUST NOT appear in any Kerberos 6063 packet: 6064 6065 * the Unspecified Address 6066 * the Loopback Address 6067 * Link-Local addresses 6068 6069 IPv4-mapped IPv6 addresses MUST be represented as addresses of 6070 type 2. 6071 6072 DECnet Phase IV addresses 6073 6074 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB 6075 order. The type of DECnet Phase IV addresses is twelve (12). 6076 6077 Netbios addresses 6078 6079 Netbios addresses are 16-octet addresses typically composed of 1 6080 to 15 alphanumeric characters and padded with the US-ASCII SPC 6081 character (code 32). The 16th octet MUST be the US-ASCII NUL 6082 character (code 0). The type of Netbios addresses is twenty (20). 6083 6084 Directional Addresses 6085 6086 In many environments, including the sender address in KRB_SAFE and 6087 KRB_PRIV messages is undesirable because the addresses may be 6088 changed in transport by network address translators. However, if 6089 these addresses are removed, the messages may be subject to a 6090 reflection attack in which a message is reflected back to its 6091 originator. The directional address type provides a way to avoid 6092 transport addresses and reflection attacks. Directional addresses 6093 are encoded as four byte unsigned integers in network byte order. 6094 If the message is originated by the party sending the original 6095 KRB_AP_REQ message, then an address of 0 SHOULD be used. If the 6096 message is originated by the party to whom that KRB_AP_REQ was 6097 sent, then the address 1 SHOULD be used. Applications involving 6098 multiple parties can specify the use of other addresses. 6099 6100 Directional addresses MUST only be used for the sender address 6101 field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used 6102 as a ticket address or in a KRB_AP_REQ message. This address type 6103 SHOULD only be used in situations where the sending party knows 6104 6105 6106 6107February 2004 [Page 102] 6108 6109 6110 6111 6112 6113Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6114 6115 6116 that the receiving party supports the address type. This generally 6117 means that directional addresses may only be used when the 6118 application protocol requires their support. Directional addresses 6119 are type (3). 6120 61217.2. KDC messaging - IP Transports 6122 6123 Kerberos defines two IP transport mechanisms for communication 6124 between clients and servers: UDP/IP and TCP/IP. 6125 61267.2.1. UDP/IP transport 6127 6128 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 6129 requests and SHOULD listen for such requests on port 88 (decimal) 6130 unless specifically configured to listen on an alternative UDP 6131 port. Alternate ports MAY be used when running multiple KDCs for 6132 multiple realms on the same host. 6133 6134 Kerberos clients supporting IP transports SHOULD support the 6135 sending of UDP requests. Clients SHOULD use KDC discovery [7.2.3] 6136 to identify the IP address and port to which they will send their 6137 request. 6138 6139 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 6140 transport, the client shall send a UDP datagram containing only an 6141 encoding of the request to the KDC. The KDC will respond with a 6142 reply datagram containing only an encoding of the reply message 6143 (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the 6144 sender's IP address. The response to a request made through UDP/IP 6145 transport MUST also use UDP/IP transport. If the response can not 6146 be handled using UDP (for example because it is too large), the 6147 KDC MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to 6148 retry the request using the TCP transport. 6149 61507.2.2. TCP/IP transport 6151 6152 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 6153 requests and SHOULD listen for such requests on port 88 (decimal) 6154 unless specifically configured to listen on an alternate TCP port. 6155 Alternate ports MAY be used when running multiple KDCs for 6156 multiple realms on the same host. 6157 6158 Clients MUST support the sending of TCP requests, but MAY choose 6159 to initially try a request using the UDP transport. Clients SHOULD 6160 use KDC discovery [7.2.3] to identify the IP address and port to 6161 which they will send their request. 6162 6163 Implementation note: Some extensions to the Kerberos protocol will 6164 6165 6166 6167February 2004 [Page 103] 6168 6169 6170 6171 6172 6173Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6174 6175 6176 not succeed if any client or KDC not supporting the TCP transport 6177 is involved. Implementations of RFC 1510 were not required to 6178 support TCP/IP transports. 6179 6180 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, 6181 the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned 6182 to the client on the same TCP stream that was established for the 6183 request. The KDC MAY close the TCP stream after sending a 6184 response, but MAY leave the stream open for a reasonable period of 6185 time if it expects a followup. Care must be taken in managing 6186 TCP/IP connections on the KDC to prevent denial of service attacks 6187 based on the number of open TCP/IP connections. 6188 6189 The client MUST be prepared to have the stream closed by the KDC 6190 at anytime after the receipt of a response. A stream closure 6191 SHOULD NOT be treated as a fatal error. Instead, if multiple 6192 exchanges are required (e.g., certain forms of pre-authentication) 6193 the client may need to establish a new connection when it is ready 6194 to send subsequent messages. A client MAY close the stream after 6195 receiving a response, and SHOULD close the stream if it does not 6196 expect to send followup messages. 6197 6198 A client MAY send multiple requests before receiving responses, 6199 though it must be prepared to handle the connection being closed 6200 after the first response. 6201 6202 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) 6203 sent over the TCP stream is preceded by the length of the request 6204 as 4 octets in network byte order. The high bit of the length is 6205 reserved for future expansion and MUST currently be set to zero. 6206 If a KDC that does not understand how to interpret a set high bit 6207 of the length encoding receives a request with the high order bit 6208 of the length set, it MUST return a KRB-ERROR message with the 6209 error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream. 6210 6211 If multiple requests are sent over a single TCP connection, and 6212 the KDC sends multiple responses, the KDC is not required to send 6213 the responses in the order of the corresponding requests. This may 6214 permit some implementations to send each response as soon as it is 6215 ready even if earlier requests are still being processed (for 6216 example, waiting for a response from an external device or 6217 database). 6218 62197.2.3. KDC Discovery on IP Networks 6220 6221 Kerberos client implementations MUST provide a means for the 6222 client to determine the location of the Kerberos Key Distribution 6223 Centers (KDCs). Traditionally, Kerberos implementations have 6224 6225 6226 6227February 2004 [Page 104] 6228 6229 6230 6231 6232 6233Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6234 6235 6236 stored such configuration information in a file on each client 6237 machine. Experience has shown this method of storing configuration 6238 information presents problems with out-of-date information and 6239 scaling problems, especially when using cross-realm 6240 authentication. This section describes a method for using the 6241 Domain Name System [RFC 1035] for storing KDC location 6242 information. 6243 62447.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 6245 6246 In Kerberos, realm names are case sensitive. While it is strongly 6247 encouraged that all realm names be all upper case this 6248 recommendation has not been adopted by all sites. Some sites use 6249 all lower case names and other use mixed case. DNS on the other 6250 hand is case insensitive for queries. Since the realm names 6251 "MYREALM", "myrealm", and "MyRealm" are all different, but resolve 6252 the same in the domain name system, it is necessary that only one 6253 of the possible combinations of upper and lower case characters be 6254 used in realm names. 6255 62567.2.3.2. Specifying KDC Location information with DNS SRV records 6257 6258 KDC location information is to be stored using the DNS SRV RR [RFC 6259 2782]. The format of this RR is as follows: 6260 6261 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target 6262 6263 The Service name for Kerberos is always "kerberos". 6264 6265 The Proto can be one of "udp", "tcp". If these SRV records are to 6266 be used, both "udp" and "tcp" records MUST be specified for all 6267 KDC deployments. 6268 6269 The Realm is the Kerberos realm that this record corresponds to. 6270 The realm MUST be a domain style realm name. 6271 6272 TTL, Class, SRV, Priority, Weight, and Target have the standard 6273 meaning as defined in RFC 2782. 6274 6275 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV 6276 records SHOULD be the value assigned to "kerberos" by the Internet 6277 Assigned Number Authority: 88 (decimal) unless the KDC is 6278 configured to listen on an alternate TCP port. 6279 6280 Implementation note: Many existing client implementations do not 6281 support KDC Discovery and are configured to send requests to the 6282 IANA assigned port (88 decimal), so it is strongly recommended 6283 that KDCs be configured to listen on that port. 6284 6285 6286 6287February 2004 [Page 105] 6288 6289 6290 6291 6292 6293Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6294 6295 62967.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 6297 6298 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 6299 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 6300 should be directed to kdc1.example.com first as per the specified 6301 priority. Weights are not used in these sample records. 6302 6303 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 6304 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 6305 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 6306 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 6307 63087.3. Name of the TGS 6309 6310 The principal identifier of the ticket-granting service shall be 6311 composed of three parts: (1) the realm of the KDC issuing the TGS 6312 ticket (2) a two-part name of type NT-SRV-INST, with the first 6313 part "krbtgt" and the second part the name of the realm which will 6314 accept the ticket-granting ticket. For example, a ticket-granting 6315 ticket issued by the ATHENA.MIT.EDU realm to be used to get 6316 tickets from the ATHENA.MIT.EDU KDC has a principal identifier of 6317 "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 6318 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 6319 used to get tickets from the MIT.EDU realm has a principal 6320 identifier of "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") 6321 (name). 6322 63237.4. OID arc for KerberosV5 6324 6325 This OID MAY be used to identify Kerberos protocol messages 6326 encapsulated in other protocols. It also designates the OID arc 6327 for KerberosV5-related OIDs assigned by future IETF action. 6328 Implementation note:: RFC 1510 had an incorrect value (5) for 6329 "dod" in its OID. 6330 6331 id-krb5 OBJECT IDENTIFIER ::= { 6332 iso(1) identified-organization(3) dod(6) internet(1) 6333 security(5) kerberosV5(2) 6334 } 6335 6336 6337 Assignment of OIDs beneath the id-krb5 arc must be obtained by 6338 contacting the registrar for the id-krb5 arc, or its designee. At 6339 the time of the issuance of this RFC, such registrations can be 6340 obtained by contacting krb5-oid-registrar@mit.edu. 6341 63427.5. Protocol constants and associated values 6343 6344 6345 6346 6347February 2004 [Page 106] 6348 6349 6350 6351 6352 6353Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6354 6355 6356 The following tables list constants used in the protocol and 6357 define their meanings. Ranges are specified in the "specification" 6358 section that limit the values of constants for which values are 6359 defined here. This allows implementations to make assumptions 6360 about the maximum values that will be received for these 6361 constants. Implementation receiving values outside the range 6362 specified in the "specification" section MAY reject the request, 6363 but they MUST recover cleanly. 6364 63657.5.1. Key usage numbers 6366 6367 The encryption and checksum specifications in [@KCRYPTO] require 6368 as input a "key usage number", to alter the encryption key used in 6369 any specific message, to make certain types of cryptographic 6370 attack more difficult. These are the key usage values assigned in 6371 this document: 6372 6373 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted 6374 with the client key (section 5.2.7.2) 6375 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session 6376 key or application session key), encrypted with the 6377 service key (section 5.3) 6378 3. AS-REP encrypted part (includes TGS session key or 6379 application session key), encrypted with the client key 6380 (section 5.4.2) 6381 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 6382 the TGS session key (section 5.4.1) 6383 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 6384 the TGS authenticator subkey (section 5.4.1) 6385 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 6386 keyed with the TGS session key (sections 5.5.1) 6387 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator 6388 (includes TGS authenticator subkey), encrypted with the 6389 TGS session key (section 5.5.1) 6390 8. TGS-REP encrypted part (includes application session 6391 key), encrypted with the TGS session key (section 6392 5.4.2) 6393 9. TGS-REP encrypted part (includes application session 6394 key), encrypted with the TGS authenticator subkey 6395 (section 5.4.2) 6396 10. AP-REQ Authenticator cksum, keyed with the application 6397 session key (section 5.5.1) 6398 11. AP-REQ Authenticator (includes application 6399 authenticator subkey), encrypted with the application 6400 session key (section 5.5.1) 6401 12. AP-REP encrypted part (includes application session 6402 subkey), encrypted with the application session key 6403 (section 5.5.2) 6404 6405 6406 6407February 2004 [Page 107] 6408 6409 6410 6411 6412 6413Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6414 6415 6416 13. KRB-PRIV encrypted part, encrypted with a key chosen by 6417 the application (section 5.7.1) 6418 14. KRB-CRED encrypted part, encrypted with a key chosen by 6419 the application (section 5.8.1) 6420 15. KRB-SAFE cksum, keyed with a key chosen by the 6421 application (section 5.6.1) 6422 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) 6423 22-25. Reserved for use in GSSAPI mechanisms derived from RFC 6424 1964. (raeburn/MIT) 6425 16-18,20-21,26-511. Reserved for future use in Kerberos and related 6426 protocols. 6427 512-1023. Reserved for uses internal to a Kerberos 6428 implementation. 6429 1024. Encryption for application use in protocols that 6430 do not specify key usage values 6431 1025. Checksums for application use in protocols that 6432 do not specify key usage values 6433 1026-2047. Reserved for application use. 6434 6435 64367.5.2. PreAuthentication Data Types 6437 6438 padata and data types padata-type value comment 6439 6440 PA-TGS-REQ 1 6441 PA-ENC-TIMESTAMP 2 6442 PA-PW-SALT 3 6443 [reserved] 4 6444 PA-ENC-UNIX-TIME 5 (deprecated) 6445 PA-SANDIA-SECUREID 6 6446 PA-SESAME 7 6447 PA-OSF-DCE 8 6448 PA-CYBERSAFE-SECUREID 9 6449 PA-AFS3-SALT 10 6450 PA-ETYPE-INFO 11 6451 PA-SAM-CHALLENGE 12 (sam/otp) 6452 PA-SAM-RESPONSE 13 (sam/otp) 6453 PA-PK-AS-REQ 14 (pkinit) 6454 PA-PK-AS-REP 15 (pkinit) 6455 PA-ETYPE-INFO2 19 (replaces pa-etype-info) 6456 PA-USE-SPECIFIED-KVNO 20 6457 PA-SAM-REDIRECT 21 (sam/otp) 6458 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 6459 TD-PADATA 22 (embeds padata) 6460 PA-SAM-ETYPE-INFO 23 (sam/otp) 6461 PA-ALT-PRINC 24 (crawdad@fnal.gov) 6462 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 6463 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 6464 6465 6466 6467February 2004 [Page 108] 6468 6469 6470 6471 6472 6473Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6474 6475 6476 PA-EXTRA-TGT 41 Reserved extra TGT 6477 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 6478 TD-KRB-PRINCIPAL 102 PrincipalName 6479 TD-KRB-REALM 103 Realm 6480 TD-TRUSTED-CERTIFIERS 104 from PKINIT 6481 TD-CERTIFICATE-INDEX 105 from PKINIT 6482 TD-APP-DEFINED-ERROR 106 application specific 6483 TD-REQ-NONCE 107 INTEGER 6484 TD-REQ-SEQ 108 INTEGER 6485 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 6486 64877.5.3. Address Types 6488 6489 Address type value 6490 6491 IPv4 2 6492 Directional 3 6493 ChaosNet 5 6494 XNS 6 6495 ISO 7 6496 DECNET Phase IV 12 6497 AppleTalk DDP 16 6498 NetBios 20 6499 IPv6 24 6500 65017.5.4. Authorization Data Types 6502 6503 authorization data type ad-type value 6504 AD-IF-RELEVANT 1 6505 AD-INTENDED-FOR-SERVER 2 6506 AD-INTENDED-FOR-APPLICATION-CLASS 3 6507 AD-KDC-ISSUED 4 6508 AD-AND-OR 5 6509 AD-MANDATORY-TICKET-EXTENSIONS 6 6510 AD-IN-TICKET-EXTENSIONS 7 6511 AD-MANDATORY-FOR-KDC 8 6512 reserved values 9-63 6513 OSF-DCE 64 6514 SESAME 65 6515 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 6516 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 6517 65187.5.5. Transited Encoding Types 6519 6520 transited encoding type tr-type value 6521 DOMAIN-X500-COMPRESS 1 6522 reserved values all others 6523 6524 6525 6526 6527February 2004 [Page 109] 6528 6529 6530 6531 6532 6533Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6534 6535 65367.5.6. Protocol Version Number 6537 6538 Label Value Meaning or MIT code 6539 6540 pvno 5 current Kerberos protocol version number 6541 65427.5.7. Kerberos Message Types 6543 6544 message types 6545 6546 KRB_AS_REQ 10 Request for initial authentication 6547 KRB_AS_REP 11 Response to KRB_AS_REQ request 6548 KRB_TGS_REQ 12 Request for authentication based on TGT 6549 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 6550 KRB_AP_REQ 14 application request to server 6551 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 6552 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request 6553 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply 6554 KRB_SAFE 20 Safe (checksummed) application message 6555 KRB_PRIV 21 Private (encrypted) application message 6556 KRB_CRED 22 Private (encrypted) message to forward credentials 6557 KRB_ERROR 30 Error response 6558 65597.5.8. Name Types 6560 6561 name types 6562 6563 KRB_NT_UNKNOWN 0 Name type not known 6564 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 6565 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 6566 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 6567 KRB_NT_SRV_XHST 4 Service with host as remaining components 6568 KRB_NT_UID 5 Unique ID 6569 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 6570 KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 6571 KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name 6572 65737.5.9. Error Codes 6574 6575 error codes 6576 6577 KDC_ERR_NONE 0 No error 6578 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 6579 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 6580 KDC_ERR_BAD_PVNO 3 Requested protocol version number 6581 not supported 6582 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 6583 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 6584 6585 6586 6587February 2004 [Page 110] 6588 6589 6590 6591 6592 6593Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6594 6595 6596 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 6597 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 6598 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 6599 KDC_ERR_NULL_KEY 9 The client or server has a null key 6600 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 6601 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 6602 KDC_ERR_POLICY 12 KDC policy rejects request 6603 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 6604 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 6605 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 6606 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 6607 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 6608 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 6609 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 6610 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 6611 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 6612 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 6613 KDC_ERR_KEY_EXPIRED 23 Password has expired 6614 - change password to reset 6615 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 6616 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired 6617 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 6618 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 6619 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 6620 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 6621 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 6622 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 6623 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 6624 KRB_AP_ERR_REPEAT 34 Request is a replay 6625 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 6626 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 6627 KRB_AP_ERR_SKEW 37 Clock skew too great 6628 KRB_AP_ERR_BADADDR 38 Incorrect net address 6629 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 6630 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 6631 KRB_AP_ERR_MODIFIED 41 Message stream modified 6632 KRB_AP_ERR_BADORDER 42 Message out of order 6633 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 6634 KRB_AP_ERR_NOKEY 45 Service key not available 6635 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 6636 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 6637 KRB_AP_ERR_METHOD 48 Alternative authentication method required 6638 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 6639 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 6640 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 6641 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 6642 KRB_ERR_GENERIC 60 Generic error (description in e-text) 6643 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 6644 6645 6646 6647February 2004 [Page 111] 6648 6649 6650 6651 6652 6653Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6654 6655 6656 KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT 6657 KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT 6658 KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT 6659 KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT 6660 KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT 6661 KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER 6662 KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC 6663 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER 6664 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT 6665 KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT 6666 KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT 6667 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT 6668 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT 6669 KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT 6670 KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT 6671 66728. Interoperability requirements 6673 6674 Version 5 of the Kerberos protocol supports a myriad of options. 6675 Among these are multiple encryption and checksum types, 6676 alternative encoding schemes for the transited field, optional 6677 mechanisms for pre-authentication, the handling of tickets with no 6678 addresses, options for mutual authentication, user-to-user 6679 authentication, support for proxies, forwarding, postdating, and 6680 renewing tickets, the format of realm names, and the handling of 6681 authorization data. 6682 6683 In order to ensure the interoperability of realms, it is necessary 6684 to define a minimal configuration which must be supported by all 6685 implementations. This minimal configuration is subject to change 6686 as technology does. For example, if at some later date it is 6687 discovered that one of the required encryption or checksum 6688 algorithms is not secure, it will be replaced. 6689 66908.1. Specification 2 6691 6692 This section defines the second specification of these options. 6693 Implementations which are configured in this way can be said to 6694 support Kerberos Version 5 Specification 2 (5.2). Specification 1 6695 (deprecated) may be found in RFC1510. 6696 6697 Transport 6698 6699 TCP/IP and UDP/IP transport MUST be supported by clients and KDCs 6700 claiming conformance to specification 2. 6701 6702 Encryption and checksum methods 6703 6704 6705 6706 6707February 2004 [Page 112] 6708 6709 6710 6711 6712 6713Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6714 6715 6716 The following encryption and checksum mechanisms MUST be 6717 supported. 6718 6719 Encryption: AES256-CTS-HMAC-SHA1-96 6720 Checksums: HMAC-SHA1-96-AES256 6721 6722 Implementations SHOULD support other mechanisms as well, but the 6723 additional mechanisms may only be used when communicating with 6724 principals known to also support them. The mechanisms that SHOULD 6725 be supported are: 6726 6727 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD 6728 Checksums: DES-MD5, HMAC-SHA1-DES3-KD 6729 6730 Implementations MAY support other mechanisms as well, but the 6731 additional mechanisms may only be used when communicating with 6732 principals known to also support them. 6733 6734 Implementation note: earlier implementations of Kerberos generate 6735 messages using the CRC-32, RSA-MD5 checksum methods. For 6736 interoperability with these earlier releases implementors MAY 6737 consider supporting these checksum methods but should carefully 6738 analyze the security impplications to limit the situations within 6739 which these methods are accepted. 6740 6741 Realm Names 6742 6743 All implementations MUST understand hierarchical realms in both 6744 the Internet Domain and the X.500 style. When a ticket-granting 6745 ticket for an unknown realm is requested, the KDC MUST be able to 6746 determine the names of the intermediate realms between the KDCs 6747 realm and the requested realm. 6748 6749 Transited field encoding 6750 6751 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be 6752 supported. Alternative encodings MAY be supported, but they may 6753 be used only when that encoding is supported by ALL intermediate 6754 realms. 6755 6756 Pre-authentication methods 6757 6758 The TGS-REQ method MUST be supported. The TGS-REQ method is not 6759 used on the initial request. The PA-ENC-TIMESTAMP method MUST be 6760 supported by clients but whether it is enabled by default MAY be 6761 determined on a realm by realm basis. If not used in the initial 6762 request and the error KDC_ERR_PREAUTH_REQUIRED is returned 6763 specifying PA-ENC-TIMESTAMP as an acceptable method, the client 6764 6765 6766 6767February 2004 [Page 113] 6768 6769 6770 6771 6772 6773Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6774 6775 6776 SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- 6777 authentication method. Servers need not support the PA-ENC- 6778 TIMESTAMP method, but if not supported the server SHOULD ignore 6779 the presence of PA-ENC-TIMESTAMP pre-authentication in a request. 6780 6781 The ETYPE-INFO2 method MUST be supported; this method is used to 6782 communicate the set of supported encryption types, and 6783 corresponding salt and string to key paramters. The ETYPE-INFO 6784 method SHOULD be supported for interoperability with older 6785 implementation. 6786 6787 Mutual authentication 6788 6789 Mutual authentication (via the KRB_AP_REP message) MUST be 6790 supported. 6791 6792 Ticket addresses and flags 6793 6794 All KDCs MUST pass through tickets that carry no addresses (i.e. 6795 if a TGT contains no addresses, the KDC will return derivative 6796 tickets). Implementations SHOULD default to requesting 6797 addressless tickets as this significantly increases 6798 interoperability with network address translation. In some cases 6799 realms or application servers MAY require that tickets have an 6800 address. 6801 6802 Implementations SHOULD accept directional address type for the 6803 KRB_SAFE and KRB_PRIV message and SHOULD include directional 6804 addresses in these messages when other address types are not 6805 available. 6806 6807 Proxies and forwarded tickets MUST be supported. Individual realms 6808 and application servers can set their own policy on when such 6809 tickets will be accepted. 6810 6811 All implementations MUST recognize renewable and postdated 6812 tickets, but need not actually implement them. If these options 6813 are not supported, the starttime and endtime in the ticket shall 6814 specify a ticket's entire useful life. When a postdated ticket is 6815 decoded by a server, all implementations shall make the presence 6816 of the postdated flag visible to the calling server. 6817 6818 User-to-user authentication 6819 6820 Support for user-to-user authentication (via the ENC-TKT-IN-SKEY 6821 KDC option) MUST be provided by implementations, but individual 6822 realms MAY decide as a matter of policy to reject such requests on 6823 a per-principal or realm-wide basis. 6824 6825 6826 6827February 2004 [Page 114] 6828 6829 6830 6831 6832 6833Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6834 6835 6836 Authorization data 6837 6838 Implementations MUST pass all authorization data subfields from 6839 ticket-granting tickets to any derivative tickets unless directed 6840 to suppress a subfield as part of the definition of that 6841 registered subfield type (it is never incorrect to pass on a 6842 subfield, and no registered subfield types presently specify 6843 suppression at the KDC). 6844 6845 Implementations MUST make the contents of any authorization data 6846 subfields available to the server when a ticket is used. 6847 Implementations are not required to allow clients to specify the 6848 contents of the authorization data fields. 6849 6850 Constant ranges 6851 6852 All protocol constants are constrained to 32 bit (signed) values 6853 unless further constrained by the protocol definition. This limit 6854 is provided to allow implementations to make assumptions about the 6855 maximum values that will be received for these constants. 6856 Implementation receiving values outside this range MAY reject the 6857 request, but they MUST recover cleanly. 6858 68598.2. Recommended KDC values 6860 6861 Following is a list of recommended values for a KDC configuration. 6862 6863 minimum lifetime 5 minutes 6864 maximum renewable lifetime 1 week 6865 maximum ticket lifetime 1 day 6866 acceptable clock skew 5 minutes 6867 empty addresses Allowed. 6868 proxiable, etc. Allowed. 6869 68709. IANA considerations 6871 6872 Section 7 of this document specifies protocol constants and other 6873 defined values required for the interoperability of multiple 6874 implementations. Until otherwise specified in a subsequent RFC, or 6875 upon disbanding of the Kerberos working group, allocations of 6876 additional protocol constants and other defined values required 6877 for extensions to the Kerberos protocol will be administered by 6878 the kerberos working group. Following the recomendations outlined 6879 in [RFC 2434], guidance is provided to the IANA as follows: 6880 6881 "reserved" realm name types in section 6.1 and "other" realm types 6882 except those beginning with "X-" or "x-" will not be registered 6883 without IETF standards action, at which point guidlines for 6884 6885 6886 6887February 2004 [Page 115] 6888 6889 6890 6891 6892 6893Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6894 6895 6896 further assignment will be specified. Realm name types beginning 6897 with "X-" or "x-" are for private use. 6898 6899 For host address types described in section 7.1, negative values 6900 are for private use. Assignment of additional positive numbers is 6901 subject to review by the kerberos working group or other expert 6902 review. 6903 6904 Additional key usage numbers as defined in section 7.5.1 will be 6905 assigned subject to review by the kerberos working group or other 6906 expert review. 6907 6908 Additional preauthentciation data type values as defined in 6909 section 7.5.2 will be assigned subject to review by the kerberos 6910 working group or other expert review. 6911 6912 Additional Authorization Data Types as defined in section 7.5.4 6913 will be assigned subject to review by the kerberos working group 6914 or other expert review. Although it is anticipated that there may 6915 be significant demand for private use types, provision is 6916 intentionaly not made for a private use portion of the namespace 6917 because conficts between privately assigned values coule have 6918 detrimental security implications. 6919 6920 Additional Transited Encoding Types as defined in section 7.5.5 6921 present special concerns for interoperability with existing 6922 implementations. As such, such assignments will only be made by 6923 standards action, except that the Kerberos working group or 6924 another other working group with competent jurisdiction may make 6925 preliminary assignments for documents which are moving through the 6926 standards process. 6927 6928 Additional Kerberos Message Types as described in section 7.5.7 6929 will be assigned subject to review by the kerberos working group 6930 or other expert review. 6931 6932 Additional Name Types as described in section 7.5.8 will be 6933 assigned subject to review by the kerberos working group or other 6934 expert review. 6935 6936 Additional error codes described in section 7.5.9 will be assigned 6937 subject to review by the kerberos working group or other expert 6938 review. 6939 694010. Security Considerations 6941 6942 As an authentication service, Kerberos provides a means of 6943 verifying the identity of principals on a network. Kerberos does 6944 6945 6946 6947February 2004 [Page 116] 6948 6949 6950 6951 6952 6953Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6954 6955 6956 not, by itself, provide authorization. Applications should not 6957 accept the issuance of a service ticket by the Kerberos server as 6958 granting authority to use the service, since such applications may 6959 become vulnerable to the bypass of this authorization check in an 6960 environment if they inter-operate with other KDCs or where other 6961 options for application authentication are provided. 6962 6963 Denial of service attacks are not solved with Kerberos. There are 6964 places in the protocols where an intruder can prevent an 6965 application from participating in the proper authentication steps. 6966 Because authentication is a required step for the use of many 6967 services, successful denial of service attacks on a Kerberos 6968 server might result in the denial of other network services that 6969 rely on Kerberos for authentication. Kerberos is vulnerable to 6970 many kinds of denial of service attacks: denial of service attacks 6971 on the network which would prevent clients from contacting the 6972 KDC; denial of service attacks on the domain name system which 6973 could prevent a client from finding the IP address of the Kerberos 6974 server; and denial of service attack by overloading the Kerberos 6975 KDC itself with repeated requests. 6976 6977 Interoperability conflicts caused by incompatible character-set 6978 usage (see 5.2.1) can result in denial of service for clients that 6979 utilize character-sets in Kerberos strings other than those stored 6980 in the KDC database. 6981 6982 Authentication servers maintain a database of principals (i.e., 6983 users and servers) and their secret keys. The security of the 6984 authentication server machines is critical. The breach of security 6985 of an authentication server will compromise the security of all 6986 servers that rely upon the compromised KDC, and will compromise 6987 the authentication of any principals registered in the realm of 6988 the compromised KDC. 6989 6990 Principals must keep their secret keys secret. If an intruder 6991 somehow steals a principal's key, it will be able to masquerade as 6992 that principal or impersonate any server to the legitimate 6993 principal. 6994 6995 Password guessing attacks are not solved by Kerberos. If a user 6996 chooses a poor password, it is possible for an attacker to 6997 successfully mount an off-line dictionary attack by repeatedly 6998 attempting to decrypt, with successive entries from a dictionary, 6999 messages obtained which are encrypted under a key derived from the 7000 user's password. 7001 7002 Unless pre-authentication options are required by the policy of a 7003 realm, the KDC will not know whether a request for authentication 7004 7005 7006 7007February 2004 [Page 117] 7008 7009 7010 7011 7012 7013Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7014 7015 7016 succeeds. An attacker can request a reply with credentials for any 7017 principal. These credentials will likely not be of much use to the 7018 attacker unless it knows the client's secret key, but the 7019 availability of the response encrypted in the client's secret key 7020 provides the attacker with ciphertext that may be used to mount 7021 brute force or dictionary attacks to decrypt the credentials, by 7022 guessing the user's password. For this reason it is strongly 7023 encouraged that Kerberos realms require the use of pre- 7024 authentication. Even with pre-authentication, attackers may try 7025 brute force or dictionary attacks against credentials that are 7026 observed by eavesdropping on the network. 7027 7028 Because a client can request a ticket for any server principal and 7029 can attempt a brute force or dictionary attack against the server 7030 principal's key using that ticket, it is strongly encouraged that 7031 keys be randomly generated (rather than generated from passwords) 7032 for any principals that are usable as the target principal for a 7033 KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750] 7034 7035 Although the DES-CBC-MD5 encryption method and DES-MD5 checksum 7036 methods are listed as SHOULD be implemented for backward 7037 compatibility, the single DES encryption algorithm on which these 7038 are based is weak and stronger algorithms should be used whenever 7039 possible. 7040 7041 Each host on the network must have a clock which is loosely 7042 synchronized to the time of the other hosts; this synchronization 7043 is used to reduce the bookkeeping needs of application servers 7044 when they do replay detection. The degree of "looseness" can be 7045 configured on a per-server basis, but is typically on the order of 7046 5 minutes. If the clocks are synchronized over the network, the 7047 clock synchronization protocol MUST itself be secured from network 7048 attackers. 7049 7050 Principal identifiers must not recycled on a short-term basis. A 7051 typical mode of access control will use access control lists 7052 (ACLs) to grant permissions to particular principals. If a stale 7053 ACL entry remains for a deleted principal and the principal 7054 identifier is reused, the new principal will inherit rights 7055 specified in the stale ACL entry. By not reusing principal 7056 identifiers, the danger of inadvertent access is removed. 7057 7058 Proper decryption of an KRB_AS_REP message from the KDC is not 7059 sufficient for the host to verify the identity of the user; the 7060 user and an attacker could cooperate to generate a KRB_AS_REP 7061 format message which decrypts properly but is not from the proper 7062 KDC. To authenticate a user logging on to a local system, the 7063 credentials obtained in the AS exchange may first be used in a TGS 7064 7065 7066 7067February 2004 [Page 118] 7068 7069 7070 7071 7072 7073Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7074 7075 7076 exchange to obtain credentials for a local server. Those 7077 credentials must then be verified by a local server through 7078 successful completion of the Client/Server exchange. 7079 7080 Many RFC 1510 compliant implementations ignore unknown 7081 authorization data elements. Depending on these implementations to 7082 honor authorization data restrictions may create a security 7083 weakness. 7084 7085 Kerberos credentials contain clear-text information identifying 7086 the principals to which they apply. If privacy of this information 7087 is needed, this exchange should itself be encapsulated in a 7088 protocol providing for confidentiality on the exchange of these 7089 credentials. 7090 7091 Applications must take care to protect communications subsequent 7092 to authentication either by using the KRB_PRIV or KRB_SAFE 7093 messages as appropriate, or by applying their own confidentiality 7094 or integrity mechanisms on such communications. Completion of the 7095 KRB_AP_REQ and KRB_AP_REP exchange without subsequent use of 7096 confidentiality and integrity mechanisms provides only for 7097 authentication of the parties to the communication and not 7098 confidentiality and integrity of the subsequent communication. 7099 Application applying confidentiality and integrity protection 7100 mechanisms other than KRB_PRIV and KRB_SAFE must make sure that 7101 the authentication step is appropriately linked with the protected 7102 communication channel that is established by the application. 7103 7104 Unless the application server provides its own suitable means to 7105 protect against replay (for example, a challenge-response sequence 7106 initiated by the server after authentication, or use of a server- 7107 generated encryption subkey), the server must utilize a replay 7108 cache to remember any authenticator presented within the allowable 7109 clock skew. All services sharing a key need to use the same replay 7110 cache. If separate replay caches are used, then and authenticator 7111 used with one such service could later be replayed to a different 7112 service with the same service principal. 7113 7114 If a server loses track of authenticators presented within the 7115 allowable clock skew, it must reject all requests until the clock 7116 skew interval has passed, providing assurance that any lost or 7117 replayed authenticators will fall outside the allowable clock skew 7118 and can no longer be successfully replayed. 7119 7120 Implementations of Kerberos should not use untrusted directory 7121 servers to determine the realm of a host. To allow such would 7122 allow the compromise of the directory server to enable an attacker 7123 to direct the client to accept authentication with the wrong 7124 7125 7126 7127February 2004 [Page 119] 7128 7129 7130 7131 7132 7133Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7134 7135 7136 principal (i.e. one with a similar name, but in a realm with which 7137 the legitimate host was not registered). 7138 7139 Implementations of Kerberos must not use DNS to map one name to 7140 another (canonicalize) to determine the host part of the principal 7141 name with which one is to communicate. To allow such 7142 canonicalization would allow a compromise of the DNS to result in 7143 a client obtaining credentials and correctly authenticating to the 7144 wrong principal. Though the client will know who it is 7145 communicating with, it will not be the principal with which it 7146 intended to communicate. 7147 7148 If the Kerberos server returns a TGT for a 'closer' realm other 7149 than the desired realm, the client may use local policy 7150 configuration to verify that the authentication path used is an 7151 acceptable one. Alternatively, a client may choose its own 7152 authentication path, rather than relying on the Kerberos server to 7153 select one. In either case, any policy or configuration 7154 information used to choose or validate authentication paths, 7155 whether by the Kerberos server or client, must be obtained from a 7156 trusted source. 7157 7158 The Kerberos protocol in its basic form does not provide perfect 7159 forward secrecy for communications. If traffic has been recorded 7160 by an eavesdropper, then messages encrypted using the KRB_PRIV 7161 message, or messages encrypted using application specific 7162 encryption under keys exchanged using Kerberos can be decrypted if 7163 any of the user's, application server's, or KDC's key is 7164 subsequently discovered. This is because the session key use to 7165 encrypt such messages is transmitted over the network encrypted in 7166 the key of the application server, and also encrypted under the 7167 session key from the user's ticket-granting ticket when returned 7168 to the user in the KRB_TGS_REP message. The session key from the 7169 ticket-granting ticket was sent to the user in the KRB_AS_REP 7170 message encrypted in the user's secret key, and embedded in the 7171 ticket-granting ticket, which was encrypted in the key of the KDC. 7172 Application requiring perfect forward secrecy must exchange keys 7173 through mechanisms that provide such assurance, but may use 7174 Kerberos for authentication of the encrypted channel established 7175 through such other means. 7176 717711. Author's Addresses 7178 7179 7180 Clifford Neuman 7181 Information Sciences Institute 7182 University of Southern California 7183 4676 Admiralty Way 7184 7185 7186 7187February 2004 [Page 120] 7188 7189 7190 7191 7192 7193Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7194 7195 7196 Marina del Rey, CA 90292, USA 7197 Email: bcn@isi.edu 7198 7199 Tom Yu 7200 Massachusetts Institute of Technology 7201 77 Massachusetts Avenue 7202 Cambridge, MA 02139, USA 7203 Email: tlyu@mit.edu 7204 7205 Sam Hartman 7206 Massachusetts Institute of Technology 7207 77 Massachusetts Avenue 7208 Cambridge, MA 02139, USA 7209 Email: hartmans@mit.edu 7210 7211 Kenneth Raeburn 7212 Massachusetts Institute of Technology 7213 77 Massachusetts Avenue 7214 Cambridge, MA 02139, USA 7215 Email: raeburn@MIT.EDU 7216 7217 721812. Acknowledgements 7219 7220 This document is a revision to RFC1510 which was co-authored with 7221 John Kohl. The specification of the Kerberos protocol described 7222 in this document is the result of many years of effort. Over this 7223 period many individuals have contributed to the definition of the 7224 protocol and to the writing of the specification. Unfortunately it 7225 is not possible to list all contributors as authors of this 7226 document, though there are many not listed who are authors in 7227 spirit, because they contributed text for parts of some sections, 7228 because they contributed to the design of parts of the protocol, 7229 or because they contributed significantly to the discussion of the 7230 protocol in the IETF common authentication technology (CAT) and 7231 Kerberos working groups. 7232 7233 Among those contributing to the development and specification of 7234 Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan 7235 Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John 7236 Kohl, Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John 7237 Linn, Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, 7238 Jerome Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, 7239 Mike Swift, Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques 7240 Vidrine, Assar Westerlund, and Nicolas Williams. Many other 7241 members of MIT Project Athena, the MIT networking group, and the 7242 Kerberos and CAT working groups of the IETF contributed but are 7243 not listed. 7244 7245 7246 7247February 2004 [Page 121] 7248 7249 7250 7251 7252 7253Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7254 7255 7256 Funding for the RFC Editor function is currently provided by the 7257 Internet Society. 7258 725913. REFERENCES 7260 726113.1 NORMATIVE REFERENCES 7262 7263 [@KCRYPTO] 7264 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 7265 crypto. 7266 7267 [@AES] 7268 RFC-Editor: To be replaced by RFC number for draft-raeburn0krb- 7269 rijndael-krb. 7270 7271 [ISO-646/ECMA-6] 7272 7-bit Coded Character Set 7273 7274 [ISO-2022/ECMA-35] 7275 Character Code Structure and Extension Techniques 7276 7277 [ISO-4873/ECMA-43] 7278 8-bit Coded Character Set Structure and Rules 7279 7280 [RFC1035] 7281 P.V. Mockapetris, RFC1035: "Domain Names - Implementations and 7282 Specification," November 1, 1987, Obsoletes - RFC973, RFC882, 7283 RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982, 7284 RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, 7285 RFC2535, RFC2845, and RFC3425. Status: Standard. 7286 7287 [RFC2119] 7288 7289 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate 7290 Requirement Levels", March 1997. 7291 7292 [RFC2434] 7293 T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA 7294 Consideration Secionts in RFCs" October, 1998. 7295 7296 [RFC2782] 7297 A. Gulbrandsen, P. Vixie and L. Esibov., RFC2782: "A DNS RR for 7298 Specifying the Location of Services (DNS SRV)," February 2000. 7299 7300 [RFC2253] 7301 M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory 7302 Access Protocol (v3): UTF-8 String Representation or Distinguished 7303 Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377, 7304 7305 7306 7307February 2004 [Page 122] 7308 7309 7310 7311 7312 7313Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7314 7315 7316 Status: Proposed Standard. 7317 7318 [RFC2373] 7319 R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing 7320 Architecture," July 1998, Status: Proposed Standard. 7321 7322 [X680] 7323 Abstract Syntax Notation One (ASN.1): Specification of Basic 7324 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 7325 International Standard 8824-1:1998. 7326 7327 [X690] 7328 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 7329 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 7330 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 7331 Standard 8825-1:1998. 7332 733313.2 INFORMATIVE REFERENCES 7334 7335 [DGT96] 7336 Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks 7337 Adrift: History, Protocols, and Implementation", USENIX Computing 7338 Systems 9:1 (January 1996). 7339 7340 [DS81] 7341 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 7342 Distribution Protocols," Communications of the ACM, Vol. 24(8), 7343 pp. 533-536 (August 1981). 7344 7345 [KNT94] 7346 7347 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 7348 Evolution of the Kerberos Authentication System". In Distributed 7349 Open Systems, pages 78-94. IEEE Computer Society Press, 1994. 7350 7351 [MNSS87] 7352 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 7353 Section E.2.1: Kerberos Authentication and Authorization System, 7354 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 7355 1987). 7356 7357 [NS78] 7358 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 7359 Authentication in Large Networks of Computers," Communications of 7360 the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 7361 7362 [Neu93] 7363 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 7364 7365 7366 7367February 2004 [Page 123] 7368 7369 7370 7371 7372 7373Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7374 7375 7376 Distributed Systems," in Proceedings of the 13th International 7377 Conference on Distributed Computing Systems, Pittsburgh, PA (May, 7378 1993). 7379 7380 [NT94] 7381 B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication 7382 Service for Computer Networks," IEEE Communications Magazine, Vol. 7383 32(9), pp. 33-38 (September 1994). 7384 7385 [Pat92]. 7386 J. Pato, Using Pre-Authentication to Avoid Password Guessing 7387 Attacks, Open Software Foundation DCE Request for Comments 26 7388 (December 1992). 7389 7390 [RFC1510] 7391 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network 7392 Authentication Service (v5)," September 1993, Status: Proposed 7393 Standard. 7394 7395 [RFC1750] 7396 D. Eastlake, S. Crocker, and J. Schiller "Randomness 7397 Recommendation for Security" December 1994, Status: Informational. 7398 7399 [RFC2026] 7400 S. Bradner, RFC2026: "The Internet Standard Process - Revision 7401 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 7402 Practice. 7403 7404 [SNS88] 7405 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An 7406 Authentication Service for Open Network Systems," pp. 191-202 in 7407 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 7408 7409 741014. Copyright Statement 7411 7412 Copyright (C) The Internet Society (2004). This document is 7413 subject to the rights, licenses and restrictions contained in BCP 7414 78 and except as set forth therein, the authors retain all their 7415 rights. 7416 7417 This document and the information contained herein are provided on 7418 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 7419 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 7420 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 7421 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 7422 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 7423 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 7424 7425 7426 7427February 2004 [Page 124] 7428 7429 7430 7431 7432 7433Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7434 7435 7436 PARTICULAR PURPOSE. 7437 743815. Intellectual Property 7439 7440 The IETF takes no position regarding the validity or scope of any 7441 Intellectual Property Rights or other rights that might be claimed 7442 to pertain to the implementation or use of the technology 7443 described in this document or the extent to which any license 7444 under such rights might or might not be available; nor does it 7445 represent that it has made any independent effort to identify any 7446 such rights. Information on the procedures with respect to rights 7447 in RFC documents can be found in BCP 78 and BCP 79. 7448 7449 Copies of IPR disclosures made to the IETF Secretariat and any 7450 assurances of licenses to be made available, or the result of an 7451 attempt made to obtain a general license or permission for the use 7452 of such proprietary rights by implementers or users of this 7453 specification can be obtained from the IETF on-line IPR repository 7454 at http://www.ietf.org/ipr. 7455 7456 The IETF invites any interested party to bring to its attention 7457 any copyrights, patents or patent applications, or other 7458 proprietary rights that may cover technology that may be required 7459 to implement this standard. Please address the information to the 7460 IETF at ietf-ipr@ietf.org. 7461 7462A. ASN.1 module 7463 7464 KerberosV5Spec2 { 7465 iso(1) identified-organization(3) dod(6) internet(1) 7466 security(5) kerberosV5(2) modules(4) krb5spec2(2) 7467 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 7468 7469 -- OID arc for KerberosV5 7470 -- 7471 -- This OID may be used to identify Kerberos protocol messages 7472 -- encapsulated in other protocols. 7473 -- 7474 -- This OID also designates the OID arc for KerberosV5-related OIDs. 7475 -- 7476 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. 7477 id-krb5 OBJECT IDENTIFIER ::= { 7478 iso(1) identified-organization(3) dod(6) internet(1) 7479 security(5) kerberosV5(2) 7480 } 7481 7482 Int32 ::= INTEGER (-2147483648..2147483647) 7483 -- signed values representable in 32 bits 7484 7485 7486 7487February 2004 [Page 125] 7488 7489 7490 7491 7492 7493Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7494 7495 7496 UInt32 ::= INTEGER (0..4294967295) 7497 -- unsigned 32 bit values 7498 7499 Microseconds ::= INTEGER (0..999999) 7500 -- microseconds 7501 7502 KerberosString ::= GeneralString (IA5String) 7503 7504 Realm ::= KerberosString 7505 7506 PrincipalName ::= SEQUENCE { 7507 name-type [0] Int32, 7508 name-string [1] SEQUENCE OF KerberosString 7509 } 7510 7511 KerberosTime ::= GeneralizedTime -- with no fractional seconds 7512 7513 HostAddress ::= SEQUENCE { 7514 addr-type [0] Int32, 7515 address [1] OCTET STRING 7516 } 7517 7518 -- NOTE: HostAddresses is always used as an OPTIONAL field and 7519 -- should not be empty. 7520 HostAddresses -- NOTE: subtly different from rfc1510, 7521 -- but has a value mapping and encodes the same 7522 ::= SEQUENCE OF HostAddress 7523 7524 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 7525 -- should not be empty. 7526 AuthorizationData ::= SEQUENCE OF SEQUENCE { 7527 ad-type [0] Int32, 7528 ad-data [1] OCTET STRING 7529 } 7530 7531 PA-DATA ::= SEQUENCE { 7532 -- NOTE: first tag is [1], not [0] 7533 padata-type [1] Int32, 7534 padata-value [2] OCTET STRING -- might be encoded AP-REQ 7535 } 7536 7537 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 7538 -- shall be sent, but no fewer than 32 7539 7540 EncryptedData ::= SEQUENCE { 7541 etype [0] Int32 -- EncryptionType --, 7542 kvno [1] UInt32 OPTIONAL, 7543 cipher [2] OCTET STRING -- ciphertext 7544 7545 7546 7547February 2004 [Page 126] 7548 7549 7550 7551 7552 7553Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7554 7555 7556 } 7557 7558 EncryptionKey ::= SEQUENCE { 7559 keytype [0] Int32 -- actually encryption type --, 7560 keyvalue [1] OCTET STRING 7561 } 7562 7563 Checksum ::= SEQUENCE { 7564 cksumtype [0] Int32, 7565 checksum [1] OCTET STRING 7566 } 7567 7568 Ticket ::= [APPLICATION 1] SEQUENCE { 7569 tkt-vno [0] INTEGER (5), 7570 realm [1] Realm, 7571 sname [2] PrincipalName, 7572 enc-part [3] EncryptedData -- EncTicketPart 7573 } 7574 7575 -- Encrypted part of ticket 7576 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 7577 flags [0] TicketFlags, 7578 key [1] EncryptionKey, 7579 crealm [2] Realm, 7580 cname [3] PrincipalName, 7581 transited [4] TransitedEncoding, 7582 authtime [5] KerberosTime, 7583 starttime [6] KerberosTime OPTIONAL, 7584 endtime [7] KerberosTime, 7585 renew-till [8] KerberosTime OPTIONAL, 7586 caddr [9] HostAddresses OPTIONAL, 7587 authorization-data [10] AuthorizationData OPTIONAL 7588 } 7589 7590 -- encoded Transited field 7591 TransitedEncoding ::= SEQUENCE { 7592 tr-type [0] Int32 -- must be registered --, 7593 contents [1] OCTET STRING 7594 } 7595 7596 TicketFlags ::= KerberosFlags 7597 -- reserved(0), 7598 -- forwardable(1), 7599 -- forwarded(2), 7600 -- proxiable(3), 7601 -- proxy(4), 7602 -- may-postdate(5), 7603 -- postdated(6), 7604 7605 7606 7607February 2004 [Page 127] 7608 7609 7610 7611 7612 7613Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7614 7615 7616 -- invalid(7), 7617 -- renewable(8), 7618 -- initial(9), 7619 -- pre-authent(10), 7620 -- hw-authent(11), 7621 -- the following are new since 1510 7622 -- transited-policy-checked(12), 7623 -- ok-as-delegate(13) 7624 7625 AS-REQ ::= [APPLICATION 10] KDC-REQ 7626 7627 TGS-REQ ::= [APPLICATION 12] KDC-REQ 7628 7629 KDC-REQ ::= SEQUENCE { 7630 -- NOTE: first tag is [1], not [0] 7631 pvno [1] INTEGER (5) , 7632 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 7633 padata [3] SEQUENCE OF PA-DATA OPTIONAL 7634 -- NOTE: not empty --, 7635 req-body [4] KDC-REQ-BODY 7636 } 7637 7638 KDC-REQ-BODY ::= SEQUENCE { 7639 kdc-options [0] KDCOptions, 7640 cname [1] PrincipalName OPTIONAL 7641 -- Used only in AS-REQ --, 7642 realm [2] Realm 7643 -- Server's realm 7644 -- Also client's in AS-REQ --, 7645 sname [3] PrincipalName OPTIONAL, 7646 from [4] KerberosTime OPTIONAL, 7647 till [5] KerberosTime, 7648 rtime [6] KerberosTime OPTIONAL, 7649 nonce [7] UInt32, 7650 etype [8] SEQUENCE OF Int32 -- EncryptionType 7651 -- in preference order --, 7652 addresses [9] HostAddresses OPTIONAL, 7653 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 7654 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 7655 -- NOTE: not empty 7656 } 7657 7658 KDCOptions ::= KerberosFlags 7659 -- reserved(0), 7660 -- forwardable(1), 7661 -- forwarded(2), 7662 -- proxiable(3), 7663 -- proxy(4), 7664 7665 7666 7667February 2004 [Page 128] 7668 7669 7670 7671 7672 7673Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7674 7675 7676 -- allow-postdate(5), 7677 -- postdated(6), 7678 -- unused7(7), 7679 -- renewable(8), 7680 -- unused9(9), 7681 -- unused10(10), 7682 -- opt-hardware-auth(11), 7683 -- unused12(12), 7684 -- unused13(13), 7685 -- 15 is reserved for canonicalize 7686 -- unused15(15), 7687 -- 26 was unused in 1510 7688 -- disable-transited-check(26), 7689 -- 7690 -- renewable-ok(27), 7691 -- enc-tkt-in-skey(28), 7692 -- renew(30), 7693 -- validate(31) 7694 7695 AS-REP ::= [APPLICATION 11] KDC-REP 7696 7697 TGS-REP ::= [APPLICATION 13] KDC-REP 7698 7699 KDC-REP ::= SEQUENCE { 7700 pvno [0] INTEGER (5), 7701 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 7702 padata [2] SEQUENCE OF PA-DATA OPTIONAL 7703 -- NOTE: not empty --, 7704 crealm [3] Realm, 7705 cname [4] PrincipalName, 7706 ticket [5] Ticket, 7707 enc-part [6] EncryptedData 7708 -- EncASRepPart or EncTGSRepPart, 7709 -- as appropriate 7710 } 7711 7712 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 7713 7714 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 7715 7716 EncKDCRepPart ::= SEQUENCE { 7717 key [0] EncryptionKey, 7718 last-req [1] LastReq, 7719 nonce [2] UInt32, 7720 key-expiration [3] KerberosTime OPTIONAL, 7721 flags [4] TicketFlags, 7722 authtime [5] KerberosTime, 7723 starttime [6] KerberosTime OPTIONAL, 7724 7725 7726 7727February 2004 [Page 129] 7728 7729 7730 7731 7732 7733Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7734 7735 7736 endtime [7] KerberosTime, 7737 renew-till [8] KerberosTime OPTIONAL, 7738 srealm [9] Realm, 7739 sname [10] PrincipalName, 7740 caddr [11] HostAddresses OPTIONAL 7741 } 7742 7743 LastReq ::= SEQUENCE OF SEQUENCE { 7744 lr-type [0] Int32, 7745 lr-value [1] KerberosTime 7746 } 7747 7748 AP-REQ ::= [APPLICATION 14] SEQUENCE { 7749 pvno [0] INTEGER (5), 7750 msg-type [1] INTEGER (14), 7751 ap-options [2] APOptions, 7752 ticket [3] Ticket, 7753 authenticator [4] EncryptedData -- Authenticator 7754 } 7755 7756 APOptions ::= KerberosFlags 7757 -- reserved(0), 7758 -- use-session-key(1), 7759 -- mutual-required(2) 7760 7761 -- Unencrypted authenticator 7762 Authenticator ::= [APPLICATION 2] SEQUENCE { 7763 authenticator-vno [0] INTEGER (5), 7764 crealm [1] Realm, 7765 cname [2] PrincipalName, 7766 cksum [3] Checksum OPTIONAL, 7767 cusec [4] Microseconds, 7768 ctime [5] KerberosTime, 7769 subkey [6] EncryptionKey OPTIONAL, 7770 seq-number [7] UInt32 OPTIONAL, 7771 authorization-data [8] AuthorizationData OPTIONAL 7772 } 7773 7774 AP-REP ::= [APPLICATION 15] SEQUENCE { 7775 pvno [0] INTEGER (5), 7776 msg-type [1] INTEGER (15), 7777 enc-part [2] EncryptedData -- EncAPRepPart 7778 } 7779 7780 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 7781 ctime [0] KerberosTime, 7782 cusec [1] Microseconds, 7783 subkey [2] EncryptionKey OPTIONAL, 7784 7785 7786 7787February 2004 [Page 130] 7788 7789 7790 7791 7792 7793Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7794 7795 7796 seq-number [3] UInt32 OPTIONAL 7797 } 7798 7799 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 7800 pvno [0] INTEGER (5), 7801 msg-type [1] INTEGER (20), 7802 safe-body [2] KRB-SAFE-BODY, 7803 cksum [3] Checksum 7804 } 7805 7806 KRB-SAFE-BODY ::= SEQUENCE { 7807 user-data [0] OCTET STRING, 7808 timestamp [1] KerberosTime OPTIONAL, 7809 usec [2] Microseconds OPTIONAL, 7810 seq-number [3] UInt32 OPTIONAL, 7811 s-address [4] HostAddress, 7812 r-address [5] HostAddress OPTIONAL 7813 } 7814 7815 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 7816 pvno [0] INTEGER (5), 7817 msg-type [1] INTEGER (21), 7818 -- NOTE: there is no [2] tag 7819 enc-part [3] EncryptedData -- EncKrbPrivPart 7820 } 7821 7822 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 7823 user-data [0] OCTET STRING, 7824 timestamp [1] KerberosTime OPTIONAL, 7825 usec [2] Microseconds OPTIONAL, 7826 seq-number [3] UInt32 OPTIONAL, 7827 s-address [4] HostAddress -- sender's addr --, 7828 r-address [5] HostAddress OPTIONAL -- recip's addr 7829 } 7830 7831 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 7832 pvno [0] INTEGER (5), 7833 msg-type [1] INTEGER (22), 7834 tickets [2] SEQUENCE OF Ticket, 7835 enc-part [3] EncryptedData -- EncKrbCredPart 7836 } 7837 7838 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 7839 ticket-info [0] SEQUENCE OF KrbCredInfo, 7840 nonce [1] UInt32 OPTIONAL, 7841 timestamp [2] KerberosTime OPTIONAL, 7842 usec [3] Microseconds OPTIONAL, 7843 s-address [4] HostAddress OPTIONAL, 7844 7845 7846 7847February 2004 [Page 131] 7848 7849 7850 7851 7852 7853Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7854 7855 7856 r-address [5] HostAddress OPTIONAL 7857 } 7858 7859 KrbCredInfo ::= SEQUENCE { 7860 key [0] EncryptionKey, 7861 prealm [1] Realm OPTIONAL, 7862 pname [2] PrincipalName OPTIONAL, 7863 flags [3] TicketFlags OPTIONAL, 7864 authtime [4] KerberosTime OPTIONAL, 7865 starttime [5] KerberosTime OPTIONAL, 7866 endtime [6] KerberosTime OPTIONAL, 7867 renew-till [7] KerberosTime OPTIONAL, 7868 srealm [8] Realm OPTIONAL, 7869 sname [9] PrincipalName OPTIONAL, 7870 caddr [10] HostAddresses OPTIONAL 7871 } 7872 7873 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 7874 pvno [0] INTEGER (5), 7875 msg-type [1] INTEGER (30), 7876 ctime [2] KerberosTime OPTIONAL, 7877 cusec [3] Microseconds OPTIONAL, 7878 stime [4] KerberosTime, 7879 susec [5] Microseconds, 7880 error-code [6] Int32, 7881 crealm [7] Realm OPTIONAL, 7882 cname [8] PrincipalName OPTIONAL, 7883 realm [9] Realm -- service realm --, 7884 sname [10] PrincipalName -- service name --, 7885 e-text [11] KerberosString OPTIONAL, 7886 e-data [12] OCTET STRING OPTIONAL 7887 } 7888 7889 METHOD-DATA ::= SEQUENCE OF PA-DATA 7890 7891 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 7892 data-type [0] INTEGER, 7893 data-value [1] OCTET STRING OPTIONAL 7894 } 7895 7896 -- preauth stuff follows 7897 7898 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 7899 7900 PA-ENC-TS-ENC ::= SEQUENCE { 7901 patimestamp [0] KerberosTime -- client's time --, 7902 pausec [1] Microseconds OPTIONAL 7903 } 7904 7905 7906 7907February 2004 [Page 132] 7908 7909 7910 7911 7912 7913Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7914 7915 7916 ETYPE-INFO-ENTRY ::= SEQUENCE { 7917 etype [0] Int32, 7918 salt [1] OCTET STRING OPTIONAL 7919 } 7920 7921 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 7922 7923 ETYPE-INFO2-ENTRY ::= SEQUENCE { 7924 etype [0] Int32, 7925 salt [1] KerberosString OPTIONAL, 7926 s2kparams [2] OCTET STRING OPTIONAL 7927 } 7928 7929 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 7930 7931 AD-IF-RELEVANT ::= AuthorizationData 7932 7933 AD-KDCIssued ::= SEQUENCE { 7934 ad-checksum [0] Checksum, 7935 i-realm [1] Realm OPTIONAL, 7936 i-sname [2] PrincipalName OPTIONAL, 7937 elements [3] AuthorizationData 7938 } 7939 7940 AD-AND-OR ::= SEQUENCE { 7941 condition-count [0] INTEGER, 7942 elements [1] AuthorizationData 7943 } 7944 7945 AD-MANDATORY-FOR-KDC ::= AuthorizationData 7946 7947 END 7948 7949B. Changes since RFC-1510 7950 7951 This document replaces RFC-1510 and clarifies specification of 7952 items that were not completely specified. Where changes to 7953 recommended implementation choices were made, or where new options 7954 were added, those changes are described within the document and 7955 listed in this section. More significantly, "Specification 2" in 7956 section 8 changes the required encryption and checksum methods to 7957 bring them in line with the best current practices and to 7958 deprecate methods that are no longer considered sufficiently 7959 strong. 7960 7961 Discussion was added to section 1 regarding the ability to rely on 7962 the KDC to check the transited field, and on the inclusion of a 7963 flag in a ticket indicating that this check has occurred. This is 7964 7965 7966 7967February 2004 [Page 133] 7968 7969 7970 7971 7972 7973Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 7974 7975 7976 a new capability not present in RFC1510. Pre-existing 7977 implementations may ignore or not set this flag without negative 7978 security implications. 7979 7980 The definition of the secret key says that in the case of a user 7981 the key may be derived from a password. In 1510, it said that the 7982 key was derived from the password. This change was made to 7983 accommodate situations where the user key might be stored on a 7984 smart-card, or otherwise obtained independent of a password. 7985 7986 The introduction mentions the use of public key cryptography for 7987 initial authentication in Kerberos by reference. RFC1510 did not 7988 include such a reference. 7989 7990 Section 1.2 was added to explain that while Kerberos provides 7991 authentication of a named principal, it is still the 7992 responsibility of the application to ensure that the authenticated 7993 name is the entity with which the application wishes to 7994 communicate. 7995 7996 Discussion of extensibility has been added to the introduction. 7997 7998 Discussion of how extensibility affects ticket flags and KDC 7999 options was added to the introduction of section 2. No changes 8000 were made to existing options and flags specified in RFC1510, 8001 though some of the sections in the specification were renumbered, 8002 and text was revised to make the description and intent of 8003 existing options clearer, especially with respect to the ENC-TKT- 8004 IN-SKEY option (now section 2.9.2) which is used for user-to-user 8005 authentication. The new option and ticket flag transited policy 8006 checking (section 2.7) was added. 8007 8008 A warning regarding generation of session keys for application use 8009 was added to section 3, urging the inclusion of key entropy from 8010 the KDC generated session key in the ticket. An example regarding 8011 use of the sub-session key was added to section 3.2.6. 8012 Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt 8013 pre-authentication data items were added. The recommendation for 8014 use of pre-authentication was changed from "may" to "should" and a 8015 note was added regarding known plaintext attacks. 8016 8017 In RFC 1510, section 4 described the database in the KDC. This 8018 discussion was not necessary for interoperability and 8019 unnecessarily constrained implementation. The old section 4 was 8020 removed. 8021 8022 The current section 4 was formerly section 6 on encryption and 8023 checksum specifications. The major part of this section was 8024 8025 8026 8027February 2004 [Page 134] 8028 8029 8030 8031 8032 8033Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 8034 8035 8036 brought up to date to support new encryption methods, and move to 8037 a separate document. Those few remaining aspects of the encryption 8038 and checksum specification specific to Kerberos are now specified 8039 in section 4. 8040 8041 Significant changes were made to the layout of section 5 to 8042 clarify the correct behavior for optional fields. Many of these 8043 changes were made necessary because of improper ASN.1 description 8044 in the original Kerberos specification which left the correct 8045 behavior underspecified. Additionally, the wording in this section 8046 was tightened wherever possible to ensure that implementations 8047 conforming to this specification will be extensible with the 8048 addition of new fields in future specifications. 8049 8050 Text was added describing time_t=0 issues in the ASN.1. Text was 8051 also added, clarifying issues with implementations treating 8052 omitted optional integers as zero. Text was added clarifying 8053 behavior for optional SEQUENCE or SEQUENCE OF that may be empty. 8054 Discussion was added regarding sequence numbers and behavior of 8055 some implementations, including "zero" behavior and negative 8056 numbers. A compatibility note was added regarding the 8057 unconditional sending of EncTGSRepPart regardless of the enclosing 8058 reply type. Minor changes were made to the description of the 8059 HostAddresses type. Integer types were constrained. KerberosString 8060 was defined as a (significantly) constrained GeneralString. 8061 KerberosFlags was defined to reflect existing implementation 8062 behavior that departs from the definition in RFC 1510. The 8063 transited-policy-checked(12) and the ok-as-delegate(13) ticket 8064 flags were added. The disable-transited-check(26) KDC option was 8065 added. 8066 8067 Descriptions of commonly implemented PA-DATA were added to section 8068 5. The description of KRB-SAFE has been updated to note the 8069 existing implementation behavior of double-encoding. 8070 8071 There were two definitions of METHOD-DATA in RFC 1510. The second 8072 one, intended for use with KRB_AP_ERR_METHOD was removed leaving 8073 the SEQUENCE OF PA-DATA definition. 8074 8075 Section 7, naming constraints, from RFC1510 was moved to section 8076 6. 8077 8078 Words were added describing the convention that domain based realm 8079 names for newly created realms should be specified as upper case. 8080 This recommendation does not make lower case realm names illegal. 8081 Words were added highlighting that the slash separated components 8082 in the X500 style of realm names is consistent with existing 8083 RFC1510 based implementations, but that it conflicts with the 8084 8085 8086 8087February 2004 [Page 135] 8088 8089 8090 8091 8092 8093Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 8094 8095 8096 general recommendation of X.500 name representation specified in 8097 RFC2253. 8098 8099 Section 8, network transport, constants and defined values, from 8100 RFC1510 was moved to section 7. Since RFC1510, the definition of 8101 the TCP transport for Kerberos messages was added, and the 8102 encryption and checksum number assignments have been moved into a 8103 separate document. 8104 8105 "Specification 2" in section 8 of the current document changes the 8106 required encryption and checksum methods to bring them in line 8107 with the best current practices and to deprecate methods that are 8108 no longer considered sufficiently strong. 8109 8110 Two new sections, on IANA considerations and security 8111 considerations were added. 8112 8113 The pseudo-code has been removed from the appendix. The pseudo- 8114 code was sometimes misinterpreted to limit implementation choices 8115 and in RFC 1510, it was not always consistent with the words in 8116 the specification. Effort was made to clear up any ambiguities in 8117 the specification, rather than to rely on the pseudo-code. 8118 8119 An appendix was added containing the complete ASN.1 module drawn 8120 from the discussion in section 5 of the current document. 8121 8122END NOTES 8123 8124 [TM] Project Athena, Athena, and Kerberos are trademarks of the 8125 Massachusetts Institute of Technology (MIT). No commercial use of 8126 these trademarks may be made without prior written permission of 8127 MIT. 8128 8129 [1] Note, however, that many applications use Kerberos' functions 8130 only upon the initiation of a stream-based network connection. 8131 Unless an application subsequently provides integrity protection 8132 for the data stream, the identity verification applies only to the 8133 initiation of the connection, and does not guarantee that 8134 subsequent messages on the connection originate from the same 8135 principal. 8136 8137 [2] Secret and private are often used interchangeably in the 8138 literature. In our usage, it takes two (or more) to share a 8139 secret, thus a shared DES key is a secret key. Something is only 8140 private when no one but its owner knows it. Thus, in public key 8141 cryptosystems, one has a public and a private key. 8142 8143 [3] Of course, with appropriate permission the client could 8144 8145 8146 8147February 2004 [Page 136] 8148 8149 8150 8151 8152 8153Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 8154 8155 8156 arrange registration of a separately-named principal in a remote 8157 realm, and engage in normal exchanges with that realm's services. 8158 However, for even small numbers of clients this becomes 8159 cumbersome, and more automatic methods as described here are 8160 necessary. 8161 8162 [4] Though it is permissible to request or issue tickets with no 8163 network addresses specified. 8164 8165 [5] The password-changing request must not be honored unless the 8166 requester can provide the old password (the user's current secret 8167 key). Otherwise, it would be possible for someone to walk up to an 8168 unattended session and change another user's password. 8169 8170 [6] To authenticate a user logging on to a local system, the 8171 credentials obtained in the AS exchange may first be used in a TGS 8172 exchange to obtain credentials for a local server. Those 8173 credentials must then be verified by a local server through 8174 successful completion of the Client/Server exchange. 8175 8176 [7] "Random" means that, among other things, it should be 8177 impossible to guess the next session key based on knowledge of 8178 past session keys. This can only be achieved in a pseudo-random 8179 number generator if it is based on cryptographic principles. It is 8180 more desirable to use a truly random number generator, such as one 8181 based on measurements of random physical phenomena. See [RFC1750] 8182 for an in depth discussion of randomness. 8183 8184 [8] Tickets contain both an encrypted and unencrypted portion, so 8185 cleartext here refers to the entire unit, which can be copied from 8186 one message and replayed in another without any cryptographic 8187 skill. 8188 8189 [9] Note that this can make applications based on unreliable 8190 transports difficult to code correctly. If the transport might 8191 deliver duplicated messages, either a new authenticator must be 8192 generated for each retry, or the application server must match 8193 requests and replies and replay the first reply in response to a 8194 detected duplicate. 8195 8196 [10] Note also that the rejection here is restricted to 8197 authenticators from the same principal to the same server. Other 8198 client principals communicating with the same server principal 8199 should not be have their authenticators rejected if the time and 8200 microsecond fields happen to match some other client's 8201 authenticator. 8202 8203 [11] If this is not done, an attacker could subvert the 8204 8205 8206 8207February 2004 [Page 137] 8208 8209 8210 8211 8212 8213Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 8214 8215 8216 authentication by recording the ticket and authenticator sent over 8217 the network to a server and replaying them following an event that 8218 caused the server to lose track of recently seen authenticators. 8219 8220 [12] In the Kerberos version 4 protocol, the timestamp in the 8221 reply was the client's timestamp plus one. This is not necessary 8222 in version 5 because version 5 messages are formatted in such a 8223 way that it is not possible to create the reply by judicious 8224 message surgery (even in encrypted form) without knowledge of the 8225 appropriate encryption keys. 8226 8227 [13] Note that for encrypting the KRB_AP_REP message, the sub- 8228 session key is not used, even if present in the Authenticator. 8229 8230 [14] Implementations of the protocol may provide routines to 8231 choose subkeys based on session keys and random numbers and to 8232 generate a negotiated key to be returned in the KRB_AP_REP 8233 message. 8234 8235 [15]This can be accomplished in several ways. It might be known 8236 beforehand (since the realm is part of the principal identifier), 8237 it might be stored in a nameserver, or it might be obtained from a 8238 configuration file. If the realm to be used is obtained from a 8239 nameserver, there is a danger of being spoofed if the nameservice 8240 providing the realm name is not authenticated. This might result 8241 in the use of a realm which has been compromised, and would result 8242 in an attacker's ability to compromise the authentication of the 8243 application server to the client. 8244 8245 [16] If the client selects a sub-session key, care must be taken 8246 to ensure the randomness of the selected sub-session key. One 8247 approach would be to generate a random number and XOR it with the 8248 session key from the ticket-granting ticket. 8249 8250 8251 8252 8253 8254 8255 8256 8257 8258 8259 8260 8261 8262 8263 8264 8265 8266 8267February 2004 [Page 138] 8268