1 2 3INTERNET-DRAFT Tom Yu 4draft-ietf-krb-wg-rfc1510ter-01.txt MIT 5Expires: 19 March 2005 15 September 2005 6 7 The Kerberos Network Authentication Service (Version 5) 8 9Status of This Memo 10 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 20 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 25 26 The list of current Internet-Drafts can be accessed at 27 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 30 The list of Internet-Draft Shadow Directories can be accessed at 31 32 http://www.ietf.org/shadow.html 33 34 35Copyright Notice 36 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 39Abstract 40 41 This document describes version 5 of the Kerberos network 42 authentication protocol. It describes a framework to allow for 43 extensions to be made to the protocol without creating 44 interoperability problems. 45 46Key Words for Requirements 47 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 50 to be interpreted as described in RFC 2119. 51 52 53 54 55Yu Expires: Mar 2005 [Page 1] 56 57Internet-Draft rfc1510ter-01 15 Sep 2005 58 59Table of Contents 60 61 Status of This Memo .............................................. 1 62 Copyright Notice ................................................. 1 63 Abstract ......................................................... 1 64 Key Words for Requirements ....................................... 1 65 Table of Contents ................................................ 2 66 1. Introduction ................................................. 5 67 1.1. Kerberos Protocol Overview ................................. 5 68 1.2. Document Organization ...................................... 6 69 2. Compatibility Considerations ................................. 6 70 2.1. Extensibility .............................................. 7 71 2.2. Compatibility with RFC 1510 ................................ 7 72 2.3. Backwards Compatibility .................................... 7 73 2.4. 1.4.2. Sending Extensible Messages ......................... 8 74 2.5. Criticality ................................................ 8 75 2.6. Authenticating Cleartext Portions of Messages .............. 9 76 2.7. Capability Negotiation ..................................... 10 77 3. Use of ASN.1 in Kerberos ..................................... 10 78 3.1. Module Header .............................................. 11 79 3.2. Top-Level Type ............................................. 11 80 3.3. Previously Unused ASN.1 Notation (informative) ............. 12 81 3.3.1. Parameterized Types ...................................... 12 82 3.3.2. COMPONENTS OF Notation ................................... 12 83 3.3.3. Constraints .............................................. 12 84 3.4. New Types .................................................. 13 85 4. Basic Types .................................................. 14 86 4.1. Constrained Integer Types .................................. 14 87 4.2. KerberosTime ............................................... 15 88 4.3. KerberosString ............................................. 15 89 4.4. Language Tags .............................................. 16 90 4.5. KerberosFlags .............................................. 16 91 4.6. Typed Holes ................................................ 16 92 4.7. HostAddress and HostAddresses .............................. 17 93 4.7.1. Internet (IPv4) Addresses ................................ 17 94 4.7.2. Internet (IPv6) Addresses ................................ 17 95 4.7.3. DECnet Phase IV addresses ................................ 18 96 4.7.4. Netbios addresses ........................................ 18 97 4.7.5. Directional Addresses .................................... 18 98 5. Principals ................................................... 19 99 5.1. Name Types ................................................. 19 100 5.2. Principal Type Definition .................................. 19 101 5.3. Principal Name Reuse ....................................... 20 102 5.4. Realm Names ................................................ 20 103 5.5. Printable Representations of Principal Names ............... 21 104 5.6. Ticket-Granting Service Principal .......................... 21 105 5.6.1. Cross-Realm TGS Principals ............................... 21 106 6. Types Relating to Encryption ................................. 21 107 6.1. Assigned Numbers for Encryption ............................ 22 108 6.1.1. EType .................................................... 22 109 6.1.2. Key Usages ............................................... 22 110 111Yu Expires: Mar 2005 [Page 2] 112 113Internet-Draft rfc1510ter-01 15 Sep 2005 114 115 6.2. Which Key to Use ........................................... 23 116 6.3. EncryptionKey .............................................. 24 117 6.4. EncryptedData .............................................. 24 118 6.5. Checksums .................................................. 25 119 6.5.1. ChecksumOf ............................................... 26 120 6.5.2. Signed ................................................... 27 121 7. Tickets ...................................................... 27 122 7.1. Timestamps ................................................. 28 123 7.2. Ticket Flags ............................................... 28 124 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 29 125 7.2.2. Invalid Tickets .......................................... 29 126 7.2.3. OK as Delegate ........................................... 30 127 7.2.4. Renewable Tickets ........................................ 30 128 7.2.5. Postdated Tickets ........................................ 31 129 7.2.6. Proxiable and Proxy Tickets .............................. 32 130 7.2.7. Forwarded and Forwardable Tickets ........................ 33 131 7.3. Transited Realms ........................................... 34 132 7.4. Authorization Data ......................................... 34 133 7.4.1. AD-IF-RELEVANT ........................................... 35 134 7.4.2. AD-KDCIssued ............................................. 35 135 7.4.3. AD-AND-OR ................................................ 37 136 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 37 137 7.5. Encrypted Part of Ticket ................................... 37 138 7.6. Cleartext Part of Ticket ................................... 38 139 8. Credential Acquisition ....................................... 40 140 8.1. KDC-REQ .................................................... 40 141 8.2. PA-DATA .................................................... 46 142 8.3. KDC-REQ Processing ......................................... 46 143 8.3.1. Handling Replays ......................................... 46 144 8.3.2. Request Validation ....................................... 47 145 8.3.2.1. AS-REQ Authentication .................................. 47 146 8.3.2.2. TGS-REQ Authentication ................................. 47 147 8.3.2.3. Principal Validation ................................... 47 148 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 48 149 8.3.3. Timestamp Handling ....................................... 48 150 8.3.3.1. AS-REQ Timestamp Processing ............................ 49 151 8.3.3.2. TGS-REQ Timestamp Processing ........................... 49 152 8.3.4. Handling Transited Realms ................................ 50 153 8.3.5. Address Processing ....................................... 50 154 8.3.6. Ticket Flag Processing ................................... 51 155 8.3.7. Key Selection ............................................ 52 156 8.3.7.1. Reply Key and Session Key Selection .................... 52 157 8.3.7.2. Ticket Key Selection ................................... 52 158 8.4. KDC-REP .................................................... 52 159 8.5. Reply Validation ........................................... 55 160 8.6. IP Transports .............................................. 55 161 8.6.1. UDP/IP transport ......................................... 55 162 8.6.2. TCP/IP transport ......................................... 56 163 8.6.3. KDC Discovery on IP Networks ............................. 57 164 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57 165 8.6.3.2. DNS SRV records for KDC location ....................... 58 166 167Yu Expires: Mar 2005 [Page 3] 168 169Internet-Draft rfc1510ter-01 15 Sep 2005 170 171 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP 172 Networks ............................................ 58 173 9. Errors ....................................................... 58 174 10. Session Key Exchange ........................................ 61 175 10.1. AP-REQ .................................................... 61 176 10.2. AP-REP .................................................... 63 177 11. Session Key Use ............................................. 65 178 11.1. KRB-SAFE .................................................. 65 179 11.2. KRB-PRIV .................................................. 65 180 11.3. KRB-CRED .................................................. 66 181 12. Security Considerations ..................................... 67 182 12.1. Time Synchronization ...................................... 67 183 12.2. Replays ................................................... 67 184 12.3. Principal Name Reuse ...................................... 67 185 12.4. Password Guessing ......................................... 67 186 12.5. Forward Secrecy ........................................... 67 187 12.6. Authorization ............................................. 68 188 12.7. Login Authentication ...................................... 68 189 13. IANA Considerations ......................................... 68 190 14. Acknowledgments ............................................. 69 191 Appendices ....................................................... 69 192 A. ASN.1 Module (Normative) ..................................... 69 193 B. Kerberos and Character Encodings (Informative) ...............103 194 C. Kerberos History (Informative) ...............................104 195 D. Notational Differences from [KCLAR] ..........................105 196 Normative References .............................................106 197 Informative References ...........................................106 198 Author's Address .................................................108 199 Copyright Statement ..............................................108 200 Intellectual Property Statement ..................................108 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Yu Expires: Mar 2005 [Page 4] 224 225Internet-Draft rfc1510ter-01 15 Sep 2005 226 2271. Introduction 228 229 The Kerberos network authentication protocol is a trusted-third-party 230 protocol utilizing symmetric-key cryptography. It assumes that all 231 communications between parties in the protocol may be arbitrarily 232 tampered with or monitored, and that the security of the overall 233 system depends only on the effectiveness of the cryptographic 234 techniques and the secrecy of the cryptographic keys used. The 235 Kerberos protocol authenticates an application client's identity to 236 an application server, and likewise authenticates the application 237 server's identity to the application client. These assurances are 238 made possible by the client and the server sharing secrets with the 239 trusted third party: the Kerberos server, also known as the Key 240 Distribution Center (KDC). In addition, the protocol establishes an 241 ephemeral shared secret (the session key) between the client and the 242 server, allowing the protection of further communications between 243 them. 244 245 The Kerberos protocol, as originally specified, provides insufficient 246 means for extending the protocol in a backwards-compatible way. This 247 deficiency has caused problems for interoperability. This document 248 describes a framework which enables backwards-compatible extensions 249 to the Kerberos protocol. 250 2511.1. Kerberos Protocol Overview 252 253 Kerberos comprises three main sub-protocols: credentials acquisition, 254 session key exchange, and session key usage. A client acquires 255 credentials by asking the KDC for a credential for a service; the KDC 256 issues the credential, which contains a ticket and a session key. 257 The ticket, containing the client's identity, timestamps, expiration 258 time, and a session key, is a encrypted in a key known to the 259 application server. The KDC encrypts the credential using a key 260 known to the client, and transmits the credential to the client. 261 262 There are two means of requesting credentials: the Authentication 263 Service (AS) exchange, and the Ticket-Granting Service (TGS) 264 exchange. In the typical AS exchange, a client uses a password- 265 derived key to decrypt the response. In the TGS exchange, the KDC 266 behaves as an application server; the client authenticates to the TGS 267 by using a Ticket-Granting Ticket (TGT). The client usually obtains 268 the TGT by using the AS exchange. 269 270 Session key exchange consists of the client transmitting the ticket 271 to the application server, accompanied by an authenticator. The 272 authenticator contains a timestamp and additional data encrypted 273 using the ticket's session key. The application server decrypts the 274 ticket, extracting the session key. The application server then uses 275 the session key to decrypt the authenticator. Upon successful 276 decryption of the authenticator, the application server knows that 277 the data in the authenticator were sent by the client named in the 278 279Yu Expires: Mar 2005 [Page 5] 280 281Internet-Draft rfc1510ter-01 15 Sep 2005 282 283 associated ticket. Additionally, since authenticators expire more 284 quickly than tickets, the application server has some assurance that 285 the transaction is not a replay. The application server may send an 286 encrypted acknowledgment to the client, verifying its identity to the 287 client. 288 289 Once session key exchange has occurred, the client and server may use 290 the established session key to protect further traffic. This 291 protection may consist of protection of integrity only, or of 292 protection of confidentiality and integrity. Additional measures 293 exist for a client to securely forward credentials to a server. 294 295 The entire scheme depends on loosely synchronized clocks. 296 Synchronization of the clock on the KDC with the application server 297 clock allows the application server to accurately determine whether a 298 credential is expired. Likewise, synchronization of the clock on the 299 client with the application server clock prevents replay attacks 300 utilizing the same credential. Careful design of the application 301 protocol may allow replay prevention without requiring client-server 302 clock synchronization. 303 304 After establishing a session key, application client and the 305 application server can exchange Kerberos protocol messages that use 306 the session key to protect the integrity or confidentiality of 307 communications between the client and the server. Additionally, the 308 client may forward credentials to the application server. 309 310 The credentials acquisition protocol takes place over specific, 311 defined transports (UDP and TCP). Application protocols define which 312 transport to use for the session key establishment protocol and for 313 messages using the session key; the application may choose to perform 314 its own encapsulation of the Kerberos messages, for example. 315 3161.2. Document Organization 317 318 The remainder of this document begins by describing the general 319 frameworks for protocol extensibility, including whether to interpret 320 unknown extensions as critical. It then defines the protocol 321 messages and exchanges. 322 323 The definition of the Kerberos protocol uses Abstract Syntax Notation 324 One (ASN.1) [X680], which specifies notation for describing the 325 abstract content of protocol messages. This document defines a 326 number of base types using ASN.1; these base types subsequently 327 appear in multiple types which define actual protocol messages. 328 Definitions of principal names and of tickets, which are central to 329 the protocol, also appear preceding the protocol message definitions. 330 331 332 333 334 335Yu Expires: Mar 2005 [Page 6] 336 337Internet-Draft rfc1510ter-01 15 Sep 2005 338 3392. Compatibility Considerations 340 3412.1. Extensibility 342 343 In the past, significant interoperability problems have resulted from 344 conflicting assumptions about how the Kerberos protocol can be 345 extended. As the deployed base of Kerberos grows, the ability to 346 extend the Kerberos protocol becomes more important. In order to 347 ensure that vendors and the IETF can extend the protocol while 348 maintaining backwards compatibility, this document outlines a 349 framework for extending Kerberos. 350 351 Kerberos provides two general mechanisms for protocol extensibility. 352 Many protocol messages, including some defined in RFC 1510, contain 353 typed holes--sub-messages containing an octet string along with an 354 integer that identifies how to interpret the octet string. The 355 integer identifiers are registered centrally, but can be used both 356 for vendor extensions and for extensions standardized in the IETF. 357 This document adds typed holes to a number of messages which 358 previously lacked typed holes. 359 360 Many new messages defined in this document also contain ASN.1 361 extension markers. These markers allow future revisions of this 362 document to add additional elements to messages, for cases where 363 typed holes are inadequate for some reason. Because tag numbers and 364 position in a sequence need to be coordinated in order to maintain 365 interoperability, implementations MUST NOT include ASN.1 extensions 366 except when those extensions are specified by IETF standards-track 367 documents. 368 3692.2. Compatibility with RFC 1510 370 371 Implementations of RFC 1510 did not use extensible ASN.1 types. 372 Sending additional fields not in RFC 1510 to these implementations 373 results in undefined behavior. Examples of this behavior are known 374 to include discarding messages with no error indications. 375 376 Where messages have been changed since RFC 1510, ASN.1 CHOICE types 377 are used; one alternative of the CHOICE provides a message which is 378 wire-encoding compatible with RFC 1510, and the other alternative 379 provides the new, extensible message. 380 381 Implementations sending new messages MUST ensure that the recipient 382 supports these new messages. Along with each extensible message is a 383 guideline for when that message MAY be used. IF that guideline is 384 followed, then the recipient is guaranteed to understand the message. 385 3862.3. Backwards Compatibility 387 388 This document describes two sets (for the most part) of ASN.1 types. 389 The first set of types is wire-encoding compatible with RFC 1510 and 390 391Yu Expires: Mar 2005 [Page 7] 392 393Internet-Draft rfc1510ter-01 15 Sep 2005 394 395 [KCLAR]. The second set of types is the set of types enabling 396 extensibility. This second set may be referred to as 397 "extensibility-enabled types". [ need to make this consistent 398 throughout? ] 399 400 A major difference between the new extensibility-enabled types and 401 the types for RFC 1510 compatibility is that the extensibility- 402 enabled types allow for the use of UTF-8 encodings in various 403 character strings in the protocol. Each party in the protocol must 404 have some knowledge of the capabilities of the other parties in the 405 protocol. There are methods for establishing this knowledge without 406 necessarily requiring explicit configuration. 407 408 An extensibility-enabled client can detect whether a KDC supports the 409 extensibility-enabled types by requesting an extensibility-enabled 410 reply. If the KDC replies with an extensibility-enabled reply, the 411 client knows that the KDC supports extensibility. If the KDC issues 412 an extensibility-enabled ticket, the client knows that the service 413 named in the ticket is extensibility-enabled. 414 4152.4. 1.4.2. Sending Extensible Messages 416 417 Care must be taken to make sure that old implementations can 418 understand messages sent to them even if they do not understand an 419 extension that is used. Unless the sender knows the extension is 420 supported, the extension cannot change the semantics of the core 421 message or previously defined extensions. 422 423 For example, an extension including key information necessary to 424 decrypt the encrypted part of a KDC-REP could only be used in 425 situations where the recipient was known to support the extension. 426 Thus when designing such extensions it is important to provide a way 427 for the recipient to notify the sender of support for the extension. 428 For example in the case of an extension that changes the KDC-REP 429 reply key, the client could indicate support for the extension by 430 including a padata element in the AS-REQ sequence. The KDC should 431 only use the extension if this padata element is present in the AS- 432 REQ. Even if policy requires the use of the extension, it is better 433 to return an error indicating that the extension is required than to 434 use the extension when the recipient may not support it; debugging 435 why implementations do not interoperate is easier when errors are 436 returned. 437 4382.5. Criticality 439 440 Recipients of unknown message extensions (including typed holes, new 441 flags, and ASN.1 extension elements) should preserve the encoding of 442 the extension but otherwise ignore the presence of the extension; 443 i.e., unknown extensions SHOULD be treated as non-critical. If a 444 copy of the message is used later--for example, when a Ticket 445 received in a KDC-REP is later used in an AP-REQ--then the unknown 446 447Yu Expires: Mar 2005 [Page 8] 448 449Internet-Draft rfc1510ter-01 15 Sep 2005 450 451 extensions MUST be included. 452 453 An implementation SHOULD NOT reject a request merely because it does 454 not understand some element of the request. As a related 455 consequence, implementations SHOULD handle communicating with other 456 implementations which do not implement some requested options. This 457 may require designers of options to provide means to determine 458 whether an option has been rejected, not understood, or (perhaps 459 maliciously) deleted or modified in transit. 460 461 There is one exception to non-criticality described above: if an 462 unknown authorization data element is received by a server either in 463 an AP-REQ or in a Ticket contained in an AP-REQ, then the 464 authentication SHOULD fail. Authorization data is intended to 465 restrict the use of a ticket. If the service cannot determine 466 whether the restriction applies to that service then a security 467 weakness may result if authentication succeeds. Authorization 468 elements meant to be truly optional can be enclosed in the AD-IF- 469 RELEVANT element. 470 471 Many RFC 1510 implementations ignore unknown authorization data 472 elements. Depending on these implementations to honor authorization 473 data restrictions may create a security weakness. 474 4752.6. Authenticating Cleartext Portions of Messages 476 477 Various denial of service attacks and downgrade attacks against 478 Kerberos are possible unless plaintexts are somehow protected against 479 modification. An early design goal of Kerberos Version 5 was to 480 avoid encrypting more of the authentication exchange that was 481 required. (Version 4 doubly-encrypted the encrypted part of a ticket 482 in a KDC reply, for example.) This minimization of encryption 483 reduces the load on the KDC and busy servers. Also, during the 484 initial design of Version 5, the existence of legal restrictions on 485 the export of cryptography made it desirable to minimize of the 486 number of uses of encryption in the protocol. Unfortunately, 487 performing this minimization created numerous instances of 488 unauthenticated security-relevant plaintext fields. 489 490 The extensible variants of the messages described in this document 491 wrap the actual message in an ASN.1 sequence containing a keyed 492 checksum of the contents of the message. Guidelines in [XXX] section 493 3 specify when the checksum MUST be included and what key MUST be 494 used. Guidelines on when to include a checksum are never ambiguous: 495 a particular PDU is never correct both with and without a checksum. 496 With the exception of the KRB-ERROR message, receiving 497 implementations MUST reject messages where a checksum is included and 498 not expected or where a checksum is expected but not included. The 499 receiving implementation does not always have sufficient information 500 to know whether a KRB-ERROR should contain a checksum. Even so, 501 KRB-ERROR messages with invalid checksums MUST be rejected and 502 503Yu Expires: Mar 2005 [Page 9] 504 505Internet-Draft rfc1510ter-01 15 Sep 2005 506 507 implementations MAY consider the presence or absence of a checksum 508 when evaluating whether to trust the error. 509 510 This authenticated cleartext protection is provided only in the 511 extensible variants of the messages; it is never used when 512 communicating with an RFC 1510 implementation. 513 5142.7. Capability Negotiation 515 516 Kerberos is a three-party protocol. Each of the three parties 517 involved needs a means of detecting the capabilities supported by the 518 others. Two of the parties, the KDC and the application server, do 519 not communicate directly in the Kerberos protocol. Communicating 520 capabilities from the KDC to the application server requires using a 521 ticket as an intermediary. 522 523 The main capability requiring negotiation is the support of the 524 extensibility framework described in this document. Negotiation of 525 this capability while remaining compatible with RFC 1510 526 implementations is possible. The main complication is that the 527 client needs to know whether the application server supports the 528 extensibility framework prior to sending any message to the 529 application server. This can be accomplished if the KDC has 530 knowledge of whether an application server supports the extensibility 531 framework. 532 533 Client software advertizes its capabilities when requesting 534 credentials from the KDC. If the KDC recognizes the capabilities, it 535 acknowledges this fact to the client in its reply. In addition, if 536 the KDC has knowledge that the application server supports certain 537 capabilities, it also communicates this knowledge to the client in 538 its reply. The KDC can encode its own capabilities in the ticket so 539 that the application server may discover these capabilities. The 540 client advertizes its capabilities to the application server when it 541 initiates authentication to the application server. 542 5433. Use of ASN.1 in Kerberos 544 545 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. 546 Even though ASN.1 theoretically allows the description of protocol 547 messages to be independent of the encoding rules used to encode the 548 messages, Kerberos messages MUST be encoded with DER. Subtleties in 549 the semantics of the notation, such as whether tags carry any 550 semantic content to the application, may cause the use of other ASN.1 551 encoding rules to be problematic. 552 553 Implementors not using existing ASN.1 tools (e.g., compilers or 554 support libraries) are cautioned to thoroughly read and understand 555 the actual ASN.1 specification to ensure correct implementation 556 behavior. There is more complexity in the notation than is 557 immediately obvious, and some tutorials and guides to ASN.1 are 558 559Yu Expires: Mar 2005 [Page 10] 560 561Internet-Draft rfc1510ter-01 15 Sep 2005 562 563 misleading or erroneous. Recommended tutorials and guides include 564 [Dub00], [Lar99], though there is still no substitute for reading the 565 actual ASN.1 specification. 566 5673.1. Module Header 568 569 The type definitions in this document assume an ASN.1 module 570 definition of the following form: 571 572 KerberosV5Spec3 { 573 iso(1) identified-organization(3) dod(6) internet(1) 574 security(5) kerberosV5(2) modules(4) krb5spec3(4) 575 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 576 577 -- Rest of definitions here 578 579 END 580 581 This specifies that the tagging context for the module will be 582 explicit and that automatic tagging is not done. 583 584 Some other publications [RFC1510] [RFC1964] erroneously specify an 585 object identifier (OID) having an incorrect value of "5" for the 586 "dod" component of the OID. In the case of RFC 1964, use of the 587 "correct" OID value would result in a change in the wire protocol; 588 therefore, the RFC 1964 OID remains unchanged for now. 589 5903.2. Top-Level Type 591 592 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol 593 Data Units or PDUs) which an application may directly reference. 594 Applications SHOULD NOT transmit any types other than those which are 595 alternatives of the KRB-PDU CHOICE. 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Yu Expires: Mar 2005 [Page 11] 616 617Internet-Draft rfc1510ter-01 15 Sep 2005 618 619 -- top-level type 620 -- 621 -- Applications should not directly reference any types 622 -- other than KRB-PDU and its component types. 623 -- 624 KRB-PDU ::= CHOICE { 625 ticket Ticket, 626 as-req AS-REQ, 627 as-rep AS-REP, 628 tgs-req TGS-REQ, 629 tgs-rep TGS-REP, 630 ap-req AP-REQ, 631 ap-rep AP-REP, 632 krb-safe KRB-SAFE, 633 krb-priv KRB-PRIV, 634 krb-cred KRB-CRED, 635 tgt-req TGT-REQ, 636 krb-error KRB-ERROR, 637 ... 638 } 639 640 6413.3. Previously Unused ASN.1 Notation (informative) 642 643 Some aspects of ASN.1 notation used in this document were not used in 644 [KCLAR], and may be unfamiliar to some readers. This subsection is 645 informative; for normative definitions of the notation, see the 646 actual ASN.1 specifications [X680], [X682], [X683]. 647 6483.3.1. Parameterized Types 649 650 This document uses ASN.1 parameterized types [X683] to make 651 definitions of types more readable. For some types, some or all of 652 the parameters are advisory, i.e., they are not encoded in any form 653 for transmission in a protocol message. These advisory parameters 654 can describe implementation behavior associated with the type. 655 6563.3.2. COMPONENTS OF Notation 657 658 The "COMPONENTS OF" notation, used to define the RFC 1510 659 compatibility types, extracts all of the component types of an ASN.1 660 SEQUENCE type. The extension marker (the "..." notation) and any 661 extension components are not extracted by "COMPONENTS OF". The 662 "COMPONENTS OF" notation permits concise definition of multiple types 663 which have many components in common with each other. 664 6653.3.3. Constraints 666 667 This document uses ASN.1 constraints, including the 668 "UserDefinedConstraint" notation [X682]. Some constraints can be 669 handled automatically by tools that can parse them. Uses of the 670 671Yu Expires: Mar 2005 [Page 12] 672 673Internet-Draft rfc1510ter-01 15 Sep 2005 674 675 "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will 676 typically need to have behavior manually coded; the notation provides 677 a formalized way of conveying intended implementation behavior. 678 679 The "WITH COMPONENTS" constraint notation allows constraints to apply 680 to component types of a SEQUENCE type. This constraint notation 681 effectively allows constraints to "reach into" a type to constrain 682 its component types. 683 6843.4. New Types 685 686 This document defines a number of ASN.1 types which are new since 687 [KCLAR]. The names of these types will typically have a suffix like 688 "Ext", indicating that the types are intended to support 689 extensibility. Types original to RFC 1510 and [KCLAR] have been 690 renamed to have a suffix like "1510". The "Ext" and "1510" types 691 often contain a number of common elements; these common elements have 692 a suffix like "Common". The "1510" types have various ASN.1 693 constraints applied to them; the constraints limit the possible 694 values of the "1510" types to those permitted by RFC 1510 or by 695 [KCLAR]. The "Ext" types may have different constraints, typically 696 to force string values to be sent as UTF-8. 697 698 For example, consider 699 700 -- example "common" type 701 Foo-Common ::= SEQUENCE { 702 a [0] INTEGER, 703 b [1] OCTET STRING, 704 ..., 705 c [2] INTEGER, 706 ... 707 } 708 709 -- example "RFC 1510 compatibility" type 710 Foo-1510 ::= SEQUENCE { 711 -- the COMPONENTS OF notation drops the extension marker 712 -- and all extension additions. 713 COMPONENTS OF Foo-Common 714 } 715 716 -- example "extensibility-enabled" type 717 Foo-Ext ::= Foo-Common 718 719 where "Foo-Common" is a common type used to define both the "1510" 720 and "Ext" versions of a type. "Foo-1510" is the RFC 1510 version of 721 the type, while "Foo-Ext" is the extensible version. "Foo-1510" does 722 not contain the extension marker, nor does it contain the extension 723 component "c". The type "Foo-1510" is equivalent to "Foo-1510- 724 Equiv", shown below. 725 726 727Yu Expires: Mar 2005 [Page 13] 728 729Internet-Draft rfc1510ter-01 15 Sep 2005 730 731 -- example type equivalent to Foo-1510 732 Foo-1510-Equiv ::= SEQUENCE { 733 a [0] INTEGER, 734 b [1] OCTET STRING 735 } 736 737 7384. Basic Types 739 740 These "basic" Kerberos ASN.1 types appear in multiple other Kerberos 741 types. 742 7434.1. Constrained Integer Types 744 745 In RFC 1510, many types contained references to the unconstrained 746 INTEGER type. Since an unconstrained INTEGER can contain almost any 747 possible abstract integer value, most of the unconstrained references 748 to INTEGER in RFC 1510 were constrained to 32 bits or smaller in 749 [KCLAR]. 750 751 -- signed values representable in 32 bits 752 -- 753 -- These are often used as assigned numbers for various things. 754 Int32 ::= INTEGER (-2147483648..2147483647) 755 756 The "Int32" type often contains an assigned number identifying the 757 contents of a typed hole. Unless otherwise stated, non-negative 758 values are registered, and negative values are available for local 759 use. 760 761 -- unsigned 32 bit values 762 UInt32 ::= INTEGER (0..4294967295) 763 764 The "UInt32" type is used in some places where an unsigned 32-bit 765 integer is needed. 766 767 -- unsigned 64 bit values 768 UInt64 ::= INTEGER (0..18446744073709551615) 769 770 The "UInt64" type is used in places where 32 bits of precision may 771 provide inadequate security. 772 773 -- sequence numbers 774 SeqNum ::= UInt64 775 776 Sequence numbers were constrained to 32 bits in [KCLAR], but this 777 document allows for 64-bit sequence numbers. 778 779 -- nonces 780 Nonce ::= UInt64 781 782 783Yu Expires: Mar 2005 [Page 14] 784 785Internet-Draft rfc1510ter-01 15 Sep 2005 786 787 Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded 788 to 64 bits here. 789 790 -- microseconds 791 Microseconds ::= INTEGER (0..999999) 792 793 The "microseconds" type is intended to carry the microseconds part of 794 a time value. 795 7964.2. KerberosTime 797 798 KerberosTime ::= GeneralizedTime (CONSTRAINED BY { 799 -- MUST NOT include fractional seconds 800 }) 801 802 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 803 KerberosTime value MUST NOT include any fractional portions of the 804 seconds. As required by the DER, it further MUST NOT include any 805 separators, and it specifies the UTC time zone (Z). Example: The 806 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 807 November 1985 is "19851106210627Z". 808 8094.3. KerberosString 810 811 -- used for names and for error messages 812 KerberosString ::= CHOICE { 813 ia5 GeneralString (IA5String), 814 utf8 UTF8String, 815 ... -- no extension may be sent 816 -- to an rfc1510 implementation -- 817 } 818 819 The KerberosString type is used for character strings in various 820 places in the Kerberos protocol. For compatibility with RFC 1510, 821 GeneralString values constrained to IA5String (US-ASCII) are 822 permitted in messages exchanged with RFC 1510 implementations. The 823 new protocol messages contain strings encoded as UTF-8, and these 824 strings MUST be normalized using [SASLPREP]. KerberosString values 825 are present in principal names and in error messages. Control 826 characters SHOULD NOT be used in principal names, and used with 827 caution in error messages. 828 829 -- IA5 choice only; useful for constraints 830 KerberosStringIA5 ::= KerberosString 831 (WITH COMPONENTS { ia5 PRESENT }) 832 833 -- IA5 excluded; useful for constraints 834 KerberosStringExt ::= KerberosString 835 (WITH COMPONENTS { ia5 ABSENT }) 836 837 KerberosStringIA5 requires the use of the "ia5" alternative, while 838 839Yu Expires: Mar 2005 [Page 15] 840 841Internet-Draft rfc1510ter-01 15 Sep 2005 842 843 KerberosStringExt forbids it. These types appear in ASN.1 844 constraints on messages. 845 846 For detailed background regarding the history of character string use 847 in Kerberos, as well as discussion of some compatibility issues, see 848 Appendix B. 849 8504.4. Language Tags 851 852 -- used for language tags 853 LangTag ::= PrintableString 854 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 855 856 The "LangTag" type is used to specify language tags for localization 857 purposes, using the [RFC3066] format. 858 8594.5. KerberosFlags 860 861 For several message types, a specific constrained bit string type, 862 KerberosFlags, is used. 863 864 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 865 (CONSTRAINED BY { 866 -- MUST be a valid value of -- NamedBits 867 -- but if the value to be sent would be truncated to shorter 868 -- than 32 bits according to DER, the value MUST be padded 869 -- with trailing zero bits to 32 bits. Otherwise, no 870 -- trailing zero bits may be present. 871 872 }) 873 874 875 The actual bit string type encoded in Kerberos messages does not use 876 named bits. The advisory parameter of the KerberosFlags type names a 877 bit string type defined using named bits, whose value is encoded as 878 if it were a bit string with unnamed bits. This practice is 879 necessary because the DER require trailing zero bits to be removed 880 when encoding bit strings defined using named bits. Existing 881 implementations of Kerberos send exactly 32 bits rather than 882 truncating, so the size constraint requires the transmission of at 883 least 32 bits. Trailing zero bits beyond the first 32 bits are 884 truncated. 885 8864.6. Typed Holes 887 888 -- Typed hole identifiers 889 TH-id ::= CHOICE { 890 int32 Int32, 891 rel-oid RELATIVE-OID 892 } 893 894 895Yu Expires: Mar 2005 [Page 16] 896 897Internet-Draft rfc1510ter-01 15 Sep 2005 898 899 The "TH-id" type is a generalized means to identify the contents of a 900 typed hole. The "int32" alternative may be used for simple integer 901 assignments, in the same manner as "Int32", while the "rel-oid" 902 alternative may be used for hierarchical delegation. 903 9044.7. HostAddress and HostAddresses 905 906 AddrType ::= Int32 907 908 HostAddress ::= SEQUENCE { 909 addr-type [0] AddrType, 910 address [1] OCTET STRING 911 } 912 913 -- NOTE: HostAddresses is always used as an OPTIONAL field and 914 -- should not be a zero-length SEQUENCE OF. 915 -- 916 -- The extensible messages explicitly constrain this to be 917 -- non-empty. 918 HostAddresses ::= SEQUENCE OF HostAddress 919 920 921 addr-type 922 This field specifies the type of address that follows. 923 924 address 925 This field encodes a single address of the type identified by 926 "addr-type". 927 928 All negative values for the host address type are reserved for local 929 use. All non-negative values are reserved for officially assigned 930 type fields and interpretations. 931 932 933 addr-type | meaning 934 __________|______________ 935 2 | IPv4 936 3 | directional 937 12 | DECnet 938 20 | NetBIOS 939 24 | IPv6 940 941 942 9434.7.1. Internet (IPv4) Addresses 944 945 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in 946 MSB order (most significant byte first). The IPv4 loopback address 947 SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is 948 two (2). 949 950 951Yu Expires: Mar 2005 [Page 17] 952 953Internet-Draft rfc1510ter-01 15 Sep 2005 954 9554.7.2. Internet (IPv6) Addresses 956 957 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded 958 in MSB order (most significant byte first). The type of IPv6 959 addresses is twenty-four (24). The following addresses MUST NOT 960 appear in any Kerberos PDU: 961 962 * the Unspecified Address 963 964 * the Loopback Address 965 966 * Link-Local addresses 967 968 This restriction applies to the inclusion in the address fields of 969 Kerberos PDUs, but not to the address fields of packets that might 970 carry such PDUs. The restriction is necessary because the use of an 971 address with non-global scope could allow the acceptance of a message 972 sent from a node that may have the same address, but which is not the 973 host intended by the entity that added the restriction. If the 974 link-local address type needs to be used for communication, then the 975 address restriction in tickets must not be used (i.e. addressless 976 tickets must be used). 977 978 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 979 2. 980 9814.7.3. DECnet Phase IV addresses 982 983 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. 984 The type of DECnet Phase IV addresses is twelve (12). 985 9864.7.4. Netbios addresses 987 988 Netbios addresses are 16-octet addresses typically composed of 1 to 989 15 alphanumeric characters and padded with the US-ASCII SPC character 990 (code 32). The 16th octet MUST be the US-ASCII NUL character (code 991 0). The type of Netbios addresses is twenty (20). 992 9934.7.5. Directional Addresses 994 995 In many environments, including the sender address in KRB-SAFE and 996 KRB-PRIV messages is undesirable because the addresses may be changed 997 in transport by network address translators. However, if these 998 addresses are removed, the messages may be subject to a reflection 999 attack in which a message is reflected back to its originator. The 1000 directional address type provides a way to avoid transport addresses 1001 and reflection attacks. Directional addresses are encoded as four 1002 byte unsigned integers in network byte order. If the message is 1003 originated by the party sending the original AP-REQ message, then an 1004 address of 0 SHOULD be used. If the message is originated by the 1005 party to whom that AP-REQ was sent, then the address 1 SHOULD be 1006 1007Yu Expires: Mar 2005 [Page 18] 1008 1009Internet-Draft rfc1510ter-01 15 Sep 2005 1010 1011 used. Applications involving multiple parties can specify the use of 1012 other addresses. 1013 1014 Directional addresses MUST only be used for the sender address field 1015 in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a 1016 ticket address or in a AP-REQ message. This address type SHOULD only 1017 be used in situations where the sending party knows that the 1018 receiving party supports the address type. This generally means that 1019 directional addresses may only be used when the application protocol 1020 requires their support. Directional addresses are type (3). 1021 10225. Principals 1023 1024 Principals are participants in the Kerberos protocol. A "realm" 1025 consists of principals in one administrative domain, served by one 1026 KDC (or one replicated set of KDCs). Each principal name has an 1027 arbitrary number of components, though typical principal names will 1028 only have one or two components. A principal name is meant to be 1029 readable by and meaningful to humans, especially in a realm lacking a 1030 centrally adminstered authorization infrastructure. 1031 10325.1. Name Types 1033 1034 Each PrincipalName has NameType indicating what sort of name it is. 1035 The name-type SHOULD be treated as a hint. Ignoring the name type, 1036 no two names can be the same (i.e., at least one of the components, 1037 or the realm, must be different). 1038 1039 -- assigned numbers for name types (used in principal names) 1040 NameType ::= Int32 1041 1042 -- Name type not known 1043 nt-unknown NameType ::= 0 1044 -- Just the name of the principal as in DCE, or for users 1045 nt-principal NameType ::= 1 1046 -- Service and other unique instance (krbtgt) 1047 nt-srv-inst NameType ::= 2 1048 -- Service with host name as instance (telnet, rcommands) 1049 nt-srv-hst NameType ::= 3 1050 -- Service with host as remaining components 1051 nt-srv-xhst NameType ::= 4 1052 -- Unique ID 1053 nt-uid NameType ::= 5 1054 -- Encoded X.509 Distingished name [RFC 2253] 1055 nt-x500-principal NameType ::= 6 1056 -- Name in form of SMTP email name (e.g. user@foo.com) 1057 nt-smtp-name NameType ::= 7 1058 -- Enterprise name - may be mapped to principal name 1059 nt-enterprise NameType ::= 10 1060 1061 1062 1063Yu Expires: Mar 2005 [Page 19] 1064 1065Internet-Draft rfc1510ter-01 15 Sep 2005 1066 10675.2. Principal Type Definition 1068 1069 PrincipalName ::= SEQUENCE { 1070 name-type [0] NameType, 1071 -- May have zero elements, or individual elements may be 1072 -- zero-length, but this is NOT RECOMMENDED. 1073 name-string [1] SEQUENCE OF KerberosString 1074 } 1075 1076 1077 name-type 1078 hint of the type of name that follows 1079 1080 name-string 1081 The "name-string" encodes a sequence of components that form a 1082 name, each component encoded as a KerberosString. Taken 1083 together, a PrincipalName and a Realm form a principal 1084 identifier. Most PrincipalNames will have only a few components 1085 (typically one or two). 1086 10875.3. Principal Name Reuse 1088 1089 Realm administrators SHOULD use extreme caution when considering 1090 reusing a principal name. A service administrator might explicitly 1091 enter principal names into a local access control list (ACL) for the 1092 service. If such local ACLs exist independently of a centrally 1093 administered authorization infrastructure, realm administrators 1094 SHOULD NOT reuse principal names until confirming that all extant ACL 1095 entries referencing that principal name have been updated. Failure 1096 to perform this check can result in a security vulnerability, as a 1097 new principal can inadvertently inherit unauthorized privileges upon 1098 receiving a reused principal name. An organization whose Kerberos- 1099 authenticated services all use a centrally-adminstered authorization 1100 infrastructure may not need to take these precautions regarding 1101 principal name reuse. 1102 11035.4. Realm Names 1104 1105 Realm ::= KerberosString 1106 1107 -- IA5 only 1108 RealmIA5 ::= Realm (KerberosStringIA5) 1109 1110 -- IA5 excluded 1111 RealmExt ::= Realm (KerberosStringExt) 1112 1113 1114 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a 1115 character with the code 0 (the US-ASCII NUL). Most realms will 1116 usually consist of several components separated by periods (.), in 1117 the style of Internet Domain Names, or separated by slashes (/) in 1118 1119Yu Expires: Mar 2005 [Page 20] 1120 1121Internet-Draft rfc1510ter-01 15 Sep 2005 1122 1123 the style of X.500 names. 1124 11255.5. Printable Representations of Principal Names 1126 1127 [ perhaps non-normative? ] 1128 1129 The printable form of a principal name consists of the concatenation 1130 of components of the PrincipalName value using the slash character 1131 (/), followed by an at-sign (@), followed by the realm name. Any 1132 occurrence of a backslash (\), slash (/) or at-sign (@) in the 1133 PrincipalName value is quoted by a backslash. 1134 11355.6. Ticket-Granting Service Principal 1136 1137 The PrincipalName value corresponding to a ticket-granting service 1138 has two components: the first component is the string "krbtgt", and 1139 the second component is the realm name of the TGS which will accept a 1140 ticket-granting ticket having this service principal name. The realm 1141 name of service always indicates which realm issued the ticket. A 1142 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for 1143 obtaining tickets in the same realm would have the following ASN.1 1144 values for its "realm" and "sname" components, respectively: 1145 1146 -- Example Realm and PrincipalName for a TGS 1147 1148 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" 1149 1150 tgtPrinc1 PrincipalName ::= { 1151 name-type nt-srv-inst, 1152 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } 1153 } 1154 1155 Its printable representation would be written as 1156 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". 1157 11585.6.1. Cross-Realm TGS Principals 1159 1160 It is possible for a principal in one realm to authenticate to a 1161 service in another realm. A KDC can issue a cross-realm ticket- 1162 granting ticket to allow one of its principals to authenticate to a 1163 service in a foreign realm. For example, the TGS principal 1164 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a 1165 client principal in the realm A.EXAMPLE.COM to authenticate to a 1166 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM 1167 issues a ticket to a client originating in A.EXAMPLE.COM, the 1168 client's realm name remains "A.EXAMPLE.COM", even though the service 1169 principal will have the realm "B.EXAMPLE.COM". 1170 1171 1172 1173 1174 1175Yu Expires: Mar 2005 [Page 21] 1176 1177Internet-Draft rfc1510ter-01 15 Sep 2005 1178 11796. Types Relating to Encryption 1180 1181 Many Kerberos protocol messages contain encrypted encodings of 1182 various data types. Some Kerberos protocol messages also contain 1183 checksums (signatures) of encodings of various types. 1184 11856.1. Assigned Numbers for Encryption 1186 1187 Encryption algorithm identifiers and key usages both have assigned 1188 numbers, described in [KCRYPTO]. 1189 11906.1.1. EType 1191 1192 EType is the integer type for assigned numbers for encryption 1193 algorithms. Defined in [KCRYPTO]. 1194 1195 -- Assigned numbers denoting encryption mechanisms. 1196 EType ::= Int32 1197 1198 -- assigned numbers for encryption schemes 1199 et-des-cbc-crc EType ::= 1 1200 et-des-cbc-md4 EType ::= 2 1201 et-des-cbc-md5 EType ::= 3 1202 -- [reserved] 4 1203 et-des3-cbc-md5 EType ::= 5 1204 -- [reserved] 6 1205 et-des3-cbc-sha1 EType ::= 7 1206 et-dsaWithSHA1-CmsOID EType ::= 9 1207 et-md5WithRSAEncryption-CmsOID EType ::= 10 1208 et-sha1WithRSAEncryption-CmsOID EType ::= 11 1209 et-rc2CBC-EnvOID EType ::= 12 1210 et-rsaEncryption-EnvOID EType ::= 13 1211 et-rsaES-OAEP-ENV-OID EType ::= 14 1212 et-des-ede3-cbc-Env-OID EType ::= 15 1213 et-des3-cbc-sha1-kd EType ::= 16 1214 -- AES 1215 et-aes128-cts-hmac-sha1-96 EType ::= 17 1216 -- AES 1217 et-aes256-cts-hmac-sha1-96 EType ::= 18 1218 -- Microsoft 1219 et-rc4-hmac EType ::= 23 1220 -- Microsoft 1221 et-rc4-hmac-exp EType ::= 24 1222 -- opaque; PacketCable 1223 et-subkey-keymaterial EType ::= 65 1224 1225 12266.1.2. Key Usages 1227 1228 KeyUsage is the integer type for assigned numbers for key usages. 1229 Key usage values are inputs to the encryption and decryption 1230 1231Yu Expires: Mar 2005 [Page 22] 1232 1233Internet-Draft rfc1510ter-01 15 Sep 2005 1234 1235 functions described in [KCRYPTO]. 1236 1237 -- Assigned numbers denoting key usages. 1238 KeyUsage ::= UInt32 1239 1240 -- 1241 -- Actual identifier names are provisional and subject to 1242 -- change. 1243 -- 1244 ku-pa-enc-ts KeyUsage ::= 1 1245 ku-Ticket KeyUsage ::= 2 1246 ku-EncASRepPart KeyUsage ::= 3 1247 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 1248 ku-TGSReqAuthData-subkey KeyUsage ::= 5 1249 ku-pa-TGSReq-cksum KeyUsage ::= 6 1250 ku-pa-TGSReq-authenticator KeyUsage ::= 7 1251 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 1252 ku-EncTGSRepPart-subkey KeyUsage ::= 9 1253 ku-Authenticator-cksum KeyUsage ::= 10 1254 ku-APReq-authenticator KeyUsage ::= 11 1255 ku-EncAPRepPart KeyUsage ::= 12 1256 ku-EncKrbPrivPart KeyUsage ::= 13 1257 ku-EncKrbCredPart KeyUsage ::= 14 1258 ku-KrbSafe-cksum KeyUsage ::= 15 1259 ku-ad-KDCIssued-cksum KeyUsage ::= 19 1260 1261 1262 -- The following numbers are provisional... 1263 -- conflicts may exist elsewhere. 1264 ku-Ticket-cksum KeyUsage ::= 25 1265 ku-ASReq-cksum KeyUsage ::= 26 1266 ku-TGSReq-cksum KeyUsage ::= 27 1267 ku-ASRep-cksum KeyUsage ::= 28 1268 ku-TGSRep-cksum KeyUsage ::= 29 1269 ku-APReq-cksum KeyUsage ::= 30 1270 ku-APRep-cksum KeyUsage ::= 31 1271 ku-KrbCred-cksum KeyUsage ::= 32 1272 ku-KrbError-cksum KeyUsage ::= 33 1273 ku-KDCRep-cksum KeyUsage ::= 34 1274 1275 12766.2. Which Key to Use 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287Yu Expires: Mar 2005 [Page 23] 1288 1289Internet-Draft rfc1510ter-01 15 Sep 2005 1290 1291 -- KeyToUse identifies which key is to be used to encrypt or 1292 -- sign a given value. 1293 -- 1294 -- Values of KeyToUse are never actually transmitted over the 1295 -- wire, or even used directly by the implementation in any 1296 -- way, as key usages are; it exists primarily to identify 1297 -- which key gets used for what purpose. Thus, the specific 1298 -- numeric values associated with this type are irrelevant. 1299 KeyToUse ::= ENUMERATED { 1300 -- unspecified 1301 key-unspecified, 1302 -- server long term key 1303 key-server, 1304 -- client long term key 1305 key-client, 1306 -- key selected by KDC for encryption of a KDC-REP 1307 key-kdc-rep, 1308 -- session key from ticket 1309 key-session, 1310 -- subsession key negotiated via AP-REQ/AP-REP 1311 key-subsession, 1312 ... 1313 } 1314 1315 13166.3. EncryptionKey 1317 1318 The "EncryptionKey" type holds an encryption key. 1319 1320 EncryptionKey ::= SEQUENCE { 1321 keytype [0] EType, 1322 keyvalue [1] OCTET STRING 1323 } 1324 1325 1326 keytype 1327 This "EType" identifies the encryption algorithm, described in 1328 [KCRYPTO]. 1329 1330 keyvalue 1331 Contains the actual key. 1332 13336.4. EncryptedData 1334 1335 The "EncryptedData" type contains the encryption of another data 1336 type. The recipient uses fields within EncryptedData to determine 1337 which key to use for decryption. 1338 1339 1340 1341 1342 1343Yu Expires: Mar 2005 [Page 24] 1344 1345Internet-Draft rfc1510ter-01 15 Sep 2005 1346 1347 1348 -- "Type" specifies which ASN.1 type is encrypted to the 1349 -- ciphertext in the EncryptedData. "Keys" specifies a set of 1350 -- keys of which one key may be used to encrypt the data. 1351 -- "KeyUsages" specifies a set of key usages, one of which may 1352 -- be used to encrypt. 1353 -- 1354 -- None of the parameters is transmitted over the wire. 1355 EncryptedData { 1356 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1357 } ::= SEQUENCE { 1358 etype [0] EType, 1359 kvno [1] UInt32 OPTIONAL, 1360 cipher [2] OCTET STRING (CONSTRAINED BY { 1361 -- must be encryption of -- 1362 OCTET STRING (CONTAINING Type), 1363 -- with one of the keys -- KeyToUse:Keys, 1364 -- with key usage being one of -- 1365 KeyUsage:KeyUsages 1366 }), 1367 ... 1368 } 1369 1370 1371 1372 KeyUsages 1373 Advisory parameter indicating which key usage to use when 1374 encrypting the ciphertext. If "KeyUsages" indicate multiple 1375 "KeyUsage" values, the detailed description of the containing 1376 message will indicate which key to use under which conditions. 1377 1378 Type 1379 Advisory parameter indicating the ASN.1 type whose DER encoding 1380 is the plaintext encrypted into the EncryptedData. 1381 1382 Keys 1383 Advisory parameter indicating which key to use to perform the 1384 encryption. If "Keys" indicate multiple "KeyToUse" values, the 1385 detailed description of the containing message will indicate 1386 which key to use under which conditions. 1387 1388 KeyUsages 1389 Advisory parameter indicating which "KeyUsage" value is used to 1390 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, 1391 the detailed description of the containing message will indicate 1392 which key usage to use under which conditions. 1393 13946.5. Checksums 1395 1396 Several types contain checksums (actually signatures) of data. 1397 1398 1399Yu Expires: Mar 2005 [Page 25] 1400 1401Internet-Draft rfc1510ter-01 15 Sep 2005 1402 1403 CksumType ::= Int32 1404 1405 -- The parameters specify which key to use to produce the 1406 -- signature, as well as which key usage to use. The 1407 -- parameters are not actually sent over the wire. 1408 Checksum { 1409 KeyToUse:Keys, KeyUsage:KeyUsages 1410 } ::= SEQUENCE { 1411 cksumtype [0] CksumType, 1412 checksum [1] OCTET STRING (CONSTRAINED BY { 1413 -- signed using one of the keys -- 1414 KeyToUse:Keys, 1415 -- with key usage being one of -- 1416 KeyUsage:KeyUsages 1417 }) 1418 } 1419 1420 1421 CksumType 1422 Integer type for assigned numbers for signature algorithms. 1423 Defined in [KCRYPTO] 1424 1425 Keys 1426 As in EncryptedData 1427 1428 KeyUsages 1429 As in EncryptedData 1430 1431 cksumtype 1432 Signature algorithm used to produce the signature. 1433 1434 checksum 1435 The actual checksum. 1436 14376.5.1. ChecksumOf 1438 1439 ChecksumOf is similar to "Checksum", but specifies which type is 1440 signed. 1441 1442 -- a Checksum that must contain the checksum 1443 -- of a particular type 1444 ChecksumOf { 1445 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1446 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 1447 ..., 1448 checksum (CONSTRAINED BY { 1449 -- must be checksum of -- 1450 OCTET STRING (CONTAINING Type) 1451 }) 1452 }) 1453 1454 1455Yu Expires: Mar 2005 [Page 26] 1456 1457Internet-Draft rfc1510ter-01 15 Sep 2005 1458 1459 Type 1460 Indicates the ASN.1 type whose DER encoding is signed. 1461 14626.5.2. Signed 1463 1464 Signed is similar to "ChecksumOf", but contains an actual instance of 1465 the type being signed in addition to the signature. 1466 1467 -- parameterized type for wrapping authenticated plaintext 1468 Signed { 1469 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 1470 } ::= SEQUENCE { 1471 cksum [0] ChecksumOf { 1472 InnerType, Keys, KeyUsages 1473 } OPTIONAL, 1474 inner [1] InnerType, 1475 ... 1476 } 1477 1478 14797. Tickets 1480 1481 [ A large number of items described here are duplicated in the 1482 sections describing KDC-REQ processing. Should find a way to avoid 1483 this duplication. ] 1484 1485 A ticket binds a principal name to a session key. The important 1486 fields of a ticket are in the encrypted part. The components in 1487 common between the RFC 1510 and the extensible versions are 1488 1489 EncTicketPartCommon ::= SEQUENCE { 1490 flags [0] TicketFlags, 1491 key [1] EncryptionKey, 1492 crealm [2] Realm, 1493 cname [3] PrincipalName, 1494 transited [4] TransitedEncoding, 1495 authtime [5] KerberosTime, 1496 starttime [6] KerberosTime OPTIONAL, 1497 endtime [7] KerberosTime, 1498 renew-till [8] KerberosTime OPTIONAL, 1499 caddr [9] HostAddresses OPTIONAL, 1500 authorization-data [10] AuthorizationData OPTIONAL, 1501 ... 1502 } 1503 1504 1505 crealm 1506 This field contains the client's realm. 1507 1508 cname 1509 This field contains the client's name. 1510 1511Yu Expires: Mar 2005 [Page 27] 1512 1513Internet-Draft rfc1510ter-01 15 Sep 2005 1514 1515 caddr 1516 This field lists the network addresses (if absent, all addresses 1517 are permitted) from which the ticket is valid. 1518 1519 Descriptions of the other fields appear in the following sections. 1520 15217.1. Timestamps 1522 1523 Three of the ticket timestamps may be requested from the KDC. The 1524 timestamps may differ from those requested, depending on site policy. 1525 1526 authtime 1527 The time at which the client authenticated, as recorded by the 1528 KDC. 1529 1530 starttime 1531 The earliest time when the ticket is valid. If not present, the 1532 ticket is valid starting at the authtime. This is requested as 1533 the "from" field of KDC-REQ-BODY-COMMON. 1534 1535 endtime 1536 This time is requested in the "till" field of KDC-REQ-BODY- 1537 COMMON. Contains the time after which the ticket will not be 1538 honored (its expiration time). Note that individual services 1539 MAY place their own limits on the life of a ticket and MAY 1540 reject tickets which have not yet expired. As such, this is 1541 really an upper bound on the expiration time for the ticket. 1542 1543 renew-till 1544 This time is requested in the "rtime" field of KDC-REQ-BODY- 1545 COMMON. It is only present in tickets that have the "renewable" 1546 flag set in the flags field. It indicates the maximum endtime 1547 that may be included in a renewal. It can be thought of as the 1548 absolute expiration time for the ticket, including all renewals. 1549 15507.2. Ticket Flags 1551 1552 A number of flags may be set in the ticket, further defining some of 1553 its capabilities. Some of these flags map to flags in a KDC request. 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567Yu Expires: Mar 2005 [Page 28] 1568 1569Internet-Draft rfc1510ter-01 15 Sep 2005 1570 1571 TicketFlags ::= KerberosFlags { TicketFlagsBits } 1572 1573 TicketFlagsBits ::= BIT STRING { 1574 reserved (0), 1575 forwardable (1), 1576 forwarded (2), 1577 proxiable (3), 1578 proxy (4), 1579 may-postdate (5), 1580 postdated (6), 1581 invalid (7), 1582 renewable (8), 1583 initial (9), 1584 pre-authent (10), 1585 hw-authent (11), 1586 transited-policy-checked (12), 1587 ok-as-delegate (13), 1588 anonymous (14), 1589 cksummed-ticket (15) 1590 } 1591 1592 15937.2.1. Flags Relating to Initial Ticket Acquisition 1594 1595 [ adapted KCLAR 2.1. ] 1596 1597 Several flags indicate the details of how the initial ticket was 1598 acquired. 1599 1600 initial 1601 The "initial" flag indicates that a ticket was issued using the 1602 AS protocol, rather than issued based on a ticket-granting 1603 ticket. Application servers (e.g., a password-changing program) 1604 requiring a client's definite knowledge of its secret key can 1605 insist that this flag be set in any tickets they accept, thus 1606 being assured that the client's key was recently presented to 1607 the application client. 1608 1609 pre-authent 1610 The "pre-authent" flag indicates that some sort of pre- 1611 authentication was used during the AS exchange. 1612 1613 hw-authent 1614 The "hw-authent" flag indicates that some sort of hardware-based 1615 pre-authentication occurred during the AS exchange. 1616 1617 Both the "pre-authent" and the "hw-authent" flags may be present with 1618 or without the "initial" flag; such tickets with the "initial" flag 1619 clear are ones which are derived from initial tickets with the "pre- 1620 authent" or "hw-authent" flags set. 1621 1622 1623Yu Expires: Mar 2005 [Page 29] 1624 1625Internet-Draft rfc1510ter-01 15 Sep 2005 1626 16277.2.2. Invalid Tickets 1628 1629 [ KCLAR 2.2. ] 1630 1631 The "invalid" flag indicates that a ticket is invalid. Application 1632 servers MUST reject tickets which have this flag set. A postdated 1633 ticket will be issued in this form. Invalid tickets MUST be 1634 validated by the KDC before use, by presenting them to the KDC in a 1635 TGS request with the "validate" option specified. The KDC will only 1636 validate tickets after their starttime has passed. The validation is 1637 required so that postdated tickets which have been stolen before 1638 their starttime can be rendered permanently invalid (through a hot- 1639 list mechanism -- see Section 8.3.2.4). 1640 16417.2.3. OK as Delegate 1642 1643 [ KCLAR 2.8. ] 1644 1645 The "ok-as-delegate" flag provides a way for a KDC to communicate 1646 local realm policy to a client regarding whether the service for 1647 which the ticket is issued is trusted to accept delegated 1648 credentials. For some applications, a client may need to delegate 1649 credentials to a service to act on its behalf in contacting other 1650 services. The ability of a client to obtain a service ticket for a 1651 service conveys no information to the client about whether the 1652 service should be trusted to accept delegated credentials. 1653 1654 The copy of the ticket flags visible to the client may have the "ok- 1655 as-delegate" flag set to indicate to the client that the service 1656 specified in the ticket has been determined by policy of the realm to 1657 be a suitable recipient of delegation. A client can use the presence 1658 of this flag to help it make a decision whether to delegate 1659 credentials (either grant a proxy or a forwarded ticket-granting 1660 ticket) to this service. It is acceptable to ignore the value of 1661 this flag. When setting this flag, an administrator should consider 1662 the security and placement of the server on which the service will 1663 run, as well as whether the service requires the use of delegated 1664 credentials. 1665 16667.2.4. Renewable Tickets 1667 1668 [ adapted KCLAR 2.3. ] 1669 1670 The "renewable" flag indicates whether the ticket may be renewed. 1671 1672 Renewable tickets can be used to mitigate the consequences of ticket 1673 theft. Applications may desire to hold credentials which can be 1674 valid for long periods of time. However, this can expose the 1675 credentials to potential theft for equally long periods, and those 1676 stolen credentials would be valid until the expiration time of the 1677 ticket(s). Simply using short-lived tickets and obtaining new ones 1678 1679Yu Expires: Mar 2005 [Page 30] 1680 1681Internet-Draft rfc1510ter-01 15 Sep 2005 1682 1683 periodically would require the application to have long-term access 1684 to the client's secret key, which is an even greater risk. 1685 1686 Renewable tickets have two "expiration times": the first is when the 1687 current instance of the ticket expires, and the second is the latest 1688 permissible value for an individual expiration time. An application 1689 client must periodically present an unexpired renewable ticket to the 1690 KDC, setting the "renew" option in the KDC request. The KDC will 1691 issue a new ticket with a new session key and a later expiration 1692 time. All other fields of the ticket are left unmodified by the 1693 renewal process. When the latest permissible expiration time 1694 arrives, the ticket expires permanently. At each renewal, the KDC 1695 MAY consult a hot-list to determine if the ticket had been reported 1696 stolen since its last renewal; it will refuse to renew such stolen 1697 tickets, and thus the usable lifetime of stolen tickets is reduced. 1698 1699 The "renewable" flag in a ticket is normally only interpreted by the 1700 ticket-granting service. It can usually be ignored by application 1701 servers. However, some particularly careful application servers MAY 1702 disallow renewable tickets. 1703 1704 If a renewable ticket is not renewed by its expiration time, the KDC 1705 will not renew the ticket. The "renewable" flag is clear by default, 1706 but a client can request it be set by setting the "renewable" option 1707 in the AS-REQ message. If it is set, then the "renew-till" field in 1708 the ticket contains the time after which the ticket may not be 1709 renewed. 1710 17117.2.5. Postdated Tickets 1712 1713 postdated 1714 indicates a ticket which has been postdated 1715 1716 may-postdate 1717 indicates that postdated tickets may be issued based on this 1718 ticket 1719 1720 [ KCLAR 2.4. ] 1721 1722 Applications may occasionally need to obtain tickets for use much 1723 later, e.g., a batch submission system would need tickets to be valid 1724 at the time the batch job is serviced. However, it is dangerous to 1725 hold valid tickets in a batch queue, since they will be on-line 1726 longer and more prone to theft. Postdated tickets provide a way to 1727 obtain these tickets from the KDC at job submission time, but to 1728 leave them "dormant" until they are activated and validated by a 1729 further request of the KDC. If a ticket theft were reported in the 1730 interim, the KDC would refuse to validate the ticket, and the thief 1731 would be foiled. 1732 1733 1734 1735Yu Expires: Mar 2005 [Page 31] 1736 1737Internet-Draft rfc1510ter-01 15 Sep 2005 1738 1739 The "may-postdate" flag in a ticket is normally only interpreted by 1740 the TGS. It can be ignored by application servers. This flag MUST 1741 be set in a ticket-granting ticket in order for the KDC to issue a 1742 postdated ticket based on the presented ticket. It is reset by 1743 default; it MAY be requested by a client by setting the "allow- 1744 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag 1745 does not allow a client to obtain a postdated ticket-granting ticket; 1746 postdated ticket-granting tickets can only by obtained by requesting 1747 the postdating in the AS-REQ message. The life (endtime minus 1748 starttime) of a postdated ticket will be the remaining life of the 1749 ticket-granting ticket at the time of the request, unless the 1750 "renewable" option is also set, in which case it can be the full life 1751 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY 1752 limit how far in the future a ticket may be postdated. 1753 1754 The "postdated" flag indicates that a ticket has been postdated. The 1755 application server can check the authtime field in the ticket to see 1756 when the original authentication occurred. Some services MAY choose 1757 to reject postdated tickets, or they may only accept them within a 1758 certain period after the original authentication. When the KDC 1759 issues a "postdated" ticket, it will also be marked as "invalid", so 1760 that the application client MUST present the ticket to the KDC for 1761 validation before use. 1762 17637.2.6. Proxiable and Proxy Tickets 1764 1765 proxy 1766 indicates a proxy ticket 1767 1768 proxiable 1769 indicates that proxy tickets may be issued based on this ticket 1770 1771 [ KCLAR 2.5. ] 1772 1773 It may be necessary for a principal to allow a service to perform an 1774 operation on its behalf. The service must be able to take on the 1775 identity of the client, but only for a particular purpose. A 1776 principal can allow a service to take on the principal's identity for 1777 a particular purpose by granting it a proxy. 1778 1779 The process of granting a proxy using the "proxy" and "proxiable" 1780 flags is used to provide credentials for use with specific services. 1781 Though conceptually also a proxy, users wishing to delegate their 1782 identity in a form usable for all purposes MUST use the ticket 1783 forwarding mechanism described in the next section to forward a 1784 ticket-granting ticket. 1785 1786 The "proxiable" flag in a ticket is normally only interpreted by the 1787 ticket-granting service. It can be ignored by application servers. 1788 When set, this flag tells the ticket-granting server that it is OK to 1789 issue a new ticket (but not a ticket-granting ticket) with a 1790 1791Yu Expires: Mar 2005 [Page 32] 1792 1793Internet-Draft rfc1510ter-01 15 Sep 2005 1794 1795 different network address based on this ticket. This flag is set if 1796 requested by the client on initial authentication. By default, the 1797 client will request that it be set when requesting a ticket-granting 1798 ticket, and reset when requesting any other ticket. 1799 1800 This flag allows a client to pass a proxy to a server to perform a 1801 remote request on its behalf (e.g. a print service client can give 1802 the print server a proxy to access the client's files on a particular 1803 file server in order to satisfy a print request). 1804 1805 In order to complicate the use of stolen credentials, Kerberos 1806 tickets may contain a set of network addresses from which they are 1807 valid. When granting a proxy, the client MUST specify the new 1808 network address from which the proxy is to be used, or indicate that 1809 the proxy is to be issued for use from any address. 1810 1811 The "proxy" flag is set in a ticket by the TGS when it issues a proxy 1812 ticket. Application servers MAY check this flag and at their option 1813 they MAY require additional authentication from the agent presenting 1814 the proxy in order to provide an audit trail. 1815 18167.2.7. Forwarded and Forwardable Tickets 1817 1818 forwarded 1819 indicates a forwarded ticket 1820 1821 forwardable 1822 indicates that forwarded tickets may be issued based on this 1823 ticket 1824 1825 [ KCLAR 2.6. ] 1826 1827 Authentication forwarding is an instance of a proxy where the service 1828 that is granted is complete use of the client's identity. An example 1829 where it might be used is when a user logs in to a remote system and 1830 wants authentication to work from that system as if the login were 1831 local. 1832 1833 The "forwardable" flag in a ticket is normally only interpreted by 1834 the ticket-granting service. It can be ignored by application 1835 servers. The "forwardable" flag has an interpretation similar to 1836 that of the "proxiable" flag, except ticket-granting tickets may also 1837 be issued with different network addresses. This flag is reset by 1838 default, but users MAY request that it be set by setting the 1839 "forwardable" option in the AS request when they request their 1840 initial ticket-granting ticket. 1841 1842 This flag allows for authentication forwarding without requiring the 1843 user to enter a password again. If the flag is not set, then 1844 authentication forwarding is not permitted, but the same result can 1845 still be achieved if the user engages in the AS exchange specifying 1846 1847Yu Expires: Mar 2005 [Page 33] 1848 1849Internet-Draft rfc1510ter-01 15 Sep 2005 1850 1851 the requested network addresses and supplies a password. 1852 1853 The "forwarded" flag is set by the TGS when a client presents a 1854 ticket with the "forwardable" flag set and requests a forwarded 1855 ticket by specifying the "forwarded" KDC option and supplying a set 1856 of addresses for the new ticket. It is also set in all tickets 1857 issued based on tickets with the "forwarded" flag set. Application 1858 servers may choose to process "forwarded" tickets differently than 1859 non-forwarded tickets. 1860 1861 If addressless tickets are forwarded from one system to another, 1862 clients SHOULD still use this option to obtain a new TGT in order to 1863 have different session keys on the different systems. 1864 18657.3. Transited Realms 1866 1867 [ KCLAR 2.7., plus new stuff ] 1868 18697.4. Authorization Data 1870 1871 [ KCLAR 5.2.6. ] 1872 1873 ADType ::= TH-id 1874 1875 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1876 ad-type [0] ADType, 1877 ad-data [1] OCTET STRING 1878 } 1879 1880 1881 ad-type 1882 This field identifies the contents of the ad-data. All negative 1883 values are reserved for local use. Non-negative values are 1884 reserved for registered use. 1885 1886 ad-data 1887 This field contains authorization data to be interpreted 1888 according to the value of the corresponding ad-type field. 1889 1890 Each sequence of ADType and OCTET STRING is referred to as an 1891 authorization element. Elements MAY be application specific, 1892 however, there is a common set of recursive elements that should be 1893 understood by all implementations. These elements contain other 1894 AuthorizationData, and the interpretation of the encapsulating 1895 element determines which enclosed elements must be interpreted, and 1896 which may be ignored. 1897 1898 Depending on the meaning of the encapsulating element, the 1899 encapsulated AuthorizationData may be ignored, interpreted as issued 1900 directly by the KDC, or be stored in a separate plaintext part of the 1901 ticket. The types of the encapsulating elements are specified as 1902 1903Yu Expires: Mar 2005 [Page 34] 1904 1905Internet-Draft rfc1510ter-01 15 Sep 2005 1906 1907 part of the Kerberos protocol because behavior based on these 1908 container elements should be understood across implementations, while 1909 other elements need only be understood by the applications which they 1910 affect. 1911 1912 Authorization data elements are considered critical if present in a 1913 ticket or authenticator. Unless encapsulated in a known 1914 authorization data element modifying the criticality of the elements 1915 it contains, an application server MUST reject the authentication of 1916 a client whose AP-REQ or ticket contains an unrecognized 1917 authorization data element. Authorization data is intended to 1918 restrict the use of a ticket. If the service cannot determine 1919 whether it is the target of a restriction, a security weakness may 1920 exist if the ticket can be used for that service. Authorization 1921 elements that are truly optional can be enclosed in AD-IF-RELEVANT 1922 element. 1923 1924 1925 ad-type | contents of ad-data 1926 ________|_______________________________________ 1927 1 | DER encoding of AD-IF-RELEVANT 1928 4 | DER encoding of AD-KDCIssued 1929 5 | DER encoding of AD-AND-OR 1930 8 | DER encoding of AD-MANDATORY-FOR-KDC 1931 1932 1933 19347.4.1. AD-IF-RELEVANT 1935 1936 ad-if-relevant ADType ::= int32 : 1 1937 1938 -- Encapsulates another AuthorizationData. 1939 -- Intended for application servers; receiving application servers 1940 -- MAY ignore. 1941 AD-IF-RELEVANT ::= AuthorizationData 1942 1943 AD elements encapsulated within the if-relevant element are intended 1944 for interpretation only by application servers that understand the 1945 particular ad-type of the embedded element. Application servers that 1946 do not understand the type of an element embedded within the if- 1947 relevant element MAY ignore the uninterpretable element. This element 1948 promotes interoperability across implementations which may have local 1949 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). 1950 19517.4.2. AD-KDCIssued 1952 1953 1954 1955 1956 1957 1958 1959Yu Expires: Mar 2005 [Page 35] 1960 1961Internet-Draft rfc1510ter-01 15 Sep 2005 1962 1963 -- KDC-issued privilege attributes 1964 ad-kdcissued ADType ::= int32 : 4 1965 1966 AD-KDCIssued ::= SEQUENCE { 1967 ad-checksum [0] ChecksumOf { 1968 AuthorizationData, { key-session }, 1969 { ku-ad-KDCIssued-cksum }}, 1970 i-realm [1] Realm OPTIONAL, 1971 i-sname [2] PrincipalName OPTIONAL, 1972 elements [3] AuthorizationData 1973 } 1974 1975 1976 ad-checksum 1977 A cryptographic checksum computed over the DER encoding of the 1978 AuthorizationData in the "elements" field, keyed with the 1979 session key. Its checksumtype is the mandatory checksum type 1980 for the encryption type of the session key, and its key usage 1981 value is 19. 1982 1983 i-realm, i-sname 1984 The name of the issuing principal if different from the KDC 1985 itself. This field would be used when the KDC can verify the 1986 authenticity of elements signed by the issuing principal and it 1987 allows this KDC to notify the application server of the validity 1988 of those elements. 1989 1990 elements 1991 AuthorizationData issued by the KDC. 1992 1993 The KDC-issued ad-data field is intended to provide a means for 1994 Kerberos credentials to embed within themselves privilege attributes 1995 and other mechanisms for positive authorization, amplifying the 1996 privileges of the principal beyond what it would have if using 1997 credentials without such an authorization-data element. 1998 1999 This amplification of privileges cannot be provided without this 2000 element because the definition of the authorization-data field allows 2001 elements to be added at will by the bearer of a TGT at the time that 2002 they request service tickets and elements may also be added to a 2003 delegated ticket by inclusion in the authenticator. 2004 2005 For KDC-issued elements this is prevented because the elements are 2006 signed by the KDC by including a checksum encrypted using the 2007 server's key (the same key used to encrypt the ticket -- or a key 2008 derived from that key). AuthorizationData encapsulated with in the 2009 AD-KDCIssued element MUST be ignored by the application server if 2010 this "signature" is not present. Further, AuthorizationData 2011 encapsulated within this element from a ticket-granting ticket MAY be 2012 interpreted by the KDC, and used as a basis according to policy for 2013 including new signed elements within derivative tickets, but they 2014 2015Yu Expires: Mar 2005 [Page 36] 2016 2017Internet-Draft rfc1510ter-01 15 Sep 2005 2018 2019 will not be copied to a derivative ticket directly. If they are 2020 copied directly to a derivative ticket by a KDC that is not aware of 2021 this element, the signature will not be correct for the application 2022 ticket elements, and the field will be ignored by the application 2023 server. 2024 2025 This element and the elements it encapsulates MAY be safely ignored 2026 by applications, application servers, and KDCs that do not implement 2027 this element. 2028 2029 The ad-type for AD-KDC-ISSUED is (4). 2030 20317.4.3. AD-AND-OR 2032 2033 ad-and-or ADType ::= int32 : 5 2034 2035 AD-AND-OR ::= SEQUENCE { 2036 condition-count [0] INTEGER, 2037 elements [1] AuthorizationData 2038 } 2039 2040 2041 When restrictive AD elements are encapsulated within the and-or 2042 element, the and-or element is considered satisfied if and only if at 2043 least the number of encapsulated elements specified in condition- 2044 count are satisfied. Therefore, this element MAY be used to 2045 implement an "or" operation by setting the condition-count field to 2046 1, and it MAY specify an "and" operation by setting the condition 2047 count to the number of embedded elements. Application servers that do 2048 not implement this element MUST reject tickets that contain 2049 authorization data elements of this type. 2050 2051 The ad-type for AD-AND-OR is (5). 2052 20537.4.4. AD-MANDATORY-FOR-KDC 2054 2055 -- KDCs MUST interpret any AuthorizationData wrapped in this. 2056 ad-mandatory-for-kdc ADType ::= int32 : 8 2057 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2058 2059 AD elements encapsulated within the mandatory-for-kdc element are to 2060 be interpreted by the KDC. KDCs that do not understand the type of 2061 an element embedded within the mandatory-for-kdc element MUST reject 2062 the request. 2063 2064 The ad-type for AD-MANDATORY-FOR-KDC is (8). 2065 20667.5. Encrypted Part of Ticket 2067 2068 The complete definition of the encrypted part is 2069 2070 2071Yu Expires: Mar 2005 [Page 37] 2072 2073Internet-Draft rfc1510ter-01 15 Sep 2005 2074 2075 -- Encrypted part of ticket 2076 EncTicketPart ::= CHOICE { 2077 rfc1510 [APPLICATION 3] EncTicketPart1510, 2078 ext [APPLICATION 5] EncTicketPartExt 2079 } 2080 2081 with the common portion being 2082 2083 EncTicketPartCommon ::= SEQUENCE { 2084 flags [0] TicketFlags, 2085 key [1] EncryptionKey, 2086 crealm [2] Realm, 2087 cname [3] PrincipalName, 2088 transited [4] TransitedEncoding, 2089 authtime [5] KerberosTime, 2090 starttime [6] KerberosTime OPTIONAL, 2091 endtime [7] KerberosTime, 2092 renew-till [8] KerberosTime OPTIONAL, 2093 caddr [9] HostAddresses OPTIONAL, 2094 authorization-data [10] AuthorizationData OPTIONAL, 2095 ... 2096 } 2097 2098 2099 The encrypted part of the backwards-compatibility form of a ticket 2100 is: 2101 2102 EncTicketPart1510 ::= SEQUENCE { 2103 COMPONENTS OF EncTicketPartCommon 2104 } (WITH COMPONENTS { 2105 ..., 2106 -- explicitly force IA5 in strings 2107 crealm (RealmIA5), 2108 cname (PrincipalNameIA5) 2109 }) 2110 2111 The encrypted part of the extensible form of a ticket is: 2112 2113 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { 2114 ..., 2115 -- explicitly force UTF-8 in strings 2116 crealm (RealmExt), 2117 cname (PrincipalNameExt), 2118 -- explicitly constrain caddr to be non-empty if present 2119 caddr (SIZE (1..MAX)), 2120 -- forbid empty authorization-data encodings 2121 authorization-data (SIZE (1..MAX)) 2122 }) 2123 2124 2125 2126 2127Yu Expires: Mar 2005 [Page 38] 2128 2129Internet-Draft rfc1510ter-01 15 Sep 2005 2130 21317.6. Cleartext Part of Ticket 2132 2133 The complete definition of Ticket is: 2134 2135 Ticket ::= CHOICE { 2136 rfc1510 [APPLICATION 1] Ticket1510, 2137 ext [APPLICATION 4] Signed { 2138 TicketExt, { key-server }, { ku-Ticket-cksum } 2139 } 2140 } 2141 2142 with the common portion being: 2143 2144 -- takes a parameter specifying which type gets encrypted 2145 TicketCommon { EncPart } ::= SEQUENCE { 2146 tkt-vno [0] INTEGER (5), 2147 realm [1] Realm, 2148 sname [2] PrincipalName, 2149 enc-part [3] EncryptedData { 2150 EncPart, { key-server }, { ku-Ticket } 2151 }, 2152 ..., 2153 extensions [4] TicketExtensions OPTIONAL, 2154 ... 2155 } 2156 2157 2158 The "sname" field provides the name of the target service principal 2159 in cleartext, as a hint to aid the server in choosing the correct 2160 decryption key. 2161 2162 The backwards-compatibility form of Ticket is: 2163 2164 Ticket1510 ::= SEQUENCE { 2165 COMPONENTS OF TicketCommon { EncTicketPart1510 } 2166 } (WITH COMPONENTS { 2167 ..., 2168 -- explicitly force IA5 in strings 2169 realm (RealmIA5), 2170 sname (PrincipalNameIA5) 2171 }) 2172 2173 The extensible form of Ticket is: 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183Yu Expires: Mar 2005 [Page 39] 2184 2185Internet-Draft rfc1510ter-01 15 Sep 2005 2186 2187 -- APPLICATION tag goes inside Signed{} as well as outside, 2188 -- to prevent possible substitution attacks. 2189 TicketExt ::= [APPLICATION 4] TicketCommon { 2190 EncTicketPartExt 2191 } (WITH COMPONENTS { 2192 ..., 2193 -- explicitly force UTF-8 in strings 2194 realm (RealmExt), 2195 sname (PrincipalNameExt) 2196 }) 2197 2198 2199 TicketExtensions, which may only be present in the extensible form of 2200 Ticket, are a cleartext typed hole for extension use. 2201 AuthorizationData already provides an encrypted typed hole. 2202 2203 TEType ::= TH-id 2204 2205 -- ticket extensions: for TicketExt only 2206 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 2207 te-type [0] TEType, 2208 te-data [1] OCTET STRING 2209 } 2210 2211 2212 A client will only receive an extensible Ticket if the application 2213 server supports extensibility. 2214 22158. Credential Acquisition 2216 2217 There are two exchanges that can be used for acquiring credentials: 2218 the AS exchange and the TGS exchange. These exchanges have many 2219 similarities, and this document describes them in parallel, noting 2220 which behaviors are specific to one type of exchange. The AS request 2221 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests 2222 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) 2223 are forms of KDC replies (KDC-REP). 2224 2225 The credentials acquisition protocol operates over specific 2226 transports. Additionally, specific methods exist to permit a client 2227 to discover the KDC host with which to communicate. 2228 22298.1. KDC-REQ 2230 2231 The KDC-REQ has a large number of fields in common between the RFC 2232 1510 and the extensible versions. The KDC-REQ type itself is never 2233 directly encoded; it is always a part of a AS-REQ or a TGS-REQ. 2234 2235 2236 2237 2238 2239Yu Expires: Mar 2005 [Page 40] 2240 2241Internet-Draft rfc1510ter-01 15 Sep 2005 2242 2243 KDC-REQ-COMMON ::= SEQUENCE { 2244 -- NOTE: first tag is [1], not [0] 2245 pvno [1] INTEGER (5), 2246 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- 2247 | 12 -- TGS-REQ.rfc1510 -- 2248 | 6 -- AS-REQ.ext -- 2249 | 8 -- TGS-REQ.ext -- ), 2250 padata [3] SEQUENCE OF PA-DATA OPTIONAL 2251 -- NOTE: not empty 2252 } 2253 2254 2255 KDC-REQ-BODY-COMMON ::= SEQUENCE { 2256 kdc-options [0] KDCOptions, 2257 cname [1] PrincipalName OPTIONAL 2258 -- Used only in AS-REQ --, 2259 2260 realm [2] Realm 2261 -- Server's realm; also client's in AS-REQ --, 2262 2263 sname [3] PrincipalName OPTIONAL, 2264 from [4] KerberosTime OPTIONAL, 2265 till [5] KerberosTime OPTIONAL 2266 -- was required in rfc1510; 2267 -- still required for compat versions 2268 -- of messages --, 2269 2270 rtime [6] KerberosTime OPTIONAL, 2271 nonce [7] Nonce, 2272 etype [8] SEQUENCE OF EType 2273 -- in preference order --, 2274 2275 addresses [9] HostAddresses OPTIONAL, 2276 enc-authorization-data [10] EncryptedData { 2277 AuthorizationData, { key-session | key-subsession }, 2278 { ku-TGSReqAuthData-subkey | 2279 ku-TGSReqAuthData-sesskey } 2280 } OPTIONAL, 2281 2282 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2283 -- NOTE: not empty --, 2284 ... 2285 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 2286 LangTag OPTIONAL, 2287 ... 2288 } 2289 2290 2291 Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of 2292 an EncTicketPartCommon. The KDC copies most of them unchanged, 2293 provided that the requested values meet site policy. 2294 2295Yu Expires: Mar 2005 [Page 41] 2296 2297Internet-Draft rfc1510ter-01 15 Sep 2005 2298 2299 kdc-options 2300 These flags do not correspond directly to "flags" in 2301 EncTicketPartCommon. 2302 2303 cname 2304 This field is copied to the "cname" field in 2305 EncTicketPartCommon. The "cname" field is required in an AS- 2306 REQ; the client places its own name here. In a TGS-REQ, the 2307 "cname" in the ticket in the AP-REQ takes precedence. 2308 2309 realm 2310 This field is the server's realm, and also holds the client's 2311 realm in an AS-REQ. 2312 2313 sname 2314 The "sname" field indicates the server's name. It may be absent 2315 in a TGS-REQ which requests user-to-user authentication, in 2316 which case the "sname" of the issued ticket will be taken from 2317 the included additional ticket. 2318 2319 The "from", "till", and "rtime" fields correspond to the "starttime", 2320 "endtime", and "renew-till" fields of EncTicketPartCommon. 2321 2322 addresses 2323 This field corresponds to the "caddr" field of 2324 EncTicketPartCommon. 2325 2326 enc-authorization-data 2327 For TGS-REQ, this field contains authorization data encrypted 2328 using either the TGT session key or the AP-REQ subsession key; 2329 the KDC may copy these into the "authorization-data" field of 2330 EncTicketPartCommon if policy permits. 2331 2332 lang-tags 2333 Only present in the extensible messages. Specifies the set of 2334 languages which the client is willing to accept in error 2335 messages. 2336 2337 KDC options used in a KDC-REQ are: 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351Yu Expires: Mar 2005 [Page 42] 2352 2353Internet-Draft rfc1510ter-01 15 Sep 2005 2354 2355 KDCOptions ::= KerberosFlags { KDCOptionsBits } 2356 2357 KDCOptionsBits ::= BIT STRING { 2358 reserved (0), 2359 forwardable (1), 2360 forwarded (2), 2361 proxiable (3), 2362 proxy (4), 2363 allow-postdate (5), 2364 postdated (6), 2365 unused7 (7), 2366 renewable (8), 2367 unused9 (9), 2368 unused10 (10), 2369 unused11 (11), 2370 unused12 (12), 2371 unused13 (13), 2372 requestanonymous (14), 2373 canonicalize (15), 2374 disable-transited-check (26), 2375 renewable-ok (27), 2376 enc-tkt-in-skey (28), 2377 renew (30), 2378 validate (31) 2379 -- XXX need "need ticket1" flag? 2380 } 2381 2382 Different options apply to different phases of KDC-REQ processing. 2383 2384 The backwards-compatibility form of a KDC-REQ is: 2385 2386 KDC-REQ-1510 ::= SEQUENCE { 2387 COMPONENTS OF KDC-REQ-COMMON, 2388 req-body [4] KDC-REQ-BODY-1510 2389 } (WITH COMPONENTS { ..., msg-type (10 | 12) }) 2390 2391 The extensible form of a KDC-REQ is: 2392 2393 -- APPLICATION tag goes inside Signed{} as well as outside, 2394 -- to prevent possible substitution attacks. 2395 KDC-REQ-EXT ::= SEQUENCE { 2396 COMPONENTS OF KDC-REQ-COMMON, 2397 req-body [4] KDC-REQ-BODY-EXT, 2398 ... 2399 } (WITH COMPONENTS { 2400 ..., 2401 msg-type (6 | 8), 2402 padata (SIZE (1..MAX)) 2403 }) 2404 2405 The backwards-compatibility form of a KDC-REQ-BODY is: 2406 2407Yu Expires: Mar 2005 [Page 43] 2408 2409Internet-Draft rfc1510ter-01 15 Sep 2005 2410 2411 KDC-REQ-BODY-1510 ::= SEQUENCE { 2412 COMPONENTS OF KDC-REQ-BODY-COMMON 2413 } (WITH COMPONENTS { 2414 ..., 2415 cname (PrincipalNameIA5), 2416 realm (RealmIA5), 2417 sname (PrincipalNameIA5), 2418 till PRESENT, 2419 nonce (UInt32) 2420 }) 2421 2422 The extensible form of a KDC-REQ-BODY is: 2423 2424 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON 2425 (WITH COMPONENTS { 2426 ..., 2427 cname (PrincipalNameExt), 2428 realm (RealmExt), 2429 sname (PrincipalNameExt), 2430 addresses (SIZE (1..MAX)), 2431 enc-authorization-data (EncryptedData { 2432 AuthorizationData (SIZE (1..MAX)), 2433 { key-session | key-subsession }, 2434 { ku-TGSReqAuthData-subkey | 2435 ku-TGSReqAuthData-sesskey } 2436 }), 2437 additional-tickets (SIZE (1..MAX)) 2438 }) 2439 2440 The AS-REQ is: 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463Yu Expires: Mar 2005 [Page 44] 2464 2465Internet-Draft rfc1510ter-01 15 Sep 2005 2466 2467 AS-REQ ::= CHOICE { 2468 rfc1510 [APPLICATION 10] KDC-REQ-1510 2469 (WITH COMPONENTS { 2470 ..., 2471 msg-type (10), 2472 -- AS-REQ must include client name 2473 req-body (WITH COMPONENTS { ..., cname PRESENT }) 2474 }), 2475 ext [APPLICATION 6] Signed { 2476 -- APPLICATION tag goes inside Signed{} as well as 2477 -- outside, to prevent possible substitution attacks. 2478 [APPLICATION 6] KDC-REQ-EXT, 2479 -- not sure this is correct key to use; do we even want 2480 -- to sign AS-REQ? 2481 { key-client }, 2482 { ku-ASReq-cksum } 2483 } 2484 (WITH COMPONENTS { 2485 ..., 2486 msg-type (6), 2487 -- AS-REQ must include client name 2488 req-body (WITH COMPONENTS { ..., cname PRESENT }) 2489 }) 2490 } 2491 2492 A client SHOULD NOT send the extensible AS-REQ alternative to a KDC 2493 if the client does not know that the KDC supports the extensibility 2494 framework. A client SHOULD send the extensible AS-REQ alternative in 2495 a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the 2496 AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX 2497 what if their contents conflict? ] 2498 2499 The TGS-REQ is: 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519Yu Expires: Mar 2005 [Page 45] 2520 2521Internet-Draft rfc1510ter-01 15 Sep 2005 2522 2523 TGS-REQ ::= CHOICE { 2524 rfc1510 [APPLICATION 12] KDC-REQ-1510 2525 (WITH COMPONENTS { 2526 ..., 2527 msg-type (12), 2528 -- client name optional in TGS-REQ 2529 req-body (WITH COMPONENTS { ..., cname ABSENT }) 2530 }), 2531 ext [APPLICATION 8] Signed { 2532 -- APPLICATION tag goes inside Signed{} as well as 2533 -- outside, to prevent possible substitution attacks. 2534 [APPLICATION 8] KDC-REQ-EXT, 2535 { key-session }, { ku-TGSReq-cksum } 2536 } 2537 (WITH COMPONENTS { 2538 ..., 2539 msg-type (8), 2540 -- client name optional in TGS-REQ 2541 req-body (WITH COMPONENTS { ..., cname ABSENT }) 2542 }) 2543 } 2544 2545 25468.2. PA-DATA 2547 2548 PA-DATA have multiple uses in the Kerberos protocol. They may pre- 2549 authenticate an AS-REQ; they may also modify several of the 2550 encryption keys used in a KDC-REP. PA-DATA may also provide "hints" 2551 to the client about which long-term key (usually password-derived) to 2552 use. PA-DATA may also include "hints" about which pre-authentication 2553 mechanisms to use, or include data for input into a pre- 2554 authentication mechanism. 2555 2556 [ XXX enumerate standard padata here ] 2557 25588.3. KDC-REQ Processing 2559 2560 Processing of a KDC-REQ proceeds through several steps. An 2561 implementation need not perform these steps exactly as described, as 2562 long as it behaves as if the steps were performed as described. The 2563 KDC performs replay handling upon receiving the request; it then 2564 validates the request, adjusts timestamps, and selects the keys used 2565 in the reply. It copies data from the request into the issued 2566 ticket, adjusting the values to conform with its policies. The KDC 2567 then transmits the reply to the client. 2568 25698.3.1. Handling Replays 2570 2571 Because Kerberos can run over unreliable transports such as UDP, the 2572 KDC MUST be prepared to retransmit responses in case they are lost. 2573 If a KDC receives a request identical to one it has recently 2574 2575Yu Expires: Mar 2005 [Page 46] 2576 2577Internet-Draft rfc1510ter-01 15 Sep 2005 2578 2579 successfully processed, the KDC MUST respond with a KDC-REP message 2580 rather than a replay error. In order to reduce the amount of 2581 ciphertext given to a potential attacker, KDCs MAY send the same 2582 response generated when the request was first handled. KDCs MUST 2583 obey this replay behavior even if the actual transport in use is 2584 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, 2585 and the entire request is not identical to a recently successfully 2586 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is 2587 appropriate for AP-REQ processing. 2588 25898.3.2. Request Validation 2590 25918.3.2.1. AS-REQ Authentication 2592 2593 Site policy determines whether a given client principal is required 2594 to provide some pre-authentication prior to receiving an AS-REP. 2595 Since the default reply key is typically the client's long-term 2596 password-based key, an attacker may easily request known plaintext 2597 (in the form of an AS-REP) upon which to mount a dictionary attack. 2598 Pre-authentication can limit the possibility of such an attack. 2599 2600 If site policy requires pre-authentication for a client principal, 2601 and no pre-authentication is provided, the KDC returns the error 2602 "kdc-err-preauth-required". Accompanying this error are "e-data" 2603 which include hints telling the client which pre-authentication 2604 mechanisms to use, or data for input to pre-authentication mechanisms 2605 (e.g., input to challenge-response systems). If pre-authentication 2606 fails, the KDC returns the error "kdc-err-preauth-failed". 2607 2608 [ may need additional changes based on Sam's preauth draft ] 2609 26108.3.2.2. TGS-REQ Authentication 2611 2612 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- 2613 tgs-req". The KDC MUST validate the checksum in the Authenticator of 2614 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- 2615 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the 2616 request. [ padata not signed by authenticator! ] Any error from the 2617 AP-REQ validation process SHOULD be returned in a KRB-ERROR message. 2618 The service principal in the ticket of the AP-REQ may be a ticket- 2619 granting service principal, or a normal application service 2620 principal. A ticket which is not a ticket-granting ticket MUST NOT 2621 be used to issue a ticket for any service other than the one named in 2622 the ticket. In this case, the "renew", "validate", or "proxy" [?also 2623 forwarded?] option must be set in the request. 2624 26258.3.2.3. Principal Validation 2626 2627 If the client principal in an AS-REQ is unknown, the KDC returns the 2628 error "kdc-err-c-principal-unknown". If the server principal in a 2629 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- 2630 2631Yu Expires: Mar 2005 [Page 47] 2632 2633Internet-Draft rfc1510ter-01 15 Sep 2005 2634 2635 unknown". 2636 26378.3.2.4. Checking For Revoked or Invalid Tickets 2638 2639 [ KCLAR 3.3.3.1 ] 2640 2641 Whenever a request is made to the ticket-granting server, the 2642 presented ticket(s) is(are) checked against a hot-list of tickets 2643 which have been canceled. This hot-list might be implemented by 2644 storing a range of issue timestamps for "suspect tickets"; if a 2645 presented ticket had an authtime in that range, it would be rejected. 2646 In this way, a stolen ticket-granting ticket or renewable ticket 2647 cannot be used to gain additional tickets (renewals or otherwise) 2648 once the theft has been reported to the KDC for the realm in which 2649 the server resides. Any normal ticket obtained before it was 2650 reported stolen will still be valid (because they require no 2651 interaction with the KDC), but only until their normal expiration 2652 time. If TGTs have been issued for cross-realm authentication, use 2653 of the cross-realm TGT will not be affected unless the hot-list is 2654 propagated to the KDCs for the realms for which such cross-realm 2655 tickets were issued. 2656 2657 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT 2658 issue any ticket unless the TGS-REQ requests the "validate" option. 2659 26608.3.3. Timestamp Handling 2661 2662 [ some aspects of timestamp handling, especially regarding postdating 2663 and renewal, are difficult to read in KCLAR... needs closer 2664 examination here ] 2665 2666 Processing of "starttime" (requested in the "from" field) differs 2667 depending on whether the "postdated" option is set in the request. 2668 If the "postdated" option is not set, and the requested "starttime" 2669 is in the future beyond the window of acceptable clock skew, the KDC 2670 returns the error "kdc-err-cannot-postdate". If the "postdated" 2671 option is not set, and the requested "starttime" is absent or does 2672 not indicate a time in the future beyond the acceptable clock skew, 2673 the KDC sets the "starttime" to the KDC's current time. The 2674 "postdated" option MUST NOT be honored if the ticket is being 2675 requested by TGS-REQ and the "may-postdate" is not set in the TGT. 2676 Otherwise, if the "postdated" option is set, and site policy permits, 2677 the KDC sets the "starttime" as requested, and sets the "invalid" 2678 flag in the new ticket. 2679 2680 The "till" field is required in the RFC 1510 version of the KDC-REQ. 2681 If the "till" field is equal to "19700101000000Z" (midnight, January 2682 1, 1970), the KDC SHOULD behave as if the "till" field were absent. 2683 2684 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or 2685 "renew-till" time is later than the "renew-till" time of the ticket 2686 2687Yu Expires: Mar 2005 [Page 48] 2688 2689Internet-Draft rfc1510ter-01 15 Sep 2005 2690 2691 from which it is derived. 2692 26938.3.3.1. AS-REQ Timestamp Processing 2694 2695 In the AS exchange, the "authtime" of a ticket is set to the local 2696 time at the KDC. 2697 2698 The "endtime" of the ticket will be set to the earlier of the 2699 requested "till" time and a time determined by local policy, possibly 2700 determined using factors specific to the realm or principal. For 2701 example, the expiration time MAY be set to the earliest of the 2702 following: 2703 2704 * the expiration time ("till" value) requested 2705 2706 * the ticket's start time plus the maximum allowable lifetime 2707 associated with the client principal from the authentication 2708 server's database 2709 2710 * the ticket's start time plus the maximum allowable lifetime 2711 associated with the server principal 2712 2713 * the ticket's start time plus the maximum lifetime set by the 2714 policy of the local realm 2715 2716 If the requested expiration time minus the start time (as determined 2717 above) is less than a site-determined minimum lifetime, an error 2718 message with code "kdc-err-never-valid" is returned. If the 2719 requested expiration time for the ticket exceeds what was determined 2720 as above, and if the "renewable-ok" option was requested, then the 2721 "renewable" flag is set in the new ticket, and the "renew-till" value 2722 is set as if the "renewable" option were requested. 2723 2724 If the "renewable" option has been requested or if the "renewable-ok" 2725 option has been set and a renewable ticket is to be issued, then the 2726 "renew-till" field MAY be set to the earliest of: 2727 2728 * its requested value 2729 2730 * the start time of the ticket plus the minimum of the two maximum 2731 renewable lifetimes associated with the principals' database 2732 entries 2733 2734 * the start time of the ticket plus the maximum renewable lifetime 2735 set by the policy of the local realm 2736 27378.3.3.2. TGS-REQ Timestamp Processing 2738 2739 In the TGS exchange, the KDC sets the "authtime" to that of the 2740 ticket in the AP-REQ authenticating the TGS-REQ. [?application 2741 server can print a ticket for itself with a spoofed authtime. 2742 2743Yu Expires: Mar 2005 [Page 49] 2744 2745Internet-Draft rfc1510ter-01 15 Sep 2005 2746 2747 security issues for hot-list?] [ MIT implementation may change 2748 authtime of renewed tickets; needs check... ] 2749 2750 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ 2751 requests an "endtime" (in the "till" field), then the "endtime" of 2752 the new ticket is set to the minimum of 2753 2754 * the requested "endtime" value, 2755 2756 * the "endtime" in the TGT, and 2757 2758 * an "endtime" determined by site policy on ticket lifetimes. 2759 2760 If the new ticket is a renewal, the "endtime" of the new ticket is 2761 bounded by the minimum of 2762 2763 * the requested "endtime" value, 2764 2765 * the value of the "renew-till" value of the old, 2766 2767 * the "starttime" of the new ticket plus the lifetime (endtime 2768 minus starttime) of the old ticket, i.e., the lifetime of the 2769 new ticket may not exceed that of the ticket being renewed [ 2770 adapted from KCLAR 3.3.3. ], and 2771 2772 * an "endtime" determined by site policy on ticket lifetimes. 2773 2774 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with 2775 a "starttime", "endtime", or "renew-till" time later than the 2776 "renew-till" time of the TGT. 2777 27788.3.4. Handling Transited Realms 2779 2780 The KDC checks the ticket in a TGS-REQ against site policy, unless 2781 the "disable-transited-check" option is set in the TGS-REQ. If site 2782 policy permits the transit path in the TGS-REQ ticket, the KDC sets 2783 the "transited-policy-checked" flag in the issued ticket. If the 2784 "disable-transited-check" option is set, the issued ticket will have 2785 the "transited-policy-checked" flag cleared. 2786 27878.3.5. Address Processing The requested "addresses" in the KDC-REQ are 2788 copied into the issued ticket. If the "addresses" field is absent or 2789 empty in a TGS-REQ, the KDC copies addresses from the ticket in the 2790 TGS-REQ into the issued ticket, unless the either "forwarded" or 2791 "proxy" option is set. If the "forwarded" option is set, and the 2792 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies 2793 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the 2794 issued ticket. The KDC behaves similarly if the "proxy" option is 2795 set in the TGS-REQ and the "proxiable" flag is set in the ticket. 2796 The "proxy" option will not be honored on requests for additional 2797 ticket-granting tickets. 2798 2799Yu Expires: Mar 2005 [Page 50] 2800 2801Internet-Draft rfc1510ter-01 15 Sep 2005 2802 28038.3.6. Ticket Flag Processing 2804 2805 Many kdc-options request that the KDC set a corresponding flag in the 2806 issued ticket. kdc-options marked with an asterisk (*) in the 2807 following table do not directly request the corresponding ticket flag 2808 and therefore require special handling. 2809 2810 2811 kdc-option | ticket flag affected 2812 ________________________|__________________________ 2813 forwardable | forwardable 2814 forwarded | forwarded 2815 proxiable | proxiable 2816 proxy | proxy 2817 allow-postdate | may-postdate 2818 postdated | postdated 2819 renewable | renewable 2820 requestanonymous | anonymous 2821 canonicalize | - 2822 disable-transited-check*| transited-policy-checked 2823 renewable-ok* | renewable 2824 enc-tkt-in-skey | - 2825 renew | - 2826 validate* | invalid 2827 2828 2829 2830 forwarded 2831 The KDC sets the "forwarded" flag in the issued ticket if the 2832 "forwarded" option is set in the TGS-REQ and the "forwardable" 2833 flag is set in the TGS-REQ ticket. 2834 2835 proxy 2836 The KDC sets the "proxy" flag in the issued ticket if the 2837 "proxy" option is set in the TGS-REQ and the "proxiable" flag is 2838 set in the TGS-REQ ticket. 2839 2840 disable-transited-check 2841 The handling of the "disable-transited-check" kdc-option is 2842 described in Section 8.3.4. 2843 2844 renewable-ok 2845 The handling of the "renewable-ok" kdc-option is described in 2846 Section 8.3.3.1. 2847 2848 enc-tkt-in-skey 2849 This flag modifies ticket key selection to use the session key 2850 of an additional ticket included in the TGS-REQ, for the purpose 2851 of user-to-user authentication. 2852 2853 2854 2855Yu Expires: Mar 2005 [Page 51] 2856 2857Internet-Draft rfc1510ter-01 15 Sep 2005 2858 2859 validate 2860 If the "validate" kdc-option is set in a TGS-REQ, and the 2861 "starttime" has passed, the KDC will clear the "invalid" bit on 2862 the ticket before re-issuing it. 2863 28648.3.7. Key Selection 2865 2866 Three keys are involved in creating a KDC-REP. The reply key 2867 encrypts the encrypted part of the KDC-REP. The session key is 2868 stored in the encrypted part of the ticket, and is also present in 2869 the encrypted part of the KDC-REP so that the client can retrieve it. 2870 The ticket key is used to encrypt the ticket. These keys all have 2871 initial values for a given exchange; pre-authentication and other 2872 extension mechanisms may change the value used for any of these keys. 2873 2874 [ again, may need changes based on Sam's preauth draft ] 2875 28768.3.7.1. Reply Key and Session Key Selection 2877 2878 The set of encryption types which the client will understand appears 2879 in the "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set 2880 of possible reply keys and the set of session key encryption types 2881 based on the "etype" field. 2882 2883 For the AS exchange, the reply key is initially a long-term key of 2884 the client, limited to those encryption types listed in the "etype" 2885 field. The KDC SHOULD use the first valid strong "etype" for which 2886 an encryption key is available. For the TGS exchange, the reply key 2887 is initially the subsession key of the Authenticator. If the 2888 Authenticator subsesion key is absent, the reply key is initially the 2889 session key of the ticket used to authenticate the TGS-REQ. 2890 2891 The session key is initially randomly generated, and has an 2892 encryption type which both the client and the server will understand. 2893 Typically, the KDC has prior knowledge of which encryption types the 2894 server will understand. It selects the first valid strong "etype" 2895 listed the request which the server also will understand. 2896 28978.3.7.2. Ticket Key Selection 2898 2899 The ticket key is initially the long-term key of the service. The 2900 "enc-tkt-in-skey" option requests user-to-user authentication, where 2901 the ticket encryption key of the issued ticket is set equal to the 2902 session key of the additional ticket in the request. 2903 29048.4. KDC-REP 2905 2906 The important parts of the KDC-REP are encrypted. 2907 2908 2909 2910 2911Yu Expires: Mar 2005 [Page 52] 2912 2913Internet-Draft rfc1510ter-01 15 Sep 2005 2914 2915 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 2916 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 2917 2918 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 2919 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 2920 2921 EncKDCRepPartCom ::= SEQUENCE { 2922 key [0] EncryptionKey, 2923 last-req [1] LastReq, 2924 nonce [2] Nonce, 2925 key-expiration [3] KerberosTime OPTIONAL, 2926 flags [4] TicketFlags, 2927 authtime [5] KerberosTime, 2928 starttime [6] KerberosTime OPTIONAL, 2929 endtime [7] KerberosTime, 2930 renew-till [8] KerberosTime OPTIONAL, 2931 srealm [9] Realm, 2932 sname [10] PrincipalName, 2933 caddr [11] HostAddresses OPTIONAL, 2934 ... 2935 } 2936 2937 EncKDCRepPart1510 ::= SEQUENCE { 2938 COMPONENTS OF EncKDCRepPartCom 2939 } (WITH COMPONENTS { 2940 ..., 2941 srealm (RealmIA5), 2942 sname (PrincipalNameIA5), 2943 nonce UInt32 }) 2944 2945 EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS { 2946 ..., 2947 srealm (RealmExt), 2948 sname (PrincipalNameExt) 2949 }) 2950 2951 2952 Most of the fields of EncKDCRepPartCom are duplicates of the 2953 corresponding fields in the returned ticket. 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967Yu Expires: Mar 2005 [Page 53] 2968 2969Internet-Draft rfc1510ter-01 15 Sep 2005 2970 2971 KDC-REP-COMMON { EncPart } ::= SEQUENCE { 2972 pvno [0] INTEGER (5), 2973 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 2974 13 -- TGS.rfc1510 -- | 2975 7 -- AS-REP.ext -- | 2976 9 -- TGS-REP.ext -- ), 2977 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 2978 crealm [3] Realm, 2979 cname [4] PrincipalName, 2980 ticket [5] Ticket, 2981 2982 enc-part [6] EncryptedData { 2983 EncPart, 2984 { key-reply }, 2985 -- maybe reach into EncryptedData in AS-REP/TGS-REP 2986 -- definitions to apply constraints on key usages? 2987 { ku-EncASRepPart -- if AS-REP -- | 2988 ku-EncTGSRepPart-subkey -- if TGS-REP and 2989 -- using Authenticator 2990 -- session key -- | 2991 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 2992 -- subsession key -- } 2993 }, 2994 2995 ..., 2996 -- In extensible version, KDC signs original request 2997 -- to avoid replay attacks against client. 2998 req-cksum [7] ChecksumOf { CHOICE { 2999 as-req AS-REQ, 3000 tgs-req TGS-REQ 3001 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 3002 lang-tag [8] LangTag OPTIONAL, 3003 ... 3004 } 3005 3006 3007 KDC-REP-1510 { EncPart } ::= SEQUENCE { 3008 COMPONENTS OF KDC-REP-COMMON { EncPart } 3009 } (WITH COMPONENTS { 3010 ..., 3011 msg-type (11 | 13), 3012 crealm (RealmIA5), 3013 cname (PrincipalNameIA5) 3014 }) 3015 3016 3017 3018 3019 3020 3021 3022 3023Yu Expires: Mar 2005 [Page 54] 3024 3025Internet-Draft rfc1510ter-01 15 Sep 2005 3026 3027 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart } 3028 (WITH COMPONENTS { 3029 ..., 3030 msg-type (7 | 9), 3031 crealm (RealmExt), 3032 cname (PrincipalNameExt) 3033 }) 3034 3035 3036 req-cksum 3037 Signature of the original request using the reply key, to avoid 3038 replay attacks against the client, among other things. Only 3039 present in the extensible version of KDC-REP. 3040 3041 AS-REP ::= CHOICE { 3042 rfc1510 [APPLICATION 11] KDC-REP-1510 { 3043 EncASRepPart1510 3044 } (WITH COMPONENTS { ..., msg-type (11) }), 3045 ext [APPLICATION 7] Signed { 3046 [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, 3047 { key-reply }, { ku-ASRep-cksum } 3048 } (WITH COMPONENTS { ..., msg-type (7) }) 3049 } 3050 3051 3052 TGS-REP ::= CHOICE { 3053 rfc1510 [APPLICATION 13] KDC-REP-1510 { 3054 EncTGSRepPart1510 3055 } (WITH COMPONENTS { ..., msg-type (13) }), 3056 ext [APPLICATION 9] Signed { 3057 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 3058 { key-reply }, { ku-TGSRep-cksum } 3059 } (WITH COMPONENTS { ..., msg-type (9) }) 3060 } 3061 3062 3063 The extensible versions of AS-REQ and TGS-REQ are signed with the 3064 reply key, to prevent an attacker from performing a delayed denial- 3065 of-service attack by substituting the ticket. 3066 30678.5. Reply Validation 3068 3069 [ signature verification ] 3070 30718.6. IP Transports 3072 3073 [ KCLAR 7.2 ] 3074 3075 Kerberos defines two IP transport mechanisms for the credentials 3076 acquisition protocol: UDP/IP and TCP/IP. 3077 3078 3079Yu Expires: Mar 2005 [Page 55] 3080 3081Internet-Draft rfc1510ter-01 15 Sep 2005 3082 30838.6.1. UDP/IP transport 3084 3085 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 3086 requests and SHOULD listen for such requests on port 88 (decimal) 3087 unless specifically configured to listen on an alternative UDP port. 3088 Alternate ports MAY be used when running multiple KDCs for multiple 3089 realms on the same host. 3090 3091 Kerberos clients supporting IP transports SHOULD support the sending 3092 of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to 3093 identify the IP address and port to which they will send their 3094 request. 3095 3096 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 3097 transport, the client shall send a UDP datagram containing only an 3098 encoding of the request to the KDC. The KDC will respond with a reply 3099 datagram containing only an encoding of the reply message (either a 3100 KRB-ERROR or a KDC-REP) to the sending port at the sender's IP 3101 address. The response to a request made through UDP/IP transport MUST 3102 also use UDP/IP transport. If the response can not be handled using 3103 UDP (for example because it is too large), the KDC MUST return "krb- 3104 err-response-too-big", forcing the client to retry the request using 3105 the TCP transport. 3106 31078.6.2. TCP/IP transport 3108 3109 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 3110 requests and SHOULD listen for such requests on port 88 (decimal) 3111 unless specifically configured to listen on an alternate TCP port. 3112 Alternate ports MAY be used when running multiple KDCs for multiple 3113 realms on the same host. 3114 3115 Clients MUST support the sending of TCP requests, but MAY choose to 3116 initially try a request using the UDP transport. Clients SHOULD use 3117 KDC discovery (Section 8.6.3) to identify the IP address and port to 3118 which they will send their request. 3119 3120 Implementation note: Some extensions to the Kerberos protocol will 3121 not succeed if any client or KDC not supporting the TCP transport is 3122 involved. Implementations of RFC 1510 were not required to support 3123 TCP/IP transports. 3124 3125 When the KDC-REQ message is sent to the KDC over a TCP stream, the 3126 response (KDC-REP or KRB-ERROR message) MUST be returned to the 3127 client on the same TCP stream that was established for the request. 3128 The KDC MAY close the TCP stream after sending a response, but MAY 3129 leave the stream open for a reasonable period of time if it expects a 3130 followup. Care must be taken in managing TCP/IP connections on the 3131 KDC to prevent denial of service attacks based on the number of open 3132 TCP/IP connections. 3133 3134 3135Yu Expires: Mar 2005 [Page 56] 3136 3137Internet-Draft rfc1510ter-01 15 Sep 2005 3138 3139 The client MUST be prepared to have the stream closed by the KDC at 3140 anytime after the receipt of a response. A stream closure SHOULD NOT 3141 be treated as a fatal error. Instead, if multiple exchanges are 3142 required (e.g., certain forms of pre-authentication) the client may 3143 need to establish a new connection when it is ready to send 3144 subsequent messages. A client MAY close the stream after receiving a 3145 response, and SHOULD close the stream if it does not expect to send 3146 followup messages. 3147 3148 A client MAY send multiple requests before receiving responses, 3149 though it must be prepared to handle the connection being closed 3150 after the first response. 3151 3152 Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over 3153 the TCP stream is preceded by the length of the request as 4 octets 3154 in network byte order. The high bit of the length is reserved for 3155 future expansion and MUST currently be set to zero. If a KDC that 3156 does not understand how to interpret a set high bit of the length 3157 encoding receives a request with the high order bit of the length 3158 set, it MUST return a KRB-ERROR message with the error "krb-err- 3159 field-toolong" and MUST close the TCP stream. 3160 3161 If multiple requests are sent over a single TCP connection, and the 3162 KDC sends multiple responses, the KDC is not required to send the 3163 responses in the order of the corresponding requests. This may 3164 permit some implementations to send each response as soon as it is 3165 ready even if earlier requests are still being processed (for 3166 example, waiting for a response from an external device or database). 3167 31688.6.3. KDC Discovery on IP Networks 3169 3170 Kerberos client implementations MUST provide a means for the client 3171 to determine the location of the Kerberos Key Distribution Centers 3172 (KDCs). Traditionally, Kerberos implementations have stored such 3173 configuration information in a file on each client machine. 3174 Experience has shown this method of storing configuration information 3175 presents problems with out-of-date information and scaling problems, 3176 especially when using cross-realm authentication. This section 3177 describes a method for using the Domain Name System [RFC 1035] for 3178 storing KDC location information. 3179 31808.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 3181 3182 In Kerberos, realm names are case sensitive. While it is strongly 3183 encouraged that all realm names be all upper case this recommendation 3184 has not been adopted by all sites. Some sites use all lower case 3185 names and other use mixed case. DNS, on the other hand, is case 3186 insensitive for queries. Since the realm names "MYREALM", "myrealm", 3187 and "MyRealm" are all different, but resolve the same in the domain 3188 name system, it is necessary that only one of the possible 3189 combinations of upper and lower case characters be used in realm 3190 3191Yu Expires: Mar 2005 [Page 57] 3192 3193Internet-Draft rfc1510ter-01 15 Sep 2005 3194 3195 names. 3196 31978.6.3.2. DNS SRV records for KDC location 3198 3199 KDC location information is to be stored using the DNS SRV RR [RFC 3200 2782]. The format of this RR is as follows: 3201 3202 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target 3203 3204 The Service name for Kerberos is always "kerberos". 3205 3206 The Proto can be one of "udp", "tcp". If these SRV records are to be 3207 used, both "udp" and "tcp" records MUST be specified for all KDC 3208 deployments. 3209 3210 The Realm is the Kerberos realm that this record corresponds to. The 3211 realm MUST be a domain style realm name. 3212 3213 TTL, Class, SRV, Priority, Weight, and Target have the standard 3214 meaning as defined in RFC 2782. 3215 3216 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV 3217 records SHOULD be the value assigned to "kerberos" by the Internet 3218 Assigned Number Authority: 88 (decimal) unless the KDC is configured 3219 to listen on an alternate TCP port. 3220 3221 Implementation note: Many existing client implementations do not 3222 support KDC Discovery and are configured to send requests to the IANA 3223 assigned port (88 decimal), so it is strongly recommended that KDCs 3224 be configured to listen on that port. 3225 32268.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 3227 3228 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 3229 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 3230 should be directed to kdc1.example.com first as per the specified 3231 priority. Weights are not used in these sample records. 3232 3233 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 3234 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 3235 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 3236 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 3237 3238 32399. Errors 3240 3241 The KRB-ERROR message is returned by the KDC if an error occurs 3242 during credentials acquisition. It may also be returned by an 3243 application server if an error occurs during authentication. 3244 3245 3246 3247Yu Expires: Mar 2005 [Page 58] 3248 3249Internet-Draft rfc1510ter-01 15 Sep 2005 3250 3251 ErrCode ::= Int32 3252 3253 KRB-ERROR ::= CHOICE { 3254 rfc1510 [APPLICATION 30] KRB-ERROR-1510, 3255 ext [APPLICATION 23] Signed { 3256 KRB-ERROR-EXT, { ku-KrbError-cksum } } 3257 } 3258 3259 3260 The extensible KRB-ERROR is only signed if there has been a key 3261 negotiated with its recipient. KRB-ERROR messages sent in response 3262 to AS-REQ messages will probably not be signed unless a 3263 preauthentication mechanism has negotiated a key. (Signing using a 3264 client's long-term key can expose ciphertext to dictionary attacks.) 3265 3266 The parts of a KRB-ERROR common to both the backwards-compatibility 3267 and the extensibile messages are 3268 3269 KRB-ERROR-COMMON ::= SEQUENCE { 3270 pvno [0] INTEGER (5), 3271 msg-type [1] INTEGER (30 | 23), 3272 ctime [2] KerberosTime OPTIONAL, 3273 cusec [3] Microseconds OPTIONAL, 3274 stime [4] KerberosTime, 3275 susec [5] Microseconds, 3276 error-code [6] ErrCode, 3277 crealm [7] Realm OPTIONAL, 3278 cname [8] PrincipalName OPTIONAL, 3279 realm [9] Realm -- Correct realm --, 3280 sname [10] PrincipalName -- Correct name --, 3281 e-text [11] KerberosString OPTIONAL, 3282 e-data [12] OCTET STRING OPTIONAL, 3283 ..., 3284 typed-data [13] TYPED-DATA OPTIONAL, 3285 nonce [14] Nonce OPTIONAL, 3286 lang-tag [15] LangTag OPTIONAL, 3287 ... 3288 } 3289 3290 3291 KRB-ERROR-1510 ::= SEQUENCE { 3292 COMPONENTS OF KRB-ERROR-COMMON 3293 } (WITH COMPONENTS { 3294 ..., 3295 msg-type (30) 3296 }) 3297 3298 3299 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON 3300 (WITH COMPONENTS { ..., msg-type (23) }) 3301 3302 3303Yu Expires: Mar 2005 [Page 59] 3304 3305Internet-Draft rfc1510ter-01 15 Sep 2005 3306 3307 ctime, cusec 3308 Client's time, if known from a KDC-REQ or AP-REQ. 3309 3310 stime, susec 3311 KDC or application server's current time. 3312 3313 error-code 3314 Numeric error code designating the error. 3315 3316 crealm, cname 3317 Client's realm and name, if known. 3318 3319 realm, sname 3320 server's realm and name. [ XXX what if these aren't known? ] 3321 3322 e-text 3323 Human-readable text providing additional details for the error. 3324 3325 e-data 3326 This field contains additional data about the error for use by 3327 the client to help it recover from or handle the error. If the 3328 "error-code" is "kdc-err-preauth-required", then the e-data 3329 field will contain an encoding of a sequence of padata fields, 3330 each corresponding to an acceptable pre-authentication method 3331 and optionally containing data for the method: 3332 3333 METHOD-DATA ::= SEQUENCE OF PA-DATA 3334 3335 3336 For error codes defined in this document other than "kdc-err- 3337 preauth-required", the format and contents of the e-data field 3338 are implementation-defined. Similarly, for future error codes, 3339 the format and contents of the e-data field are implementation- 3340 defined unless specified. 3341 3342 lang-tag 3343 Indicates the language of the message in the "e-text" field. It 3344 is only present in the extensible KRB-ERROR. 3345 3346 nonce 3347 is the nonce from a KDC-REQ. It is only present in the 3348 extensible KRB-ERROR. 3349 3350 typed-data 3351 TYPED-DATA is a typed hole allowing for additional data to be 3352 returned in error conditions, since "e-data" is insufficiently 3353 flexible for some purposes. TYPED-DATA is only present in the 3354 extensible KRB-ERROR. 3355 3356 3357 3358 3359Yu Expires: Mar 2005 [Page 60] 3360 3361Internet-Draft rfc1510ter-01 15 Sep 2005 3362 3363 TDType ::= TH-id 3364 3365 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3366 data-type [0] TDType, 3367 data-value [1] OCTET STRING OPTIONAL 3368 } 3369 3370 337110. Session Key Exchange 3372 3373 Session key exchange consists of the AP-REQ and AP-REP messages. The 3374 client sends the AP-REQ message, and the service responds with an 3375 AP-REP message if mutual authentication is desired. Following 3376 session key exchange, the client and service share a secret session 3377 key, or possibly a subsesion key, which can be used to protect 3378 further communications. Additionally, the session key exchange 3379 process can establish initial sequence numbers which the client and 3380 service can use to detect replayed messages. 3381 338210.1. AP-REQ 3383 3384 An AP-REQ message contains a ticket and a authenticator. The 3385 authenticator is ciphertext encrypted with the session key contained 3386 in the ticket. The plaintext contents of the authenticator are: 3387 3388 -- plaintext of authenticator 3389 Authenticator ::= [APPLICATION 2] SEQUENCE { 3390 authenticator-vno [0] INTEGER (5), 3391 crealm [1] Realm, 3392 cname [2] PrincipalName, 3393 cksum [3] Checksum {{ key-session }, 3394 { ku-Authenticator-cksum | 3395 ku-pa-TGSReq-cksum }} OPTIONAL, 3396 cusec [4] Microseconds, 3397 ctime [5] KerberosTime, 3398 subkey [6] EncryptionKey OPTIONAL, 3399 seq-number [7] SeqNum OPTIONAL, 3400 authorization-data [8] AuthorizationData OPTIONAL 3401 } 3402 3403 The common parts between the RFC 1510 and the extensible versions of 3404 the AP-REQ are: 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415Yu Expires: Mar 2005 [Page 61] 3416 3417Internet-Draft rfc1510ter-01 15 Sep 2005 3418 3419 AP-REQ-COMMON ::= SEQUENCE { 3420 pvno [0] INTEGER (5), 3421 msg-type [1] INTEGER (14 | 18), 3422 ap-options [2] APOptions, 3423 ticket [3] Ticket, 3424 authenticator [4] EncryptedData { 3425 Authenticator, 3426 { key-session }, 3427 { ku-APReq-authenticator | 3428 ku-pa-TGSReq-authenticator } 3429 }, 3430 ..., 3431 extensions [5] ApReqExtensions OPTIONAL, 3432 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 3433 OF LangTag OPTIONAL, 3434 ... 3435 } 3436 3437 The complete definition of AP-REQ is: 3438 3439 AP-REQ ::= CHOICE { 3440 rfc1510 [APPLICATION 14] AP-REQ-1510, 3441 ext [APPLICATION 18] Signed { 3442 AP-REQ-EXT, { key-session }, { ku-APReq-cksum } 3443 } 3444 } 3445 3446 3447 AP-REQ-COMMON ::= SEQUENCE { 3448 pvno [0] INTEGER (5), 3449 msg-type [1] INTEGER (14 | 18), 3450 ap-options [2] APOptions, 3451 ticket [3] Ticket, 3452 authenticator [4] EncryptedData { 3453 Authenticator, 3454 { key-session }, 3455 { ku-APReq-authenticator | 3456 ku-pa-TGSReq-authenticator } 3457 }, 3458 ..., 3459 extensions [5] ApReqExtensions OPTIONAL, 3460 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 3461 OF LangTag OPTIONAL, 3462 ... 3463 } 3464 3465 3466 3467 3468 3469 3470 3471Yu Expires: Mar 2005 [Page 62] 3472 3473Internet-Draft rfc1510ter-01 15 Sep 2005 3474 3475 AP-REQ-1510 ::= SEQUENCE { 3476 COMPONENTS OF AP-REQ-COMMON 3477 } (WITH COMPONENTS { 3478 ..., 3479 msg-type (14), 3480 authenticator (EncryptedData { 3481 Authenticator (WITH COMPONENTS { 3482 ..., 3483 crealm (RealmIA5), 3484 cname (PrincipalNameIA5), 3485 seqnum (UInt32) 3486 }), { key-session }, { ku-APReq-authenticator }}) 3487 }) 3488 3489 3490 AP-REQ-EXT ::= AP-REQ-COMMON 3491 (WITH COMPONENTS { 3492 ..., 3493 msg-type (18), 3494 -- The following constraints on Authenticator assume that 3495 -- we want to restrict the use of AP-REQ-EXT with TicketExt 3496 -- only, since that is the only way we can enforce UTF-8. 3497 authenticator (EncryptedData { 3498 Authenticator (WITH COMPONENTS { 3499 ..., 3500 crealm (RealmExt), 3501 cname (PrincipalNameExt), 3502 authorization-data (SIZE (1..MAX)) 3503 }), { key-session }, { ku-APReq-authenticator }}) 3504 }) 3505 3506 3507 APOptions ::= KerberosFlags { APOptionsBits } 3508 3509 APOptionsBits ::= BIT STRING { 3510 reserved (0), 3511 use-session-key (1), 3512 mutual-required (2) 3513 } 3514 3515 351610.2. AP-REP 3517 3518 An AP-REP message provides mutual authentication of the service to 3519 the client. 3520 3521 EncAPRepPart ::= CHOICE { 3522 rfc1510 [APPLICATION 27] EncAPRepPart1510, 3523 ext [APPLICATION 31] EncAPRepPartExt 3524 } 3525 3526 3527Yu Expires: Mar 2005 [Page 63] 3528 3529Internet-Draft rfc1510ter-01 15 Sep 2005 3530 3531 EncAPRepPartCom ::= SEQUENCE { 3532 ctime [0] KerberosTime, 3533 cusec [1] Microseconds, 3534 subkey [2] EncryptionKey OPTIONAL, 3535 seq-number [3] SeqNum OPTIONAL, 3536 ..., 3537 authorization-data [4] AuthorizationData OPTIONAL, 3538 ... 3539 } 3540 3541 3542 EncAPRepPart1510 ::= SEQUENCE { 3543 COMPONENTS OF ENCAPRepPartCom 3544 } (WITH COMPONENTS { 3545 ..., 3546 seq-number (UInt32), 3547 authorization-data ABSENT 3548 }) 3549 3550 3551 EncAPRepPartExt ::= EncAPRepPartCom 3552 3553 3554 AP-REP ::= CHOICE { 3555 rfc1510 [APPLICATION 15] AP-REP-1510, 3556 ext [APPLICATION 19] Signed { 3557 AP-REP-EXT, 3558 { key-session | key-subsession }, { ku-APRep-cksum }} 3559 } 3560 3561 3562 AP-REP-COMMON { EncPart } ::= SEQUENCE { 3563 pvno [0] INTEGER (5), 3564 msg-type [1] INTEGER (15 | 19), 3565 enc-part [2] EncryptedData { 3566 EncPart, 3567 { key-session | key-subsession }, { ku-EncAPRepPart }}, 3568 ..., 3569 extensions [3] ApRepExtensions OPTIONAL, 3570 ... 3571 } 3572 3573 3574 AP-REP-1510 ::= SEQUENCE { 3575 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 } 3576 } (WITH COMPONENTS { 3577 ..., 3578 msg-type (15) 3579 }) 3580 3581 3582 3583Yu Expires: Mar 2005 [Page 64] 3584 3585Internet-Draft rfc1510ter-01 15 Sep 2005 3586 3587 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON { 3588 EncAPRepPartExt 3589 } (WITH COMPONENTS { ..., msg-type (19) }) 3590 3591 359211. Session Key Use 3593 3594 Once a session key has been established, the client and server can 3595 use several kinds of messages to securely transmit data. KRB-SAFE 3596 provides integrity protection for application data, while KRB-PRIV 3597 provides confidentiality along with integrity protection. The KRB- 3598 CRED message provides a means of securely forwarding credentials from 3599 the client host to the server host. 3600 360111.1. KRB-SAFE 3602 3603 The KRB-SAFE message provides integrity protection for an included 3604 cleartext message. 3605 3606 -- Do we chew up another tag for KRB-SAFE-EXT? That would 3607 -- allow us to make safe-body optional, allowing for a GSS-MIC 3608 -- sort of message. 3609 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3610 pvno [0] INTEGER (5), 3611 msg-type [1] INTEGER (20), 3612 safe-body [2] KRB-SAFE-BODY, 3613 cksum [3] ChecksumOf { 3614 KRB-SAFE-BODY, 3615 { key-session | key-subsession }, { ku-KrbSafe-cksum }}, 3616 ... -- ASN.1 extensions must be excluded 3617 -- when sending to rfc1510 implementations 3618 } 3619 3620 3621 KRB-SAFE-BODY ::= SEQUENCE { 3622 user-data [0] OCTET STRING, 3623 timestamp [1] KerberosTime OPTIONAL, 3624 usec [2] Microseconds OPTIONAL, 3625 seq-number [3] SeqNum OPTIONAL, 3626 s-address [4] HostAddress, 3627 r-address [5] HostAddress OPTIONAL, 3628 ... -- ASN.1 extensions must be excluded 3629 -- when sending to rfc1510 implementations 3630 } 3631 3632 363311.2. KRB-PRIV 3634 3635 The KRB-PRIV message provides confidentiality and integrity 3636 protection. 3637 3638 3639Yu Expires: Mar 2005 [Page 65] 3640 3641Internet-Draft rfc1510ter-01 15 Sep 2005 3642 3643 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3644 pvno [0] INTEGER (5), 3645 msg-type [1] INTEGER (21), 3646 enc-part [3] EncryptedData { 3647 EncKrbPrivPart, 3648 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 3649 ... 3650 } 3651 3652 3653 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 3654 user-data [0] OCTET STRING, 3655 timestamp [1] KerberosTime OPTIONAL, 3656 usec [2] Microseconds OPTIONAL, 3657 seq-number [3] SeqNum OPTIONAL, 3658 s-address [4] HostAddress -- sender's addr --, 3659 r-address [5] HostAddress OPTIONAL -- recip's addr --, 3660 ... -- ASN.1 extensions must be excluded 3661 -- when sending to rfc1510 implementations 3662 } 3663 3664 366511.3. KRB-CRED 3666 3667 The KRB-CRED message provides a means of securely transferring 3668 credentials from the client to the service. 3669 3670 KRB-CRED ::= CHOICE { 3671 rfc1510 [APPLICATION 22] KRB-CRED-1510, 3672 ext [APPLICATION 24] Signed { 3673 KRB-CRED-EXT, 3674 { key-session | key-subsession }, { ku-KrbCred-cksum }} 3675 } 3676 3677 3678 KRB-CRED-COMMON ::= SEQUENCE { 3679 pvno [0] INTEGER (5), 3680 msg-type [1] INTEGER (22 | 24), 3681 tickets [2] SEQUENCE OF Ticket, 3682 enc-part [3] EncryptedData { 3683 EncKrbCredPart, 3684 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 3685 ... 3686 } 3687 3688 3689 KRB-CRED-1510 ::= SEQUENCE { 3690 COMPONENTS OF KRB-CRED-COMMON 3691 } (WITH COMPONENTS { ..., msg-type (22) }) 3692 3693 3694 3695Yu Expires: Mar 2005 [Page 66] 3696 3697Internet-Draft rfc1510ter-01 15 Sep 2005 3698 3699 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON 3700 (WITH COMPONENTS { ..., msg-type (24) }) 3701 3702 3703 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3704 ticket-info [0] SEQUENCE OF KrbCredInfo, 3705 nonce [1] Nonce OPTIONAL, 3706 timestamp [2] KerberosTime OPTIONAL, 3707 usec [3] Microseconds OPTIONAL, 3708 s-address [4] HostAddress OPTIONAL, 3709 r-address [5] HostAddress OPTIONAL 3710 } 3711 3712 3713 KrbCredInfo ::= SEQUENCE { 3714 key [0] EncryptionKey, 3715 prealm [1] Realm OPTIONAL, 3716 pname [2] PrincipalName OPTIONAL, 3717 flags [3] TicketFlags OPTIONAL, 3718 authtime [4] KerberosTime OPTIONAL, 3719 starttime [5] KerberosTime OPTIONAL, 3720 endtime [6] KerberosTime OPTIONAL, 3721 renew-till [7] KerberosTime OPTIONAL, 3722 srealm [8] Realm OPTIONAL, 3723 sname [9] PrincipalName OPTIONAL, 3724 caddr [10] HostAddresses OPTIONAL 3725 } 3726 3727 372812. Security Considerations 3729 373012.1. Time Synchronization 3731 3732 Time synchronization between the KDC and application servers is 3733 necessary to prevent acceptance of expired tickets. 3734 3735 Time synchronization is needed between application servers and 3736 clients to prevent replay attacks if a replay cache is being used. 3737 If negotiated subsession keys are used to encrypt application data, 3738 replay caches may not be necessary. 3739 374012.2. Replays 3741 374212.3. Principal Name Reuse 3743 3744 See Section 5.3. 3745 374612.4. Password Guessing 3747 3748 3749 3750 3751Yu Expires: Mar 2005 [Page 67] 3752 3753Internet-Draft rfc1510ter-01 15 Sep 2005 3754 375512.5. Forward Secrecy 3756 3757 [from KCLAR 10.; needs some rewriting] 3758 3759 The Kerberos protocol in its basic form does not provide perfect 3760 forward secrecy for communications. If traffic has been recorded by 3761 an eavesdropper, then messages encrypted using the KRB-PRIV message, 3762 or messages encrypted using application-specific encryption under 3763 keys exchanged using Kerberos can be decrypted if any of the user's, 3764 application server's, or KDC's key is subsequently discovered. This 3765 is because the session key used to encrypt such messages is 3766 transmitted over the network encrypted in the key of the application 3767 server, and also encrypted under the session key from the user's 3768 ticket-granting ticket when returned to the user in the TGS-REP 3769 message. The session key from the ticket-granting ticket was sent to 3770 the user in the AS-REP message encrypted in the user's secret key, 3771 and embedded in the ticket-granting ticket, which was encrypted in 3772 the key of the KDC. Application requiring perfect forward secrecy 3773 must exchange keys through mechanisms that provide such assurance, 3774 but may use Kerberos for authentication of the encrypted channel 3775 established through such other means. 3776 377712.6. Authorization 3778 3779 As an authentication service, Kerberos provides a means of verifying 3780 the identity of principals on a network. Kerberos does not, by 3781 itself, provide authorization. Applications SHOULD NOT accept the 3782 mere issuance of a service ticket by the Kerberos server as granting 3783 authority to use the service. 3784 378512.7. Login Authentication 3786 3787 Some applications, particularly those which provide login access when 3788 provided with a password, SHOULD NOT treat successful acquisition of 3789 credentials as sufficient proof of the user's identity. An attacker 3790 posing as a user could generate an illegitimate KDC-REP message which 3791 decrypts properly. To authenticate a user logging on to a local 3792 system, the credentials obtained SHOULD be used in a TGS exchange to 3793 obtain credentials for a local service. Successful use of those 3794 credentials to authenticate to the local service assures that the 3795 initially obtained credentials are from a valid KDC. 3796 379713. IANA Considerations 3798 3799 [ needs more work ] 3800 3801 Each use of Int32 in this document defines a number space. [ XXX 3802 enumerate these ] Negative numbers are reserved for private use; 3803 local and experimental extensions should use these values. Zero is 3804 reserved and may not be assigned. 3805 3806 3807Yu Expires: Mar 2005 [Page 68] 3808 3809Internet-Draft rfc1510ter-01 15 Sep 2005 3810 3811 Typed hole contents may be identified by either Int32 values or by 3812 RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical 3813 namespace, assignments to the top level of the RELATIVE-OID space may 3814 be made on a first-come, first-served basis. 3815 381614. Acknowledgments 3817 3818 Much of the text here is adapted from draft-ietf-krb-wg-kerberos- 3819 clarifications-07. The description of the general form of the 3820 extensibility framework was derived from text by Sam Hartman. 3821 3822Appendices 3823 3824A. ASN.1 Module (Normative) 3825 3826 KerberosV5Spec3 { 3827 iso(1) identified-organization(3) dod(6) internet(1) 3828 security(5) kerberosV5(2) modules(4) krb5spec3(4) 3829 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 3830 3831 3832 -- OID arc for KerberosV5 3833 -- 3834 -- This OID may be used to identify Kerberos protocol messages 3835 -- encapsulated in other protocols. 3836 -- 3837 -- This OID also designates the OID arc for KerberosV5-related 3838 -- OIDs. 3839 -- 3840 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its 3841 -- OID. 3842 id-krb5 OBJECT IDENTIFIER ::= { 3843 iso(1) identified-organization(3) dod(6) internet(1) 3844 security(5) kerberosV5(2) 3845 } 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863Yu Expires: Mar 2005 [Page 69] 3864 3865Internet-Draft rfc1510ter-01 15 Sep 2005 3866 3867 -- top-level type 3868 -- 3869 -- Applications should not directly reference any types 3870 -- other than KRB-PDU and its component types. 3871 -- 3872 KRB-PDU ::= CHOICE { 3873 ticket Ticket, 3874 as-req AS-REQ, 3875 as-rep AS-REP, 3876 tgs-req TGS-REQ, 3877 tgs-rep TGS-REP, 3878 ap-req AP-REQ, 3879 ap-rep AP-REP, 3880 krb-safe KRB-SAFE, 3881 krb-priv KRB-PRIV, 3882 krb-cred KRB-CRED, 3883 tgt-req TGT-REQ, 3884 krb-error KRB-ERROR, 3885 ... 3886 } 3887 3888 3889 -- 3890 -- *** basic types 3891 -- 3892 3893 3894 -- signed values representable in 32 bits 3895 -- 3896 -- These are often used as assigned numbers for various things. 3897 Int32 ::= INTEGER (-2147483648..2147483647) 3898 3899 3900 -- Typed hole identifiers 3901 TH-id ::= CHOICE { 3902 int32 Int32, 3903 rel-oid RELATIVE-OID 3904 } 3905 3906 3907 -- unsigned 32 bit values 3908 UInt32 ::= INTEGER (0..4294967295) 3909 3910 3911 -- unsigned 64 bit values 3912 UInt64 ::= INTEGER (0..18446744073709551615) 3913 3914 3915 -- sequence numbers 3916 SeqNum ::= UInt64 3917 3918 3919Yu Expires: Mar 2005 [Page 70] 3920 3921Internet-Draft rfc1510ter-01 15 Sep 2005 3922 3923 -- nonces 3924 Nonce ::= UInt64 3925 3926 3927 -- microseconds 3928 Microseconds ::= INTEGER (0..999999) 3929 3930 3931 KerberosTime ::= GeneralizedTime (CONSTRAINED BY { 3932 -- MUST NOT include fractional seconds 3933 }) 3934 3935 3936 -- used for names and for error messages 3937 KerberosString ::= CHOICE { 3938 ia5 GeneralString (IA5String), 3939 utf8 UTF8String, 3940 ... -- no extension may be sent 3941 -- to an rfc1510 implementation -- 3942 } 3943 3944 3945 -- IA5 choice only; useful for constraints 3946 KerberosStringIA5 ::= KerberosString 3947 (WITH COMPONENTS { ia5 PRESENT }) 3948 3949 -- IA5 excluded; useful for constraints 3950 KerberosStringExt ::= KerberosString 3951 (WITH COMPONENTS { ia5 ABSENT }) 3952 3953 3954 -- used for language tags 3955 LangTag ::= PrintableString 3956 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975Yu Expires: Mar 2005 [Page 71] 3976 3977Internet-Draft rfc1510ter-01 15 Sep 2005 3978 3979 -- assigned numbers for name types (used in principal names) 3980 NameType ::= Int32 3981 3982 -- Name type not known 3983 nt-unknown NameType ::= 0 3984 -- Just the name of the principal as in DCE, or for users 3985 nt-principal NameType ::= 1 3986 -- Service and other unique instance (krbtgt) 3987 nt-srv-inst NameType ::= 2 3988 -- Service with host name as instance (telnet, rcommands) 3989 nt-srv-hst NameType ::= 3 3990 -- Service with host as remaining components 3991 nt-srv-xhst NameType ::= 4 3992 -- Unique ID 3993 nt-uid NameType ::= 5 3994 -- Encoded X.509 Distingished name [RFC 2253] 3995 nt-x500-principal NameType ::= 6 3996 -- Name in form of SMTP email name (e.g. user@foo.com) 3997 nt-smtp-name NameType ::= 7 3998 -- Enterprise name - may be mapped to principal name 3999 nt-enterprise NameType ::= 10 4000 4001 4002 PrincipalName ::= SEQUENCE { 4003 name-type [0] NameType, 4004 -- May have zero elements, or individual elements may be 4005 -- zero-length, but this is NOT RECOMMENDED. 4006 name-string [1] SEQUENCE OF KerberosString 4007 } 4008 4009 4010 -- IA5 only 4011 PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS { 4012 ..., 4013 name-string (WITH COMPONENT (KerberosStringIA5)) 4014 }) 4015 4016 -- IA5 excluded 4017 PrincipalNameExt ::= PrincpalName (WITH COMPONENTS { 4018 ..., 4019 name-string (WITH COMPONENT (KerberosStringExt)) 4020 }) 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031Yu Expires: Mar 2005 [Page 72] 4032 4033Internet-Draft rfc1510ter-01 15 Sep 2005 4034 4035 Realm ::= KerberosString 4036 4037 -- IA5 only 4038 RealmIA5 ::= Realm (KerberosStringIA5) 4039 4040 -- IA5 excluded 4041 RealmExt ::= Realm (KerberosStringExt) 4042 4043 4044 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 4045 (CONSTRAINED BY { 4046 -- MUST be a valid value of -- NamedBits 4047 -- but if the value to be sent would be truncated to shorter 4048 -- than 32 bits according to DER, the value MUST be padded 4049 -- with trailing zero bits to 32 bits. Otherwise, no 4050 -- trailing zero bits may be present. 4051 4052 }) 4053 4054 4055 AddrType ::= Int32 4056 4057 HostAddress ::= SEQUENCE { 4058 addr-type [0] AddrType, 4059 address [1] OCTET STRING 4060 } 4061 4062 -- NOTE: HostAddresses is always used as an OPTIONAL field and 4063 -- should not be a zero-length SEQUENCE OF. 4064 -- 4065 -- The extensible messages explicitly constrain this to be 4066 -- non-empty. 4067 HostAddresses ::= SEQUENCE OF HostAddress 4068 4069 4070 -- 4071 -- *** crypto-related types and assignments 4072 -- 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087Yu Expires: Mar 2005 [Page 73] 4088 4089Internet-Draft rfc1510ter-01 15 Sep 2005 4090 4091 -- Assigned numbers denoting encryption mechanisms. 4092 EType ::= Int32 4093 4094 -- assigned numbers for encryption schemes 4095 et-des-cbc-crc EType ::= 1 4096 et-des-cbc-md4 EType ::= 2 4097 et-des-cbc-md5 EType ::= 3 4098 -- [reserved] 4 4099 et-des3-cbc-md5 EType ::= 5 4100 -- [reserved] 6 4101 et-des3-cbc-sha1 EType ::= 7 4102 et-dsaWithSHA1-CmsOID EType ::= 9 4103 et-md5WithRSAEncryption-CmsOID EType ::= 10 4104 et-sha1WithRSAEncryption-CmsOID EType ::= 11 4105 et-rc2CBC-EnvOID EType ::= 12 4106 et-rsaEncryption-EnvOID EType ::= 13 4107 et-rsaES-OAEP-ENV-OID EType ::= 14 4108 et-des-ede3-cbc-Env-OID EType ::= 15 4109 et-des3-cbc-sha1-kd EType ::= 16 4110 -- AES 4111 et-aes128-cts-hmac-sha1-96 EType ::= 17 4112 -- AES 4113 et-aes256-cts-hmac-sha1-96 EType ::= 18 4114 -- Microsoft 4115 et-rc4-hmac EType ::= 23 4116 -- Microsoft 4117 et-rc4-hmac-exp EType ::= 24 4118 -- opaque; PacketCable 4119 et-subkey-keymaterial EType ::= 65 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143Yu Expires: Mar 2005 [Page 74] 4144 4145Internet-Draft rfc1510ter-01 15 Sep 2005 4146 4147 -- Assigned numbers denoting key usages. 4148 KeyUsage ::= UInt32 4149 4150 -- 4151 -- Actual identifier names are provisional and subject to 4152 -- change. 4153 -- 4154 ku-pa-enc-ts KeyUsage ::= 1 4155 ku-Ticket KeyUsage ::= 2 4156 ku-EncASRepPart KeyUsage ::= 3 4157 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 4158 ku-TGSReqAuthData-subkey KeyUsage ::= 5 4159 ku-pa-TGSReq-cksum KeyUsage ::= 6 4160 ku-pa-TGSReq-authenticator KeyUsage ::= 7 4161 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 4162 ku-EncTGSRepPart-subkey KeyUsage ::= 9 4163 ku-Authenticator-cksum KeyUsage ::= 10 4164 ku-APReq-authenticator KeyUsage ::= 11 4165 ku-EncAPRepPart KeyUsage ::= 12 4166 ku-EncKrbPrivPart KeyUsage ::= 13 4167 ku-EncKrbCredPart KeyUsage ::= 14 4168 ku-KrbSafe-cksum KeyUsage ::= 15 4169 ku-ad-KDCIssued-cksum KeyUsage ::= 19 4170 4171 4172 -- The following numbers are provisional... 4173 -- conflicts may exist elsewhere. 4174 ku-Ticket-cksum KeyUsage ::= 25 4175 ku-ASReq-cksum KeyUsage ::= 26 4176 ku-TGSReq-cksum KeyUsage ::= 27 4177 ku-ASRep-cksum KeyUsage ::= 28 4178 ku-TGSRep-cksum KeyUsage ::= 29 4179 ku-APReq-cksum KeyUsage ::= 30 4180 ku-APRep-cksum KeyUsage ::= 31 4181 ku-KrbCred-cksum KeyUsage ::= 32 4182 ku-KrbError-cksum KeyUsage ::= 33 4183 ku-KDCRep-cksum KeyUsage ::= 34 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199Yu Expires: Mar 2005 [Page 75] 4200 4201Internet-Draft rfc1510ter-01 15 Sep 2005 4202 4203 -- KeyToUse identifies which key is to be used to encrypt or 4204 -- sign a given value. 4205 -- 4206 -- Values of KeyToUse are never actually transmitted over the 4207 -- wire, or even used directly by the implementation in any 4208 -- way, as key usages are; it exists primarily to identify 4209 -- which key gets used for what purpose. Thus, the specific 4210 -- numeric values associated with this type are irrelevant. 4211 KeyToUse ::= ENUMERATED { 4212 -- unspecified 4213 key-unspecified, 4214 -- server long term key 4215 key-server, 4216 -- client long term key 4217 key-client, 4218 -- key selected by KDC for encryption of a KDC-REP 4219 key-kdc-rep, 4220 -- session key from ticket 4221 key-session, 4222 -- subsession key negotiated via AP-REQ/AP-REP 4223 key-subsession, 4224 ... 4225 } 4226 4227 4228 EncryptionKey ::= SEQUENCE { 4229 keytype [0] EType, 4230 keyvalue [1] OCTET STRING 4231 } 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255Yu Expires: Mar 2005 [Page 76] 4256 4257Internet-Draft rfc1510ter-01 15 Sep 2005 4258 4259 4260 -- "Type" specifies which ASN.1 type is encrypted to the 4261 -- ciphertext in the EncryptedData. "Keys" specifies a set of 4262 -- keys of which one key may be used to encrypt the data. 4263 -- "KeyUsages" specifies a set of key usages, one of which may 4264 -- be used to encrypt. 4265 -- 4266 -- None of the parameters is transmitted over the wire. 4267 EncryptedData { 4268 Type, KeyToUse:Keys, KeyUsage:KeyUsages 4269 } ::= SEQUENCE { 4270 etype [0] EType, 4271 kvno [1] UInt32 OPTIONAL, 4272 cipher [2] OCTET STRING (CONSTRAINED BY { 4273 -- must be encryption of -- 4274 OCTET STRING (CONTAINING Type), 4275 -- with one of the keys -- KeyToUse:Keys, 4276 -- with key usage being one of -- 4277 KeyUsage:KeyUsages 4278 }), 4279 ... 4280 } 4281 4282 4283 4284 CksumType ::= Int32 4285 4286 -- The parameters specify which key to use to produce the 4287 -- signature, as well as which key usage to use. The 4288 -- parameters are not actually sent over the wire. 4289 Checksum { 4290 KeyToUse:Keys, KeyUsage:KeyUsages 4291 } ::= SEQUENCE { 4292 cksumtype [0] CksumType, 4293 checksum [1] OCTET STRING (CONSTRAINED BY { 4294 -- signed using one of the keys -- 4295 KeyToUse:Keys, 4296 -- with key usage being one of -- 4297 KeyUsage:KeyUsages 4298 }) 4299 } 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311Yu Expires: Mar 2005 [Page 77] 4312 4313Internet-Draft rfc1510ter-01 15 Sep 2005 4314 4315 -- a Checksum that must contain the checksum 4316 -- of a particular type 4317 ChecksumOf { 4318 Type, KeyToUse:Keys, KeyUsage:KeyUsages 4319 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 4320 ..., 4321 checksum (CONSTRAINED BY { 4322 -- must be checksum of -- 4323 OCTET STRING (CONTAINING Type) 4324 }) 4325 }) 4326 4327 4328 -- parameterized type for wrapping authenticated plaintext 4329 Signed { 4330 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 4331 } ::= SEQUENCE { 4332 cksum [0] ChecksumOf { 4333 InnerType, Keys, KeyUsages 4334 } OPTIONAL, 4335 inner [1] InnerType, 4336 ... 4337 } 4338 4339 4340 -- 4341 -- *** Tickets 4342 -- 4343 4344 4345 Ticket ::= CHOICE { 4346 rfc1510 [APPLICATION 1] Ticket1510, 4347 ext [APPLICATION 4] Signed { 4348 TicketExt, { key-server }, { ku-Ticket-cksum } 4349 } 4350 } 4351 4352 4353 -- takes a parameter specifying which type gets encrypted 4354 TicketCommon { EncPart } ::= SEQUENCE { 4355 tkt-vno [0] INTEGER (5), 4356 realm [1] Realm, 4357 sname [2] PrincipalName, 4358 enc-part [3] EncryptedData { 4359 EncPart, { key-server }, { ku-Ticket } 4360 }, 4361 ..., 4362 extensions [4] TicketExtensions OPTIONAL, 4363 ... 4364 } 4365 4366 4367Yu Expires: Mar 2005 [Page 78] 4368 4369Internet-Draft rfc1510ter-01 15 Sep 2005 4370 4371 Ticket1510 ::= SEQUENCE { 4372 COMPONENTS OF TicketCommon { EncTicketPart1510 } 4373 } (WITH COMPONENTS { 4374 ..., 4375 -- explicitly force IA5 in strings 4376 realm (RealmIA5), 4377 sname (PrincipalNameIA5) 4378 }) 4379 4380 4381 -- APPLICATION tag goes inside Signed{} as well as outside, 4382 -- to prevent possible substitution attacks. 4383 TicketExt ::= [APPLICATION 4] TicketCommon { 4384 EncTicketPartExt 4385 } (WITH COMPONENTS { 4386 ..., 4387 -- explicitly force UTF-8 in strings 4388 realm (RealmExt), 4389 sname (PrincipalNameExt) 4390 }) 4391 4392 4393 -- Encrypted part of ticket 4394 EncTicketPart ::= CHOICE { 4395 rfc1510 [APPLICATION 3] EncTicketPart1510, 4396 ext [APPLICATION 5] EncTicketPartExt 4397 } 4398 4399 4400 EncTicketPartCommon ::= SEQUENCE { 4401 flags [0] TicketFlags, 4402 key [1] EncryptionKey, 4403 crealm [2] Realm, 4404 cname [3] PrincipalName, 4405 transited [4] TransitedEncoding, 4406 authtime [5] KerberosTime, 4407 starttime [6] KerberosTime OPTIONAL, 4408 endtime [7] KerberosTime, 4409 renew-till [8] KerberosTime OPTIONAL, 4410 caddr [9] HostAddresses OPTIONAL, 4411 authorization-data [10] AuthorizationData OPTIONAL, 4412 ... 4413 } 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423Yu Expires: Mar 2005 [Page 79] 4424 4425Internet-Draft rfc1510ter-01 15 Sep 2005 4426 4427 EncTicketPart1510 ::= SEQUENCE { 4428 COMPONENTS OF EncTicketPartCommon 4429 } (WITH COMPONENTS { 4430 ..., 4431 -- explicitly force IA5 in strings 4432 crealm (RealmIA5), 4433 cname (PrincipalNameIA5) 4434 }) 4435 4436 4437 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { 4438 ..., 4439 -- explicitly force UTF-8 in strings 4440 crealm (RealmExt), 4441 cname (PrincipalNameExt), 4442 -- explicitly constrain caddr to be non-empty if present 4443 caddr (SIZE (1..MAX)), 4444 -- forbid empty authorization-data encodings 4445 authorization-data (SIZE (1..MAX)) 4446 }) 4447 4448 4449 -- 4450 -- *** Authorization Data 4451 -- 4452 4453 4454 ADType ::= TH-id 4455 4456 AuthorizationData ::= SEQUENCE OF SEQUENCE { 4457 ad-type [0] ADType, 4458 ad-data [1] OCTET STRING 4459 } 4460 4461 4462 ad-if-relevant ADType ::= int32 : 1 4463 4464 -- Encapsulates another AuthorizationData. 4465 -- Intended for application servers; receiving application servers 4466 -- MAY ignore. 4467 AD-IF-RELEVANT ::= AuthorizationData 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479Yu Expires: Mar 2005 [Page 80] 4480 4481Internet-Draft rfc1510ter-01 15 Sep 2005 4482 4483 -- KDC-issued privilege attributes 4484 ad-kdcissued ADType ::= int32 : 4 4485 4486 AD-KDCIssued ::= SEQUENCE { 4487 ad-checksum [0] ChecksumOf { 4488 AuthorizationData, { key-session }, 4489 { ku-ad-KDCIssued-cksum }}, 4490 i-realm [1] Realm OPTIONAL, 4491 i-sname [2] PrincipalName OPTIONAL, 4492 elements [3] AuthorizationData 4493 } 4494 4495 4496 ad-and-or ADType ::= int32 : 5 4497 4498 AD-AND-OR ::= SEQUENCE { 4499 condition-count [0] INTEGER, 4500 elements [1] AuthorizationData 4501 } 4502 4503 4504 -- KDCs MUST interpret any AuthorizationData wrapped in this. 4505 ad-mandatory-for-kdc ADType ::= int32 : 8 4506 AD-MANDATORY-FOR-KDC ::= AuthorizationData 4507 4508 4509 TrType ::= TH-id -- must be registered 4510 4511 -- encoded Transited field 4512 TransitedEncoding ::= SEQUENCE { 4513 tr-type [0] TrType, 4514 contents [1] OCTET STRING 4515 } 4516 4517 4518 TEType ::= TH-id 4519 4520 -- ticket extensions: for TicketExt only 4521 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4522 te-type [0] TEType, 4523 te-data [1] OCTET STRING 4524 } 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535Yu Expires: Mar 2005 [Page 81] 4536 4537Internet-Draft rfc1510ter-01 15 Sep 2005 4538 4539 TicketFlags ::= KerberosFlags { TicketFlagsBits } 4540 4541 TicketFlagsBits ::= BIT STRING { 4542 reserved (0), 4543 forwardable (1), 4544 forwarded (2), 4545 proxiable (3), 4546 proxy (4), 4547 may-postdate (5), 4548 postdated (6), 4549 invalid (7), 4550 renewable (8), 4551 initial (9), 4552 pre-authent (10), 4553 hw-authent (11), 4554 transited-policy-checked (12), 4555 ok-as-delegate (13), 4556 anonymous (14), 4557 cksummed-ticket (15) 4558 } 4559 4560 4561 -- 4562 -- *** KDC protocol 4563 -- 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591Yu Expires: Mar 2005 [Page 82] 4592 4593Internet-Draft rfc1510ter-01 15 Sep 2005 4594 4595 AS-REQ ::= CHOICE { 4596 rfc1510 [APPLICATION 10] KDC-REQ-1510 4597 (WITH COMPONENTS { 4598 ..., 4599 msg-type (10), 4600 -- AS-REQ must include client name 4601 req-body (WITH COMPONENTS { ..., cname PRESENT }) 4602 }), 4603 ext [APPLICATION 6] Signed { 4604 -- APPLICATION tag goes inside Signed{} as well as 4605 -- outside, to prevent possible substitution attacks. 4606 [APPLICATION 6] KDC-REQ-EXT, 4607 -- not sure this is correct key to use; do we even want 4608 -- to sign AS-REQ? 4609 { key-client }, 4610 { ku-ASReq-cksum } 4611 } 4612 (WITH COMPONENTS { 4613 ..., 4614 msg-type (6), 4615 -- AS-REQ must include client name 4616 req-body (WITH COMPONENTS { ..., cname PRESENT }) 4617 }) 4618 } 4619 4620 4621 TGS-REQ ::= CHOICE { 4622 rfc1510 [APPLICATION 12] KDC-REQ-1510 4623 (WITH COMPONENTS { 4624 ..., 4625 msg-type (12), 4626 -- client name optional in TGS-REQ 4627 req-body (WITH COMPONENTS { ..., cname ABSENT }) 4628 }), 4629 ext [APPLICATION 8] Signed { 4630 -- APPLICATION tag goes inside Signed{} as well as 4631 -- outside, to prevent possible substitution attacks. 4632 [APPLICATION 8] KDC-REQ-EXT, 4633 { key-session }, { ku-TGSReq-cksum } 4634 } 4635 (WITH COMPONENTS { 4636 ..., 4637 msg-type (8), 4638 -- client name optional in TGS-REQ 4639 req-body (WITH COMPONENTS { ..., cname ABSENT }) 4640 }) 4641 } 4642 4643 4644 4645 4646 4647Yu Expires: Mar 2005 [Page 83] 4648 4649Internet-Draft rfc1510ter-01 15 Sep 2005 4650 4651 KDC-REQ-COMMON ::= SEQUENCE { 4652 -- NOTE: first tag is [1], not [0] 4653 pvno [1] INTEGER (5), 4654 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- 4655 | 12 -- TGS-REQ.rfc1510 -- 4656 | 6 -- AS-REQ.ext -- 4657 | 8 -- TGS-REQ.ext -- ), 4658 padata [3] SEQUENCE OF PA-DATA OPTIONAL 4659 -- NOTE: not empty 4660 } 4661 4662 4663 KDC-REQ-1510 ::= SEQUENCE { 4664 COMPONENTS OF KDC-REQ-COMMON, 4665 req-body [4] KDC-REQ-BODY-1510 4666 } (WITH COMPONENTS { ..., msg-type (10 | 12) }) 4667 4668 4669 -- APPLICATION tag goes inside Signed{} as well as outside, 4670 -- to prevent possible substitution attacks. 4671 KDC-REQ-EXT ::= SEQUENCE { 4672 COMPONENTS OF KDC-REQ-COMMON, 4673 req-body [4] KDC-REQ-BODY-EXT, 4674 ... 4675 } (WITH COMPONENTS { 4676 ..., 4677 msg-type (6 | 8), 4678 padata (SIZE (1..MAX)) 4679 }) 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703Yu Expires: Mar 2005 [Page 84] 4704 4705Internet-Draft rfc1510ter-01 15 Sep 2005 4706 4707 KDC-REQ-BODY-COMMON ::= SEQUENCE { 4708 kdc-options [0] KDCOptions, 4709 cname [1] PrincipalName OPTIONAL 4710 -- Used only in AS-REQ --, 4711 4712 realm [2] Realm 4713 -- Server's realm; also client's in AS-REQ --, 4714 4715 sname [3] PrincipalName OPTIONAL, 4716 from [4] KerberosTime OPTIONAL, 4717 till [5] KerberosTime OPTIONAL 4718 -- was required in rfc1510; 4719 -- still required for compat versions 4720 -- of messages --, 4721 4722 rtime [6] KerberosTime OPTIONAL, 4723 nonce [7] Nonce, 4724 etype [8] SEQUENCE OF EType 4725 -- in preference order --, 4726 4727 addresses [9] HostAddresses OPTIONAL, 4728 enc-authorization-data [10] EncryptedData { 4729 AuthorizationData, { key-session | key-subsession }, 4730 { ku-TGSReqAuthData-subkey | 4731 ku-TGSReqAuthData-sesskey } 4732 } OPTIONAL, 4733 4734 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 4735 -- NOTE: not empty --, 4736 ... 4737 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 4738 LangTag OPTIONAL, 4739 ... 4740 } 4741 4742 4743 KDC-REQ-BODY-1510 ::= SEQUENCE { 4744 COMPONENTS OF KDC-REQ-BODY-COMMON 4745 } (WITH COMPONENTS { 4746 ..., 4747 cname (PrincipalNameIA5), 4748 realm (RealmIA5), 4749 sname (PrincipalNameIA5), 4750 till PRESENT, 4751 nonce (UInt32) 4752 }) 4753 4754 4755 4756 4757 4758 4759Yu Expires: Mar 2005 [Page 85] 4760 4761Internet-Draft rfc1510ter-01 15 Sep 2005 4762 4763 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON 4764 (WITH COMPONENTS { 4765 ..., 4766 cname (PrincipalNameExt), 4767 realm (RealmExt), 4768 sname (PrincipalNameExt), 4769 addresses (SIZE (1..MAX)), 4770 enc-authorization-data (EncryptedData { 4771 AuthorizationData (SIZE (1..MAX)), 4772 { key-session | key-subsession }, 4773 { ku-TGSReqAuthData-subkey | 4774 ku-TGSReqAuthData-sesskey } 4775 }), 4776 additional-tickets (SIZE (1..MAX)) 4777 }) 4778 4779 4780 KDCOptions ::= KerberosFlags { KDCOptionsBits } 4781 4782 KDCOptionsBits ::= BIT STRING { 4783 reserved (0), 4784 forwardable (1), 4785 forwarded (2), 4786 proxiable (3), 4787 proxy (4), 4788 allow-postdate (5), 4789 postdated (6), 4790 unused7 (7), 4791 renewable (8), 4792 unused9 (9), 4793 unused10 (10), 4794 unused11 (11), 4795 unused12 (12), 4796 unused13 (13), 4797 requestanonymous (14), 4798 canonicalize (15), 4799 disable-transited-check (26), 4800 renewable-ok (27), 4801 enc-tkt-in-skey (28), 4802 renew (30), 4803 validate (31) 4804 -- XXX need "need ticket1" flag? 4805 } 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815Yu Expires: Mar 2005 [Page 86] 4816 4817Internet-Draft rfc1510ter-01 15 Sep 2005 4818 4819 AS-REP ::= CHOICE { 4820 rfc1510 [APPLICATION 11] KDC-REP-1510 { 4821 EncASRepPart1510 4822 } (WITH COMPONENTS { ..., msg-type (11) }), 4823 ext [APPLICATION 7] Signed { 4824 [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, 4825 { key-reply }, { ku-ASRep-cksum } 4826 } (WITH COMPONENTS { ..., msg-type (7) }) 4827 } 4828 4829 4830 TGS-REP ::= CHOICE { 4831 rfc1510 [APPLICATION 13] KDC-REP-1510 { 4832 EncTGSRepPart1510 4833 } (WITH COMPONENTS { ..., msg-type (13) }), 4834 ext [APPLICATION 9] Signed { 4835 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 4836 { key-reply }, { ku-TGSRep-cksum } 4837 } (WITH COMPONENTS { ..., msg-type (9) }) 4838 } 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871Yu Expires: Mar 2005 [Page 87] 4872 4873Internet-Draft rfc1510ter-01 15 Sep 2005 4874 4875 KDC-REP-COMMON { EncPart } ::= SEQUENCE { 4876 pvno [0] INTEGER (5), 4877 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 4878 13 -- TGS.rfc1510 -- | 4879 7 -- AS-REP.ext -- | 4880 9 -- TGS-REP.ext -- ), 4881 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 4882 crealm [3] Realm, 4883 cname [4] PrincipalName, 4884 ticket [5] Ticket, 4885 4886 enc-part [6] EncryptedData { 4887 EncPart, 4888 { key-reply }, 4889 -- maybe reach into EncryptedData in AS-REP/TGS-REP 4890 -- definitions to apply constraints on key usages? 4891 { ku-EncASRepPart -- if AS-REP -- | 4892 ku-EncTGSRepPart-subkey -- if TGS-REP and 4893 -- using Authenticator 4894 -- session key -- | 4895 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 4896 -- subsession key -- } 4897 }, 4898 4899 ..., 4900 -- In extensible version, KDC signs original request 4901 -- to avoid replay attacks against client. 4902 req-cksum [7] ChecksumOf { CHOICE { 4903 as-req AS-REQ, 4904 tgs-req TGS-REQ 4905 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 4906 lang-tag [8] LangTag OPTIONAL, 4907 ... 4908 } 4909 4910 4911 KDC-REP-1510 { EncPart } ::= SEQUENCE { 4912 COMPONENTS OF KDC-REP-COMMON { EncPart } 4913 } (WITH COMPONENTS { 4914 ..., 4915 msg-type (11 | 13), 4916 crealm (RealmIA5), 4917 cname (PrincipalNameIA5) 4918 }) 4919 4920 4921 4922 4923 4924 4925 4926 4927Yu Expires: Mar 2005 [Page 88] 4928 4929Internet-Draft rfc1510ter-01 15 Sep 2005 4930 4931 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart } 4932 (WITH COMPONENTS { 4933 ..., 4934 msg-type (7 | 9), 4935 crealm (RealmExt), 4936 cname (PrincipalNameExt) 4937 }) 4938 4939 4940 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 4941 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 4942 4943 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 4944 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 4945 4946 EncKDCRepPartCom ::= SEQUENCE { 4947 key [0] EncryptionKey, 4948 last-req [1] LastReq, 4949 nonce [2] Nonce, 4950 key-expiration [3] KerberosTime OPTIONAL, 4951 flags [4] TicketFlags, 4952 authtime [5] KerberosTime, 4953 starttime [6] KerberosTime OPTIONAL, 4954 endtime [7] KerberosTime, 4955 renew-till [8] KerberosTime OPTIONAL, 4956 srealm [9] Realm, 4957 sname [10] PrincipalName, 4958 caddr [11] HostAddresses OPTIONAL, 4959 ... 4960 } 4961 4962 EncKDCRepPart1510 ::= SEQUENCE { 4963 COMPONENTS OF EncKDCRepPartCom 4964 } (WITH COMPONENTS { 4965 ..., 4966 srealm (RealmIA5), 4967 sname (PrincipalNameIA5), 4968 nonce UInt32 }) 4969 4970 EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS { 4971 ..., 4972 srealm (RealmExt), 4973 sname (PrincipalNameExt) 4974 }) 4975 4976 4977 4978 4979 4980 4981 4982 4983Yu Expires: Mar 2005 [Page 89] 4984 4985Internet-Draft rfc1510ter-01 15 Sep 2005 4986 4987 LRType ::= TH-id 4988 LastReq ::= SEQUENCE OF SEQUENCE { 4989 lr-type [0] LRType, 4990 lr-value [1] KerberosTime 4991 } 4992 4993 4994 -- 4995 -- *** preauth 4996 -- 4997 4998 4999 PaDataType ::= TH-id 5000 PaDataOID ::= RELATIVE-OID 5001 5002 PA-DATA ::= SEQUENCE { 5003 -- NOTE: first tag is [1], not [0] 5004 padata-type [1] PaDataType, 5005 padata-value [2] OCTET STRING 5006 } 5007 5008 5009 -- AP-REQ authenticating a TGS-REQ 5010 pa-tgs-req PaDataType ::= int32 : 1 5011 PA-TGS-REQ ::= AP-REQ 5012 5013 5014 -- Encrypted timestamp preauth 5015 -- Encryption key used is client's long-term key. 5016 pa-enc-timestamp PaDataType ::= int32 : 2 5017 5018 PA-ENC-TIMESTAMP ::= EncryptedData { 5019 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } 5020 } 5021 5022 PA-ENC-TS-ENC ::= SEQUENCE { 5023 patimestamp [0] KerberosTime -- client's time --, 5024 pausec [1] Microseconds OPTIONAL 5025 } 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039Yu Expires: Mar 2005 [Page 90] 5040 5041Internet-Draft rfc1510ter-01 15 Sep 2005 5042 5043 -- Hints returned in AS-REP or KRB-ERROR to help client 5044 -- choose a password-derived key, either for preauthentication 5045 -- or for decryption of the reply. 5046 pa-etype-info PaDataType ::= int32 : 11 5047 5048 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 5049 5050 ETYPE-INFO-ENTRY ::= SEQUENCE { 5051 etype [0] EType, 5052 salt [1] OCTET STRING OPTIONAL 5053 } 5054 5055 5056 -- Similar to etype-info, but with parameters provided for 5057 -- the string-to-key function. 5058 pa-etype-info2 PaDataType ::= int32 : 19 5059 5060 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) 5061 OF ETYPE-INFO-ENTRY 5062 5063 ETYPE-INFO2-ENTRY ::= SEQUENCE { 5064 etype [0] EType, 5065 salt [1] KerberosString OPTIONAL, 5066 s2kparams [2] OCTET STRING OPTIONAL 5067 } 5068 5069 5070 -- Obsolescent. Salt for client's long-term key. 5071 -- Its character encoding is unspecified. 5072 pa-pw-salt PaDataType ::= int32 : 3 5073 -- The "padata-value" does not encode an ASN.1 type. 5074 -- Instead, "padata-value" must consist of the salt string to 5075 -- be used by the client, in an unspecified character 5076 -- encoding. 5077 5078 5079 -- An extensible AS-REQ may be sent as a padata in a 5080 -- non-extensible AS-REQ to allow for backwards compatibility. 5081 pa-as-req PaDataType ::= int32 : 42 -- provisional 5082 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) 5083 5084 5085 -- 5086 -- *** Session key exchange 5087 -- 5088 5089 5090 5091 5092 5093 5094 5095Yu Expires: Mar 2005 [Page 91] 5096 5097Internet-Draft rfc1510ter-01 15 Sep 2005 5098 5099 AP-REQ ::= CHOICE { 5100 rfc1510 [APPLICATION 14] AP-REQ-1510, 5101 ext [APPLICATION 18] Signed { 5102 AP-REQ-EXT, { key-session }, { ku-APReq-cksum } 5103 } 5104 } 5105 5106 5107 AP-REQ-COMMON ::= SEQUENCE { 5108 pvno [0] INTEGER (5), 5109 msg-type [1] INTEGER (14 | 18), 5110 ap-options [2] APOptions, 5111 ticket [3] Ticket, 5112 authenticator [4] EncryptedData { 5113 Authenticator, 5114 { key-session }, 5115 { ku-APReq-authenticator | 5116 ku-pa-TGSReq-authenticator } 5117 }, 5118 ..., 5119 extensions [5] ApReqExtensions OPTIONAL, 5120 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 5121 OF LangTag OPTIONAL, 5122 ... 5123 } 5124 5125 5126 AP-REQ-1510 ::= SEQUENCE { 5127 COMPONENTS OF AP-REQ-COMMON 5128 } (WITH COMPONENTS { 5129 ..., 5130 msg-type (14), 5131 authenticator (EncryptedData { 5132 Authenticator (WITH COMPONENTS { 5133 ..., 5134 crealm (RealmIA5), 5135 cname (PrincipalNameIA5), 5136 seqnum (UInt32) 5137 }), { key-session }, { ku-APReq-authenticator }}) 5138 }) 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151Yu Expires: Mar 2005 [Page 92] 5152 5153Internet-Draft rfc1510ter-01 15 Sep 2005 5154 5155 AP-REQ-EXT ::= AP-REQ-COMMON 5156 (WITH COMPONENTS { 5157 ..., 5158 msg-type (18), 5159 -- The following constraints on Authenticator assume that 5160 -- we want to restrict the use of AP-REQ-EXT with TicketExt 5161 -- only, since that is the only way we can enforce UTF-8. 5162 authenticator (EncryptedData { 5163 Authenticator (WITH COMPONENTS { 5164 ..., 5165 crealm (RealmExt), 5166 cname (PrincipalNameExt), 5167 authorization-data (SIZE (1..MAX)) 5168 }), { key-session }, { ku-APReq-authenticator }}) 5169 }) 5170 5171 5172 ApReqExtType ::= TH-id 5173 5174 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 5175 apReqExt-Type [0] ApReqExtType, 5176 apReqExt-Data [1] OCTET STRING 5177 } 5178 5179 5180 APOptions ::= KerberosFlags { APOptionsBits } 5181 5182 APOptionsBits ::= BIT STRING { 5183 reserved (0), 5184 use-session-key (1), 5185 mutual-required (2) 5186 } 5187 5188 5189 -- plaintext of authenticator 5190 Authenticator ::= [APPLICATION 2] SEQUENCE { 5191 authenticator-vno [0] INTEGER (5), 5192 crealm [1] Realm, 5193 cname [2] PrincipalName, 5194 cksum [3] Checksum {{ key-session }, 5195 { ku-Authenticator-cksum | 5196 ku-pa-TGSReq-cksum }} OPTIONAL, 5197 cusec [4] Microseconds, 5198 ctime [5] KerberosTime, 5199 subkey [6] EncryptionKey OPTIONAL, 5200 seq-number [7] SeqNum OPTIONAL, 5201 authorization-data [8] AuthorizationData OPTIONAL 5202 } 5203 5204 5205 5206 5207Yu Expires: Mar 2005 [Page 93] 5208 5209Internet-Draft rfc1510ter-01 15 Sep 2005 5210 5211 AP-REP ::= CHOICE { 5212 rfc1510 [APPLICATION 15] AP-REP-1510, 5213 ext [APPLICATION 19] Signed { 5214 AP-REP-EXT, 5215 { key-session | key-subsession }, { ku-APRep-cksum }} 5216 } 5217 5218 5219 AP-REP-COMMON { EncPart } ::= SEQUENCE { 5220 pvno [0] INTEGER (5), 5221 msg-type [1] INTEGER (15 | 19), 5222 enc-part [2] EncryptedData { 5223 EncPart, 5224 { key-session | key-subsession }, { ku-EncAPRepPart }}, 5225 ..., 5226 extensions [3] ApRepExtensions OPTIONAL, 5227 ... 5228 } 5229 5230 5231 AP-REP-1510 ::= SEQUENCE { 5232 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 } 5233 } (WITH COMPONENTS { 5234 ..., 5235 msg-type (15) 5236 }) 5237 5238 5239 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON { 5240 EncAPRepPartExt 5241 } (WITH COMPONENTS { ..., msg-type (19) }) 5242 5243 5244 ApRepExtType ::= TH-id 5245 5246 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 5247 apRepExt-Type [0] ApRepExtType, 5248 apRepExt-Data [1] OCTET STRING 5249 } 5250 5251 5252 EncAPRepPart ::= CHOICE { 5253 rfc1510 [APPLICATION 27] EncAPRepPart1510, 5254 ext [APPLICATION 31] EncAPRepPartExt 5255 } 5256 5257 5258 5259 5260 5261 5262 5263Yu Expires: Mar 2005 [Page 94] 5264 5265Internet-Draft rfc1510ter-01 15 Sep 2005 5266 5267 EncAPRepPart1510 ::= SEQUENCE { 5268 COMPONENTS OF ENCAPRepPartCom 5269 } (WITH COMPONENTS { 5270 ..., 5271 seq-number (UInt32), 5272 authorization-data ABSENT 5273 }) 5274 5275 5276 EncAPRepPartExt ::= EncAPRepPartCom 5277 5278 5279 EncAPRepPartCom ::= SEQUENCE { 5280 ctime [0] KerberosTime, 5281 cusec [1] Microseconds, 5282 subkey [2] EncryptionKey OPTIONAL, 5283 seq-number [3] SeqNum OPTIONAL, 5284 ..., 5285 authorization-data [4] AuthorizationData OPTIONAL, 5286 ... 5287 } 5288 5289 5290 -- 5291 -- *** Application messages 5292 -- 5293 5294 5295 -- Do we chew up another tag for KRB-SAFE-EXT? That would 5296 -- allow us to make safe-body optional, allowing for a GSS-MIC 5297 -- sort of message. 5298 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 5299 pvno [0] INTEGER (5), 5300 msg-type [1] INTEGER (20), 5301 safe-body [2] KRB-SAFE-BODY, 5302 cksum [3] ChecksumOf { 5303 KRB-SAFE-BODY, 5304 { key-session | key-subsession }, { ku-KrbSafe-cksum }}, 5305 ... -- ASN.1 extensions must be excluded 5306 -- when sending to rfc1510 implementations 5307 } 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319Yu Expires: Mar 2005 [Page 95] 5320 5321Internet-Draft rfc1510ter-01 15 Sep 2005 5322 5323 KRB-SAFE-BODY ::= SEQUENCE { 5324 user-data [0] OCTET STRING, 5325 timestamp [1] KerberosTime OPTIONAL, 5326 usec [2] Microseconds OPTIONAL, 5327 seq-number [3] SeqNum OPTIONAL, 5328 s-address [4] HostAddress, 5329 r-address [5] HostAddress OPTIONAL, 5330 ... -- ASN.1 extensions must be excluded 5331 -- when sending to rfc1510 implementations 5332 } 5333 5334 5335 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 5336 pvno [0] INTEGER (5), 5337 msg-type [1] INTEGER (21), 5338 enc-part [3] EncryptedData { 5339 EncKrbPrivPart, 5340 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 5341 ... 5342 } 5343 5344 5345 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 5346 user-data [0] OCTET STRING, 5347 timestamp [1] KerberosTime OPTIONAL, 5348 usec [2] Microseconds OPTIONAL, 5349 seq-number [3] SeqNum OPTIONAL, 5350 s-address [4] HostAddress -- sender's addr --, 5351 r-address [5] HostAddress OPTIONAL -- recip's addr --, 5352 ... -- ASN.1 extensions must be excluded 5353 -- when sending to rfc1510 implementations 5354 } 5355 5356 5357 KRB-CRED ::= CHOICE { 5358 rfc1510 [APPLICATION 22] KRB-CRED-1510, 5359 ext [APPLICATION 24] Signed { 5360 KRB-CRED-EXT, 5361 { key-session | key-subsession }, { ku-KrbCred-cksum }} 5362 } 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375Yu Expires: Mar 2005 [Page 96] 5376 5377Internet-Draft rfc1510ter-01 15 Sep 2005 5378 5379 KRB-CRED-COMMON ::= SEQUENCE { 5380 pvno [0] INTEGER (5), 5381 msg-type [1] INTEGER (22 | 24), 5382 tickets [2] SEQUENCE OF Ticket, 5383 enc-part [3] EncryptedData { 5384 EncKrbCredPart, 5385 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 5386 ... 5387 } 5388 5389 5390 KRB-CRED-1510 ::= SEQUENCE { 5391 COMPONENTS OF KRB-CRED-COMMON 5392 } (WITH COMPONENTS { ..., msg-type (22) }) 5393 5394 5395 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON 5396 (WITH COMPONENTS { ..., msg-type (24) }) 5397 5398 5399 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 5400 ticket-info [0] SEQUENCE OF KrbCredInfo, 5401 nonce [1] Nonce OPTIONAL, 5402 timestamp [2] KerberosTime OPTIONAL, 5403 usec [3] Microseconds OPTIONAL, 5404 s-address [4] HostAddress OPTIONAL, 5405 r-address [5] HostAddress OPTIONAL 5406 } 5407 5408 5409 KrbCredInfo ::= SEQUENCE { 5410 key [0] EncryptionKey, 5411 prealm [1] Realm OPTIONAL, 5412 pname [2] PrincipalName OPTIONAL, 5413 flags [3] TicketFlags OPTIONAL, 5414 authtime [4] KerberosTime OPTIONAL, 5415 starttime [5] KerberosTime OPTIONAL, 5416 endtime [6] KerberosTime OPTIONAL, 5417 renew-till [7] KerberosTime OPTIONAL, 5418 srealm [8] Realm OPTIONAL, 5419 sname [9] PrincipalName OPTIONAL, 5420 caddr [10] HostAddresses OPTIONAL 5421 } 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431Yu Expires: Mar 2005 [Page 97] 5432 5433Internet-Draft rfc1510ter-01 15 Sep 2005 5434 5435 TGT-REQ ::= [APPLICATION 16] SEQUENCE { 5436 pvno [0] INTEGER (5), 5437 msg-type [1] INTEGER (16), 5438 sname [2] PrincipalName OPTIONAL, 5439 srealm [3] Realm OPTIONAL, 5440 ... 5441 } 5442 5443 5444 -- 5445 -- *** Error messages 5446 -- 5447 5448 5449 ErrCode ::= Int32 5450 5451 KRB-ERROR ::= CHOICE { 5452 rfc1510 [APPLICATION 30] KRB-ERROR-1510, 5453 ext [APPLICATION 23] Signed { 5454 KRB-ERROR-EXT, { ku-KrbError-cksum } } 5455 } 5456 5457 5458 KRB-ERROR-COMMON ::= SEQUENCE { 5459 pvno [0] INTEGER (5), 5460 msg-type [1] INTEGER (30 | 23), 5461 ctime [2] KerberosTime OPTIONAL, 5462 cusec [3] Microseconds OPTIONAL, 5463 stime [4] KerberosTime, 5464 susec [5] Microseconds, 5465 error-code [6] ErrCode, 5466 crealm [7] Realm OPTIONAL, 5467 cname [8] PrincipalName OPTIONAL, 5468 realm [9] Realm -- Correct realm --, 5469 sname [10] PrincipalName -- Correct name --, 5470 e-text [11] KerberosString OPTIONAL, 5471 e-data [12] OCTET STRING OPTIONAL, 5472 ..., 5473 typed-data [13] TYPED-DATA OPTIONAL, 5474 nonce [14] Nonce OPTIONAL, 5475 lang-tag [15] LangTag OPTIONAL, 5476 ... 5477 } 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487Yu Expires: Mar 2005 [Page 98] 5488 5489Internet-Draft rfc1510ter-01 15 Sep 2005 5490 5491 KRB-ERROR-1510 ::= SEQUENCE { 5492 COMPONENTS OF KRB-ERROR-COMMON 5493 } (WITH COMPONENTS { 5494 ..., 5495 msg-type (30) 5496 }) 5497 5498 5499 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON 5500 (WITH COMPONENTS { ..., msg-type (23) }) 5501 5502 5503 METHOD-DATA ::= SEQUENCE OF PA-DATA 5504 5505 5506 TDType ::= TH-id 5507 5508 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5509 data-type [0] TDType, 5510 data-value [1] OCTET STRING OPTIONAL 5511 } 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543Yu Expires: Mar 2005 [Page 99] 5544 5545Internet-Draft rfc1510ter-01 15 Sep 2005 5546 5547 -- 5548 -- *** Error codes 5549 -- 5550 5551 -- No error 5552 kdc-err-none ErrCode ::= 0 5553 -- Client's entry in database has expired 5554 kdc-err-name-exp ErrCode ::= 1 5555 -- Server's entry in database has expired 5556 kdc-err-service-exp ErrCode ::= 2 5557 -- Requested protocol version number not supported 5558 kdc-err-bad-pvno ErrCode ::= 3 5559 -- Client's key encrypted in old master key 5560 kdc-err-c-old-mast-kvno ErrCode ::= 4 5561 -- Server's key encrypted in old master key 5562 kdc-err-s-old-mast-kvno ErrCode ::= 5 5563 -- Client not found in Kerberos database 5564 kdc-err-c-principal-unknown ErrCode ::= 6 5565 -- Server not found in Kerberos database 5566 kdc-err-s-principal-unknown ErrCode ::= 7 5567 -- Multiple principal entries in database 5568 kdc-err-principal-not-unique ErrCode ::= 8 5569 -- The client or server has a null key 5570 kdc-err-null-key ErrCode ::= 9 5571 -- Ticket not eligible for postdating 5572 kdc-err-cannot-postdate ErrCode ::= 10 5573 -- Requested start time is later than end time 5574 kdc-err-never-valid ErrCode ::= 11 5575 -- KDC policy rejects request 5576 kdc-err-policy ErrCode ::= 12 5577 -- KDC cannot accommodate requested option 5578 kdc-err-badoption ErrCode ::= 13 5579 -- KDC has no support for encryption type 5580 kdc-err-etype-nosupp ErrCode ::= 14 5581 -- KDC has no support for checksum type 5582 kdc-err-sumtype-nosupp ErrCode ::= 15 5583 -- KDC has no support for padata type 5584 kdc-err-padata-type-nosupp ErrCode ::= 16 5585 -- KDC has no support for transited type 5586 kdc-err-trtype-nosupp ErrCode ::= 17 5587 -- Clients credentials have been revoked 5588 kdc-err-client-revoked ErrCode ::= 18 5589 -- Credentials for server have been revoked 5590 kdc-err-service-revoked ErrCode ::= 19 5591 -- TGT has been revoked 5592 kdc-err-tgt-revoked ErrCode ::= 20 5593 5594 5595 5596 5597 5598 5599Yu Expires: Mar 2005 [Page 100] 5600 5601Internet-Draft rfc1510ter-01 15 Sep 2005 5602 5603 -- Client not yet valid - try again later 5604 kdc-err-client-notyet ErrCode ::= 21 5605 -- Server not yet valid - try again later 5606 kdc-err-service-notyet ErrCode ::= 22 5607 -- Password has expired - change password to reset 5608 kdc-err-key-expired ErrCode ::= 23 5609 -- Pre-authentication information was invalid 5610 kdc-err-preauth-failed ErrCode ::= 24 5611 -- Additional pre-authenticationrequired 5612 kdc-err-preauth-required ErrCode ::= 25 5613 -- Requested server and ticket don't match 5614 kdc-err-server-nomatch ErrCode ::= 26 5615 -- Server principal valid for user2user only 5616 kdc-err-must-use-user2user ErrCode ::= 27 5617 -- KDC Policy rejects transited path 5618 kdc-err-path-not-accpeted ErrCode ::= 28 5619 -- A service is not available 5620 kdc-err-svc-unavailable ErrCode ::= 29 5621 -- Integrity check on decrypted field failed 5622 krb-ap-err-bad-integrity ErrCode ::= 31 5623 -- Ticket expired 5624 krb-ap-err-tkt-expired ErrCode ::= 32 5625 -- Ticket not yet valid 5626 krb-ap-err-tkt-nyv ErrCode ::= 33 5627 -- Request is a replay 5628 krb-ap-err-repeat ErrCode ::= 34 5629 -- The ticket isn't for us 5630 krb-ap-err-not-us ErrCode ::= 35 5631 -- Ticket and authenticator don't match 5632 krb-ap-err-badmatch ErrCode ::= 36 5633 -- Clock skew too great 5634 krb-ap-err-skew ErrCode ::= 37 5635 -- Incorrect net address 5636 krb-ap-err-badaddr ErrCode ::= 38 5637 -- Protocol version mismatch 5638 krb-ap-err-badversion ErrCode ::= 39 5639 -- Invalid msg type 5640 krb-ap-err-msg-type ErrCode ::= 40 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655Yu Expires: Mar 2005 [Page 101] 5656 5657Internet-Draft rfc1510ter-01 15 Sep 2005 5658 5659 -- Message stream modified 5660 krb-ap-err-modified ErrCode ::= 41 5661 -- Message out of order 5662 krb-ap-err-badorder ErrCode ::= 42 5663 -- Specified version of key is not available 5664 krb-ap-err-badkeyver ErrCode ::= 44 5665 -- Service key not available 5666 krb-ap-err-nokey ErrCode ::= 45 5667 -- Mutual authentication failed 5668 krb-ap-err-mut-fail ErrCode ::= 46 5669 -- Incorrect message direction 5670 krb-ap-err-baddirection ErrCode ::= 47 5671 -- Alternative authentication method required 5672 krb-ap-err-method ErrCode ::= 48 5673 -- Incorrect sequence number in message 5674 krb-ap-err-badseq ErrCode ::= 49 5675 -- Inappropriate type of checksum in message 5676 krb-ap-err-inapp-cksum ErrCode ::= 50 5677 -- Policy rejects transited path 5678 krb-ap-path-not-accepted ErrCode ::= 51 5679 -- Response too big for UDP, retry with TCP 5680 krb-err-response-too-big ErrCode ::= 52 5681 -- Generic error (description in e-text) 5682 krb-err-generic ErrCode ::= 60 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711Yu Expires: Mar 2005 [Page 102] 5712 5713Internet-Draft rfc1510ter-01 15 Sep 2005 5714 5715 -- Field is too long for this implementation 5716 krb-err-field-toolong ErrCode ::= 61 5717 -- Reserved for PKINIT 5718 kdc-error-client-not-trusted ErrCode ::= 62 5719 -- Reserved for PKINIT 5720 kdc-error-kdc-not-trusted ErrCode ::= 63 5721 -- Reserved for PKINIT 5722 kdc-error-invalid-sig ErrCode ::= 64 5723 -- Reserved for PKINIT 5724 kdc-err-key-too-weak ErrCode ::= 65 5725 -- Reserved for PKINIT 5726 kdc-err-certificate-mismatch ErrCode ::= 66 5727 -- No TGT available to validate USER-TO-USER 5728 krb-ap-err-no-tgt ErrCode ::= 67 5729 -- USER-TO-USER TGT issued different KDC 5730 kdc-err-wrong-realm ErrCode ::= 68 5731 -- Ticket must be for USER-TO-USER 5732 krb-ap-err-user-to-user-required ErrCode ::= 69 5733 -- Reserved for PKINIT 5734 kdc-err-cant-verify-certificate ErrCode ::= 70 5735 -- Reserved for PKINIT 5736 kdc-err-invalid-certificate ErrCode ::= 71 5737 -- Reserved for PKINIT 5738 kdc-err-revoked-certificate ErrCode ::= 72 5739 -- Reserved for PKINIT 5740 kdc-err-revocation-status-unknown ErrCode ::= 73 5741 -- Reserved for PKINIT 5742 kdc-err-revocation-status-unavailable ErrCode ::= 74 5743 5744 5745 END 5746 5747 5748B. Kerberos and Character Encodings (Informative) 5749 5750 [adapted from KCLAR 5.2.1] 5751 5752 The original specification of the Kerberos protocol in RFC 1510 uses 5753 GeneralString in numerous places for human-readable string data. 5754 Historical implementations of Kerberos cannot utilize the full power 5755 of GeneralString. This ASN.1 type requires the use of designation 5756 and invocation escape sequences as specified in ISO 2022 | ECMA-35 5757 [ISO2022] to switch character sets, and the default character set 5758 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] 5759 International Reference Version (IRV) (aka U.S. ASCII), which mostly 5760 works. 5761 5762 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3) 5763 and two Control-function code elements (C0..C1). DER previously 5764 [X690-1997] prohibited the designation of character sets as any but 5765 the G0 and C0 sets. This had the side effect of prohibiting the use 5766 5767Yu Expires: Mar 2005 [Page 103] 5768 5769Internet-Draft rfc1510ter-01 15 Sep 2005 5770 5771 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any 5772 other character-sets that utilize a 96-character set, since it is 5773 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code 5774 element. Recent revisions to the ASN.1 standards resolve this 5775 contradiction. 5776 5777 In practice, many implementations treat RFC 1510 GeneralStrings as if 5778 they were 8-bit strings of whichever character set the implementation 5779 defaults to, without regard for correct usage of character-set 5780 designation escape sequences. The default character set is often 5781 determined by the current user's operating system dependent locale. 5782 At least one major implementation places unescaped UTF-8 encoded 5783 Unicode characters in the GeneralString. This failure to conform to 5784 the GeneralString specifications results in interoperability issues 5785 when conflicting character encodings are utilized by the Kerberos 5786 clients, services, and KDC. 5787 5788 This unfortunate situation is the result of improper documentation of 5789 the restrictions of the ASN.1 GeneralString type in prior Kerberos 5790 specifications. 5791 5792 [the following should probably be rewritten and moved into the 5793 principal name section] 5794 5795 For compatibility, implementations MAY choose to accept GeneralString 5796 values that contain characters other than those permitted by 5797 IA5String, but they should be aware that character set designation 5798 codes will likely be absent, and that the encoding should probably be 5799 treated as locale-specific in almost every way. Implementations MAY 5800 also choose to emit GeneralString values that are beyond those 5801 permitted by IA5String, but should be aware that doing so is 5802 extraordinarily risky from an interoperability perspective. 5803 5804 Some existing implementations use GeneralString to encode unescaped 5805 locale-specific characters. This is a violation of the ASN.1 5806 standard. Most of these implementations encode US-ASCII in the left- 5807 hand half, so as long the implementation transmits only US-ASCII, the 5808 ASN.1 standard is not violated in this regard. As soon as such an 5809 implementation encodes unescaped locale-specific characters with the 5810 high bit set, it violates the ASN.1 standard. 5811 5812 Other implementations have been known to use GeneralString to contain 5813 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 5814 is a different encoding, not a 94 or 96 character "G" set as defined 5815 by ISO 2022. It is believed that these implementations do not even 5816 use the ISO 2022 escape sequence to change the character encoding. 5817 Even if implementations were to announce the change of encoding by 5818 using that escape sequence, the ASN.1 standard prohibits the use of 5819 any escape sequences other than those used to designate/invoke "G" or 5820 "C" sets allowed by GeneralString. 5821 5822 5823Yu Expires: Mar 2005 [Page 104] 5824 5825Internet-Draft rfc1510ter-01 15 Sep 2005 5826 5827C. Kerberos History (Informative) 5828 5829 [Adapted from KCLAR "BACKGROUND"] 5830 5831 The Kerberos model is based in part on Needham and Schroeder's 5832 trusted third-party authentication protocol [NS78] and on 5833 modifications suggested by Denning and Sacco [DS81]. The original 5834 design and implementation of Kerberos Versions 1 through 4 was the 5835 work of two former Project Athena staff members, Steve Miller of 5836 Digital Equipment Corporation and Clifford Neuman (now at the 5837 Information Sciences Institute of the University of Southern 5838 California), along with Jerome Saltzer, Technical Director of Project 5839 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 5840 members of Project Athena have also contributed to the work on 5841 Kerberos. 5842 5843 Version 5 of the Kerberos protocol (described in this document) has 5844 evolved from Version 4 based on new requirements and desires for 5845 features not available in Version 4. The design of Version 5 of the 5846 Kerberos protocol was led by Clifford Neuman and John Kohl with much 5847 input from the community. The development of the MIT reference 5848 implementation was led at MIT by John Kohl and Theodore Ts'o, with 5849 help and contributed code from many others. Since RFC1510 was 5850 issued, extensions and revisions to the protocol have been proposed 5851 by many individuals. Some of these proposals are reflected in this 5852 document. Where such changes involved significant effort, the 5853 document cites the contribution of the proposer. 5854 5855 Reference implementations of both version 4 and version 5 of Kerberos 5856 are publicly available and commercial implementations have been 5857 developed and are widely used. Details on the differences between 5858 Kerberos Versions 4 and 5 can be found in [KNT94]. 5859 5860D. Notational Differences from [KCLAR] 5861 5862 [ possible point for discussion ] 5863 5864 [KCLAR] uses notational conventions slightly different from this 5865 document. As a derivative of RFC 1510, the text of [KCLAR] uses C- 5866 language style identifier names for defined values. In ASN.1 5867 notation, identifiers referencing defined values must begin with a 5868 lowercase letter and contain hyphen (-) characters rather than 5869 underscore (_) characters, while identifiers referencing types begin 5870 with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase 5871 identifiers with underscores to identify defined values. This has 5872 the potential to create confusion, but neither document defines 5873 values using actual ASN.1 value-assignment notation. 5874 5875 It is debatable whether it is advantageous to write all identifier 5876 names (regardless of their ASN.1 token type) in all-uppercase letters 5877 for the purpose of emphasis in running text. The alternative is to 5878 5879Yu Expires: Mar 2005 [Page 105] 5880 5881Internet-Draft rfc1510ter-01 15 Sep 2005 5882 5883 use double-quote characters (") when ambiguity is possible. 5884 5885Normative References 5886 5887 [ISO646] 5888 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. 5889 5890 [ISO2022] 5891 "Information technology -- Character code structure and 5892 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. 5893 5894 [KCRYPTO] 5895 K. Raeburn, "Encryption and Checksum Specifications for Kerberos 5896 5", draft-ietf-krb-wg-crypto-07.txt, work in progress. 5897 5898 [RFC2119] 5899 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate 5900 Requirement Levels", March 1997. 5901 5902 [RFC3660] 5903 H. Alvestrand, "Tags for the Identification of Languages", 5904 RFC 3660, January 2001. 5905 5906 [SASLPREP] 5907 Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names 5908 and passwords", draft-ietf-sasl-saslprep-10.txt, work in 5909 progress. 5910 5911 [X680] 5912 "Information technology -- Abstract Syntax Notation One (ASN.1): 5913 Specification of basic notation", ITU-T Recommendation X.680 5914 (2002) | ISO/IEC 8824-1:2002. 5915 5916 [X682] 5917 "Information technology -- Abstract Syntax Notation One (ASN.1): 5918 Constraint specification", ITU-T Recommendation X.682 (2002) | 5919 ISO/IEC 8824-3:2002. 5920 5921 [X683] 5922 "Information technology -- Abstract Syntax Notation One (ASN.1): 5923 Parameterization of ASN.1 specifications", ITU-T Recommendation 5924 X.683 (2002) | ISO/IEC 8824-4:2002. 5925 5926 [X690] 5927 "Information technology -- ASN.1 encoding Rules: Specification 5928 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 5929 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 5930 X.690 (2002) | ISO/IEC 8825-1:2002. 5931 5932 5933 5934 5935Yu Expires: Mar 2005 [Page 106] 5936 5937Internet-Draft rfc1510ter-01 15 Sep 2005 5938 5939Informative References 5940 5941 [DS81] 5942 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 5943 Distribution Protocols," Communications of the ACM, Vol. 24(8), 5944 pp. 533-536 (August 1981). 5945 5946 [Dub00] 5947 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous 5948 Systems", Elsevier-Morgan Kaufmann, 2000. 5949 <http://www.oss.com/asn1/dubuisson.html> 5950 5951 [ISO8859-1] 5952 "Information technology -- 8-bit single-byte coded graphic 5953 character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859- 5954 1:1998. 5955 5956 [KCLAR] 5957 Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos 5958 Network Authentication Service (V5)", draft-ietf-krb-wg- 5959 kerberos-clarifications-07.txt, work in progress. 5960 5961 [KNT94] 5962 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 5963 Evolution of the Kerberos Authentication System". In 5964 Distributed Open Systems, pages 78-94. IEEE Computer Society 5965 Press, 1994. 5966 5967 [Lar96] 5968 John Larmouth, "Understanding OSI", International Thomson 5969 Computer Press, 1996. 5970 <http://www.isi.salford.ac.uk/books/osi.html> 5971 5972 [Lar99] 5973 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann, 5974 1999. <http://www.oss.com/asn1/larmouth.html> 5975 5976 [NS78] 5977 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5978 Authentication in Large Networks of Computers", Communications 5979 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5980 5981 [RFC1510] 5982 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication 5983 Service (v5)", RFC1510, September 1993, Status: Proposed 5984 Standard. 5985 5986 [RFC1964] 5987 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 5988 June 1996, Status: Proposed Standard. 5989 5990 5991Yu Expires: Mar 2005 [Page 107] 5992 5993Internet-Draft rfc1510ter-01 15 Sep 2005 5994 5995 [X690-2002] 5996 "Information technology -- ASN.1 encoding rules: Specification 5997 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 5998 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 5999 X.690 (2002) | ISO/IEC 8825-1:2002. 6000 6001Author's Address 6002 6003 Tom Yu 6004 77 Massachusetts Ave 6005 Cambridge, MA 02139 6006 USA 6007 tlyu@mit.edu 6008 6009Copyright Statement 6010 6011 Copyright (C) The Internet Society (2005). This document is subject 6012 to the rights, licenses and restrictions contained in BCP 78, and 6013 except as set forth therein, the authors retain all their rights. 6014 6015 This document and the information contained herein are provided on an 6016 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6017 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 6018 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 6019 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 6020 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6021 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6022 6023Intellectual Property Statement 6024 6025 The IETF takes no position regarding the validity or scope of any 6026 Intellectual Property Rights or other rights that might be claimed to 6027 pertain to the implementation or use of the technology described in 6028 this document or the extent to which any license under such rights 6029 might or might not be available; nor does it represent that it has 6030 made any independent effort to identify any such rights. Information 6031 on the procedures with respect to rights in RFC documents can be 6032 found in BCP 78 and BCP 79. 6033 6034 Copies of IPR disclosures made to the IETF Secretariat and any 6035 assurances of licenses to be made available, or the result of an 6036 attempt made to obtain a general license or permission for the use of 6037 such proprietary rights by implementers or users of this 6038 specification can be obtained from the IETF on-line IPR repository at 6039 http://www.ietf.org/ipr. 6040 6041 The IETF invites any interested party to bring to its attention any 6042 copyrights, patents or patent applications, or other proprietary 6043 rights that may cover technology that may be required to implement 6044 this standard. Please address the information to the IETF at ietf- 6045 ipr@ietf.org. 6046 6047Yu Expires: Mar 2005 [Page 108] 6048 6049 6050