1INTERNET-DRAFT Tom Yu 2draft-yu-krb-wg-kerberos-extensions-01.txt MIT 3Expires: 19 Jan 2005 19 July 2004 4 5 6 The Kerberos Network Authentication Service (Version 5) 7 8 9Status of This Memo 10 11 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 16 17 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 22 23 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 28 29 30 The list of current Internet-Drafts can be accessed at 31 32 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 35 36 The list of Internet-Draft Shadow Directories can be accessed at 37 38 39 http://www.ietf.org/shadow.html 40 41 42 43Copyright Notice 44 45 46 Copyright (C) The Internet Society (2004). All Rights Reserved. 47 48 49Abstract 50 51 52 This document describes version 5 of the Kerberos network 53 authentication protocol. It describes changes to the protocol which 54 allow for extensions to be made to the protocol without creating 55 interoperability problems. 56 57 58Key Words for Requirements 59 60 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 63 to be interpreted as described in RFC 2119. 64 65 66 67 68 69Yu Expires: Jan 2005 [Page 1] 70Internet-Draft yu-krb-extensions-01 19 Jul 2004 71 72 73Table of Contents 74 75 76 Status of This Memo ....................................... 1 77 Copyright Notice .......................................... 1 78 Abstract .................................................. 1 79 Key Words for Requirements ................................ 1 80 Table of Contents ......................................... 2 81 1. Introduction .......................................... 4 82 1.1. Kerberos Protocol Overview .......................... 4 83 1.2. Overview of Document ................................ 5 84 2. Extensibility ......................................... 5 85 3. Backwards Compatibility ............................... 6 86 4. Criticality ........................................... 6 87 5. Use of ASN.1 in Kerberos .............................. 6 88 5.1. Module Header ....................................... 7 89 5.2. Top-Level Type ...................................... 7 90 5.3. Previously Unused ASN.1 Notation .................... 8 91 5.3.1. Parameterized Types ............................... 8 92 5.3.2. COMPONENTS OF Notation ............................ 8 93 5.3.3. Constraints ....................................... 8 94 5.4. New Types ........................................... 9 95 6. Basic Types ........................................... 10 96 6.1. Constrained Integer Types ........................... 10 97 6.2. KerberosTime ........................................ 11 98 6.3. KerberosString ...................................... 11 99 7. Principals ............................................ 11 100 7.1. Name Types .......................................... 12 101 7.2. Principal Type Definition ........................... 12 102 7.3. Principal Name Reuse ................................ 13 103 7.4. Realm Names ......................................... 13 104 7.5. Printable Representations of Principal Names ........ 13 105 7.6. Ticket-Granting Service Principal ................... 13 106 7.6.1. Cross-Realm TGS Principals ........................ 14 107 8. Types Relating to Encryption .......................... 14 108 8.1. Assigned Numbers for Encryption ..................... 14 109 8.1.1. EType ............................................. 14 110 8.1.2. Key Usages ........................................ 15 111 8.2. Which Key to Use .................................... 16 112 8.3. EncryptionKey ....................................... 17 113 8.4. EncryptedData ....................................... 17 114 8.5. Checksums ........................................... 18 115 8.5.1. ChecksumOf ........................................ 19 116 8.5.2. Signed ............................................ 20 117 9. Tickets ............................................... 20 118 9.1. Timestamps .......................................... 21 119 9.2. Ticket Flags ........................................ 21 120 9.2.1. Flags Relating to Initial Ticket Acquisition ...... 22 121 9.2.2. Invalid Tickets ................................... 22 122 9.2.3. OK as Delegate .................................... 23 123 9.3. Renewable Tickets ................................... 23 124 9.4. Postdated Tickets ................................... 24 125 126 127Yu Expires: Jan 2005 [Page 2] 128Internet-Draft yu-krb-extensions-01 19 Jul 2004 129 130 131 9.5. Proxiable and Proxy Tickets ......................... 25 132 9.6. Forwardable Tickets ................................. 26 133 9.7. Transited Realms .................................... 27 134 9.8. Authorization Data .................................. 27 135 9.9. Encrypted Part of Ticket ............................ 27 136 9.10. Cleartext Part of Ticket ........................... 28 137 10. Credential Acquisition ............................... 28 138 10.1. KDC-REQ ............................................ 29 139 10.2. PA-DATA ............................................ 31 140 10.3. KDC-REQ Processing ................................. 31 141 10.3.1. Handling Replays ................................. 31 142 10.3.2. Request Validation ............................... 32 143 10.3.2.1. AS-REQ Authentication .......................... 32 144 10.3.2.2. TGS-REQ Authentication ......................... 32 145 10.3.2.3. Principal Validation ........................... 32 146 10.3.2.4. Checking For Revoked or Invalid Tickets ........ 32 147 10.3.3. Timestamp Handling ............................... 33 148 10.3.3.1. AS-REQ Timestamp Processing .................... 33 149 10.3.3.2. TGS-REQ Timestamp Processing ................... 34 150 10.3.4. Handling Transited Realms ........................ 35 151 10.3.5. Address Processing ............................... 35 152 10.3.6. Ticket Flag Processing ........................... 35 153 10.3.7. Key Selection .................................... 36 154 10.3.7.1. Reply Key and Session Key Selection ............ 37 155 10.3.7.2. Ticket Key Selection ........................... 37 156 10.4. Reply Validation ................................... 37 157 11. Session Key Exchange ................................. 37 158 11.1. AP-REQ ............................................. 37 159 11.2. AP-REP ............................................. 40 160 12. Session Key Use ...................................... 41 161 12.1. KRB-SAFE ........................................... 41 162 12.2. KRB-PRIV ........................................... 42 163 12.3. KRB-CRED ........................................... 42 164 13. Security Considerations .............................. 43 165 13.1. Time Synchronization ............................... 43 166 13.2. Replays ............................................ 44 167 13.3. Principal Name Reuse ............................... 44 168 13.4. Password Guessing .................................. 44 169 13.5. Forward Secrecy .................................... 44 170 13.6. Authorization ...................................... 44 171 13.7. Login Authentication ............................... 44 172 14. Acknowledgments ...................................... 45 173 Appendices ................................................ 45 174 A. ASN.1 Module (Normative) .............................. 45 175 B. Kerberos and Character Encodings (Informative) ........ 76 176 C. Kerberos History (Informative) ........................ 77 177 D. Notational Differences from [KCLAR] ................... 78 178 Normative References ...................................... 79 179 Informative References .................................... 79 180 Author's Address .......................................... 80 181 Full Copyright Statement .................................. 80 182 183 184Yu Expires: Jan 2005 [Page 3] 185Internet-Draft yu-krb-extensions-01 19 Jul 2004 186 187 1881. Introduction 189 190 191 The Kerberos network authentication protocol is a trusted third-party 192 protocol utilizing symmetric-key cryptography. It assumes that all 193 communications between parties in the protocol may be arbitrarily 194 tampered with or monitored, and that the security of the overall 195 system depends only on the effectiveness of the cryptographic 196 techniques and the secrecy of the keys used. The protocol 197 authenticates an application client's identity to an application 198 server, and likewise authenticates the application server's identity 199 to the application client. These assurances are made possible by the 200 client and the server sharing secrets with the trusted third party: 201 the Kerberos server, also known as the Key Distribution Center (KDC). 202 In addition, the protocol establishes an ephemeral shared secret (the 203 session key) between the client and the server, allowing the 204 protection of further communications between them. 205 206 2071.1. Kerberos Protocol Overview 208 209 210 Kerberos comprises three main sub-protocols: credentials acquisition, 211 session key exchange, and session key usage. A client acquires 212 credentials by asking the KDC for a credential for a service; the KDC 213 issues the credential, which contains a ticket and a session key. 214 The ticket, containing the client's identity, timestamps, expiration 215 time, and a session key, is a encrypted in a key known to the 216 application server. The KDC encrypts the credential using a key 217 known to the client, and transmits the credential to the client. 218 219 220 There are two means of requesting credentials: the Authentication 221 Service (AS) exchange, and the Ticket-Granting Service (TGS) 222 exchange. In the typical AS exchange, a client uses a password- 223 derived key to decrypt the response. In the TGS exchange, the KDC 224 behaves as an application, which the client authenticates to using a 225 Ticket-Granting Ticket (TGT). The client usually obtains the TGT by 226 using the AS exchange. 227 228 229 Session key exchange consists of the client transmitting the ticket 230 to the application server, accompanied by an authenticator. The 231 authenticator contains a timestamp and additional data encrypted 232 using the ticket's session key. The application server decrypts the 233 ticket, extracting the session key. The application server then uses 234 the session key to decrypt the authenticator. Upon successful 235 decryption of the authenticator, the application server knows that 236 the data in the authenticator were sent by the client named in the 237 associated ticket. Additionally, since authenticators expire more 238 quickly than tickets, the application server has some assurance that 239 the transaction is not a replay. The application server may send an 240 encrypted acknowledgment to the client, verifying its identity to the 241 client. 242 243 244 245 246Yu Expires: Jan 2005 [Page 4] 247Internet-Draft yu-krb-extensions-01 19 Jul 2004 248 249 250 Once session key exchange has occurred, the client and server may use 251 the established session key to protect further traffic. This 252 protection may consist of protection of integrity only, or of 253 protection of confidentiality and integrity. Additional measures 254 exist for a client to securely forward credentials to a server. 255 256 257 The entire scheme depends on loosely synchronized clocks. 258 Synchronization of the clock on the KDC with the application server 259 clock allows the application server to accurately determine whether a 260 credential is expired. Likewise, synchronization of the clock on the 261 client with the application server clock prevents replay attacks 262 utilizing the same credential. Careful design of the application 263 protocol may allow replay prevention without requiring client-server 264 clock synchronization. 265 266 267 After establishing a session key, application client and the 268 application server can exchange Kerberos protocol messages that use 269 the session key to protect the integrity or confidentiality of 270 communications between the client and the server. Additionally, the 271 client may forward credentials to the application server. 272 273 274 The credentials acquisition protocol takes place over specific, 275 defined transports (UDP and TCP). Application protocols define which 276 transport to use for the session key establishment protocol and for 277 messages using the session key; the application may choose to perform 278 its own encapsulation of the Kerberos messages, for example. 279 280 2811.2. Overview of Document 282 283 284 The remainder of this document begins by describing the general 285 frameworks for protocol extensibility, including whether to interpret 286 unknown extensions as critical. It then defines the protocol 287 messages and exchanges. 288 289 290 The definition of the Kerberos protocol uses Abstract Syntax Notation 291 One (ASN.1) [X680], which specifies notation for describing the 292 abstract content of protocol messages. This document defines a 293 number of base types using ASN.1; these base types subsequently 294 appear in multiple types which define actual protocol messages. 295 Definitions of principal names and of tickets, which are central to 296 the protocol, also appear preceding the protocol message definitions. 297 298 2992. Extensibility 300 301 302 As originally defined in RFC 1510, the Kerberos protocol does not 303 readily allow for backwards-compatible extensions to the protocol. 304 Various proposals to extend the Kerberos protocol have appeared since 305 RFC 1510, many of them creating problems for backwards compatibility. 306 This document adopts the technique of creating new extensible types 307 which encode to messages which are very similar to RFC 1510 messages 308 on the wire. This similarity allows implementors to use shared code 309 310 311Yu Expires: Jan 2005 [Page 5] 312Internet-Draft yu-krb-extensions-01 19 Jul 2004 313 314 315 paths for encoding and decoding both new and old messages. 316 317 318 The protocol defined in RFC 1510 already contains some elements 319 allowing for limited backwards-compatible extensions to the protocol. 320 Most of these elements consist of "typed holes"; these are octet 321 strings having associated assigned numbers indicating the intended 322 interpretation of the octet string. This document typed holes to 323 some types which have previously lacked typed holes. This document 324 also describes procedures for the IETF to use the extensibility model 325 of ASN.1 to make further backwards-compatible extensions of the 326 Kerberos protocol, if typed holes prove inadequate for some desired 327 extension. 328 329 3303. Backwards Compatibility 331 332 333 This document describes two sets (for the most part) of ASN.1 types. 334 The first set of types is wire-encoding compatible with RFC 1510 and 335 [KCLAR]. The second set of types is the set of types enabling 336 extensibility. This second set may be referred to as "extensibility- 337 enabled types". [ need to make this consistent throughout? ] 338 339 340 A major difference between the new extensibility-enabled types and 341 the types for RFC 1510 compatibility is that the extensibility- 342 enabled types allow for the use of UTF-8 encodings in various 343 character strings in the protocol. Each party in the protocol must 344 have some knowledge of the capabilities of the other parties in the 345 protocol. There are methods for establishing this knowledge without 346 necessarily requiring explicit configuration. 347 348 349 An extensibility-enabled client can detect whether a KDC supports the 350 extensibility-enabled types by requesting an extensibility-enabled 351 reply. If the KDC replies with an extensibility-enabled reply, the 352 client knows that the KDC supports extensibility. If the KDC issues 353 an extensibility-enabled ticket, the client knows that the service 354 named in the ticket is extensibility-enabled. 355 356 3574. Criticality 358 359 360 In general, implementations SHOULD treat unknown extension, flags, 361 etc. as non-critical; i.e., they should ignore them when they do not 362 understand them. Exceptions are clearly marked. An implementation 363 SHOULD NOT reject a request merely because it does not understand 364 some element of the request. As a related consequence, 365 implementations SHOULD handle talking to other implementations which 366 do not implement some requested options. This may require designers 367 of extensions or options to provide means to detect whether 368 extensions or options are rejected, or whether such extensions or 369 options are merely not understood, or whether such extensions or 370 options are (perhaps maliciously) deleted or modified in transit. 371 372 373 374 375Yu Expires: Jan 2005 [Page 6] 376Internet-Draft yu-krb-extensions-01 19 Jul 2004 377 378 3795. Use of ASN.1 in Kerberos 380 381 382 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. 383 Even though ASN.1 theoretically allows the description of protocol 384 messages to be independent of the encoding rules used to encode the 385 messages, Kerberos messages MUST be encoded with DER. Subtleties in 386 the semantics of the notation, such as whether tags carry any 387 semantic content to the application, may cause the use of other ASN.1 388 encoding rules to be problematic. 389 390 391 Implementors not using existing ASN.1 tools (e.g., compilers or 392 support libraries) are cautioned to thoroughly read and understand 393 the actual ASN.1 specification to ensure correct implementation 394 behavior. There is more complexity in the notation than is 395 immediately obvious, and some tutorials and guides to ASN.1 are 396 misleading or erroneous. Recommended tutorials and guides include 397 [Dub00], [Lar99], though there is still no substitute for reading the 398 actual ASN.1 specification. 399 400 4015.1. Module Header 402 403 404 The type definitions in this document assume an ASN.1 module 405 definition of the following form: 406 407 408 KerberosV5Spec3 { 409 iso(1) identified-organization(3) dod(6) internet(1) 410 security(5) kerberosV5(2) modules(4) krb5spec3(4) 411 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 412 413 414 -- Rest of definitions here 415 416 417 END 418 419 420 This specifies that the tagging context for the module will be 421 explicit and that automatic tagging is not done. 422 423 424 Some other publications [RFC1510] [RFC1964] erroneously specify an 425 object identifier (OID) having an incorrect value of "5" for the 426 "dod" component of the OID. In the case of RFC 1964, use of the 427 "correct" OID value would result in a change in the wire protocol; 428 therefore, the RFC 1964 OID remains unchanged for now. 429 430 4315.2. Top-Level Type 432 433 434 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol 435 Data Units or PDUs) which an application may directly reference. 436 Applications SHOULD NOT transmit any types other than those which are 437 alternatives of the KRB-PDU CHOICE. 438 439 440 441 442 443Yu Expires: Jan 2005 [Page 7] 444Internet-Draft yu-krb-extensions-01 19 Jul 2004 445 446 447 -- top-level type 448 -- 449 -- Applications should not directly reference any types 450 -- other than KRB-PDU and its component types. 451 -- 452 KRB-PDU ::= CHOICE { 453 ticket Ticket, 454 as-req AS-REQ, 455 as-rep AS-REP, 456 tgs-req TGS-REQ, 457 tgs-rep TGS-REP, 458 ap-req AP-REQ, 459 ap-rep AP-REP, 460 krb-safe KRB-SAFE, 461 krb-priv KRB-PRIV, 462 krb-cred KRB-CRED, 463 tgt-req TGT-REQ, 464 krb-error KRB-ERROR, 465 ... 466 } 467 468 469 4705.3. Previously Unused ASN.1 Notation 471 472 473 Some aspects of ASN.1 notation used in this document were not used in 474 [KCLAR], and may be unfamiliar to some readers. 475 476 4775.3.1. Parameterized Types 478 479 480 This document uses ASN.1 parameterized types [X683] to make 481 definitions of types more readable. For some types, some or all of 482 the parameters are advisory, i.e., they are not encoded in any form 483 for transmission in a protocol message. These advisory parameters 484 can describe implementation behavior associated with the type. 485 486 4875.3.2. COMPONENTS OF Notation 488 489 490 The "COMPONENTS OF" notation, used to define the RFC 1510 491 compatibility types, extracts all of the component types of an ASN.1 492 SEQUENCE type. The extension marker (the "..." notation) and any 493 extension components are not extracted by "COMPONENTS OF". The 494 "COMPONENTS OF" notation permits concise definition of multiple types 495 which have many components in common with each other. 496 497 4985.3.3. Constraints 499 500 501 This document uses ASN.1 constraints, including the 502 "UserDefinedConstraint" syntax [X682]. Some constraints can be 503 handled automatically by tools that can parse them. Uses of the 504 "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will 505 typically need to have behavior manually coded; these uses provide a 506 507 508Yu Expires: Jan 2005 [Page 8] 509Internet-Draft yu-krb-extensions-01 19 Jul 2004 510 511 512 formalized way of conveying intended implementation behavior. 513 514 515 The "WITH COMPONENTS" constraint notation allows constraints to apply 516 to component types of a SEQUENCE type. This constraint notation 517 effectively allows constraints to "reach into" a type to constrain 518 its component types. 519 520 5215.4. New Types 522 523 524 This document defines a number of ASN.1 types which are new since 525 RFC 1510. The names of these types will typically have a suffix like 526 "Ext", indicating that the types are intended to support 527 extensibility. Types original to RFC 1510 have been renamed to have 528 a suffix like "1510". The "Ext" and "1510" types often contain a 529 number of common elements; these common elements have a suffix like 530 "Common". The "1510" types have various ASN.1 constraints applied to 531 them; the constraints limit the possible values of the "1510" types 532 to those permitted by RFC 1510 or by [KCLAR]. The "Ext" types may 533 have different constraints, typically to force string values to be 534 sent as UTF-8. 535 536 537 For example, consider 538 539 540 -- example "common" type 541 Foo-Common ::= SEQUENCE { 542 a [0] INTEGER, 543 b [1] OCTET STRING, 544 ..., 545 c [2] INTEGER, 546 ... 547 } 548 549 550 -- example "RFC 1510 compatibility" type 551 Foo-1510 ::= SEQUENCE { 552 -- the COMPONENTS OF notation drops the extension marker 553 -- and all extension additions. 554 COMPONENTS OF Foo-Common 555 } 556 557 558 -- example "extensibility-enabled" type 559 Foo-Ext ::= Foo-Common 560 561 562 where "Foo-Common" is a common type used to define both the "1510" 563 and "Ext" versions of a type. "Foo-1510" is the RFC 1510 version of 564 the type, while "Foo-Ext" is the extensible version. "Foo-1510" does 565 not contain the extension marker, nor does it contain the extension 566 component "c". The type "Foo-1510" is equivalent to 567 "Foo-1510-Equiv", shown below. 568 569 570 571 572 573Yu Expires: Jan 2005 [Page 9] 574Internet-Draft yu-krb-extensions-01 19 Jul 2004 575 576 577 -- example type equivalent to Foo-1510 578 Foo-1510-Equiv ::= SEQUENCE { 579 a [0] INTEGER, 580 b [1] OCTET STRING 581 } 582 583 584 5856. Basic Types 586 587 588 Certain ASN.1 types in Kerberos appear repeatedly in other Kerberos 589 types. 590 591 5926.1. Constrained Integer Types 593 594 595 In RFC 1510, many types contained references to the unconstrained 596 INTEGER type. Since an unconstrained INTEGER may contain any 597 possible abstract integer value, most of the unconstrained references 598 to INTEGER in RFC 1510 have been constrained to 32 bits or smaller. 599 600 601 -- signed values representable in 32 bits 602 -- 603 -- These are often used as assigned numbers for various things. 604 Int32 ::= INTEGER (-2147483648..2147483647) 605 606 607 -- unsigned 32 bit values 608 UInt32 ::= INTEGER (0..4294967295) 609 610 611 The "Int32" type often contains an assigned number identifying the 612 type of a protocol element. Unless otherwise stated, non-negative 613 values are registered, and negative values are available for local 614 use. 615 616 617 -- unsigned 64 bit values 618 UInt64 ::= INTEGER (0..18446744073709551615) 619 620 621 The "UInt64" type is used in places where 32 bits of precision may 622 provide inadequate security. 623 624 625 -- microseconds 626 Microseconds ::= INTEGER (0..999999) 627 628 629 630 -- sequence numbers 631 SeqNum ::= UInt64 632 633 634 635 -- nonces 636 Nonce ::= UInt64 637 638 639 While these types have different abstract types from their 640 equivalents in RFC 1510, their DER encodings remain identical. 641 642 643Yu Expires: Jan 2005 [Page 10] 644Internet-Draft yu-krb-extensions-01 19 Jul 2004 645 646 647 Nonces and sequence numbers are constrained to 32 bits in the 648 RFC 1510 backwards-compatibility types. 649 650 6516.2. KerberosTime 652 653 654 -- must not have fractional seconds 655 KerberosTime ::= GeneralizedTime 656 657 658 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 659 KerberosTime value MUST NOT include any fractional portions of the 660 seconds. As required by the DER, it further MUST NOT include any 661 separators, and it specifies the UTC time zone (Z). Example: The 662 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 663 November 1985 is "19851106210627Z". 664 665 6666.3. KerberosString 667 668 669 -- used for names and for error messages 670 KerberosString ::= CHOICE { 671 ia5 GeneralString (IA5String), 672 utf8 UTF8String, 673 ... -- no extension may be sent 674 -- to an rfc1510 implementation -- 675 } 676 677 678 The KerberosString type is used for strings in various places in the 679 Kerberos protocol. For compatibility with RFC 1510, GeneralString 680 values constrained to IA5String (US-ASCII) are permitted in messages 681 exchanged with RFC 1510 implementations. The new protocol messages 682 contain strings encoded as UTF-8. KerberosString values are present 683 in principal names and in error messages. Control characters SHOULD 684 NOT be used in principal names, and used with caution in error 685 messages. 686 687 688 -- IA5 choice only; useful for constraints 689 KerberosStringIA5 ::= KerberosString 690 (WITH COMPONENTS { ia5 PRESENT }) 691 692 693 -- IA5 excluded; useful for constraints 694 KerberosStringExt ::= KerberosString 695 (WITH COMPONENTS { ia5 ABSENT }) 696 697 698 KerberosStringIA5 and KerberosStringExt respectively force and forbid 699 the use of the "ia5" alternative. These types are used as 700 constraints on other types for backwards compatibility purposes. 701 702 703 For detailed background regarding the history of character string use 704 in Kerberos, as well as discussion of some compatibility issues, see 705 Appendix B. 706 707 708 709 710Yu Expires: Jan 2005 [Page 11] 711Internet-Draft yu-krb-extensions-01 19 Jul 2004 712 713 7147. Principals 715 716 717 Principals are participants in the Kerberos protocol. A "realm" 718 consists of principals in one administrative domain, served by one 719 KDC (or one replicated set of KDCs). Each principal name has an 720 arbitrary number of components, though typical principal names will 721 only have one or two components. A principal name is meant to be 722 readable by and meaningful to humans, especially in a realm lacking a 723 centrally adminstered authorization infrastructure. 724 725 7267.1. Name Types 727 728 729 Each Principal has NameType indicating what sort of name it is. The 730 name-type SHOULD be treated as a hint. Ignoring the name type, no 731 two names can be the same (i.e., at least one of the components, or 732 the realm, must be different). 733 734 735 -- assigned numbers for name types (used in principal names) 736 NameType ::= Int32 737 738 739 -- Name type not known 740 nt-unknown NameType ::= 0 741 -- Just the name of the principal as in DCE, or for users 742 nt-principal NameType ::= 1 743 -- Service and other unique instance (krbtgt) 744 nt-srv-inst NameType ::= 2 745 -- Service with host name as instance (telnet, rcommands) 746 nt-srv-hst NameType ::= 3 747 -- Service with host as remaining components 748 nt-srv-xhst NameType ::= 4 749 -- Unique ID 750 nt-uid NameType ::= 5 751 -- Encoded X.509 Distingished name [RFC 2253] 752 nt-x500-principal NameType ::= 6 753 -- Name in form of SMTP email name (e.g. user@foo.com) 754 nt-smtp-name NameType ::= 7 755 -- Enterprise name - may be mapped to principal name 756 nt-enterprise NameType ::= 10 757 758 759 7607.2. Principal Type Definition 761 762 763 PrincipalName ::= SEQUENCE { 764 name-type [0] NameType, 765 -- May have zero elements, or individual elements may be 766 -- zero-length, but this is not recommended. 767 name-string [1] SEQUENCE OF KerberosString 768 } 769 770 771 772 773 774Yu Expires: Jan 2005 [Page 12] 775Internet-Draft yu-krb-extensions-01 19 Jul 2004 776 777 778 name-type 779 hint of the type of name that follows 780 781 782 name-string 783 The "name-string" encodes a sequence of components that form a 784 name, each component encoded as a KerberosString. Taken 785 together, a PrincipalName and a Realm form a principal 786 identifier. Most PrincipalNames will have only a few components 787 (typically one or two). 788 789 7907.3. Principal Name Reuse 791 792 793 Realm administrators SHOULD use extreme caution when considering 794 reusing a principal name. A service administrator might explicitly 795 enter principal names into a local access control list (ACL) for the 796 service. If such local ACLs exist independently of a centrally 797 administered authorization infrastructure, realm administrators 798 SHOULD NOT reuse principal names until confirming that all extant ACL 799 entries referencing that principal name have been updated. Failure 800 to perform this check can result in a security vulnerability, as a 801 new principal can inadvertently inherit unauthorized privileges upon 802 receiving a reused principal name. An organization whose Kerberos- 803 authenticated services all use a centrally-adminstered authorization 804 infrastructure may not need to take these precautions regarding 805 principal name reuse. 806 807 8087.4. Realm Names 809 810 811 Realm ::= KerberosString 812 813 814 -- IA5 only 815 RealmIA5 ::= Realm (KerberosStringIA5) 816 817 818 -- IA5 excluded 819 RealmExt ::= Realm (KerberosStringExt) 820 821 822 823 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a 824 character with the code 0 (the US-ASCII NUL). Most realms will 825 usually consist of several components separated by periods (.), in 826 the style of Internet Domain Names, or separated by slashes (/) in 827 the style of X.500 names. 828 829 8307.5. Printable Representations of Principal Names 831 832 833 [ perhaps non-normative? ] 834 835 836 The printable form of a principal name consists of the concatenation 837 of components of the PrincipalName value using the slash character 838 (/), followed by an at-sign (@), followed by the realm name. 839 840 841 842Yu Expires: Jan 2005 [Page 13] 843Internet-Draft yu-krb-extensions-01 19 Jul 2004 844 845 8467.6. Ticket-Granting Service Principal 847 848 849 The PrincipalName value corresponding to a ticket-granting service 850 has two components: the first component is the string "krbtgt", and 851 the second component is the realm name of the TGS which will accept a 852 ticket-granting ticket having this service principal name. The realm 853 name of service always indicates which realm issued the ticket. A 854 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for 855 obtaining tickets in the same realm would have the following ASN.1 856 values for its "realm" and "sname" components, respectively: 857 858 859 -- Example Realm and PrincipalName for a TGS 860 861 862 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" 863 864 865 tgtPrinc1 PrincipalName ::= { 866 name-type nt-srv-inst, 867 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } 868 } 869 870 871 Its printable representation would be written as 872 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". 873 874 8757.6.1. Cross-Realm TGS Principals 876 877 878 It is possible for a principal in one realm to authenticate to a 879 service in another realm. A KDC can issue a cross-realm ticket- 880 granting ticket to allow one of its principals to authenticate to a 881 service in a foreign realm. For example, the TGS principal 882 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a 883 client principal in the realm A.EXAMPLE.COM to authenticate to a 884 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM 885 issues a ticket to a client originating in A.EXAMPLE.COM, the 886 client's realm name remains "A.EXAMPLE.COM", even though the service 887 principal will have the realm "B.EXAMPLE.COM". 888 889 8908. Types Relating to Encryption 891 892 893 Many Kerberos protocol messages contain encryptions of various data 894 types. Kerberos protocol messages also contain checksums 895 (signatures) of various types. 896 897 8988.1. Assigned Numbers for Encryption 899 900 901 Encryption algorithm identifiers and key usages both have assigned 902 numbers, described in [KCRYPTO]. 903 904 9058.1.1. EType 906 907 908 EType is the integer type for assigned numbers for encryption 909 algorithms. Defined in [KCRYPTO]. 910 911 912Yu Expires: Jan 2005 [Page 14] 913Internet-Draft yu-krb-extensions-01 19 Jul 2004 914 915 916 -- Assigned numbers denoting encryption mechanisms. 917 EType ::= Int32 918 919 920 -- assigned numbers for encryption schemes 921 et-des-cbc-crc EType ::= 1 922 et-des-cbc-md4 EType ::= 2 923 et-des-cbc-md5 EType ::= 3 924 -- [reserved] 4 925 et-des3-cbc-md5 EType ::= 5 926 -- [reserved] 6 927 et-des3-cbc-sha1 EType ::= 7 928 et-dsaWithSHA1-CmsOID EType ::= 9 929 et-md5WithRSAEncryption-CmsOID EType ::= 10 930 et-sha1WithRSAEncryption-CmsOID EType ::= 11 931 et-rc2CBC-EnvOID EType ::= 12 932 et-rsaEncryption-EnvOID EType ::= 13 933 et-rsaES-OAEP-ENV-OID EType ::= 14 934 et-des-ede3-cbc-Env-OID EType ::= 15 935 et-des3-cbc-sha1-kd EType ::= 16 936 -- AES 937 et-aes128-cts-hmac-sha1-96 EType ::= 17 938 -- AES 939 et-aes256-cts-hmac-sha1-96 EType ::= 18 940 -- Microsoft 941 et-rc4-hmac EType ::= 23 942 -- Microsoft 943 et-rc4-hmac-exp EType ::= 24 944 -- opaque; PacketCable 945 et-subkey-keymaterial EType ::= 65 946 947 948 9498.1.2. Key Usages 950 951 952 KeyUsage is the integer type for assigned numbers for key usages. 953 Key usage values are inputs to the encryption and decryption 954 functions described in [KCRYPTO]. 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972Yu Expires: Jan 2005 [Page 15] 973Internet-Draft yu-krb-extensions-01 19 Jul 2004 974 975 976 -- Assigned numbers denoting key usages. 977 KeyUsage ::= UInt32 978 979 980 -- 981 -- Actual identifier names are provisional and subject to 982 -- change. 983 -- 984 ku-pa-enc-ts KeyUsage ::= 1 985 ku-Ticket KeyUsage ::= 2 986 ku-EncASRepPart KeyUsage ::= 3 987 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 988 ku-TGSReqAuthData-subkey KeyUsage ::= 5 989 ku-pa-TGSReq-cksum KeyUsage ::= 6 990 ku-pa-TGSReq-authenticator KeyUsage ::= 7 991 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 992 ku-EncTGSRepPart-subkey KeyUsage ::= 9 993 ku-Authenticator-cksum KeyUsage ::= 10 994 ku-APReq-authenticator KeyUsage ::= 11 995 ku-EncAPRepPart KeyUsage ::= 12 996 ku-EncKrbPrivPart KeyUsage ::= 13 997 ku-EncKrbCredPart KeyUsage ::= 14 998 ku-KrbSafe-cksum KeyUsage ::= 15 999 ku-ad-KDCIssued-cksum KeyUsage ::= 19 1000 1001 1002 1003 -- The following numbers are provisional... 1004 -- conflicts may exist elsewhere. 1005 ku-Ticket-cksum KeyUsage ::= 25 1006 ku-ASReq-cksum KeyUsage ::= 26 1007 ku-TGSReq-cksum KeyUsage ::= 27 1008 ku-ASRep-cksum KeyUsage ::= 28 1009 ku-TGSRep-cksum KeyUsage ::= 29 1010 ku-APReq-cksum KeyUsage ::= 30 1011 ku-APRep-cksum KeyUsage ::= 31 1012 ku-KrbCred-cksum KeyUsage ::= 32 1013 ku-KrbError-cksum KeyUsage ::= 33 1014 ku-KDCRep-cksum KeyUsage ::= 34 1015 1016 1017 10188.2. Which Key to Use 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032Yu Expires: Jan 2005 [Page 16] 1033Internet-Draft yu-krb-extensions-01 19 Jul 2004 1034 1035 1036 -- KeyToUse identifies which key is to be used to encrypt or 1037 -- sign a given value. 1038 -- 1039 -- Values of KeyToUse are never actually transmitted over the 1040 -- wire, or even used directly by the implementation in any 1041 -- way, as key usages are; it exists primarily to identify 1042 -- which key gets used for what purpose. Thus, the specific 1043 -- numeric values associated with this type are irrelevant. 1044 KeyToUse ::= ENUMERATED { 1045 -- unspecified 1046 key-unspecified, 1047 -- server long term key 1048 key-server, 1049 -- client long term key 1050 key-client, 1051 -- key selected by KDC for encryption of a KDC-REP 1052 key-kdc-rep, 1053 -- session key from ticket 1054 key-session, 1055 -- subsession key negotiated via AP-REQ/AP-REP 1056 key-subsession, 1057 ... 1058 } 1059 1060 1061 10628.3. EncryptionKey 1063 1064 1065 The "EncryptionKey" type holds an encryption key. 1066 1067 1068 EncryptionKey ::= SEQUENCE { 1069 keytype [0] EType, 1070 keyvalue [1] OCTET STRING 1071 } 1072 1073 1074 1075 keytype 1076 This "EType" identifies the encryption algorithm, described in 1077 [KCRYPTO]. 1078 1079 1080 keyvalue 1081 Contains the actual key. 1082 1083 10848.4. EncryptedData 1085 1086 1087 The "EncryptedData" type contains the encryption of another data 1088 type. The recipient uses fields within EncryptedData to determine 1089 which key to use for decryption. 1090 1091 1092 1093 1094 1095 1096Yu Expires: Jan 2005 [Page 17] 1097Internet-Draft yu-krb-extensions-01 19 Jul 2004 1098 1099 1100 1101 -- "Type" specifies which ASN.1 type is encrypted to the 1102 -- ciphertext in the EncryptedData. "Keys" specifies a set of 1103 -- keys of which one key may be used to encrypt the data. 1104 -- "KeyUsages" specifies a set of key usages, one of which may 1105 -- be used to encrypt. 1106 -- 1107 -- None of the parameters is transmitted over the wire. 1108 EncryptedData { 1109 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1110 } ::= SEQUENCE { 1111 etype [0] EType, 1112 kvno [1] UInt32 OPTIONAL, 1113 cipher [2] OCTET STRING (CONSTRAINED BY { 1114 -- must be encryption of -- 1115 OCTET STRING (CONTAINING Type), 1116 -- with one of the keys -- KeyToUse:Keys, 1117 -- with key usage being one of -- 1118 KeyUsage:KeyUsages 1119 }), 1120 ... 1121 } 1122 1123 1124 1125 1126 KeyUsages 1127 Advisory parameter indicating which key usage to use when 1128 encrypting the ciphertext. If "KeyUsages" indicate multiple 1129 "KeyUsage" values, the detailed description of the containing 1130 message will indicate which key to use under which conditions. 1131 1132 1133 Type 1134 Advisory parameter indicating the ASN.1 type whose DER encoding 1135 is the plaintext encrypted into the EncryptedData. 1136 1137 1138 Keys 1139 Advisory parameter indicating which key to use to perform the 1140 encryption. If "Keys" indicate multiple "KeyToUse" values, the 1141 detailed description of the containing message will indicate 1142 which key to use under which conditions. 1143 1144 1145 KeyUsages 1146 Advisory parameter indicating which "KeyUsage" value is used to 1147 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, 1148 the detailed description of the containing message will indicate 1149 which key usage to use under which conditions. 1150 1151 11528.5. Checksums 1153 1154 1155 Several types contain checksums (actually signatures) of data. 1156 1157 1158 1159Yu Expires: Jan 2005 [Page 18] 1160Internet-Draft yu-krb-extensions-01 19 Jul 2004 1161 1162 1163 CksumType ::= Int32 1164 1165 1166 -- The parameters specify which key to use to produce the 1167 -- signature, as well as which key usage to use. The 1168 -- parameters are not actually sent over the wire. 1169 Checksum { 1170 KeyToUse:Keys, KeyUsage:KeyUsages 1171 } ::= SEQUENCE { 1172 cksumtype [0] CksumType, 1173 checksum [1] OCTET STRING (CONSTRAINED BY { 1174 -- signed using one of the keys -- 1175 KeyToUse:Keys, 1176 -- with key usage being one of -- 1177 KeyUsage:KeyUsages 1178 }) 1179 } 1180 1181 1182 1183 CksumType 1184 Integer type for assigned numbers for signature algorithms. 1185 Defined in [KCRYPTO] 1186 1187 1188 Keys 1189 As in EncryptedData 1190 1191 1192 KeyUsages 1193 As in EncryptedData 1194 1195 1196 cksumtype 1197 Signature algorithm used to produce the signature. 1198 1199 1200 checksum 1201 The actual checksum. 1202 1203 12048.5.1. ChecksumOf 1205 1206 1207 ChecksumOf is like "Checksum", but specifies which type is signed. 1208 1209 1210 -- a Checksum that must contain the checksum 1211 -- of a particular type 1212 ChecksumOf { 1213 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1214 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 1215 ..., 1216 checksum (CONSTRAINED BY { 1217 -- must be checksum of -- 1218 OCTET STRING (CONTAINING Type) 1219 }) 1220 }) 1221 1222 1223 1224 1225Yu Expires: Jan 2005 [Page 19] 1226Internet-Draft yu-krb-extensions-01 19 Jul 2004 1227 1228 1229 Type 1230 Indicates the ASN.1 type whose DER encoding is signed. 1231 1232 12338.5.2. Signed 1234 1235 1236 Signed is like "ChecksumOf", but contains an actual instance of the 1237 type being signed in addition to the signature. 1238 1239 1240 -- parameterized type for wrapping authenticated plaintext 1241 Signed { 1242 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 1243 } ::= SEQUENCE { 1244 cksum [0] ChecksumOf { 1245 InnerType, Keys, KeyUsages 1246 } OPTIONAL, 1247 inner [1] InnerType, 1248 ... 1249 } 1250 1251 1252 12539. Tickets 1254 1255 1256 [ A large number of items described here are duplicated in the 1257 sections describing KDC-REQ processing. Should find a way to avoid 1258 this duplication. ] 1259 1260 1261 A ticket binds a principal name to a session key. The important 1262 fields of a ticket are in the encrypted part. The components in 1263 common between the RFC 1510 and the extensible versions are 1264 1265 1266 EncTicketPartCommon ::= SEQUENCE { 1267 flags [0] TicketFlags, 1268 key [1] EncryptionKey, 1269 crealm [2] Realm, 1270 cname [3] PrincipalName, 1271 transited [4] TransitedEncoding, 1272 authtime [5] KerberosTime, 1273 starttime [6] KerberosTime OPTIONAL, 1274 endtime [7] KerberosTime, 1275 renew-till [8] KerberosTime OPTIONAL, 1276 caddr [9] HostAddresses OPTIONAL, 1277 authorization-data [10] AuthorizationData OPTIONAL, 1278 ... 1279 } 1280 1281 1282 1283 crealm 1284 This field contains the client's realm. 1285 1286 1287 cname 1288 This field contains the client's name. 1289 1290 1291Yu Expires: Jan 2005 [Page 20] 1292Internet-Draft yu-krb-extensions-01 19 Jul 2004 1293 1294 1295 caddr 1296 This field lists the network addresses (if absent, all addresses 1297 are permitted) from which the ticket is valid. 1298 1299 1300 Descriptions of the other fields appear in the following sections. 1301 1302 13039.1. Timestamps 1304 1305 1306 Three of the ticket timestamps may be requested from the KDC. The 1307 timestamps may differ from those requested, depending on site policy. 1308 1309 1310 authtime 1311 The time at which the client authenticated, as recorded by the 1312 KDC. 1313 1314 1315 starttime 1316 The earliest time when the ticket is valid. If not present, the 1317 ticket is valid starting at the authtime. This is requested as 1318 the "from" field of KDC-REQ-BODY-COMMON. 1319 1320 1321 endtime 1322 This time is requested in the "till" field of KDC-REQ-BODY- 1323 COMMON. Contains the time after which the ticket will not be 1324 honored (its expiration time). Note that individual services 1325 MAY place their own limits on the life of a ticket and MAY 1326 reject tickets which have not yet expired. As such, this is 1327 really an upper bound on the expiration time for the ticket. 1328 1329 1330 renew-till 1331 This time is requested in the "rtime" field of KDC-REQ-BODY- 1332 COMMON. It is only present in tickets that have the "renewable" 1333 flag set in the flags field. It indicates the maximum endtime 1334 that may be included in a renewal. It can be thought of as the 1335 absolute expiration time for the ticket, including all renewals. 1336 1337 13389.2. Ticket Flags 1339 1340 1341 A number of flags may be set in the ticket, further defining some of 1342 its capabilities. Some of these flags map to flags in a KDC request. 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357Yu Expires: Jan 2005 [Page 21] 1358Internet-Draft yu-krb-extensions-01 19 Jul 2004 1359 1360 1361 TicketFlags ::= KerberosFlags { TicketFlagsBits } 1362 1363 1364 TicketFlagsBits ::= BIT STRING { 1365 reserved (0), 1366 forwardable (1), 1367 forwarded (2), 1368 proxiable (3), 1369 proxy (4), 1370 may-postdate (5), 1371 postdated (6), 1372 invalid (7), 1373 renewable (8), 1374 initial (9), 1375 pre-authent (10), 1376 hw-authent (11), 1377 transited-policy-checked (12), 1378 ok-as-delegate (13), 1379 anonymous (14), 1380 cksummed-ticket (15) 1381 } 1382 1383 1384 13859.2.1. Flags Relating to Initial Ticket Acquisition 1386 1387 1388 [ adapted KCLAR 2.1. ] 1389 1390 1391 Several flags indicate the details of how the initial ticket was 1392 acquired. 1393 1394 1395 initial 1396 The "initial" flag indicates that a ticket was issued using the 1397 AS protocol, rather than issued based on a ticket-granting 1398 ticket. Application servers (e.g., a password-changing program) 1399 requiring a client's definite knowledge of its secret key can 1400 insist that this flag be set in any tickets they accept, thus 1401 being assured that the client's key was recently presented to 1402 the application client. 1403 1404 1405 pre-authent 1406 The "pre-authent" flag indicates that some sort of pre- 1407 authentication was used during the AS exchange. 1408 1409 1410 hw-authent 1411 The "hw-authent" flag indicates that some sort of hardware-based 1412 pre-authentication occurred during the AS exchange. 1413 1414 1415 Both the "pre-authent" and the "hw-authent" flags may be present with 1416 or without the "initial" flag; such tickets with the "initial" flag 1417 clear are ones which are derived from initial tickets with the "pre- 1418 authent" or "hw-authent" flags set. 1419 1420 1421 1422Yu Expires: Jan 2005 [Page 22] 1423Internet-Draft yu-krb-extensions-01 19 Jul 2004 1424 1425 14269.2.2. Invalid Tickets 1427 1428 1429 [ KCLAR 2.2. ] 1430 1431 1432 The "invalid" flag indicates that a ticket is invalid. Application 1433 servers MUST reject tickets which have this flag set. A postdated 1434 ticket will be issued in this form. Invalid tickets MUST be 1435 validated by the KDC before use, by presenting them to the KDC in a 1436 TGS request with the "validate" option specified. The KDC will only 1437 validate tickets after their starttime has passed. The validation is 1438 required so that postdated tickets which have been stolen before 1439 their starttime can be rendered permanently invalid (through a hot- 1440 list mechanism -- see Section 10.3.2.4). 1441 1442 14439.2.3. OK as Delegate 1444 1445 1446 [ KCLAR 2.8. ] 1447 1448 1449 The "ok-as-delegate" flag provides a way for a KDC to communicate 1450 local realm policy to a client regarding whether the service for 1451 which the ticket is issued is trusted to accept delegated 1452 credentials. For some applications, a client may need to delegate 1453 credentials to a service to act on its behalf in contacting other 1454 services. The ability of a client to obtain a service ticket for a 1455 service conveys no information to the client about whether the 1456 service should be trusted to accept delegated credentials. 1457 1458 1459 The copy of the ticket flags visible to the client may have the "ok- 1460 as-delegate" flag set to indicate to the client that the service 1461 specified in the ticket has been determined by policy of the realm to 1462 be a suitable recipient of delegation. A client can use the presence 1463 of this flag to help it make a decision whether to delegate 1464 credentials (either grant a proxy or a forwarded ticket-granting 1465 ticket) to this service. It is acceptable to ignore the value of 1466 this flag. When setting this flag, an administrator should consider 1467 the security and placement of the server on which the service will 1468 run, as well as whether the service requires the use of delegated 1469 credentials. 1470 1471 14729.3. Renewable Tickets 1473 1474 1475 [ adapted KCLAR 2.3. ] 1476 1477 1478 The "renewable" flag indicates whether the ticket may be renewed. 1479 1480 1481 Renewable tickets can be used to mitigate the consequences of ticket 1482 theft. Applications may desire to hold credentials which can be 1483 valid for long periods of time. However, this can expose the 1484 credentials to potential theft for equally long periods, and those 1485 stolen credentials would be valid until the expiration time of the 1486 ticket(s). Simply using short-lived tickets and obtaining new ones 1487 1488 1489Yu Expires: Jan 2005 [Page 23] 1490Internet-Draft yu-krb-extensions-01 19 Jul 2004 1491 1492 1493 periodically would require the application to have long-term access 1494 to the client's secret key, which is an even greater risk. 1495 1496 1497 Renewable tickets have two "expiration times": the first is when the 1498 current instance of the ticket expires, and the second is the latest 1499 permissible value for an individual expiration time. An application 1500 client must periodically present an unexpired renewable ticket to the 1501 KDC, setting the "renew" option in the KDC request. The KDC will 1502 issue a new ticket with a new session key and a later expiration 1503 time. All other fields of the ticket are left unmodified by the 1504 renewal process. When the latest permissible expiration time 1505 arrives, the ticket expires permanently. At each renewal, the KDC 1506 MAY consult a hot-list to determine if the ticket had been reported 1507 stolen since its last renewal; it will refuse to renew such stolen 1508 tickets, and thus the usable lifetime of stolen tickets is reduced. 1509 1510 1511 The "renewable" flag in a ticket is normally only interpreted by the 1512 ticket-granting service. It can usually be ignored by application 1513 servers. However, some particularly careful application servers MAY 1514 disallow renewable tickets. 1515 1516 1517 If a renewable ticket is not renewed by its expiration time, the KDC 1518 will not renew the ticket. The "renewable" flag is clear by default, 1519 but a client can request it be set by setting the "renewable" option 1520 in the AS-REQ message. If it is set, then the "renew-till" field in 1521 the ticket contains the time after which the ticket may not be 1522 renewed. 1523 1524 15259.4. Postdated Tickets 1526 1527 1528 postdated 1529 indicates a ticket which has been postdated 1530 1531 1532 may-postdate 1533 indicates that postdated tickets may be issued based on this 1534 ticket 1535 1536 1537 [ KCLAR 2.4. ] 1538 1539 1540 Applications may occasionally need to obtain tickets for use much 1541 later, e.g., a batch submission system would need tickets to be valid 1542 at the time the batch job is serviced. However, it is dangerous to 1543 hold valid tickets in a batch queue, since they will be on-line 1544 longer and more prone to theft. Postdated tickets provide a way to 1545 obtain these tickets from the KDC at job submission time, but to 1546 leave them "dormant" until they are activated and validated by a 1547 further request of the KDC. If a ticket theft were reported in the 1548 interim, the KDC would refuse to validate the ticket, and the thief 1549 would be foiled. 1550 1551 1552 1553 1554Yu Expires: Jan 2005 [Page 24] 1555Internet-Draft yu-krb-extensions-01 19 Jul 2004 1556 1557 1558 The "may-postdate" flag in a ticket is normally only interpreted by 1559 the TGS. It can be ignored by application servers. This flag MUST 1560 be set in a ticket-granting ticket in order for the KDC to issue a 1561 postdated ticket based on the presented ticket. It is reset by 1562 default; it MAY be requested by a client by setting the "allow- 1563 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag 1564 does not allow a client to obtain a postdated ticket-granting ticket; 1565 postdated ticket-granting tickets can only by obtained by requesting 1566 the postdating in the AS-REQ message. The life (endtime minus 1567 starttime) of a postdated ticket will be the remaining life of the 1568 ticket-granting ticket at the time of the request, unless the 1569 "renewable" option is also set, in which case it can be the full life 1570 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY 1571 limit how far in the future a ticket may be postdated. 1572 1573 1574 The "postdated" flag indicates that a ticket has been postdated. The 1575 application server can check the authtime field in the ticket to see 1576 when the original authentication occurred. Some services MAY choose 1577 to reject postdated tickets, or they may only accept them within a 1578 certain period after the original authentication. When the KDC 1579 issues a "postdated" ticket, it will also be marked as "invalid", so 1580 that the application client MUST present the ticket to the KDC for 1581 validation before use. 1582 1583 15849.5. Proxiable and Proxy Tickets 1585 1586 1587 proxy 1588 indicates a proxy ticket 1589 1590 1591 proxiable 1592 indicates that proxy tickets may be issued based on this ticket 1593 1594 1595 [ KCLAR 2.5. ] 1596 1597 1598 It may be necessary for a principal to allow a service to perform an 1599 operation on its behalf. The service must be able to take on the 1600 identity of the client, but only for a particular purpose. A 1601 principal can allow a service to take on the principal's identity for 1602 a particular purpose by granting it a proxy. 1603 1604 1605 The process of granting a proxy using the "proxy" and "proxiable" 1606 flags is used to provide credentials for use with specific services. 1607 Though conceptually also a proxy, users wishing to delegate their 1608 identity in a form usable for all purposes MUST use the ticket 1609 forwarding mechanism described in the next section to forward a 1610 ticket-granting ticket. 1611 1612 1613 The "proxiable" flag in a ticket is normally only interpreted by the 1614 ticket-granting service. It can be ignored by application servers. 1615 When set, this flag tells the ticket-granting server that it is OK to 1616 issue a new ticket (but not a ticket-granting ticket) with a 1617 1618 1619Yu Expires: Jan 2005 [Page 25] 1620Internet-Draft yu-krb-extensions-01 19 Jul 2004 1621 1622 1623 different network address based on this ticket. This flag is set if 1624 requested by the client on initial authentication. By default, the 1625 client will request that it be set when requesting a ticket-granting 1626 ticket, and reset when requesting any other ticket. 1627 1628 1629 This flag allows a client to pass a proxy to a server to perform a 1630 remote request on its behalf (e.g. a print service client can give 1631 the print server a proxy to access the client's files on a particular 1632 file server in order to satisfy a print request). 1633 1634 1635 In order to complicate the use of stolen credentials, Kerberos 1636 tickets may contain a set of network addresses from which they are 1637 valid. When granting a proxy, the client MUST specify the new 1638 network address from which the proxy is to be used, or indicate that 1639 the proxy is to be issued for use from any address. 1640 1641 1642 The "proxy" flag is set in a ticket by the TGS when it issues a proxy 1643 ticket. Application servers MAY check this flag and at their option 1644 they MAY require additional authentication from the agent presenting 1645 the proxy in order to provide an audit trail. 1646 1647 16489.6. Forwardable Tickets 1649 1650 1651 forwarded 1652 indicates a forwarded ticket 1653 1654 1655 forwardable 1656 indicates that forwarded tickets may be issued based on this 1657 ticket 1658 1659 1660 [ KCLAR 2.6. ] 1661 1662 1663 Authentication forwarding is an instance of a proxy where the service 1664 that is granted is complete use of the client's identity. An example 1665 where it might be used is when a user logs in to a remote system and 1666 wants authentication to work from that system as if the login were 1667 local. 1668 1669 1670 The "forwardable" flag in a ticket is normally only interpreted by 1671 the ticket-granting service. It can be ignored by application 1672 servers. The "forwardable" flag has an interpretation similar to 1673 that of the "proxiable" flag, except ticket-granting tickets may also 1674 be issued with different network addresses. This flag is reset by 1675 default, but users MAY request that it be set by setting the 1676 "forwardable" option in the AS request when they request their 1677 initial ticket-granting ticket. 1678 1679 1680 This flag allows for authentication forwarding without requiring the 1681 user to enter a password again. If the flag is not set, then 1682 authentication forwarding is not permitted, but the same result can 1683 still be achieved if the user engages in the AS exchange specifying 1684 1685 1686Yu Expires: Jan 2005 [Page 26] 1687Internet-Draft yu-krb-extensions-01 19 Jul 2004 1688 1689 1690 the requested network addresses and supplies a password. 1691 1692 1693 The "forwarded" flag is set by the TGS when a client presents a 1694 ticket with the "forwardable" flag set and requests a forwarded 1695 ticket by specifying the "forwarded" KDC option and supplying a set 1696 of addresses for the new ticket. It is also set in all tickets 1697 issued based on tickets with the "forwarded" flag set. Application 1698 servers may choose to process "forwarded" tickets differently than 1699 non-forwarded tickets. 1700 1701 1702 If addressless tickets are forwarded from one system to another, 1703 clients SHOULD still use this option to obtain a new TGT in order to 1704 have different session keys on the different systems. 1705 1706 17079.7. Transited Realms 1708 1709 1710 [ KCLAR 2.7., plus new stuff ] 1711 1712 17139.8. Authorization Data 1714 1715 17169.9. Encrypted Part of Ticket 1717 1718 1719 The complete definition of the encrypted part is 1720 1721 1722 -- Encrypted part of ticket 1723 EncTicketPart ::= CHOICE { 1724 rfc1510 [APPLICATION 3] EncTicketPart1510, 1725 ext [APPLICATION 5] EncTicketPartExt 1726 } 1727 1728 1729 1730 EncTicketPart1510 ::= SEQUENCE { 1731 COMPONENTS OF EncTicketPartCommon 1732 } (WITH COMPONENTS { 1733 ..., 1734 -- explicitly force IA5 in strings 1735 crealm (RealmIA5), 1736 cname (PrincipalNameIA5) 1737 }) 1738 1739 1740 1741 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { 1742 ..., 1743 -- explicitly force UTF-8 in strings 1744 crealm (RealmExt), 1745 cname (PrincipalNameExt), 1746 -- explicitly constrain caddr to be non-empty if present 1747 caddr (SIZE (1..MAX)), 1748 -- forbid empty authorization-data encodings 1749 authorization-data (SIZE (1..MAX)) 1750 }) 1751 1752 1753Yu Expires: Jan 2005 [Page 27] 1754Internet-Draft yu-krb-extensions-01 19 Jul 2004 1755 1756 17579.10. Cleartext Part of Ticket 1758 1759 1760 Ticket ::= CHOICE { 1761 rfc1510 [APPLICATION 1] Ticket1510, 1762 ext [APPLICATION 4] Signed { 1763 TicketExt, { key-server }, { ku-Ticket-cksum } 1764 } 1765 } 1766 1767 1768 1769 -- takes a parameter specifying which type gets encrypted 1770 TicketCommon { EncPart } ::= SEQUENCE { 1771 tkt-vno [0] INTEGER (5), 1772 realm [1] Realm, 1773 sname [2] PrincipalName, 1774 enc-part [3] EncryptedData { 1775 EncPart, { key-server }, { ku-Ticket } 1776 }, 1777 ..., 1778 extensions [4] TicketExtensions OPTIONAL, 1779 ... 1780 } 1781 1782 1783 1784 Ticket1510 ::= SEQUENCE { 1785 COMPONENTS OF TicketCommon { EncTicketPart1510 } 1786 } (WITH COMPONENTS { 1787 ..., 1788 -- explicitly force IA5 in strings 1789 realm (RealmIA5), 1790 sname (PrincipalNameIA5) 1791 }) 1792 1793 1794 1795 -- APPLICATION tag goes inside Signed{} as well as outside, 1796 -- to prevent possible substitution attacks. 1797 TicketExt ::= [APPLICATION 4] TicketCommon { 1798 EncTicketPartExt 1799 } (WITH COMPONENTS { 1800 ..., 1801 -- explicitly force UTF-8 in strings 1802 realm (RealmExt), 1803 sname (PrincipalNameExt) 1804 }) 1805 1806 1807 180810. Credential Acquisition 1809 1810 1811 There are two exchanges that can be used for acquiring credentials: 1812 the AS exchange and the TGS exchange. These exchanges have many 1813 similarities, and this document describes them in parallel, noting 1814 1815 1816Yu Expires: Jan 2005 [Page 28] 1817Internet-Draft yu-krb-extensions-01 19 Jul 2004 1818 1819 1820 which behaviors are specific to one type of exchange. The AS request 1821 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests 1822 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) 1823 are forms of KDC replies (KDC-REP). 1824 1825 182610.1. KDC-REQ 1827 1828 1829 The KDC-REQ has a large number of fields in common between the RFC 1830 1510 and the extensible versions. 1831 1832 1833 KDC-REQ-COMMON ::= SEQUENCE { 1834 -- NOTE: first tag is [1], not [0] 1835 pvno [1] INTEGER (5), 1836 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- 1837 | 12 -- TGS-REQ.rfc1510 -- 1838 | 6 -- AS-REQ.ext -- 1839 | 8 -- TGS-REQ.ext -- ), 1840 padata [3] SEQUENCE OF PA-DATA OPTIONAL 1841 -- NOTE: not empty 1842 } 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876Yu Expires: Jan 2005 [Page 29] 1877Internet-Draft yu-krb-extensions-01 19 Jul 2004 1878 1879 1880 KDC-REQ-BODY-COMMON ::= SEQUENCE { 1881 kdc-options [0] KDCOptions, 1882 cname [1] PrincipalName OPTIONAL 1883 -- Used only in AS-REQ --, 1884 1885 1886 realm [2] Realm 1887 -- Server's realm; also client's in AS-REQ --, 1888 1889 1890 sname [3] PrincipalName OPTIONAL, 1891 from [4] KerberosTime OPTIONAL, 1892 till [5] KerberosTime OPTIONAL 1893 -- was required in rfc1510; 1894 -- still required for compat versions 1895 -- of messages --, 1896 1897 1898 rtime [6] KerberosTime OPTIONAL, 1899 nonce [7] Nonce, 1900 etype [8] SEQUENCE OF EType 1901 -- in preference order --, 1902 1903 1904 addresses [9] HostAddresses OPTIONAL, 1905 enc-authorization-data [10] EncryptedData { 1906 AuthorizationData, { key-session | key-subsession }, 1907 { ku-TGSReqAuthData-subkey | 1908 ku-TGSReqAuthData-sesskey } 1909 } OPTIONAL, 1910 1911 1912 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 1913 -- NOTE: not empty --, 1914 ... 1915 } 1916 1917 1918 1919 Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of 1920 an EncTicketPartCommon. The KDC copies most of them unchanged, 1921 provided that their values meet site policy. 1922 1923 1924 kdc-options 1925 These flags do not correspond directly to "flags" in 1926 EncTicketPartCommon. 1927 1928 1929 cname 1930 This field is copied to the "cname" field in 1931 EncTicketPartCommon. The "cname" field is required in an AS- 1932 REQ; the client places its own name here. In a TGS-REQ, the 1933 "cname" in the ticket in the AP-REQ takes precedence. 1934 1935 1936 realm 1937 This field is the server's realm, and also holds the client's 1938 realm in an AS-REQ. 1939 1940 1941 1942Yu Expires: Jan 2005 [Page 30] 1943Internet-Draft yu-krb-extensions-01 19 Jul 2004 1944 1945 1946 sname 1947 The "sname" field indicates the server's name. It may be absent 1948 in a TGS-REQ which requests user-to-user authentication, in 1949 which case the "sname" of the issued ticket will be taken from 1950 the included additional ticket. 1951 1952 1953 The "from", "till", and "rtime" fields correspond to the "starttime", 1954 "endtime", and "renew-till" fields of EncTicketPartCommon. 1955 1956 1957 addresses 1958 This field corresponds to the "caddr" field of 1959 EncTicketPartCommon. 1960 1961 1962 enc-authorization-data 1963 For TGS-REQ, this field contains authorization data encrypted 1964 using either the TGT session key or the AP-REQ subsession key; 1965 the KDC may copy these into the "authorization-data" field of 1966 EncTicketPartCommon if policy permits. 1967 1968 196910.2. PA-DATA 1970 1971 1972 PA-DATA have multiple uses in the Kerberos protocol. They may pre- 1973 authenticate an AS-REQ; they may also modify several of the 1974 encryption keys used in a KDC-REP. PA-DATA may also provide "hints" 1975 to the client about which long-term key (usually password-derived) to 1976 use. PA-DATA may also include "hints" about which pre-authentication 1977 mechanisms to use, or include data for input into a pre- 1978 authentication mechanism. 1979 1980 198110.3. KDC-REQ Processing 1982 1983 1984 Processing of a KDC-REQ proceeds through several steps. An 1985 implementation need not perform these steps exactly as described, as 1986 long as it behaves as if the steps were performed as described. The 1987 KDC performs replay handling upon receiving the request; it then 1988 validates the request, adjusts timestamps, and selects the keys used 1989 in the reply. It copies data from the request into the issued 1990 ticket, adjusting the values to conform with its policies. The KDC 1991 then transmits the reply to the client. 1992 1993 199410.3.1. Handling Replays 1995 1996 1997 Because Kerberos can run over unreliable transports such as UDP, the 1998 KDC MUST be prepared to retransmit responses in case they are lost. 1999 If a KDC receives a request identical to one it has recently 2000 successfully processed, the KDC MUST respond with a KDC-REP message 2001 rather than a replay error. In order to reduce the amount of 2002 ciphertext given to a potential attacker, KDCs MAY send the same 2003 response generated when the request was first handled. KDCs MUST 2004 obey this replay behavior even if the actual transport in use is 2005 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, 2006 2007 2008Yu Expires: Jan 2005 [Page 31] 2009Internet-Draft yu-krb-extensions-01 19 Jul 2004 2010 2011 2012 and the entire request is not identical to a recently successfully 2013 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is 2014 appropriate for AP-REQ processing. 2015 2016 201710.3.2. Request Validation 2018 2019 202010.3.2.1. AS-REQ Authentication 2021 2022 2023 Site policy determines whether a given client principal is required 2024 to provide some pre-authentication prior to receiving an AS-REP. 2025 Since the default reply key is typically the client's long-term 2026 password-based key, an attacker may easily request known plaintext 2027 (in the form of an AS-REP) upon which to mount a dictionary attack. 2028 Pre-authentication can limit the possibility of such an attack. 2029 2030 2031 If site policy requires pre-authentication for a client principal, 2032 and no pre-authentication is provided, the KDC returns the error 2033 "kdc-err-preauth-required". Accompanying this error are "e-data" 2034 which include hints telling the client which pre-authentication 2035 mechanisms to use, or data for input to pre-authentication mechanisms 2036 (e.g., input to challenge-response systems). If pre-authentication 2037 fails, the KDC returns the error "kdc-err-preauth-failed". 2038 2039 2040 [ may need additional changes based on Sam's preauth draft ] 2041 2042 204310.3.2.2. TGS-REQ Authentication 2044 2045 2046 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- 2047 tgs-req". The KDC MUST validate the checksum in the Authenticator of 2048 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- 2049 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the 2050 request. [ padata not signed by authenticator! ] Any error from the 2051 AP-REQ validation process SHOULD be returned in a KRB-ERROR message. 2052 The service principal in the ticket of the AP-REQ may be a ticket- 2053 granting service principal, or a normal application service 2054 principal. A ticket which is not a ticket-granting ticket MUST NOT 2055 be used to issue a ticket for any service other than the one named in 2056 the ticket. In this case, the "renew", "validate", or "proxy" [?also 2057 forwarded?] option must be set in the request. 2058 2059 206010.3.2.3. Principal Validation 2061 2062 2063 If the client principal in an AS-REQ is unknown, the KDC returns the 2064 error "kdc-err-c-principal-unknown". If the server principal in a 2065 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- 2066 unknown". 2067 2068 206910.3.2.4. Checking For Revoked or Invalid Tickets 2070 2071 2072 [ KCLAR 3.3.3.1 ] 2073 2074 2075 2076Yu Expires: Jan 2005 [Page 32] 2077Internet-Draft yu-krb-extensions-01 19 Jul 2004 2078 2079 2080 Whenever a request is made to the ticket-granting server, the 2081 presented ticket(s) is(are) checked against a hot-list of tickets 2082 which have been canceled. This hot-list might be implemented by 2083 storing a range of issue timestamps for "suspect tickets"; if a 2084 presented ticket had an authtime in that range, it would be rejected. 2085 In this way, a stolen ticket-granting ticket or renewable ticket 2086 cannot be used to gain additional tickets (renewals or otherwise) 2087 once the theft has been reported to the KDC for the realm in which 2088 the server resides. Any normal ticket obtained before it was 2089 reported stolen will still be valid (because they require no 2090 interaction with the KDC), but only until their normal expiration 2091 time. If TGTs have been issued for cross-realm authentication, use 2092 of the cross-realm TGT will not be affected unless the hot-list is 2093 propagated to the KDCs for the realms for which such cross-realm 2094 tickets were issued. 2095 2096 2097 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT 2098 issue any ticket unless the TGS-REQ requests the "validate" option. 2099 2100 210110.3.3. Timestamp Handling 2102 2103 2104 [ some aspects of timestamp handling, especially regarding postdating 2105 and renewal, are difficult to read in KCLAR... needs closer 2106 examination here ] 2107 2108 2109 Processing of "starttime" (requested in the "from" field) differs 2110 depending on whether the "postdated" option is set in the request. 2111 If the "postdated" option is not set, and the requested "starttime" 2112 is in the future beyond the window of acceptable clock skew, the KDC 2113 returns the error "kdc-err-cannot-postdate". If the "postdated" 2114 option is not set, and the requested "starttime" is absent or does 2115 not indicate a time in the future beyond the acceptable clock skew, 2116 the KDC sets the "starttime" to the KDC's current time. The 2117 "postdated" option MUST NOT be honored if the ticket is being 2118 requested by TGS-REQ and the "may-postdate" is not set in the TGT. 2119 Otherwise, if the "postdated" option is set, and site policy permits, 2120 the KDC sets the "starttime" as requested, and sets the "invalid" 2121 flag in the new ticket. 2122 2123 2124 The "till" field is required in the RFC 1510 version of the KDC-REQ. 2125 If the "till" field is equal to "19700101000000Z" (midnight, January 2126 1, 1970), the KDC SHOULD behave as if the "till" field were absent. 2127 2128 2129 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or 2130 "renew-till" time is later than the "renew-till" time of the ticket 2131 from which it is derived. 2132 2133 213410.3.3.1. AS-REQ Timestamp Processing 2135 2136 2137 In the AS exchange, the "authtime" of a ticket is set to the local 2138 time at the KDC. 2139 2140 2141Yu Expires: Jan 2005 [Page 33] 2142Internet-Draft yu-krb-extensions-01 19 Jul 2004 2143 2144 2145 The "endtime" of the ticket will be set to the earlier of the 2146 requested "till" time and a time determined by local policy, possibly 2147 determined using factors specific to the realm or principal. For 2148 example, the expiration time MAY be set to the earliest of the 2149 following: 2150 2151 2152 * the expiration time ("till" value) requested 2153 2154 2155 * the ticket's start time plus the maximum allowable lifetime 2156 associated with the client principal from the authentication 2157 server's database 2158 2159 2160 * the ticket's start time plus the maximum allowable lifetime 2161 associated with the server principal 2162 2163 2164 * the ticket's start time plus the maximum lifetime set by the 2165 policy of the local realm 2166 2167 2168 If the requested expiration time minus the start time (as determined 2169 above) is less than a site-determined minimum lifetime, an error 2170 message with code "kdc-err-never-valid" is returned. If the 2171 requested expiration time for the ticket exceeds what was determined 2172 as above, and if the "renewable-ok" option was requested, then the 2173 "renewable" flag is set in the new ticket, and the "renew-till" value 2174 is set as if the "renewable" option were requested. 2175 2176 2177 If the "renewable" option has been requested or if the "renewable-ok" 2178 option has been set and a renewable ticket is to be issued, then the 2179 "renew-till" field MAY be set to the earliest of: 2180 2181 2182 * its requested value 2183 2184 2185 * the start time of the ticket plus the minimum of the two maximum 2186 renewable lifetimes associated with the principals' database 2187 entries 2188 2189 2190 * the start time of the ticket plus the maximum renewable lifetime 2191 set by the policy of the local realm 2192 2193 219410.3.3.2. TGS-REQ Timestamp Processing 2195 2196 2197 In the TGS exchange, the KDC sets the "authtime" to that of the 2198 ticket in the AP-REQ authenticating the TGS-REQ. [?application 2199 server can print a ticket for itself with a spoofed authtime. 2200 security issues for hot-list?] [ MIT implementation may change 2201 authtime of renewed tickets; needs check... ] 2202 2203 2204 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ 2205 requests an "endtime" (in the "till" field), then the "endtime" of 2206 the new ticket is set to the minimum of 2207 2208 2209 2210Yu Expires: Jan 2005 [Page 34] 2211Internet-Draft yu-krb-extensions-01 19 Jul 2004 2212 2213 2214 * the requested "endtime" value, 2215 2216 2217 * the "endtime" in the TGT, and 2218 2219 2220 * an "endtime" determined by site policy on ticket lifetimes. 2221 2222 2223 If the new ticket is a renewal, the "endtime" of the new ticket is 2224 bounded by the minimum of 2225 2226 2227 * the requested "endtime" value, 2228 2229 2230 * the value of the "renew-till" value of the old, 2231 2232 2233 * the "starttime" of the new ticket plus the lifetime (endtime 2234 minus starttime) of the old ticket, i.e., the lifetime of the 2235 new ticket may not exceed that of the ticket being renewed [ 2236 adapted from KCLAR 3.3.3. ], and 2237 2238 2239 * an "endtime" determined by site policy on ticket lifetimes. 2240 2241 2242 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with 2243 a "starttime", "endtime", or "renew-till" time later than the "renew- 2244 till" time of the TGT. 2245 2246 224710.3.4. Handling Transited Realms 2248 2249 2250 The KDC checks the ticket in a TGS-REQ against site policy, unless 2251 the "disable-transited-check" option is set in the TGS-REQ. If site 2252 policy permits the transit path in the TGS-REQ ticket, the KDC sets 2253 the "transited-policy-checked" flag in the issued ticket. If the 2254 "disable-transited-check" option is set, the issued ticket will have 2255 the "transited-policy-checked" flag cleared. 2256 2257 225810.3.5. Address Processing The requested "addresses" in the KDC-REQ are 2259 copied into the issued ticket. If the "addresses" field is absent or 2260 empty in a TGS-REQ, the KDC copies addresses from the ticket in the 2261 TGS-REQ into the issued ticket, unless the either "forwarded" or 2262 "proxy" option is set. If the "forwarded" option is set, and the 2263 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies 2264 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the 2265 issued ticket. The KDC behaves similarly if the "proxy" option is 2266 set in the TGS-REQ and the "proxiable" flag is set in the ticket. 2267 The "proxy" option will not be honored on requests for additional 2268 ticket-granting tickets. 2269 2270 227110.3.6. Ticket Flag Processing 2272 2273 2274 Many kdc-options request that the KDC set a corresponding flag in the 2275 issued ticket. kdc-options marked with an asterisk (*) in the 2276 following table do not directly request the corresponding ticket flag 2277 and therefore require special handling. 2278 2279 2280Yu Expires: Jan 2005 [Page 35] 2281Internet-Draft yu-krb-extensions-01 19 Jul 2004 2282 | 2283 kdc-option | ticket flag affected 2284 -------------------------+-------------------------- 2285 forwardable | forwardable 2286 forwarded | forwarded 2287 proxiable | proxiable 2288 proxy | proxy 2289 allow-postdate | may-postdate 2290 postdated | postdated 2291 renewable | renewable 2292 requestanonymous | anonymous 2293 canonicalize | - 2294 disable-transited-check* | transited-policy-checked 2295 renewable-ok* | renewable 2296 enc-tkt-in-skey | - 2297 renew | - 2298 validate* | invalid 2299 2300 2301 2302 forwarded 2303 The KDC sets the "forwarded" flag in the issued ticket if the 2304 "forwarded" option is set in the TGS-REQ and the "forwardable" 2305 flag is set in the TGS-REQ ticket. 2306 2307 2308 proxy 2309 The KDC sets the "proxy" flag in the issued ticket if the 2310 "proxy" option is set in the TGS-REQ and the "proxiable" flag is 2311 set in the TGS-REQ ticket. 2312 2313 2314 disable-transited-check 2315 The handling of the "disable-transited-check" kdc-option is 2316 described in Section 10.3.4. 2317 2318 2319 renewable-ok 2320 The handling of the "renewable-ok" kdc-option is described in 2321 Section 10.3.3.1. 2322 2323 2324 validate 2325 If the "validate" kdc-option is set in a TGS-REQ, and the 2326 "starttime" has passed, the KDC will clear the "invalid" bit on 2327 the ticket before re-issuing it. 2328 2329 233010.3.7. Key Selection 2331 2332 2333 Three keys are involved in creating a KDC-REP. The reply key 2334 encrypts the encrypted part of the KDC-REP. The session key is 2335 stored in the encrypted part of the ticket, and is also present in 2336 the encrypted part of the KDC-REP so that the client can retrieve it. 2337 The ticket key is used to encrypt the ticket. These keys all have 2338 initial values for a given exchange; pre-authentication and other 2339 extension mechanisms may change the value used for any of these keys. 2340 2341 2342 2343Yu Expires: Jan 2005 [Page 36] 2344Internet-Draft yu-krb-extensions-01 19 Jul 2004 2345 2346 2347 [ again, may need changes based on Sam's preauth draft ] 2348 2349 235010.3.7.1. Reply Key and Session Key Selection 2351 2352 2353 The set of encryption types which the client will understand appears 2354 in the "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set 2355 of possible reply keys and the set of session key encryption types 2356 based on the "etype" field. 2357 2358 2359 For the AS exchange, the reply key is initially a long-term key of 2360 the client, limited to those encryption types listed in the "etype" 2361 field. The KDC SHOULD use the first valid strong "etype" for which 2362 an encryption key is available. For the TGS exchange, the reply key 2363 is initially the subsession key of the Authenticator. If the 2364 Authenticator subsesion key is absent, the reply key is initially the 2365 session key of the ticket used to authenticate the TGS-REQ. 2366 2367 2368 The session key is initially randomly generated, and has an 2369 encryption type which both the client and the server will understand. 2370 Typically, the KDC has prior knowledge of which encryption types the 2371 server will understand. It selects the first valid strong "etype" 2372 listed the request which the server also will understand. 2373 2374 237510.3.7.2. Ticket Key Selection 2376 2377 2378 The ticket key is initially the long-term key of the service. The 2379 "enc-tkt-in-skey" option requests user-to-user authentication, where 2380 the ticket encryption key of the issued ticket is set equal to the 2381 session key of the additional ticket in the request. 2382 2383 238410.4. Reply Validation 2385 2386 238711. Session Key Exchange 2388 2389 2390 Session key exchange consists of the AP-REQ and AP-REP messages. The 2391 client sends the AP-REQ message, and the service responds with an AP- 2392 REP message if mutual authentication is desired. Following session 2393 key exchange, the client and service share a secret session key, or 2394 possibly a subsesion key, which can be used to protect further 2395 communications. Additionally, the session key exchange process can 2396 establish initial sequence numbers which the client and service can 2397 use to detect replayed messages. 2398 2399 240011.1. AP-REQ 2401 2402 2403 An AP-REQ message contains a ticket and a authenticator. The 2404 authenticator is ciphertext encrypted with the session key contained 2405 in the ticket. The plaintext contents of the authenticator are: 2406 2407 2408 2409 2410 2411Yu Expires: Jan 2005 [Page 37] 2412Internet-Draft yu-krb-extensions-01 19 Jul 2004 2413 2414 2415 -- plaintext of authenticator 2416 Authenticator ::= [APPLICATION 2] SEQUENCE { 2417 authenticator-vno [0] INTEGER (5), 2418 crealm [1] Realm, 2419 cname [2] PrincipalName, 2420 cksum [3] Checksum {{ key-session }, 2421 { ku-Authenticator-cksum | 2422 ku-pa-TGSReq-cksum }} OPTIONAL, 2423 cusec [4] Microseconds, 2424 ctime [5] KerberosTime, 2425 subkey [6] EncryptionKey OPTIONAL, 2426 seq-number [7] SeqNum OPTIONAL, 2427 authorization-data [8] AuthorizationData OPTIONAL 2428 } 2429 2430 2431 The common parts between the RFC 1510 and the extensible versions of 2432 the AP-REQ are: 2433 2434 2435 AP-REQ-COMMON ::= SEQUENCE { 2436 pvno [0] INTEGER (5), 2437 msg-type [1] INTEGER (14 | 18), 2438 ap-options [2] APOptions, 2439 ticket [3] Ticket, 2440 authenticator [4] EncryptedData { 2441 Authenticator, 2442 { key-session }, 2443 { ku-APReq-authenticator | 2444 ku-pa-TGSReq-authenticator } 2445 }, 2446 ..., 2447 extensions [5] ApReqExtensions OPTIONAL, 2448 ... 2449 } 2450 2451 2452 The complete definition of AP-REQ is: 2453 2454 2455 AP-REQ ::= CHOICE { 2456 rfc1510 [APPLICATION 14] AP-REQ-1510, 2457 ext [APPLICATION 18] Signed { 2458 AP-REQ-EXT, { key-session }, { ku-APReq-cksum } 2459 } 2460 } 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472Yu Expires: Jan 2005 [Page 38] 2473Internet-Draft yu-krb-extensions-01 19 Jul 2004 2474 2475 2476 AP-REQ-COMMON ::= SEQUENCE { 2477 pvno [0] INTEGER (5), 2478 msg-type [1] INTEGER (14 | 18), 2479 ap-options [2] APOptions, 2480 ticket [3] Ticket, 2481 authenticator [4] EncryptedData { 2482 Authenticator, 2483 { key-session }, 2484 { ku-APReq-authenticator | 2485 ku-pa-TGSReq-authenticator } 2486 }, 2487 ..., 2488 extensions [5] ApReqExtensions OPTIONAL, 2489 ... 2490 } 2491 2492 2493 2494 AP-REQ-1510 ::= SEQUENCE { 2495 COMPONENTS OF AP-REQ-COMMON 2496 } (WITH COMPONENTS { 2497 ..., 2498 msg-type (14), 2499 authenticator (EncryptedData { 2500 Authenticator (WITH COMPONENTS { 2501 ..., 2502 crealm (RealmIA5), 2503 cname (PrincipalNameIA5), 2504 seqnum (UInt32) 2505 }), { key-session }, { ku-APReq-authenticator }}) 2506 }) 2507 2508 2509 2510 AP-REQ-EXT ::= AP-REQ-COMMON 2511 (WITH COMPONENTS { 2512 ..., 2513 msg-type (18), 2514 -- The following constraints on Authenticator assume that 2515 -- we want to restrict the use of AP-REQ-EXT with TicketExt 2516 -- only, since that is the only way we can enforce UTF-8. 2517 authenticator (EncryptedData { 2518 Authenticator (WITH COMPONENTS { 2519 ..., 2520 crealm (RealmExt), 2521 cname (PrincipalNameExt), 2522 authorization-data (SIZE (1..MAX)) 2523 }), { key-session }, { ku-APReq-authenticator }}) 2524 }) 2525 2526 2527 2528 2529 2530 2531Yu Expires: Jan 2005 [Page 39] 2532Internet-Draft yu-krb-extensions-01 19 Jul 2004 2533 2534 2535 APOptions ::= KerberosFlags { APOptionsBits } 2536 2537 2538 APOptionsBits ::= BIT STRING { 2539 reserved (0), 2540 use-session-key (1), 2541 mutual-required (2) 2542 } 2543 2544 2545 254611.2. AP-REP 2547 2548 2549 EncAPRepPart ::= CHOICE { 2550 rfc1510 [APPLICATION 27] EncAPRepPart1510, 2551 ext [APPLICATION 31] EncAPRepPartExt 2552 } 2553 2554 2555 2556 EncAPRepPartCom ::= SEQUENCE { 2557 ctime [0] KerberosTime, 2558 cusec [1] Microseconds, 2559 subkey [2] EncryptionKey OPTIONAL, 2560 seq-number [3] SeqNum OPTIONAL, 2561 ..., 2562 authorization-data [4] AuthorizationData OPTIONAL, 2563 ... 2564 } 2565 2566 2567 2568 EncAPRepPart1510 ::= SEQUENCE { 2569 COMPONENTS OF ENCAPRepPartCom 2570 } (WITH COMPONENTS { 2571 ..., 2572 seq-number (UInt32), 2573 authorization-data ABSENT 2574 }) 2575 2576 2577 2578 EncAPRepPartExt ::= EncAPRepPartCom 2579 2580 2581 2582 AP-REP ::= CHOICE { 2583 rfc1510 [APPLICATION 15] AP-REP-1510, 2584 ext [APPLICATION 19] Signed { 2585 AP-REP-EXT, 2586 { key-session | key-subsession }, { ku-APRep-cksum }} 2587 } 2588 2589 2590 2591 2592 2593 2594 2595Yu Expires: Jan 2005 [Page 40] 2596Internet-Draft yu-krb-extensions-01 19 Jul 2004 2597 2598 2599 AP-REP-COMMON { EncPart } ::= SEQUENCE { 2600 pvno [0] INTEGER (5), 2601 msg-type [1] INTEGER (15 | 19), 2602 enc-part [2] EncryptedData { 2603 EncPart, 2604 { key-session | key-subsession }, { ku-EncAPRepPart }}, 2605 ..., 2606 extensions [3] ApRepExtensions OPTIONAL, 2607 ... 2608 } 2609 2610 2611 2612 AP-REP-1510 ::= SEQUENCE { 2613 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 } 2614 } (WITH COMPONENTS { 2615 ..., 2616 msg-type (15) 2617 }) 2618 2619 2620 2621 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON { 2622 EncAPRepPartExt 2623 } (WITH COMPONENTS { ..., msg-type (19) }) 2624 2625 2626 262712. Session Key Use 2628 2629 263012.1. KRB-SAFE 2631 2632 2633 -- Do we chew up another tag for KRB-SAFE-EXT? That would 2634 -- allow us to make safe-body optional, allowing for a GSS-MIC 2635 -- sort of message. 2636 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 2637 pvno [0] INTEGER (5), 2638 msg-type [1] INTEGER (20), 2639 safe-body [2] KRB-SAFE-BODY, 2640 cksum [3] ChecksumOf { 2641 KRB-SAFE-BODY, 2642 { key-session | key-subsession }, { ku-KrbSafe-cksum }}, 2643 ... -- ASN.1 extensions must be excluded 2644 -- when sending to rfc1510 implementations 2645 } 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657Yu Expires: Jan 2005 [Page 41] 2658Internet-Draft yu-krb-extensions-01 19 Jul 2004 2659 2660 2661 KRB-SAFE-BODY ::= SEQUENCE { 2662 user-data [0] OCTET STRING, 2663 timestamp [1] KerberosTime OPTIONAL, 2664 usec [2] Microseconds OPTIONAL, 2665 seq-number [3] SeqNum OPTIONAL, 2666 s-address [4] HostAddress, 2667 r-address [5] HostAddress OPTIONAL, 2668 ... -- ASN.1 extensions must be excluded 2669 -- when sending to rfc1510 implementations 2670 } 2671 2672 2673 267412.2. KRB-PRIV 2675 2676 2677 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 2678 pvno [0] INTEGER (5), 2679 msg-type [1] INTEGER (21), 2680 enc-part [3] EncryptedData { 2681 EncKrbPrivPart, 2682 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 2683 ... 2684 } 2685 2686 2687 2688 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 2689 user-data [0] OCTET STRING, 2690 timestamp [1] KerberosTime OPTIONAL, 2691 usec [2] Microseconds OPTIONAL, 2692 seq-number [3] SeqNum OPTIONAL, 2693 s-address [4] HostAddress -- sender's addr --, 2694 r-address [5] HostAddress OPTIONAL -- recip's addr --, 2695 ... -- ASN.1 extensions must be excluded 2696 -- when sending to rfc1510 implementations 2697 } 2698 2699 2700 270112.3. KRB-CRED 2702 2703 2704 KRB-CRED ::= CHOICE { 2705 rfc1510 [APPLICATION 22] KRB-CRED-1510, 2706 ext [APPLICATION 24] Signed { 2707 KRB-CRED-EXT, 2708 { key-session | key-subsession }, { ku-KrbCred-cksum }} 2709 } 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719Yu Expires: Jan 2005 [Page 42] 2720Internet-Draft yu-krb-extensions-01 19 Jul 2004 2721 2722 2723 KRB-CRED-COMMON ::= SEQUENCE { 2724 pvno [0] INTEGER (5), 2725 msg-type [1] INTEGER (22 | 24), 2726 tickets [2] SEQUENCE OF Ticket, 2727 enc-part [3] EncryptedData { 2728 EncKrbCredPart, 2729 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 2730 ... 2731 } 2732 2733 2734 2735 KRB-CRED-1510 ::= SEQUENCE { 2736 COMPONENTS OF KRB-CRED-COMMON 2737 } (WITH COMPONENTS { ..., msg-type (22) }) 2738 2739 2740 2741 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON 2742 (WITH COMPONENTS { ..., msg-type (24) }) 2743 2744 2745 2746 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 2747 ticket-info [0] SEQUENCE OF KrbCredInfo, 2748 nonce [1] Nonce OPTIONAL, 2749 timestamp [2] KerberosTime OPTIONAL, 2750 usec [3] Microseconds OPTIONAL, 2751 s-address [4] HostAddress OPTIONAL, 2752 r-address [5] HostAddress OPTIONAL 2753 } 2754 2755 2756 2757 KrbCredInfo ::= SEQUENCE { 2758 key [0] EncryptionKey, 2759 prealm [1] Realm OPTIONAL, 2760 pname [2] PrincipalName OPTIONAL, 2761 flags [3] TicketFlags OPTIONAL, 2762 authtime [4] KerberosTime OPTIONAL, 2763 starttime [5] KerberosTime OPTIONAL, 2764 endtime [6] KerberosTime OPTIONAL, 2765 renew-till [7] KerberosTime OPTIONAL, 2766 srealm [8] Realm OPTIONAL, 2767 sname [9] PrincipalName OPTIONAL, 2768 caddr [10] HostAddresses OPTIONAL 2769 } 2770 2771 2772 277313. Security Considerations 2774 2775 277613.1. Time Synchronization 2777 2778 2779 Time synchronization between the KDC and application servers is 2780 necessary to prevent acceptance of expired tickets. 2781 2782 2783Yu Expires: Jan 2005 [Page 43] 2784Internet-Draft yu-krb-extensions-01 19 Jul 2004 2785 2786 2787 Time synchronization is needed between application servers and 2788 clients to prevent replay attacks if a replay cache is being used. 2789 If negotiated subsession keys are used to encrypt application data, 2790 replay caches may not be necessary. 2791 2792 279313.2. Replays 2794 2795 279613.3. Principal Name Reuse 2797 2798 2799 See Section 7.3. 2800 2801 280213.4. Password Guessing 2803 2804 280513.5. Forward Secrecy 2806 2807 2808 [from KCLAR 10.; needs some rewriting] 2809 2810 2811 The Kerberos protocol in its basic form does not provide perfect 2812 forward secrecy for communications. If traffic has been recorded by 2813 an eavesdropper, then messages encrypted using the KRB-PRIV message, 2814 or messages encrypted using application-specific encryption under 2815 keys exchanged using Kerberos can be decrypted if any of the user's, 2816 application server's, or KDC's key is subsequently discovered. This 2817 is because the session key used to encrypt such messages is 2818 transmitted over the network encrypted in the key of the application 2819 server, and also encrypted under the session key from the user's 2820 ticket-granting ticket when returned to the user in the TGS-REP 2821 message. The session key from the ticket-granting ticket was sent to 2822 the user in the AS-REP message encrypted in the user's secret key, 2823 and embedded in the ticket-granting ticket, which was encrypted in 2824 the key of the KDC. Application requiring perfect forward secrecy 2825 must exchange keys through mechanisms that provide such assurance, 2826 but may use Kerberos for authentication of the encrypted channel 2827 established through such other means. 2828 2829 283013.6. Authorization 2831 2832 2833 As an authentication service, Kerberos provides a means of verifying 2834 the identity of principals on a network. Kerberos does not, by 2835 itself, provide authorization. Applications SHOULD NOT accept the 2836 mere issuance of a service ticket by the Kerberos server as granting 2837 authority to use the service. 2838 2839 284013.7. Login Authentication 2841 2842 2843 Some applications, particularly those which provide login access when 2844 provided with a password, SHOULD NOT treat successful acquisition of 2845 credentials as sufficient proof of the user's identity. An attacker 2846 posing as a user could generate an illegitimate KDC-REP message which 2847 decrypts properly. To authenticate a user logging on to a local 2848 system, the credentials obtained SHOULD be used in a TGS exchange to 2849 2850 2851Yu Expires: Jan 2005 [Page 44] 2852Internet-Draft yu-krb-extensions-01 19 Jul 2004 2853 2854 2855 obtain credentials for a local service. Successful use of those 2856 credentials to authenticate to the local service assures that the 2857 initially obtained credentials are from a valid KDC. 2858 2859 286014. Acknowledgments 2861 2862 2863 Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-06. 2864 2865 2866Appendices 2867 2868 2869A. ASN.1 Module (Normative) 2870 2871 2872 KerberosV5Spec3 { 2873 iso(1) identified-organization(3) dod(6) internet(1) 2874 security(5) kerberosV5(2) modules(4) krb5spec3(4) 2875 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2876 2877 2878 2879 -- OID arc for KerberosV5 2880 -- 2881 -- This OID may be used to identify Kerberos protocol messages 2882 -- encapsulated in other protocols. 2883 -- 2884 -- This OID also designates the OID arc for KerberosV5-related 2885 -- OIDs. 2886 -- 2887 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its 2888 -- OID. 2889 id-krb5 OBJECT IDENTIFIER ::= { 2890 iso(1) identified-organization(3) dod(6) internet(1) 2891 security(5) kerberosV5(2) 2892 } 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914Yu Expires: Jan 2005 [Page 45] 2915Internet-Draft yu-krb-extensions-01 19 Jul 2004 2916 2917 2918 -- top-level type 2919 -- 2920 -- Applications should not directly reference any types 2921 -- other than KRB-PDU and its component types. 2922 -- 2923 KRB-PDU ::= CHOICE { 2924 ticket Ticket, 2925 as-req AS-REQ, 2926 as-rep AS-REP, 2927 tgs-req TGS-REQ, 2928 tgs-rep TGS-REP, 2929 ap-req AP-REQ, 2930 ap-rep AP-REP, 2931 krb-safe KRB-SAFE, 2932 krb-priv KRB-PRIV, 2933 krb-cred KRB-CRED, 2934 tgt-req TGT-REQ, 2935 krb-error KRB-ERROR, 2936 ... 2937 } 2938 2939 2940 2941 -- 2942 -- *** basic types 2943 -- 2944 2945 2946 2947 -- signed values representable in 32 bits 2948 -- 2949 -- These are often used as assigned numbers for various things. 2950 Int32 ::= INTEGER (-2147483648..2147483647) 2951 2952 2953 -- unsigned 32 bit values 2954 UInt32 ::= INTEGER (0..4294967295) 2955 2956 2957 2958 -- unsigned 64 bit values 2959 UInt64 ::= INTEGER (0..18446744073709551615) 2960 2961 2962 2963 -- microseconds 2964 Microseconds ::= INTEGER (0..999999) 2965 2966 2967 2968 -- sequence numbers 2969 SeqNum ::= UInt64 2970 2971 2972 2973 -- nonces 2974 Nonce ::= UInt64 2975 2976 2977 2978Yu Expires: Jan 2005 [Page 46] 2979Internet-Draft yu-krb-extensions-01 19 Jul 2004 2980 2981 2982 -- must not have fractional seconds 2983 KerberosTime ::= GeneralizedTime 2984 2985 2986 2987 -- used for names and for error messages 2988 KerberosString ::= CHOICE { 2989 ia5 GeneralString (IA5String), 2990 utf8 UTF8String, 2991 ... -- no extension may be sent 2992 -- to an rfc1510 implementation -- 2993 } 2994 2995 2996 2997 -- IA5 choice only; useful for constraints 2998 KerberosStringIA5 ::= KerberosString 2999 (WITH COMPONENTS { ia5 PRESENT }) 3000 3001 3002 -- IA5 excluded; useful for constraints 3003 KerberosStringExt ::= KerberosString 3004 (WITH COMPONENTS { ia5 ABSENT }) 3005 3006 3007 3008 -- used for language tags 3009 LangTag ::= PrintableString 3010 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 3011 3012 3013 3014 -- assigned numbers for name types (used in principal names) 3015 NameType ::= Int32 3016 3017 3018 -- Name type not known 3019 nt-unknown NameType ::= 0 3020 -- Just the name of the principal as in DCE, or for users 3021 nt-principal NameType ::= 1 3022 -- Service and other unique instance (krbtgt) 3023 nt-srv-inst NameType ::= 2 3024 -- Service with host name as instance (telnet, rcommands) 3025 nt-srv-hst NameType ::= 3 3026 -- Service with host as remaining components 3027 nt-srv-xhst NameType ::= 4 3028 -- Unique ID 3029 nt-uid NameType ::= 5 3030 -- Encoded X.509 Distingished name [RFC 2253] 3031 nt-x500-principal NameType ::= 6 3032 -- Name in form of SMTP email name (e.g. user@foo.com) 3033 nt-smtp-name NameType ::= 7 3034 -- Enterprise name - may be mapped to principal name 3035 nt-enterprise NameType ::= 10 3036 3037 3038 3039 3040 3041Yu Expires: Jan 2005 [Page 47] 3042Internet-Draft yu-krb-extensions-01 19 Jul 2004 3043 3044 3045 PrincipalName ::= SEQUENCE { 3046 name-type [0] NameType, 3047 -- May have zero elements, or individual elements may be 3048 -- zero-length, but this is not recommended. 3049 name-string [1] SEQUENCE OF KerberosString 3050 } 3051 3052 3053 3054 -- IA5 only 3055 PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS { 3056 ..., 3057 name-string (WITH COMPONENT (KerberosStringIA5)) 3058 }) 3059 3060 3061 -- IA5 excluded 3062 PrincipalNameExt ::= PrincpalName (WITH COMPONENTS { 3063 ..., 3064 name-string (WITH COMPONENT (KerberosStringExt)) 3065 }) 3066 3067 3068 3069 Realm ::= KerberosString 3070 3071 3072 -- IA5 only 3073 RealmIA5 ::= Realm (KerberosStringIA5) 3074 3075 3076 -- IA5 excluded 3077 RealmExt ::= Realm (KerberosStringExt) 3078 3079 3080 3081 -- Yet another refinement to kludge around historical 3082 -- implementation bugs... we still send at least 32 bits, but 3083 -- this parameterized type allows us to actually use named bit 3084 -- string syntax to define flags, sort of. 3085 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 3086 (CONSTRAINED BY { 3087 -- must be a valid value of -- NamedBits 3088 -- but if the value to be sent would otherwise be shorter 3089 -- than 32 bits, it must be padded with trailing zero bits 3090 -- to 32 bits. Otherwise, no trailing zero bits may be 3091 -- present. 3092 }) 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104Yu Expires: Jan 2005 [Page 48] 3105Internet-Draft yu-krb-extensions-01 19 Jul 2004 3106 3107 3108 AddrType ::= Int32 3109 3110 3111 HostAddress ::= SEQUENCE { 3112 addr-type [0] AddrType, 3113 address [1] OCTET STRING 3114 } 3115 3116 3117 -- NOTE: HostAddresses is always used as an OPTIONAL field and 3118 -- should not be a zero-length SEQUENCE OF. 3119 -- 3120 -- The extensible messages explicitly constrain this to be 3121 -- non-empty. 3122 HostAddresses ::= SEQUENCE OF HostAddress 3123 3124 3125 3126 -- 3127 -- *** crypto-related types and assignments 3128 -- 3129 3130 3131 3132 -- Assigned numbers denoting encryption mechanisms. 3133 EType ::= Int32 3134 3135 3136 -- assigned numbers for encryption schemes 3137 et-des-cbc-crc EType ::= 1 3138 et-des-cbc-md4 EType ::= 2 3139 et-des-cbc-md5 EType ::= 3 3140 -- [reserved] 4 3141 et-des3-cbc-md5 EType ::= 5 3142 -- [reserved] 6 3143 et-des3-cbc-sha1 EType ::= 7 3144 et-dsaWithSHA1-CmsOID EType ::= 9 3145 et-md5WithRSAEncryption-CmsOID EType ::= 10 3146 et-sha1WithRSAEncryption-CmsOID EType ::= 11 3147 et-rc2CBC-EnvOID EType ::= 12 3148 et-rsaEncryption-EnvOID EType ::= 13 3149 et-rsaES-OAEP-ENV-OID EType ::= 14 3150 et-des-ede3-cbc-Env-OID EType ::= 15 3151 et-des3-cbc-sha1-kd EType ::= 16 3152 -- AES 3153 et-aes128-cts-hmac-sha1-96 EType ::= 17 3154 -- AES 3155 et-aes256-cts-hmac-sha1-96 EType ::= 18 3156 -- Microsoft 3157 et-rc4-hmac EType ::= 23 3158 -- Microsoft 3159 et-rc4-hmac-exp EType ::= 24 3160 -- opaque; PacketCable 3161 et-subkey-keymaterial EType ::= 65 3162 3163 3164 3165 3166Yu Expires: Jan 2005 [Page 49] 3167Internet-Draft yu-krb-extensions-01 19 Jul 2004 3168 3169 3170 -- Assigned numbers denoting key usages. 3171 KeyUsage ::= UInt32 3172 3173 3174 -- 3175 -- Actual identifier names are provisional and subject to 3176 -- change. 3177 -- 3178 ku-pa-enc-ts KeyUsage ::= 1 3179 ku-Ticket KeyUsage ::= 2 3180 ku-EncASRepPart KeyUsage ::= 3 3181 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 3182 ku-TGSReqAuthData-subkey KeyUsage ::= 5 3183 ku-pa-TGSReq-cksum KeyUsage ::= 6 3184 ku-pa-TGSReq-authenticator KeyUsage ::= 7 3185 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 3186 ku-EncTGSRepPart-subkey KeyUsage ::= 9 3187 ku-Authenticator-cksum KeyUsage ::= 10 3188 ku-APReq-authenticator KeyUsage ::= 11 3189 ku-EncAPRepPart KeyUsage ::= 12 3190 ku-EncKrbPrivPart KeyUsage ::= 13 3191 ku-EncKrbCredPart KeyUsage ::= 14 3192 ku-KrbSafe-cksum KeyUsage ::= 15 3193 ku-ad-KDCIssued-cksum KeyUsage ::= 19 3194 3195 3196 3197 -- The following numbers are provisional... 3198 -- conflicts may exist elsewhere. 3199 ku-Ticket-cksum KeyUsage ::= 25 3200 ku-ASReq-cksum KeyUsage ::= 26 3201 ku-TGSReq-cksum KeyUsage ::= 27 3202 ku-ASRep-cksum KeyUsage ::= 28 3203 ku-TGSRep-cksum KeyUsage ::= 29 3204 ku-APReq-cksum KeyUsage ::= 30 3205 ku-APRep-cksum KeyUsage ::= 31 3206 ku-KrbCred-cksum KeyUsage ::= 32 3207 ku-KrbError-cksum KeyUsage ::= 33 3208 ku-KDCRep-cksum KeyUsage ::= 34 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225Yu Expires: Jan 2005 [Page 50] 3226Internet-Draft yu-krb-extensions-01 19 Jul 2004 3227 3228 3229 -- KeyToUse identifies which key is to be used to encrypt or 3230 -- sign a given value. 3231 -- 3232 -- Values of KeyToUse are never actually transmitted over the 3233 -- wire, or even used directly by the implementation in any 3234 -- way, as key usages are; it exists primarily to identify 3235 -- which key gets used for what purpose. Thus, the specific 3236 -- numeric values associated with this type are irrelevant. 3237 KeyToUse ::= ENUMERATED { 3238 -- unspecified 3239 key-unspecified, 3240 -- server long term key 3241 key-server, 3242 -- client long term key 3243 key-client, 3244 -- key selected by KDC for encryption of a KDC-REP 3245 key-kdc-rep, 3246 -- session key from ticket 3247 key-session, 3248 -- subsession key negotiated via AP-REQ/AP-REP 3249 key-subsession, 3250 ... 3251 } 3252 3253 3254 3255 EncryptionKey ::= SEQUENCE { 3256 keytype [0] EType, 3257 keyvalue [1] OCTET STRING 3258 } 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283Yu Expires: Jan 2005 [Page 51] 3284Internet-Draft yu-krb-extensions-01 19 Jul 2004 3285 3286 3287 3288 -- "Type" specifies which ASN.1 type is encrypted to the 3289 -- ciphertext in the EncryptedData. "Keys" specifies a set of 3290 -- keys of which one key may be used to encrypt the data. 3291 -- "KeyUsages" specifies a set of key usages, one of which may 3292 -- be used to encrypt. 3293 -- 3294 -- None of the parameters is transmitted over the wire. 3295 EncryptedData { 3296 Type, KeyToUse:Keys, KeyUsage:KeyUsages 3297 } ::= SEQUENCE { 3298 etype [0] EType, 3299 kvno [1] UInt32 OPTIONAL, 3300 cipher [2] OCTET STRING (CONSTRAINED BY { 3301 -- must be encryption of -- 3302 OCTET STRING (CONTAINING Type), 3303 -- with one of the keys -- KeyToUse:Keys, 3304 -- with key usage being one of -- 3305 KeyUsage:KeyUsages 3306 }), 3307 ... 3308 } 3309 3310 3311 3312 3313 CksumType ::= Int32 3314 3315 3316 -- The parameters specify which key to use to produce the 3317 -- signature, as well as which key usage to use. The 3318 -- parameters are not actually sent over the wire. 3319 Checksum { 3320 KeyToUse:Keys, KeyUsage:KeyUsages 3321 } ::= SEQUENCE { 3322 cksumtype [0] CksumType, 3323 checksum [1] OCTET STRING (CONSTRAINED BY { 3324 -- signed using one of the keys -- 3325 KeyToUse:Keys, 3326 -- with key usage being one of -- 3327 KeyUsage:KeyUsages 3328 }) 3329 } 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342Yu Expires: Jan 2005 [Page 52] 3343Internet-Draft yu-krb-extensions-01 19 Jul 2004 3344 3345 3346 -- a Checksum that must contain the checksum 3347 -- of a particular type 3348 ChecksumOf { 3349 Type, KeyToUse:Keys, KeyUsage:KeyUsages 3350 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 3351 ..., 3352 checksum (CONSTRAINED BY { 3353 -- must be checksum of -- 3354 OCTET STRING (CONTAINING Type) 3355 }) 3356 }) 3357 3358 3359 3360 -- parameterized type for wrapping authenticated plaintext 3361 Signed { 3362 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 3363 } ::= SEQUENCE { 3364 cksum [0] ChecksumOf { 3365 InnerType, Keys, KeyUsages 3366 } OPTIONAL, 3367 inner [1] InnerType, 3368 ... 3369 } 3370 3371 3372 3373 -- 3374 -- *** Tickets 3375 -- 3376 3377 3378 3379 Ticket ::= CHOICE { 3380 rfc1510 [APPLICATION 1] Ticket1510, 3381 ext [APPLICATION 4] Signed { 3382 TicketExt, { key-server }, { ku-Ticket-cksum } 3383 } 3384 } 3385 3386 3387 3388 -- takes a parameter specifying which type gets encrypted 3389 TicketCommon { EncPart } ::= SEQUENCE { 3390 tkt-vno [0] INTEGER (5), 3391 realm [1] Realm, 3392 sname [2] PrincipalName, 3393 enc-part [3] EncryptedData { 3394 EncPart, { key-server }, { ku-Ticket } 3395 }, 3396 ..., 3397 extensions [4] TicketExtensions OPTIONAL, 3398 ... 3399 } 3400 3401 3402 3403Yu Expires: Jan 2005 [Page 53] 3404Internet-Draft yu-krb-extensions-01 19 Jul 2004 3405 3406 3407 Ticket1510 ::= SEQUENCE { 3408 COMPONENTS OF TicketCommon { EncTicketPart1510 } 3409 } (WITH COMPONENTS { 3410 ..., 3411 -- explicitly force IA5 in strings 3412 realm (RealmIA5), 3413 sname (PrincipalNameIA5) 3414 }) 3415 3416 3417 3418 -- APPLICATION tag goes inside Signed{} as well as outside, 3419 -- to prevent possible substitution attacks. 3420 TicketExt ::= [APPLICATION 4] TicketCommon { 3421 EncTicketPartExt 3422 } (WITH COMPONENTS { 3423 ..., 3424 -- explicitly force UTF-8 in strings 3425 realm (RealmExt), 3426 sname (PrincipalNameExt) 3427 }) 3428 3429 3430 3431 -- Encrypted part of ticket 3432 EncTicketPart ::= CHOICE { 3433 rfc1510 [APPLICATION 3] EncTicketPart1510, 3434 ext [APPLICATION 5] EncTicketPartExt 3435 } 3436 3437 3438 3439 EncTicketPartCommon ::= SEQUENCE { 3440 flags [0] TicketFlags, 3441 key [1] EncryptionKey, 3442 crealm [2] Realm, 3443 cname [3] PrincipalName, 3444 transited [4] TransitedEncoding, 3445 authtime [5] KerberosTime, 3446 starttime [6] KerberosTime OPTIONAL, 3447 endtime [7] KerberosTime, 3448 renew-till [8] KerberosTime OPTIONAL, 3449 caddr [9] HostAddresses OPTIONAL, 3450 authorization-data [10] AuthorizationData OPTIONAL, 3451 ... 3452 } 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463Yu Expires: Jan 2005 [Page 54] 3464Internet-Draft yu-krb-extensions-01 19 Jul 2004 3465 3466 3467 EncTicketPart1510 ::= SEQUENCE { 3468 COMPONENTS OF EncTicketPartCommon 3469 } (WITH COMPONENTS { 3470 ..., 3471 -- explicitly force IA5 in strings 3472 crealm (RealmIA5), 3473 cname (PrincipalNameIA5) 3474 }) 3475 3476 3477 3478 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS { 3479 ..., 3480 -- explicitly force UTF-8 in strings 3481 crealm (RealmExt), 3482 cname (PrincipalNameExt), 3483 -- explicitly constrain caddr to be non-empty if present 3484 caddr (SIZE (1..MAX)), 3485 -- forbid empty authorization-data encodings 3486 authorization-data (SIZE (1..MAX)) 3487 }) 3488 3489 3490 3491 -- 3492 -- *** Authorization Data 3493 -- 3494 3495 3496 3497 ADType ::= Int32 3498 3499 3500 AuthorizationData ::= SEQUENCE OF SEQUENCE { 3501 ad-type [0] ADType, 3502 ad-data [1] OCTET STRING 3503 } 3504 3505 3506 3507 ad-if-relevant ADType ::= 1 3508 3509 3510 -- Encapsulates another AuthorizationData. 3511 -- Intended for application servers; receiving application servers 3512 -- MAY ignore. 3513 AD-IF-RELEVANT ::= AuthorizationData 3514 } 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526Yu Expires: Jan 2005 [Page 55] 3527Internet-Draft yu-krb-extensions-01 19 Jul 2004 3528 3529 3530 -- KDC-issued privilege attributes 3531 ad-kdcissued ADType ::= 4 3532 3533 3534 AD-KDCIssued ::= SEQUENCE { 3535 ad-checksum [0] ChecksumOf { 3536 AuthorizationData, { key-session }, 3537 { ku-ad-KDCIssued-cksum }}, 3538 i-realm [1] Realm OPTIONAL, 3539 i-sname [2] PrincipalName OPTIONAL, 3540 elements [3] AuthorizationData 3541 } 3542 3543 3544 3545 ad-and-or ADType ::= 5 3546 3547 3548 AD-AND-OR ::= SEQUENCE { 3549 condition-count [0] INTEGER, 3550 elements [1] AuthorizationData 3551 } 3552 3553 3554 3555 -- KDCs MUST interpret any AuthorizationData wrapped in this. 3556 ad-mandatory-for-kdc ADType ::= 8 3557 AD-MANDATORY-FOR-KDC ::= AuthorizationData 3558 3559 3560 3561 TrType ::= Int32 -- must be registered 3562 3563 3564 -- encoded Transited field 3565 TransitedEncoding ::= SEQUENCE { 3566 tr-type [0] TrType, 3567 contents [1] OCTET STRING 3568 } 3569 3570 3571 3572 TEType ::= Int32 3573 3574 3575 -- ticket extensions: for TicketExt only 3576 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 3577 te-type [0] TEType, 3578 te-data [1] OCTET STRING 3579 } 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591Yu Expires: Jan 2005 [Page 56] 3592Internet-Draft yu-krb-extensions-01 19 Jul 2004 3593 3594 3595 TicketFlags ::= KerberosFlags { TicketFlagsBits } 3596 3597 3598 TicketFlagsBits ::= BIT STRING { 3599 reserved (0), 3600 forwardable (1), 3601 forwarded (2), 3602 proxiable (3), 3603 proxy (4), 3604 may-postdate (5), 3605 postdated (6), 3606 invalid (7), 3607 renewable (8), 3608 initial (9), 3609 pre-authent (10), 3610 hw-authent (11), 3611 transited-policy-checked (12), 3612 ok-as-delegate (13), 3613 anonymous (14), 3614 cksummed-ticket (15) 3615 } 3616 3617 3618 3619 -- 3620 -- *** KDC protocol 3621 -- 3622 3623 3624 3625 AS-REQ ::= CHOICE { 3626 rfc1510 [APPLICATION 10] KDC-REQ-1510 3627 (WITH COMPONENTS { 3628 ..., 3629 msg-type (10), 3630 -- AS-REQ must include client name 3631 req-body (WITH COMPONENTS { ..., cname PRESENT }) 3632 }), 3633 ext [APPLICATION 6] Signed { 3634 -- APPLICATION tag goes inside Signed{} as well as 3635 -- outside, to prevent possible substitution attacks. 3636 [APPLICATION 6] KDC-REQ-EXT, 3637 -- not sure this is correct key to use; do we even want 3638 -- to sign AS-REQ? 3639 { key-client }, 3640 { ku-ASReq-cksum } 3641 } 3642 (WITH COMPONENTS { 3643 ..., 3644 msg-type (6), 3645 -- AS-REQ must include client name 3646 req-body (WITH COMPONENTS { ..., cname PRESENT }) 3647 }) 3648 } 3649 3650 3651Yu Expires: Jan 2005 [Page 57] 3652Internet-Draft yu-krb-extensions-01 19 Jul 2004 3653 3654 3655 TGS-REQ ::= CHOICE { 3656 rfc1510 [APPLICATION 12] KDC-REQ-1510 3657 (WITH COMPONENTS { 3658 ..., 3659 msg-type (12), 3660 -- client name optional in TGS-REQ 3661 req-body (WITH COMPONENTS { ..., cname ABSENT }) 3662 }), 3663 ext [APPLICATION 8] Signed { 3664 -- APPLICATION tag goes inside Signed{} as well as 3665 -- outside, to prevent possible substitution attacks. 3666 [APPLICATION 8] KDC-REQ-EXT, 3667 { key-session }, { ku-TGSReq-cksum } 3668 } 3669 (WITH COMPONENTS { 3670 ..., 3671 msg-type (8), 3672 -- client name optional in TGS-REQ 3673 req-body (WITH COMPONENTS { ..., cname ABSENT }) 3674 }) 3675 } 3676 3677 3678 3679 KDC-REQ-COMMON ::= SEQUENCE { 3680 -- NOTE: first tag is [1], not [0] 3681 pvno [1] INTEGER (5), 3682 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- 3683 | 12 -- TGS-REQ.rfc1510 -- 3684 | 6 -- AS-REQ.ext -- 3685 | 8 -- TGS-REQ.ext -- ), 3686 padata [3] SEQUENCE OF PA-DATA OPTIONAL 3687 -- NOTE: not empty 3688 } 3689 3690 3691 3692 KDC-REQ-1510 ::= SEQUENCE { 3693 COMPONENTS OF KDC-REQ-COMMON, 3694 req-body [4] KDC-REQ-BODY-1510 3695 } (WITH COMPONENTS { ..., msg-type (10 | 12) }) 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710Yu Expires: Jan 2005 [Page 58] 3711Internet-Draft yu-krb-extensions-01 19 Jul 2004 3712 3713 3714 -- APPLICATION tag goes inside Signed{} as well as outside, 3715 -- to prevent possible substitution attacks. 3716 KDC-REQ-EXT ::= SEQUENCE { 3717 COMPONENTS OF KDC-REQ-COMMON, 3718 req-body [4] KDC-REQ-BODY-EXT, 3719 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 3720 LangTag OPTIONAL, 3721 ... 3722 } (WITH COMPONENTS { 3723 ..., 3724 msg-type (6 | 8), 3725 padata (SIZE (1..MAX)) 3726 }) 3727 3728 3729 3730 KDC-REQ-BODY-COMMON ::= SEQUENCE { 3731 kdc-options [0] KDCOptions, 3732 cname [1] PrincipalName OPTIONAL 3733 -- Used only in AS-REQ --, 3734 3735 3736 realm [2] Realm 3737 -- Server's realm; also client's in AS-REQ --, 3738 3739 3740 sname [3] PrincipalName OPTIONAL, 3741 from [4] KerberosTime OPTIONAL, 3742 till [5] KerberosTime OPTIONAL 3743 -- was required in rfc1510; 3744 -- still required for compat versions 3745 -- of messages --, 3746 3747 3748 rtime [6] KerberosTime OPTIONAL, 3749 nonce [7] Nonce, 3750 etype [8] SEQUENCE OF EType 3751 -- in preference order --, 3752 3753 3754 addresses [9] HostAddresses OPTIONAL, 3755 enc-authorization-data [10] EncryptedData { 3756 AuthorizationData, { key-session | key-subsession }, 3757 { ku-TGSReqAuthData-subkey | 3758 ku-TGSReqAuthData-sesskey } 3759 } OPTIONAL, 3760 3761 3762 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3763 -- NOTE: not empty --, 3764 ... 3765 } 3766 3767 3768 3769 3770 3771 3772 3773Yu Expires: Jan 2005 [Page 59] 3774Internet-Draft yu-krb-extensions-01 19 Jul 2004 3775 3776 3777 KDC-REQ-BODY-1510 ::= SEQUENCE { 3778 COMPONENTS OF KDC-REQ-BODY-COMMON 3779 } (WITH COMPONENTS { 3780 ..., 3781 cname (PrincipalNameIA5), 3782 realm (RealmIA5), 3783 sname (PrincipalNameIA5), 3784 till PRESENT, 3785 nonce (UInt32) 3786 }) 3787 3788 3789 3790 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON 3791 (WITH COMPONENTS { 3792 ..., 3793 cname (PrincipalNameExt), 3794 realm (RealmExt), 3795 sname (PrincipalNameExt), 3796 addresses (SIZE (1..MAX)), 3797 enc-authorization-data (EncryptedData { 3798 AuthorizationData (SIZE (1..MAX)), 3799 { key-session | key-subsession }, 3800 { ku-TGSReqAuthData-subkey | 3801 ku-TGSReqAuthData-sesskey } 3802 }), 3803 additional-tickets (SIZE (1..MAX)) 3804 }) 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831Yu Expires: Jan 2005 [Page 60] 3832Internet-Draft yu-krb-extensions-01 19 Jul 2004 3833 3834 3835 KDCOptions ::= KerberosFlags { KDCOptionsBits } 3836 KDCOptionsBits ::= BIT STRING { 3837 reserved (0), 3838 forwardable (1), 3839 forwarded (2), 3840 proxiable (3), 3841 proxy (4), 3842 allow-postdate (5), 3843 postdated (6), 3844 unused7 (7), 3845 renewable (8), 3846 unused9 (9), 3847 unused10 (10), 3848 unused11 (11), 3849 unused12 (12), 3850 unused13 (13), 3851 requestanonymous (14), 3852 canonicalize (15), 3853 disable-transited-check (26), 3854 renewable-ok (27), 3855 enc-tkt-in-skey (28), 3856 renew (30), 3857 validate (31) 3858 -- XXX need "need ticket1" flag? 3859 } 3860 3861 3862 3863 AS-REP ::= CHOICE { 3864 rfc1510 [APPLICATION 11] KDC-REP-1510 { 3865 EncASRepPart1510 3866 } (WITH COMPONENTS { ..., msg-type (11) }), 3867 ext [APPLICATION 7] Signed { 3868 [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt }, 3869 { key-reply }, { ku-ASRep-cksum } 3870 } (WITH COMPONENTS { ..., msg-type (7) }) 3871 } 3872 3873 3874 3875 TGS-REP ::= CHOICE { 3876 rfc1510 [APPLICATION 13] KDC-REP-1510 { 3877 EncTGSRepPart1510 3878 } (WITH COMPONENTS { ..., msg-type (13) }), 3879 ext [APPLICATION 9] Signed { 3880 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 3881 { key-reply }, { ku-TGSRep-cksum } 3882 } (WITH COMPONENTS { ..., msg-type (9) }) 3883 } 3884 3885 3886 3887 3888 3889 3890Yu Expires: Jan 2005 [Page 61] 3891Internet-Draft yu-krb-extensions-01 19 Jul 2004 3892 3893 3894 KDC-REP-COMMON { EncPart } ::= SEQUENCE { 3895 pvno [0] INTEGER (5), 3896 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 3897 13 -- TGS.rfc1510 -- | 3898 7 -- AS-REP.ext -- | 3899 9 -- TGS-REP.ext -- ), 3900 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 3901 crealm [3] Realm, 3902 cname [4] PrincipalName, 3903 ticket [5] Ticket, 3904 enc-part [6] EncryptedData { 3905 EncPart, 3906 { key-reply }, 3907 -- maybe reach into EncryptedData in AS-REP/TGS-REP 3908 -- definitions to apply constraints on key usages? 3909 { ku-EncASRepPart -- if AS-REP -- | 3910 ku-EncTGSRepPart-subkey -- if TGS-REP and 3911 -- using Authenticator 3912 -- session key -- | 3913 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 3914 -- subsession key -- } 3915 }, 3916 ..., 3917 -- In extensible version, KDC signs original request 3918 -- to avoid replay attacks agaginst client. 3919 req-cksum [7] ChecksumOf { CHOICE { 3920 as-req AS-REQ, 3921 tgs-req TGS-REQ 3922 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 3923 lang-tag [8] LangTag OPTIONAL, 3924 ... 3925 } 3926 3927 3928 3929 KDC-REP-1510 { EncPart } ::= SEQUENCE { 3930 COMPONENTS OF KDC-REP-COMMON { EncPart } 3931 } (WITH COMPONENTS { 3932 ..., 3933 msg-type (11 | 13), 3934 crealm (RealmIA5), 3935 cname (PrincipalNameIA5) 3936 }) 3937 3938 3939 3940 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart } 3941 (WITH COMPONENTS { 3942 ..., 3943 msg-type (7 | 9), 3944 crealm (RealmExt), 3945 cname (PrincipalNameExt) 3946 }) 3947 3948 3949Yu Expires: Jan 2005 [Page 62] 3950Internet-Draft yu-krb-extensions-01 19 Jul 2004 3951 3952 3953 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 3954 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 3955 3956 3957 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 3958 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 3959 3960 3961 EncKDCRepPartCom ::= SEQUENCE { 3962 key [0] EncryptionKey, 3963 last-req [1] LastReq, 3964 nonce [2] Nonce, 3965 key-expiration [3] KerberosTime OPTIONAL, 3966 flags [4] TicketFlags, 3967 authtime [5] KerberosTime, 3968 starttime [6] KerberosTime OPTIONAL, 3969 endtime [7] KerberosTime, 3970 renew-till [8] KerberosTime OPTIONAL, 3971 srealm [9] Realm, 3972 sname [10] PrincipalName, 3973 caddr [11] HostAddresses OPTIONAL, 3974 ... 3975 } 3976 3977 3978 EncKDCRepPart1510 ::= SEQUENCE { 3979 COMPONENTS OF EncKDCRepPartCom 3980 } (WITH COMPONENTS { 3981 ..., 3982 srealm (RealmIA5), 3983 sname (PrincipalNameIA5), 3984 nonce UInt32 }) 3985 3986 3987 EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS { 3988 ..., 3989 srealm (RealmExt), 3990 sname (PrincipalNameExt) 3991 }) 3992 3993 3994 3995 LRType ::= Int32 3996 LastReq ::= SEQUENCE OF SEQUENCE { 3997 lr-type [0] LRType, 3998 lr-value [1] KerberosTime 3999 } 4000 4001 4002 4003 -- 4004 -- *** preauth 4005 -- 4006 4007 4008 4009 4010 4011 4012Yu Expires: Jan 2005 [Page 63] 4013Internet-Draft yu-krb-extensions-01 19 Jul 2004 4014 4015 4016 PaDataType ::= Int32 4017 PaDataOID ::= RELATIVE-OID 4018 4019 4020 PA-DATA ::= SEQUENCE { 4021 -- NOTE: first tag is [1], not [0] 4022 padata-type [1] CHOICE { 4023 int PaDataType, 4024 -- example of possible use 4025 -- of RELATIVE-OIDs 4026 oid PaDataOID 4027 }, 4028 padata-value [2] OCTET STRING 4029 } 4030 4031 4032 4033 PaDataSet PADATA-OBJ ::= { 4034 pa-tgs-req | 4035 pa-enc-timestamp | 4036 pa-etype-info | 4037 pa-etype-info2 | 4038 pa-pw-salt | 4039 pa-as-req , 4040 ... 4041 } 4042 4043 4044 4045 -- AP-REQ authenticating a TGS-REQ 4046 pa-tgs-req PaDataType ::= 1 4047 PA-TGS-REQ ::= AP-REQ 4048 4049 4050 4051 -- Encrypted timestamp preauth 4052 -- Encryption key used is client's long-term key. 4053 pa-enc-timestamp PaDataType ::= 2 4054 4055 4056 PA-ENC-TIMESTAMP ::= EncryptedData { 4057 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } 4058 } 4059 4060 4061 PA-ENC-TS-ENC ::= SEQUENCE { 4062 patimestamp [0] KerberosTime -- client's time --, 4063 pausec [1] Microseconds OPTIONAL 4064 } 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075Yu Expires: Jan 2005 [Page 64] 4076Internet-Draft yu-krb-extensions-01 19 Jul 2004 4077 4078 4079 -- Hints returned in AS-REP or KRB-ERROR to help client 4080 -- choose a password-derived key, either for preauthentication 4081 -- or for decryption of the reply. 4082 pa-etype-info PaDataType ::= 11 4083 4084 4085 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 4086 4087 4088 ETYPE-INFO-ENTRY ::= SEQUENCE { 4089 etype [0] EType, 4090 salt [1] OCTET STRING OPTIONAL 4091 } 4092 4093 4094 4095 -- Similar to etype-info, but with parameters provided for 4096 -- the string-to-key function. 4097 pa-etype-info2 PaDataType ::= 19 4098 4099 4100 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) 4101 OF ETYPE-INFO-ENTRY 4102 4103 4104 ETYPE-INFO2-ENTRY ::= SEQUENCE { 4105 etype [0] EType, 4106 salt [1] KerberosString OPTIONAL, 4107 s2kparams [2] OCTET STRING OPTIONAL 4108 } 4109 4110 4111 4112 -- Obsolescent. Salt for client's long-term key. 4113 -- Its character encoding is unspecified. 4114 pa-pw-salt PaDataType ::= 3 4115 -- The "padata-value" does not encode an ASN.1 type. 4116 -- Instead, "padata-value" must consist of the salt string to 4117 -- be used by the client, in an unspecified character 4118 -- encoding. 4119 } 4120 4121 4122 4123 -- An extensible AS-REQ may be sent as a padata in a 4124 -- non-extensible AS-REQ to allow for backwards compatibility. 4125 pa-as-req PaDataType ::= 42 -- provisional 4126 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) 4127 4128 4129 4130 -- 4131 -- *** Session key exchange 4132 -- 4133 4134 4135 4136 4137 4138 4139 4140Yu Expires: Jan 2005 [Page 65] 4141Internet-Draft yu-krb-extensions-01 19 Jul 2004 4142 4143 4144 AP-REQ ::= CHOICE { 4145 rfc1510 [APPLICATION 14] AP-REQ-1510, 4146 ext [APPLICATION 18] Signed { 4147 AP-REQ-EXT, { key-session }, { ku-APReq-cksum } 4148 } 4149 } 4150 4151 4152 4153 AP-REQ-COMMON ::= SEQUENCE { 4154 pvno [0] INTEGER (5), 4155 msg-type [1] INTEGER (14 | 18), 4156 ap-options [2] APOptions, 4157 ticket [3] Ticket, 4158 authenticator [4] EncryptedData { 4159 Authenticator, 4160 { key-session }, 4161 { ku-APReq-authenticator | 4162 ku-pa-TGSReq-authenticator } 4163 }, 4164 ..., 4165 extensions [5] ApReqExtensions OPTIONAL, 4166 ... 4167 } 4168 4169 4170 4171 AP-REQ-1510 ::= SEQUENCE { 4172 COMPONENTS OF AP-REQ-COMMON 4173 } (WITH COMPONENTS { 4174 ..., 4175 msg-type (14), 4176 authenticator (EncryptedData { 4177 Authenticator (WITH COMPONENTS { 4178 ..., 4179 crealm (RealmIA5), 4180 cname (PrincipalNameIA5), 4181 seqnum (UInt32) 4182 }), { key-session }, { ku-APReq-authenticator }}) 4183 }) 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199Yu Expires: Jan 2005 [Page 66] 4200Internet-Draft yu-krb-extensions-01 19 Jul 2004 4201 4202 4203 AP-REQ-EXT ::= AP-REQ-COMMON 4204 (WITH COMPONENTS { 4205 ..., 4206 msg-type (18), 4207 -- The following constraints on Authenticator assume that 4208 -- we want to restrict the use of AP-REQ-EXT with TicketExt 4209 -- only, since that is the only way we can enforce UTF-8. 4210 authenticator (EncryptedData { 4211 Authenticator (WITH COMPONENTS { 4212 ..., 4213 crealm (RealmExt), 4214 cname (PrincipalNameExt), 4215 authorization-data (SIZE (1..MAX)) 4216 }), { key-session }, { ku-APReq-authenticator }}) 4217 }) 4218 4219 4220 4221 ApReqExtType ::= Int32 4222 4223 4224 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4225 apReqExt-Type [0] ApReqExtType, 4226 apReqExt-Data [1] OCTET STRING 4227 } 4228 4229 4230 4231 APOptions ::= KerberosFlags { APOptionsBits } 4232 4233 4234 APOptionsBits ::= BIT STRING { 4235 reserved (0), 4236 use-session-key (1), 4237 mutual-required (2) 4238 } 4239 4240 4241 4242 -- plaintext of authenticator 4243 Authenticator ::= [APPLICATION 2] SEQUENCE { 4244 authenticator-vno [0] INTEGER (5), 4245 crealm [1] Realm, 4246 cname [2] PrincipalName, 4247 cksum [3] Checksum {{ key-session }, 4248 { ku-Authenticator-cksum | 4249 ku-pa-TGSReq-cksum }} OPTIONAL, 4250 cusec [4] Microseconds, 4251 ctime [5] KerberosTime, 4252 subkey [6] EncryptionKey OPTIONAL, 4253 seq-number [7] SeqNum OPTIONAL, 4254 authorization-data [8] AuthorizationData OPTIONAL 4255 } 4256 4257 4258 4259 4260 4261Yu Expires: Jan 2005 [Page 67] 4262Internet-Draft yu-krb-extensions-01 19 Jul 2004 4263 4264 4265 AP-REP ::= CHOICE { 4266 rfc1510 [APPLICATION 15] AP-REP-1510, 4267 ext [APPLICATION 19] Signed { 4268 AP-REP-EXT, 4269 { key-session | key-subsession }, { ku-APRep-cksum }} 4270 } 4271 4272 4273 4274 AP-REP-COMMON { EncPart } ::= SEQUENCE { 4275 pvno [0] INTEGER (5), 4276 msg-type [1] INTEGER (15 | 19), 4277 enc-part [2] EncryptedData { 4278 EncPart, 4279 { key-session | key-subsession }, { ku-EncAPRepPart }}, 4280 ..., 4281 extensions [3] ApRepExtensions OPTIONAL, 4282 ... 4283 } 4284 4285 4286 4287 AP-REP-1510 ::= SEQUENCE { 4288 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 } 4289 } (WITH COMPONENTS { 4290 ..., 4291 msg-type (15) 4292 }) 4293 4294 4295 4296 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON { 4297 EncAPRepPartExt 4298 } (WITH COMPONENTS { ..., msg-type (19) }) 4299 4300 4301 4302 ApRepExtType ::= Int32 4303 4304 4305 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4306 apRepExt-Type [0] ApRepExtType, 4307 apRepExt-Data [1] OCTET STRING 4308 } 4309 4310 4311 4312 EncAPRepPart ::= CHOICE { 4313 rfc1510 [APPLICATION 27] EncAPRepPart1510, 4314 ext [APPLICATION 31] EncAPRepPartExt 4315 } 4316 4317 4318 4319 4320 4321 4322 4323 4324Yu Expires: Jan 2005 [Page 68] 4325Internet-Draft yu-krb-extensions-01 19 Jul 2004 4326 4327 4328 EncAPRepPart1510 ::= SEQUENCE { 4329 COMPONENTS OF ENCAPRepPartCom 4330 } (WITH COMPONENTS { 4331 ..., 4332 seq-number (UInt32), 4333 authorization-data ABSENT 4334 }) 4335 4336 4337 4338 EncAPRepPartExt ::= EncAPRepPartCom 4339 4340 4341 4342 EncAPRepPartCom ::= SEQUENCE { 4343 ctime [0] KerberosTime, 4344 cusec [1] Microseconds, 4345 subkey [2] EncryptionKey OPTIONAL, 4346 seq-number [3] SeqNum OPTIONAL, 4347 ..., 4348 authorization-data [4] AuthorizationData OPTIONAL, 4349 ... 4350 } 4351 4352 4353 4354 -- 4355 -- *** Application messages 4356 -- 4357 4358 4359 4360 -- Do we chew up another tag for KRB-SAFE-EXT? That would 4361 -- allow us to make safe-body optional, allowing for a GSS-MIC 4362 -- sort of message. 4363 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4364 pvno [0] INTEGER (5), 4365 msg-type [1] INTEGER (20), 4366 safe-body [2] KRB-SAFE-BODY, 4367 cksum [3] ChecksumOf { 4368 KRB-SAFE-BODY, 4369 { key-session | key-subsession }, { ku-KrbSafe-cksum }}, 4370 ... -- ASN.1 extensions must be excluded 4371 -- when sending to rfc1510 implementations 4372 } 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385Yu Expires: Jan 2005 [Page 69] 4386Internet-Draft yu-krb-extensions-01 19 Jul 2004 4387 4388 4389 KRB-SAFE-BODY ::= SEQUENCE { 4390 user-data [0] OCTET STRING, 4391 timestamp [1] KerberosTime OPTIONAL, 4392 usec [2] Microseconds OPTIONAL, 4393 seq-number [3] SeqNum OPTIONAL, 4394 s-address [4] HostAddress, 4395 r-address [5] HostAddress OPTIONAL, 4396 ... -- ASN.1 extensions must be excluded 4397 -- when sending to rfc1510 implementations 4398 } 4399 4400 4401 4402 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4403 pvno [0] INTEGER (5), 4404 msg-type [1] INTEGER (21), 4405 enc-part [3] EncryptedData { 4406 EncKrbPrivPart, 4407 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 4408 ... 4409 } 4410 4411 4412 4413 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4414 user-data [0] OCTET STRING, 4415 timestamp [1] KerberosTime OPTIONAL, 4416 usec [2] Microseconds OPTIONAL, 4417 seq-number [3] SeqNum OPTIONAL, 4418 s-address [4] HostAddress -- sender's addr --, 4419 r-address [5] HostAddress OPTIONAL -- recip's addr --, 4420 ... -- ASN.1 extensions must be excluded 4421 -- when sending to rfc1510 implementations 4422 } 4423 4424 4425 4426 KRB-CRED ::= CHOICE { 4427 rfc1510 [APPLICATION 22] KRB-CRED-1510, 4428 ext [APPLICATION 24] Signed { 4429 KRB-CRED-EXT, 4430 { key-session | key-subsession }, { ku-KrbCred-cksum }} 4431 } 4432 4433 4434 4435 KRB-CRED-COMMON ::= SEQUENCE { 4436 pvno [0] INTEGER (5), 4437 msg-type [1] INTEGER (22 | 24), 4438 tickets [2] SEQUENCE OF Ticket, 4439 enc-part [3] EncryptedData { 4440 EncKrbCredPart, 4441 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 4442 ... 4443 } 4444 4445 4446Yu Expires: Jan 2005 [Page 70] 4447Internet-Draft yu-krb-extensions-01 19 Jul 2004 4448 4449 4450 KRB-CRED-1510 ::= SEQUENCE { 4451 COMPONENTS OF KRB-CRED-COMMON 4452 } (WITH COMPONENTS { ..., msg-type (22) }) 4453 4454 4455 4456 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON 4457 (WITH COMPONENTS { ..., msg-type (24) }) 4458 4459 4460 4461 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4462 ticket-info [0] SEQUENCE OF KrbCredInfo, 4463 nonce [1] Nonce OPTIONAL, 4464 timestamp [2] KerberosTime OPTIONAL, 4465 usec [3] Microseconds OPTIONAL, 4466 s-address [4] HostAddress OPTIONAL, 4467 r-address [5] HostAddress OPTIONAL 4468 } 4469 4470 4471 4472 KrbCredInfo ::= SEQUENCE { 4473 key [0] EncryptionKey, 4474 prealm [1] Realm OPTIONAL, 4475 pname [2] PrincipalName OPTIONAL, 4476 flags [3] TicketFlags OPTIONAL, 4477 authtime [4] KerberosTime OPTIONAL, 4478 starttime [5] KerberosTime OPTIONAL, 4479 endtime [6] KerberosTime OPTIONAL, 4480 renew-till [7] KerberosTime OPTIONAL, 4481 srealm [8] Realm OPTIONAL, 4482 sname [9] PrincipalName OPTIONAL, 4483 caddr [10] HostAddresses OPTIONAL 4484 } 4485 4486 4487 4488 TGT-REQ ::= [APPLICATION 16] SEQUENCE { 4489 pvno [0] INTEGER (5), 4490 msg-type [1] INTEGER (16), 4491 sname [2] PrincipalName OPTIONAL, 4492 srealm [3] Realm OPTIONAL, 4493 ... 4494 } 4495 4496 4497 4498 -- 4499 -- *** Error messages 4500 -- 4501 4502 4503 4504 4505 4506 4507 4508Yu Expires: Jan 2005 [Page 71] 4509Internet-Draft yu-krb-extensions-01 19 Jul 2004 4510 4511 4512 ErrCode ::= Int32 4513 4514 4515 KRB-ERROR ::= CHOICE { 4516 rfc1510 [APPLICATION 30] KRB-ERROR-1510, 4517 ext [APPLICATION 23] Signed { 4518 KRB-ERROR-EXT, { ku-KrbError-cksum } } 4519 } 4520 4521 4522 4523 KRB-ERROR-COMMON ::= SEQUENCE { 4524 pvno [0] INTEGER (5), 4525 msg-type [1] INTEGER (30 | 23), 4526 ctime [2] KerberosTime OPTIONAL, 4527 cusec [3] Microseconds OPTIONAL, 4528 stime [4] KerberosTime, 4529 susec [5] Microseconds, 4530 error-code [6] ErrCode, 4531 crealm [7] Realm OPTIONAL, 4532 cname [8] PrincipalName OPTIONAL, 4533 realm [9] Realm -- Correct realm --, 4534 sname [10] PrincipalName -- Correct name --, 4535 e-text [11] KerberosString OPTIONAL, 4536 e-data [12] OCTET STRING OPTIONAL, 4537 ..., 4538 typed-data [13] TYPED-DATA OPTIONAL, 4539 nonce [14] Nonce OPTIONAL, 4540 lang-tag [15] LangTag OPTIONAL, 4541 ... 4542 } 4543 4544 4545 4546 KRB-ERROR-1510 ::= SEQUENCE { 4547 COMPONENTS OF KRB-ERROR-COMMON 4548 } (WITH COMPONENTS { 4549 ..., 4550 msg-type (30) 4551 }) 4552 4553 4554 4555 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON 4556 (WITH COMPONENTS { ..., msg-type (23) }) 4557 4558 4559 4560 TDType ::= Int32 4561 4562 4563 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4564 data-type [0] TDType, 4565 data-value [1] OCTET STRING OPTIONAL 4566 } 4567 4568 4569 4570 4571Yu Expires: Jan 2005 [Page 72] 4572Internet-Draft yu-krb-extensions-01 19 Jul 2004 4573 4574 4575 -- 4576 -- *** Error codes 4577 -- 4578 4579 4580 -- No error 4581 kdc-err-none ErrCode ::= 0 4582 -- Client's entry in database has expired 4583 kdc-err-name-exp ErrCode ::= 1 4584 -- Server's entry in database has expired 4585 kdc-err-service-exp ErrCode ::= 2 4586 -- Requested protocol version number not supported 4587 kdc-err-bad-pvno ErrCode ::= 3 4588 -- Client's key encrypted in old master key 4589 kdc-err-c-old-mast-kvno ErrCode ::= 4 4590 -- Server's key encrypted in old master key 4591 kdc-err-s-old-mast-kvno ErrCode ::= 5 4592 -- Client not found in Kerberos database 4593 kdc-err-c-principal-unknown ErrCode ::= 6 4594 -- Server not found in Kerberos database 4595 kdc-err-s-principal-unknown ErrCode ::= 7 4596 -- Multiple principal entries in database 4597 kdc-err-principal-not-unique ErrCode ::= 8 4598 -- The client or server has a null key 4599 kdc-err-null-key ErrCode ::= 9 4600 -- Ticket not eligible for postdating 4601 kdc-err-cannot-postdate ErrCode ::= 10 4602 -- Requested start time is later than end time 4603 kdc-err-never-valid ErrCode ::= 11 4604 -- KDC policy rejects request 4605 kdc-err-policy ErrCode ::= 12 4606 -- KDC cannot accommodate requested option 4607 kdc-err-badoption ErrCode ::= 13 4608 -- KDC has no support for encryption type 4609 kdc-err-etype-nosupp ErrCode ::= 14 4610 -- KDC has no support for checksum type 4611 kdc-err-sumtype-nosupp ErrCode ::= 15 4612 -- KDC has no support for padata type 4613 kdc-err-padata-type-nosupp ErrCode ::= 16 4614 -- KDC has no support for transited type 4615 kdc-err-trtype-nosupp ErrCode ::= 17 4616 -- Clients credentials have been revoked 4617 kdc-err-client-revoked ErrCode ::= 18 4618 -- Credentials for server have been revoked 4619 kdc-err-service-revoked ErrCode ::= 19 4620 -- TGT has been revoked 4621 kdc-err-tgt-revoked ErrCode ::= 20 4622 4623 4624 4625 4626 4627 4628 4629Yu Expires: Jan 2005 [Page 73] 4630Internet-Draft yu-krb-extensions-01 19 Jul 2004 4631 4632 4633 -- Client not yet valid - try again later 4634 kdc-err-client-notyet ErrCode ::= 21 4635 -- Server not yet valid - try again later 4636 kdc-err-service-notyet ErrCode ::= 22 4637 -- Password has expired - change password to reset 4638 kdc-err-key-expired ErrCode ::= 23 4639 -- Pre-authentication information was invalid 4640 kdc-err-preauth-failed ErrCode ::= 24 4641 -- Additional pre-authenticationrequired 4642 kdc-err-preauth-required ErrCode ::= 25 4643 -- Requested server and ticket don't match 4644 kdc-err-server-nomatch ErrCode ::= 26 4645 -- Server principal valid for user2user only 4646 kdc-err-must-use-user2user ErrCode ::= 27 4647 -- KDC Policy rejects transited path 4648 kdc-err-path-not-accpeted ErrCode ::= 28 4649 -- A service is not available 4650 kdc-err-svc-unavailable ErrCode ::= 29 4651 -- Integrity check on decrypted field failed 4652 krb-ap-err-bad-integrity ErrCode ::= 31 4653 -- Ticket expired 4654 krb-ap-err-tkt-expired ErrCode ::= 32 4655 -- Ticket not yet valid 4656 krb-ap-err-tkt-nyv ErrCode ::= 33 4657 -- Request is a replay 4658 krb-ap-err-repeat ErrCode ::= 34 4659 -- The ticket isn't for us 4660 krb-ap-err-not-us ErrCode ::= 35 4661 -- Ticket and authenticator don't match 4662 krb-ap-err-badmatch ErrCode ::= 36 4663 -- Clock skew too great 4664 krb-ap-err-skew ErrCode ::= 37 4665 -- Incorrect net address 4666 krb-ap-err-badaddr ErrCode ::= 38 4667 -- Protocol version mismatch 4668 krb-ap-err-badversion ErrCode ::= 39 4669 -- Invalid msg type 4670 krb-ap-err-msg-type ErrCode ::= 40 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686Yu Expires: Jan 2005 [Page 74] 4687Internet-Draft yu-krb-extensions-01 19 Jul 2004 4688 4689 4690 -- Message stream modified 4691 krb-ap-err-modified ErrCode ::= 41 4692 -- Message out of order 4693 krb-ap-err-badorder ErrCode ::= 42 4694 -- Specified version of key is not available 4695 krb-ap-err-badkeyver ErrCode ::= 44 4696 -- Service key not available 4697 krb-ap-err-nokey ErrCode ::= 45 4698 -- Mutual authentication failed 4699 krb-ap-err-mut-fail ErrCode ::= 46 4700 -- Incorrect message direction 4701 krb-ap-err-baddirection ErrCode ::= 47 4702 -- Alternative authentication method required 4703 krb-ap-err-method ErrCode ::= 48 4704 -- Incorrect sequence number in message 4705 krb-ap-err-badseq ErrCode ::= 49 4706 -- Inappropriate type of checksum in message 4707 krb-ap-err-inapp-cksum ErrCode ::= 50 4708 -- Policy rejects transited path 4709 krb-ap-path-not-accepted ErrCode ::= 51 4710 -- Response too big for UDP, retry with TCP 4711 krb-err-response-too-big ErrCode ::= 52 4712 -- Generic error (description in e-text) 4713 krb-err-generic ErrCode ::= 60 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743Yu Expires: Jan 2005 [Page 75] 4744Internet-Draft yu-krb-extensions-01 19 Jul 2004 4745 4746 4747 -- Field is too long for this implementation 4748 krb-err-field-toolong ErrCode ::= 61 4749 -- Reserved for PKINIT 4750 kdc-error-client-not-trusted ErrCode ::= 62 4751 -- Reserved for PKINIT 4752 kdc-error-kdc-not-trusted ErrCode ::= 63 4753 -- Reserved for PKINIT 4754 kdc-error-invalid-sig ErrCode ::= 64 4755 -- Reserved for PKINIT 4756 kdc-err-key-too-weak ErrCode ::= 65 4757 -- Reserved for PKINIT 4758 kdc-err-certificate-mismatch ErrCode ::= 66 4759 -- No TGT available to validate USER-TO-USER 4760 krb-ap-err-no-tgt ErrCode ::= 67 4761 -- USER-TO-USER TGT issued different KDC 4762 kdc-err-wrong-realm ErrCode ::= 68 4763 -- Ticket must be for USER-TO-USER 4764 krb-ap-err-user-to-user-required ErrCode ::= 69 4765 -- Reserved for PKINIT 4766 kdc-err-cant-verify-certificate ErrCode ::= 70 4767 -- Reserved for PKINIT 4768 kdc-err-invalid-certificate ErrCode ::= 71 4769 -- Reserved for PKINIT 4770 kdc-err-revoked-certificate ErrCode ::= 72 4771 -- Reserved for PKINIT 4772 kdc-err-revocation-status-unknown ErrCode ::= 73 4773 -- Reserved for PKINIT 4774 kdc-err-revocation-status-unavailable ErrCode ::= 74 4775 4776 4777 4778 END 4779 4780 4781 4782B. Kerberos and Character Encodings (Informative) 4783 4784 4785 [adapted from KCLAR 5.2.1] 4786 4787 4788 The original specification of the Kerberos protocol in RFC 1510 uses 4789 GeneralString in numerous places for human-readable string data. 4790 Historical implementations of Kerberos cannot utilize the full power 4791 of GeneralString. This ASN.1 type requires the use of designation 4792 and invocation escape sequences as specified in ISO 2022 | ECMA-35 4793 [ISO2022] to switch character sets, and the default character set 4794 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] 4795 International Reference Version (IRV) (aka U.S. ASCII), which mostly 4796 works. 4797 4798 4799 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3) 4800 and two Control-function code elements (C0..C1). DER previously 4801 [X690-1997] prohibited the designation of character sets as any but 4802 the G0 and C0 sets. This had the side effect of prohibiting the use 4803 4804 4805Yu Expires: Jan 2005 [Page 76] 4806Internet-Draft yu-krb-extensions-01 19 Jul 2004 4807 4808 4809 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any 4810 other character-sets that utilize a 96-character set, since it is 4811 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code 4812 element. Recent revisions to the ASN.1 standards resolve this 4813 contradiction. 4814 4815 4816 In practice, many implementations treat RFC 1510 GeneralStrings as if 4817 they were 8-bit strings of whichever character set the implementation 4818 defaults to, without regard for correct usage of character-set 4819 designation escape sequences. The default character set is often 4820 determined by the current user's operating system dependent locale. 4821 At least one major implementation places unescaped UTF-8 encoded 4822 Unicode characters in the GeneralString. This failure to conform to 4823 the GeneralString specifications results in interoperability issues 4824 when conflicting character encodings are utilized by the Kerberos 4825 clients, services, and KDC. 4826 4827 4828 This unfortunate situation is the result of improper documentation of 4829 the restrictions of the ASN.1 GeneralString type in prior Kerberos 4830 specifications. 4831 4832 4833 [the following should probably be rewritten and moved into the 4834 principal name section] 4835 4836 4837 For compatibility, implementations MAY choose to accept GeneralString 4838 values that contain characters other than those permitted by 4839 IA5String, but they should be aware that character set designation 4840 codes will likely be absent, and that the encoding should probably be 4841 treated as locale-specific in almost every way. Implementations MAY 4842 also choose to emit GeneralString values that are beyond those 4843 permitted by IA5String, but should be aware that doing so is 4844 extraordinarily risky from an interoperability perspective. 4845 4846 4847 Some existing implementations use GeneralString to encode unescaped 4848 locale-specific characters. This is a violation of the ASN.1 4849 standard. Most of these implementations encode US-ASCII in the left- 4850 hand half, so as long the implementation transmits only US-ASCII, the 4851 ASN.1 standard is not violated in this regard. As soon as such an 4852 implementation encodes unescaped locale-specific characters with the 4853 high bit set, it violates the ASN.1 standard. 4854 4855 4856 Other implementations have been known to use GeneralString to contain 4857 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 4858 is a different encoding, not a 94 or 96 character "G" set as defined 4859 by ISO 2022. It is believed that these implementations do not even 4860 use the ISO 2022 escape sequence to change the character encoding. 4861 Even if implementations were to announce the change of encoding by 4862 using that escape sequence, the ASN.1 standard prohibits the use of 4863 any escape sequences other than those used to designate/invoke "G" or 4864 "C" sets allowed by GeneralString. 4865 4866 4867 4868Yu Expires: Jan 2005 [Page 77] 4869Internet-Draft yu-krb-extensions-01 19 Jul 2004 4870 4871 4872C. Kerberos History (Informative) 4873 4874 4875 [Adapted from KCLAR "BACKGROUND"] 4876 4877 4878 The Kerberos model is based in part on Needham and Schroeder's 4879 trusted third-party authentication protocol [NS78] and on 4880 modifications suggested by Denning and Sacco [DS81]. The original 4881 design and implementation of Kerberos Versions 1 through 4 was the 4882 work of two former Project Athena staff members, Steve Miller of 4883 Digital Equipment Corporation and Clifford Neuman (now at the 4884 Information Sciences Institute of the University of Southern 4885 California), along with Jerome Saltzer, Technical Director of Project 4886 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 4887 members of Project Athena have also contributed to the work on 4888 Kerberos. 4889 4890 4891 Version 5 of the Kerberos protocol (described in this document) has 4892 evolved from Version 4 based on new requirements and desires for 4893 features not available in Version 4. The design of Version 5 of the 4894 Kerberos protocol was led by Clifford Neuman and John Kohl with much 4895 input from the community. The development of the MIT reference 4896 implementation was led at MIT by John Kohl and Theodore Ts'o, with 4897 help and contributed code from many others. Since RFC1510 was 4898 issued, extensions and revisions to the protocol have been proposed 4899 by many individuals. Some of these proposals are reflected in this 4900 document. Where such changes involved significant effort, the 4901 document cites the contribution of the proposer. 4902 4903 4904 Reference implementations of both version 4 and version 5 of Kerberos 4905 are publicly available and commercial implementations have been 4906 developed and are widely used. Details on the differences between 4907 Kerberos Versions 4 and 5 can be found in [KNT94]. 4908 4909 4910D. Notational Differences from [KCLAR] 4911 4912 4913 [ possible point for discussion ] 4914 4915 4916 [KCLAR] uses notational conventions slightly different from this 4917 document. As a derivative of RFC 1510, the text of [KCLAR] uses C- 4918 language style identifier names for defined values. In ASN.1 4919 notation, identifiers referencing defined values must begin with a 4920 lowercase letter and contain hyphen (-) characters rather than 4921 underscore (_) characters, while identifiers referencing types begin 4922 with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase 4923 identifiers with underscores to identify defined values. This has 4924 the potential to create confusion, but neither document defines 4925 values using actual ASN.1 value-assignment notation. 4926 4927 4928 It is debatable whether it is advantageous to write all identifier 4929 names (regardless of their ASN.1 token type) in all-uppercase letters 4930 for the purpose of emphasis in running text. The alternative is to 4931 4932 4933Yu Expires: Jan 2005 [Page 78] 4934Internet-Draft yu-krb-extensions-01 19 Jul 2004 4935 4936 4937 use double-quote characters (") when ambiguity is possible. 4938 4939 4940Normative References 4941 4942 4943 [ISO646] 4944 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. 4945 4946 4947 [ISO2022] 4948 "Information technology -- Character code structure and 4949 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. 4950 4951 4952 [KCRYPTO] 4953 draft-ietf-krb-wg-crypto-07.txt 4954 4955 4956 [RFC2119] 4957 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate 4958 Requirement Levels", March 1997. 4959 4960 4961 [X680] 4962 "Information technology -- Abstract Syntax Notation One (ASN.1): 4963 Specification of basic notation", ITU-T Recommendation X.680 4964 (2002) | ISO/IEC 8824-1:2002. 4965 4966 4967 [X682] 4968 "Information technology -- Abstract Syntax Notation One (ASN.1): 4969 Constraint specification", ITU-T Recommendation X.682 (2002) | 4970 ISO/IEC 8824-3:2002. 4971 4972 4973 [X683] 4974 "Information technology -- Abstract Syntax Notation One (ASN.1): 4975 Parameterization of ASN.1 specifications", ITU-T Recommendation 4976 X.683 (2002) | ISO/IEC 8824-4:2002. 4977 4978 4979 [X690] 4980 "Information technology -- ASN.1 encoding Rules: Specification 4981 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 4982 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 4983 X.690 (2002) | ISO/IEC 8825-1:2002. 4984 4985 4986Informative References 4987 4988 4989 [DS81] 4990 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 4991 Distribution Protocols," Communications of the ACM, Vol. 24(8), 4992 pp. 533-536 (August 1981). 4993 4994 4995 [Dub00] 4996 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous 4997 Systems", Elsevier-Morgan Kaufmann, 2000. 4998 <http://www.oss.com/asn1/dubuisson.html> 4999 5000 5001 5002Yu Expires: Jan 2005 [Page 79] 5003Internet-Draft yu-krb-extensions-01 19 Jul 2004 5004 5005 5006 [ISO8859-1] 5007 "Information technology -- 8-bit single-byte coded graphic 5008 character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 5009 8859-1:1998. 5010 5011 5012 [KCLAR] 5013 draft-ietf-krb-wg-kerberos-clarifications-06.txt 5014 5015 5016 [KNT94] 5017 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 5018 Evolution of the Kerberos Authentication System". In 5019 Distributed Open Systems, pages 78-94. IEEE Computer Society 5020 Press, 1994. 5021 5022 5023 [Lar96] 5024 John Larmouth, "Understanding OSI", International Thomson 5025 Computer Press, 1996. 5026 <http://www.isi.salford.ac.uk/books/osi.html> 5027 5028 5029 [Lar99] 5030 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann, 5031 1999. <http://www.oss.com/asn1/larmouth.html> 5032 5033 5034 [NS78] 5035 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5036 Authentication in Large Networks of Computers", Communications 5037 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5038 5039 5040 [RFC1510] 5041 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication 5042 Service (v5)", RFC1510, September 1993, Status: Proposed 5043 Standard. 5044 5045 5046 [RFC1964] 5047 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 5048 June 1996, Status: Proposed Standard. 5049 5050 5051 [X690-1997] 5052 "Information technology -- ASN.1 encoding rules: Specification 5053 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 5054 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 5055 X.690 (1997) | ISO/IEC 8825-1:1998. 5056 5057 5058Author's Address 5059 5060 5061 Tom Yu 5062 77 Massachusetts Ave 5063 Cambridge, MA 02139 5064 USA 5065 tlyu@mit.edu 5066 5067 5068 5069Yu Expires: Jan 2005 [Page 80] 5070Internet-Draft yu-krb-extensions-01 19 Jul 2004 5071 5072 5073Full Copyright Statement 5074 5075 5076 Copyright (C) The Internet Society (2004). This document is subject 5077 to the rights, licenses and restrictions contained in BCP 78, and 5078 except as set forth therein, the authors retain all their rights. 5079 5080 5081 This document and the information contained herein are provided on an 5082 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5083 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5084 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5085 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5086 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5087 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127Yu Expires: Jan 2005 [Page 81]