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