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