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