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