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