1 2 3INTERNET-DRAFT Tom Yu 4draft-yu-krb-wg-kerberos-extensions-00.txt MIT 5Expires: 09 August 2004 09 February 2004 6 7 The Kerberos Network Authentication Service (Version 5) 8 9Status of This Memo 10 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 13 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 18 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 23 24 The list of current Internet-Drafts can be accessed at 25 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 28 The list of Internet-Draft Shadow Directories can be accessed at 29 30 http://www.ietf.org/shadow.html 31 32 33Copyright Notice 34 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 37Abstract 38 39 This document describes version 5 of the Kerberos network 40 authentication protocol. It describes changes to the protocol which 41 allow for extensions to be made to the protocol without creating 42 interoperability problems. 43 44 [ This document is a VERY rough draft. Many sections are not yet 45 fully filled out. The main purpose is to illustrate the beginnings 46 of a new document structure as a starting point. ] 47 48Key Words for Requirements 49 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 52 to be interpreted as described in RFC 2119. 53 54 55Yu Expires: Aug 2004 [Page 1] 56 57Internet-Draft yu-krb-extensions-00 09 Feb 2004 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 .......................................... 4 67 1.1. Kerberos Protocol Overview .......................... 4 68 1.2. Overview of Document ................................ 5 69 2. Extensibility ......................................... 5 70 3. Criticality ........................................... 6 71 4. Use of ASN.1 .......................................... 6 72 4.1. Module Header ....................................... 6 73 4.2. Top-Level Type ...................................... 7 74 4.3. Parameterized Types ................................. 7 75 4.4. Constraints ......................................... 8 76 4.5. New Types ........................................... 8 77 5. Basic Types ........................................... 8 78 5.1. Constrained Integer Types ........................... 8 79 5.2. KerberosTime ........................................ 9 80 5.3. KerberosString ...................................... 9 81 6. Principals ............................................ 10 82 6.1. Name Types .......................................... 10 83 6.2. Principal Name Reuse ................................ 11 84 7. Types Relating to Encryption .......................... 11 85 7.1. EncryptedData ....................................... 11 86 7.2. EncryptionKey ....................................... 13 87 7.3. Checksums ........................................... 13 88 7.3.1. ChecksumOf ........................................ 14 89 7.3.2. Signed ............................................ 15 90 8. Tickets ............................................... 15 91 8.1. Timestamps .......................................... 16 92 8.2. Ticket Flags ........................................ 16 93 8.2.1. Flags Relating to Initial Ticket Acquisition ...... 17 94 8.2.2. Invalid Tickets ................................... 17 95 8.2.3. OK as Delegate .................................... 18 96 8.3. Renewable Tickets ................................... 18 97 8.4. Postdated Tickets ................................... 19 98 8.5. Proxiable and Proxy Tickets ......................... 20 99 8.6. Forwardable Tickets ................................. 21 100 8.7. Transited Realms .................................... 21 101 8.8. Authorization Data .................................. 21 102 8.9. Encrypted Part of Ticket ............................ 21 103 8.10. Cleartext Part of Ticket ........................... 22 104 9. Credential Acquisition ................................ 23 105 9.1. KDC-REQ ............................................. 24 106 9.2. PA-DATA ............................................. 26 107 9.3. KDC-REQ Processing .................................. 26 108 9.3.1. Handling Replays .................................. 26 109 9.3.2. Request Validation ................................ 26 110 111Yu Expires: Aug 2004 [Page 2] 112 113Internet-Draft yu-krb-extensions-00 09 Feb 2004 114 115 9.3.2.1. AS-REQ Authentication ........................... 27 116 9.3.2.2. TGS-REQ Authentication .......................... 27 117 9.3.2.3. Principal Validation ............................ 27 118 9.3.3. Timestamp Handling ................................ 27 119 9.3.3.1. AS-REQ Timestamp Processing ..................... 28 120 9.3.3.2. TGS-REQ Timestamp Processing .................... 29 121 9.3.4. Key Selection ..................................... 29 122 9.3.5. Checking For Revoked Tickets ...................... 30 123 9.4. Reply Validation .................................... 30 124 10. Application Authentication ........................... 30 125 11. Session Key Use ...................................... 30 126 11.1. KRB-SAFE ........................................... 30 127 11.2. KRB-PRIV ........................................... 30 128 11.3. KRB-CRED ........................................... 30 129 12. Security Considerations .............................. 30 130 12.1. Time Synchronization ............................... 30 131 12.2. Replays ............................................ 30 132 12.3. Principal Name Reuse ............................... 30 133 12.4. Password Guessing .................................. 30 134 12.5. Forward Secrecy .................................... 30 135 12.6. Authorization ...................................... 31 136 12.7. Login Authentication ............................... 31 137 Appendices ................................................ 31 138 A. ASN.1 Module (Normative) .............................. 31 139 B. Kerberos and Character Encodings (Informative) ........ 60 140 C. Kerberos History (Informative) ........................ 62 141 Normative References ...................................... 62 142 Informative References .................................... 63 143 Acknowledgments ........................................... 63 144 Author's Address .......................................... 63 145 Full Copyright Statement .................................. 63 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Yu Expires: Aug 2004 [Page 3] 168 169Internet-Draft yu-krb-extensions-00 09 Feb 2004 170 1711. Introduction 172 173 The Kerberos network authentication protocol is a trusted third-party 174 protocol utilizing symmetric-key cryptography. It assumes that all 175 communications between parties in the protocol may be arbitrarily 176 tampered with or monitored, and that the security of the overall 177 system depends only on the effectiveness of the cryptographic 178 techniques and the secrecy of the keys used. The protocol 179 authenticates an application client's identity to an application 180 server, and likewise authenticates the application server's identity 181 to the application client. These assurances are made possible by the 182 client and the server sharing secrets with the trusted third party: 183 the Kerberos server, also known as the Key Distribution Center (KDC). 184 In addition, the protocol establishes an ephemeral shared secret (the 185 session key) between the client and the server, allowing the 186 protection of further communications between them. 187 1881.1. Kerberos Protocol Overview 189 190 Kerberos comprises three main sub-protocols: credentials acquisition, 191 application authentication, and session key usage. A client acquires 192 credentials by asking the for KDC a credential for a service; the KDC 193 issues the credential, consisting of a ticket and a session key. The 194 ticket, containing the client's identity, timestamps, expiration 195 time, and a session key, is a encrypted in a key known to the 196 application server. The KDC encrypts the credential using a key 197 known to the client, and transmits the credential to the client. 198 199 There are two means of requesting credentials: the Authentication 200 Service (AS) exchange, and the Ticket-Granting Service (TGS) 201 exchange. The AS exchange typically involves a client using a 202 password-derived key to decrypt the response. The TGS exchange 203 involves the KDC behaving as an application, which the client 204 authenticates to using a Ticket-Granting Ticket (TGT). The client 205 usually obtains the TGT by using the AS exchange. 206 207 Application authentication consists of the client establishing the 208 session key with the application server by transmitting the ticket to 209 the application server, along with an authenticator. The 210 authenticator contains a timestamp and additional data encrypted 211 using the ticket's session key. The application server decrypts the 212 ticket, extracting the session key. The application server then uses 213 the session key to decrypt the authenticator. Upon successful 214 decryption of the authenticator, the application server knows that 215 the data in the authenticator were sent by the client named in the 216 associated ticket. Additionally, since authenticators expire more 217 quickly than tickets, the application server has some assurance that 218 the transaction is not a replay. The application server may send an 219 encrypted acknowledgment to the client, verifying its identity to the 220 client. 221 222 223Yu Expires: Aug 2004 [Page 4] 224 225Internet-Draft yu-krb-extensions-00 09 Feb 2004 226 227 Once application authentication has occurred, the client and server 228 may use the established session key to protect further traffic. This 229 protection may consist of protection of integrity only, or of 230 protection of confidentiality and integrity. Additional measures 231 exist for a client to forward credentials to a server. 232 233 The entire scheme depends on loosely synchronized clocks. 234 Synchronization of the clock on the KDC with the application server 235 clock allows the application server to accurately determine whether a 236 credential is expired. Likewise, synchronization of the clock on the 237 client with the application server clock prevents replay attacks 238 utilizing the same credential. Careful design of the application 239 protocol may allow replay prevention without requiring client-server 240 clock synchronization. 241 242 Following the establishment of a session key between the application 243 client and the application server, the Kerberos protocol provides 244 messages that use the session key to protect the integrity or 245 confidentiality of communications between the client and the server. 246 Additionally, the client may forward credentials to the application 247 server. 248 249 The credentials acquisition protocol takes place over specific, 250 defined transports (UDP and TCP). Application protocols define which 251 transport to use for the session key establishment protocol and for 252 messages using the session key; the application may choose to perform 253 its own encapsulation of the Kerberos messages, for example. 254 2551.2. Overview of Document 256 257 The remainder of this document begins by describing the general 258 frameworks for protocol extensibility, including whether to interpret 259 unknown extensions as critical. It then defines the protocol 260 messages and exchanges. 261 262 The definition of the Kerberos protocol uses Abstract Syntax Notation 263 One (ASN.1) [X680], which specifies notation for describing the 264 abstract content of protocol messages. This document defines a 265 number of base types using ASN.1; these base types subsequently 266 appear in multiple types which define actual protocol messages. 267 Definitions of principal names and of tickets, which are central to 268 the protocol, also appear preceding the protocol message definitions. 269 2702. Extensibility 271 272 As originally defined in [RFC1510], the Kerberos protocol does not 273 readily allow for backwards-compatible extensions to the protocol. 274 Various proposals to extend the Kerberos protocol have appeared since 275 RFC 1510, many of them creating problems for backwards compatibility. 276 This document adopts the technique of creating new extensible types 277 which encode to messages which are very similar to RFC 1510 messages 278 279Yu Expires: Aug 2004 [Page 5] 280 281Internet-Draft yu-krb-extensions-00 09 Feb 2004 282 283 on the wire. This similarity allows implementors to use shared code 284 paths for encoding and decoding both new and old messages. 285 286 The protocol defined in RFC 1510 already contains some elements 287 allowing for limited backwards-compatible extensions to the protocol. 288 Most of these elements consist of "typed holes"; these are octet 289 strings whose contents have types defined by an assigned number. 290 This document adds a number of typed holes to types which have 291 previously lacked typed holes. This document also describes 292 procedures for the IETF to use the extensibility model of ASN.1 make 293 further backwards-compatible extensions of the Kerberos protocol, if 294 typed holes prove inadequate for some desired extension. 295 2963. Criticality 297 298 In general, implementations SHOULD treat unknown extension, flags, 299 etc. as non-critical; i.e., they should ignore them when they do not 300 understand them. Exceptions are clearly marked. An implementation 301 SHOULD NOT reject a request merely because it does not understand 302 some element of the request. As a related consequence, 303 implementations SHOULD handle talking to other implementations which 304 do not implement some requested options. This may require designers 305 of extensions or options to provide means detect whether extensions 306 or options are rejected, or whether such extensions or options are 307 merely not understood, or (perhaps maliciously) deleted in transit. 308 3094. Use of ASN.1 310 311 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. 312 Even though ASN.1 theoretically allows the description of protocol 313 messages to be independent of the encoding rules used to encode the 314 messages, Kerberos messages MUST be encoded with DER. Subtleties in 315 the semantics of the notation, such as whether tags carry any 316 semantic content to the application, may cause the use of other ASN.1 317 encoding rules to be problematic. 318 319 Implementors not using existing ASN.1 compilers or support libraries 320 are cautioned to thoroughly read and understand the actual ASN.1 321 specification to ensure correct implementation behavior. There is 322 more complexity in the notation than is immediately obvious, and some 323 tutorials and guides to ASN.1 are misleading or erroneous. 324 3254.1. Module Header 326 327 The type definitions in this section assume an ASN.1 module 328 definition of the following form: 329 330 331 332 333 334 335Yu Expires: Aug 2004 [Page 6] 336 337Internet-Draft yu-krb-extensions-00 09 Feb 2004 338 339 KerberosV5Spec3 { 340 iso(1) identified-organization(3) dod(6) internet(1) 341 security(5) kerberosV5(2) modules(4) krb5spec3(4) 342 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 343 344 -- Rest of definitions here 345 346 END 347 348 This specifies that the tagging context for the module will be 349 explicit and that automatic tagging is not done. 350 351 Some other publications [RFC1510] [RFC1964] erroneously specify an 352 object identifier (OID) having an incorrect value of "5" for the 353 "dod" component of the OID. In the case of RFC 1964, use of the 354 "correct" OID value would result in a change in the wire protocol; 355 therefore, the RFC 1964 OID remains unchanged for now. 356 3574.2. Top-Level Type 358 359 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol 360 Data Units or PDUs) which an application may directly reference. 361 Applications SHOULD NOT transmit any types other than those which are 362 alternatives of the KRB-PDU CHOICE. 363 364 -- top-level type 365 -- 366 -- Applications should not directly reference any types 367 -- other than KRB-PDU and its component types. 368 -- 369 KRB-PDU ::= CHOICE { 370 ticket Ticket, 371 as-req AS-REQ, 372 as-rep AS-REP, 373 tgs-req TGS-REQ, 374 tgs-rep TGS-REP, 375 ap-req AP-REQ, 376 ap-rep AP-REP, 377 krb-safe KRB-SAFE, 378 krb-priv KRB-PRIV, 379 krb-cred KRB-CRED, 380 tgt-req TGT-REQ, 381 krb-error KRB-ERROR, 382 ... 383 } 384 385 3864.3. Parameterized Types 387 388 This document uses ASN.1 parameterized types [X683] to make 389 definitions of types more readable. For some types, some or all of 390 391Yu Expires: Aug 2004 [Page 7] 392 393Internet-Draft yu-krb-extensions-00 09 Feb 2004 394 395 the parameters are advisory, i.e., they are not encoded in any form 396 for transmission in a protocol message. These advisory parameters 397 can describe implementation behavior associated with the type. 398 3994.4. Constraints 400 401 This document uses ASN.1 constraints, including the 402 "UserDefinedConstraint" syntax [X682]. Some constraints can be 403 handled automatically by tools that can parse them. Uses of the 404 "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will 405 typically need to have behavior manually coded; these uses provide a 406 formalized way of conveying intended implementation behavior. 407 4084.5. New Types 409 410 This document defines a number of new ASN.1 types. The names of 411 these types will typically have a suffix like "Ext", indicating that 412 the types are intended to support extensibility. Types original to 413 RFC 1510 have been renamed to have a suffix like "1510". The "Ext" 414 and "1510" types often contain a number of common elements; these 415 common elements have a suffix like "Common". The "1510" types have 416 various ASN.1 constraints applied to them; the constraints limit the 417 possible values of the "1510" types to those permitted by RFC 1510 or 418 by [KCLAR]. The "Ext" types may have different constraints, 419 typically to force string values to be sent as UTF-8. 420 4215. Basic Types 422 423 Certain ASN.1 types in Kerberos appear in numerous other types. 424 4255.1. Constrained Integer Types 426 427 In [RFC1510], many types contained references to the unconstrained 428 INTEGER type. Since an unconstrained INTEGER may contain any 429 possible abstract integer value, most of the unconstrained references 430 to INTEGER in [RFC1510] have been constrained to 32 bits or smaller. 431 432 -- signed values representable in 32 bits 433 -- 434 -- These are often used as assigned numbers for various things. 435 Int32 ::= INTEGER (-2147483648..2147483647) 436 437 -- unsigned 32 bit values 438 UInt32 ::= INTEGER (0..4294967295) 439 440 The "Int32" type often contains an assigned number identifying the 441 type of a protocol element. Unless otherwise stated, non-negative 442 values are registered, and negative values are available for local 443 use. 444 445 446 447Yu Expires: Aug 2004 [Page 8] 448 449Internet-Draft yu-krb-extensions-00 09 Feb 2004 450 451 -- microseconds 452 Microseconds ::= INTEGER (0..999999) 453 454 455 -- sequence numbers 456 -- 457 -- We may want to increase this to 2**64 and define a UInt64 458 -- type. 459 SeqNum ::= UInt32 460 461 462 -- nonces 463 -- 464 -- Likewise, we may want to make this UInt64. 465 Nonce ::= UInt32 466 467 While these types have different abstract types from their 468 equivalents in [RFC1510], their DER encodings remain identical. 469 4705.2. KerberosTime 471 472 -- must not have fractional seconds 473 KerberosTime ::= GeneralizedTime 474 475 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 476 KerberosTime value MUST NOT include any fractional portions of the 477 seconds. As required by the DER, it further MUST NOT include any 478 separators, and it specifies the UTC time zone (Z). Example: The only 479 valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 480 November 1985 is "19851106210627Z". 481 4825.3. KerberosString 483 484 -- used for names and for error messages 485 KerberosString ::= CHOICE { 486 ia5 GeneralString (IA5String), 487 utf8 UTF8String, 488 ... -- no extension may be sent 489 -- to an rfc1510 implementation -- 490 } 491 492 The KerberosString type is used for strings in various places in the 493 Kerberos protocol. For compatibility with RFC 1510, GeneralString 494 values constrained to IA5String (US-ASCII) are permitted in messages 495 exchanged with RFC 1510 implementations. The new protocol messages 496 contain strings encoded as UTF-8. KerberosString values are present 497 in principal names and in error messages. Control characters SHOULD 498 NOT be used in principal names, and used with caution in error 499 messages. 500 501 502 503Yu Expires: Aug 2004 [Page 9] 504 505Internet-Draft yu-krb-extensions-00 09 Feb 2004 506 507 For detailed background regarding the history of character string use 508 in Kerberos, as well as discussion of some compatibility issues, see 509 Appendix B. 510 5116. Principals 512 513 Principals are participants in the Kerberos protocol. A "realm" 514 consists of principals in one administrative domain, served by one 515 KDC (or one replicated set of KDCs). Each principal name has an 516 arbitrary number of components, though typical principal names will 517 only have one or two components. A principal name is meant to be 518 readable by and meaningful to humans, especially in a realm lacking a 519 centrally adminstered authorization infrastructure. 520 521 Realm ::= KerberosString 522 523 PrincipalName ::= SEQUENCE { 524 name-type [0] NameType, 525 -- May have zero elements, or individual elements may be 526 -- zero-length, but this is not recommended. 527 name-string [1] SEQUENCE OF KerberosString 528 } 529 530 -- assigned numbers for name types (used in principal names) 531 NameType ::= Int32 532 533 534 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a 535 character with the code 0 (the US-ASCII NUL). Most realms will 536 usually consist of several components separated by periods (.), in 537 the style of Internet Domain Names, or separated by slashes (/) in 538 the style of X.500 names. 539 540 name-type 541 Specifies the type of name that follows. The name-type SHOULD 542 be treated as a hint. Ignoring the name type, no two names can 543 be the same (i.e., at least one of the components, or the realm, 544 must be different). 545 546 name-string 547 Encodes a sequence of components that form a name, each 548 component encoded as a KerberosString. Taken together, a 549 PrincipalName and a Realm form a principal identifier. Most 550 PrincipalNames will have only a few components (typically one or 551 two). 552 5536.1. Name Types 554 555 556 557 558 559Yu Expires: Aug 2004 [Page 10] 560 561Internet-Draft yu-krb-extensions-00 09 Feb 2004 562 563 -- Name type not known 564 nt-unknown NameType ::= 0 565 -- Just the name of the principal as in DCE, or for users 566 nt-principal NameType ::= 1 567 -- Service and other unique instance (krbtgt) 568 nt-srv-inst NameType ::= 2 569 -- Service with host name as instance (telnet, rcommands) 570 nt-srv-hst NameType ::= 3 571 -- Service with host as remaining components 572 nt-srv-xhst NameType ::= 4 573 -- Unique ID 574 nt-uid NameType ::= 5 575 -- Encoded X.509 Distingished name [RFC 2253] 576 nt-x500-principal NameType ::= 6 577 -- Name in form of SMTP email name (e.g. user@foo.com) 578 nt-smtp-name NameType ::= 7 579 -- Enterprise name - may be mapped to principal name 580 nt-enterprise NameType ::= 10 581 582 5836.2. Principal Name Reuse 584 585 Realm administrators SHOULD use extreme caution when considering 586 reusing a principal name. A service administrator might explicitly 587 enter principal names into a local access control list (ACL) for the 588 service. If such local ACLs exist independently of a centrally 589 administered authorization infrastructure, realm administrators 590 SHOULD NOT reuse principal names until confirming that all extant ACL 591 entries referencing that principal name have been updated. Failure 592 to perform this check can result in a security vulnerability, as a 593 new principal can inadvertently inherit unauthorized privileges upon 594 receiving a reused principal name. An organization whose Kerberos- 595 authenticated services all use a centrally-adminstered authorization 596 infrastructure may not need to take these precautions regarding 597 principal name reuse. 598 5997. Types Relating to Encryption 600 601 Many Kerberos protocol messages contain encryptions of various data 602 types. Kerberos protocol messages also contain checksums 603 (signatures) of various types. 604 6057.1. EncryptedData 606 607 The "EncryptedData" type contains the encryption of another data 608 type. The recipient uses fields within EncryptedData to determine 609 which key to use for decryption. 610 611 612 613 614 615Yu Expires: Aug 2004 [Page 11] 616 617Internet-Draft yu-krb-extensions-00 09 Feb 2004 618 619 -- "Type" specifies which ASN.1 type is encrypted to the 620 -- ciphertext in the EncryptedData. "Keys" specifies a set of 621 -- keys of which one key may be used to encrypt the data. 622 -- "KeyUsages" specifies a set of key usages, one of which may 623 -- be used to encrypt. 624 -- 625 -- None of the parameters is transmitted over the wire. 626 EncryptedData { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::= 627 SEQUENCE { 628 etype [0] EType, 629 kvno [1] UInt32 OPTIONAL, 630 cipher [2] OCTET STRING (CONSTRAINED BY { 631 -- must be encryption of -- 632 OCTET STRING (CONTAINING Type), 633 -- with one of the keys -- KeyToUse:Keys, 634 -- with key usage being one of -- 635 KeyUsage:KeyUsages 636 }), 637 ... 638 } 639 640 -- Assigned numbers denoting encryption mechanisms. 641 EType ::= Int32 642 643 -- Assigned numbers denoting key usages. 644 KeyUsage ::= UInt32 645 646 647 EType 648 Integer type for assigned numbers for encryption algorithms. 649 Defined in [KCRYPTO] 650 651 KeyUsage 652 Integer type for assigned numbers for key usages. Key usage 653 values are inputs to the encryption and decryption functions 654 described in [KCRYPTO]. 655 656 Type 657 Advisory parameter indicating the ASN.1 type whose DER encoding 658 is the plaintext encrypted into the EncryptedData. 659 660 Keys 661 Advisory parameter indicating which key to use to perform the 662 encryption. If "Keys" indicate multiple "KeyToUse" values, the 663 detailed description of the containing message will indicate 664 which key to use under which conditions. 665 666 667 668 669 670 671Yu Expires: Aug 2004 [Page 12] 672 673Internet-Draft yu-krb-extensions-00 09 Feb 2004 674 675 -- KeyToUse identifies which key is to be used to encrypt or 676 -- sign a given value. 677 -- 678 -- Values of KeyToUse are never actually transmitted over the 679 -- wire, or even used directly by the implementation in any 680 -- way, as key usages are; it exists primarily to identify 681 -- which key gets used for what purpose. Thus, the specific 682 -- numeric values associated with this type are irrelevant. 683 KeyToUse ::= ENUMERATED { 684 -- unspecified 685 key-unspecified, 686 -- server long term key 687 key-server, 688 -- client long term key 689 key-client, 690 -- key selected by KDC for encryption of a KDC-REP 691 key-kdc-rep, 692 -- session key from ticket 693 key-session, 694 -- subsession key negotiated via AP-REQ/AP-REP 695 key-subsession, 696 ... 697 } 698 699 700 KeyUsages 701 Advisory parameter indicating which "KeyUsage" value is used to 702 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, 703 the detailed description of the containing message will indicate 704 which key usage to use under which conditions. 705 7067.2. EncryptionKey 707 708 The "EncryptionKey" type holds an encryption key. 709 710 EncryptionKey ::= SEQUENCE { 711 keytype [0] EType, 712 keyvalue [1] OCTET STRING 713 } 714 715 716 keytype 717 This "EType" identifies the encryption algorithm, described in 718 [KCRYPTO]. 719 720 keyvalue 721 Contains the actual key. 722 7237.3. Checksums 724 725 726 727Yu Expires: Aug 2004 [Page 13] 728 729Internet-Draft yu-krb-extensions-00 09 Feb 2004 730 731 Several types contain checksums (actually signatures) of data. 732 733 CksumType ::= Int32 734 735 -- The parameters specify which key to use to produce the 736 -- signature, as well as which key usage to use. The 737 -- parameters are not actually sent over the wire. 738 Checksum { KeyToUse:Keys, KeyUsage:KeyUsages } ::= SEQUENCE { 739 cksumtype [0] CksumType, 740 checksum [1] OCTET STRING (CONSTRAINED BY { 741 -- signed using one of the keys -- 742 KeyToUse:Keys, 743 -- with key usage being one of -- 744 KeyUsage:KeyUsages 745 }) 746 } 747 748 749 CksumType 750 Integer type for assigned numbers for signature algorithms. 751 Defined in [KCRYPTO] 752 753 Keys 754 As in EncryptedData 755 756 KeyUsages 757 As in EncryptedData 758 759 cksumtype 760 Signature algorithm used to produce the signature. 761 762 checksum 763 The actual checksum. 764 7657.3.1. ChecksumOf 766 767 ChecksumOf is like "Checksum", but specifies which type is signed. 768 769 -- a Checksum that must contain the checksum of a particular type 770 ChecksumOf { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::= 771 Checksum { Keys, KeyUsages } 772 (WITH COMPONENTS { 773 ..., 774 checksum (CONSTRAINED BY { 775 -- must be checksum of -- 776 OCTET STRING (CONTAINING Type) 777 }) 778 }) 779 780 781 782 783Yu Expires: Aug 2004 [Page 14] 784 785Internet-Draft yu-krb-extensions-00 09 Feb 2004 786 787 Type 788 Indicates the ASN.1 type whose DER encoding is signed. 789 7907.3.2. Signed 791 792 Signed is like "ChecksumOf", but contains an actual instance of the 793 type being signed in addition to the signature. 794 795 -- parameterized type for wrapping authenticated plaintext 796 Signed { InnerType, KeyToUse:Keys, KeyUsage:KeyUsages } ::= 797 SEQUENCE { 798 cksum [0] ChecksumOf 799 { InnerType, Keys, KeyUsages } OPTIONAL, 800 inner [1] InnerType, 801 ... 802 } 803 804 8058. Tickets 806 807 The important fields of a ticket are in the encrypted part. The 808 components in common between the RFC 1510 and the extensible versions 809 are 810 811 EncTicketPartCommon ::= SEQUENCE { 812 flags [0] TicketFlags, 813 key [1] EncryptionKey, 814 crealm [2] Realm, 815 cname [3] PrincipalName, 816 transited [4] TransitedEncoding, 817 authtime [5] KerberosTime, 818 starttime [6] KerberosTime OPTIONAL, 819 endtime [7] KerberosTime, 820 renew-till [8] KerberosTime OPTIONAL, 821 caddr [9] HostAddresses OPTIONAL, 822 authorization-data [10] AuthorizationData OPTIONAL, 823 ... 824 } 825 826 827 crealm 828 This field contains the client's realm. 829 830 cname 831 This field contains the client's name. 832 833 caddr 834 This field lists the network addresses (if absent, all addresses 835 are permitted) from which the ticket is valid. 836 837 838 839Yu Expires: Aug 2004 [Page 15] 840 841Internet-Draft yu-krb-extensions-00 09 Feb 2004 842 843 Descriptions of the other fields appear in the following sections. 844 8458.1. Timestamps 846 847 Three of the ticket timestamps may be requested from the KDC. The 848 timestamps may differ from those requested, depending on site policy. 849 850 authtime 851 The time at which the client authenticated, as recorded by the 852 KDC. 853 854 starttime 855 The earliest time when the ticket is valid. If not present, the 856 ticket is valid starting at the authtime. This is requested as 857 the "from" field of KDC-REQ-BODY-COMMON. 858 859 endtime 860 This time is requested in the "till" field of KDC-REQ-BODY- 861 COMMON. Contains the time after which the ticket will not be 862 honored (its expiration time). Note that individual services 863 MAY place their own limits on the life of a ticket and MAY 864 reject tickets which have not yet expired. As such, this is 865 really an upper bound on the expiration time for the ticket. 866 867 renew-till 868 This time is requested in the "rtime" field of KDC-REQ-BODY- 869 COMMON. It is only present in tickets that have the "renewable" 870 flag set in the flags field. It indicates the maximum endtime 871 that may be included in a renewal. It can be thought of as the 872 absolute expiration time for the ticket, including all renewals. 873 8748.2. Ticket Flags 875 876 A number of flags may be set in the ticket, further defining some of 877 its capabilities. Some of these flags map to flags in a KDC request. 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895Yu Expires: Aug 2004 [Page 16] 896 897Internet-Draft yu-krb-extensions-00 09 Feb 2004 898 899 TicketFlags ::= KerberosFlags { TicketFlagsBits } 900 901 TicketFlagsBits ::= BIT STRING { 902 reserved (0), 903 forwardable (1), 904 forwarded (2), 905 proxiable (3), 906 proxy (4), 907 may-postdate (5), 908 postdated (6), 909 invalid (7), 910 renewable (8), 911 initial (9), 912 pre-authent (10), 913 hw-authent (11), 914 transited-policy-checked (12), 915 ok-as-delegate (13), 916 anonymous (14), 917 cksummed-ticket (15) 918 } 919 920 9218.2.1. Flags Relating to Initial Ticket Acquisition 922 923 [ adapted KCLAR 2.1. ] 924 925 Several flags indicate the details of how the initial ticket was 926 acquired. 927 928 initial 929 The "initial" flag indicates that a ticket was issued using the 930 AS protocol, rather than issued based on a ticket-granting 931 ticket. Application servers (e.g., a password-changing program) 932 requiring a client's definite knowledge of its secret keycan 933 insist that this flag be set in any tickets they accept, and 934 thus be assured that the client's key was recently presented to 935 the application client. 936 937 pre-authent 938 The "pre-authent" flag indicates that some sort of pre- 939 authentication was used during the AS exchange. 940 941 hw-authent 942 The "hw-authent" flag indicates that some sort of hardware-based 943 pre-authentication occurred during the AS exchange. 944 945 Both the "pre-authent" and the "hw-authent" flags may be present with 946 or without the "initial" flag; such tickets with the "initial" flag 947 clear are ones which are derived from initial tickets with the "pre- 948 authent" or "hw-authent" flags set. 949 950 951Yu Expires: Aug 2004 [Page 17] 952 953Internet-Draft yu-krb-extensions-00 09 Feb 2004 954 9558.2.2. Invalid Tickets 956 957 [ KCLAR 2.2. ] 958 959 The "invalid" flag indicates that a ticket is invalid. Application 960 servers MUST reject tickets which have this flag set. A postdated 961 ticket will be issued in this form. Invalid tickets MUST be 962 validated by the KDC before use, by presenting them to the KDC in a 963 TGS request with the "validate" option specified. The KDC will only 964 validate tickets after their starttime has passed. The validation is 965 required so that postdated tickets which have been stolen before 966 their starttime can be rendered permanently invalid (through a hot- 967 list mechanism -- see Section 9.3.5). 968 9698.2.3. OK as Delegate 970 971 [ KCLAR 2.8. ] 972 973 For some applications a client may need to delegate authority to a 974 server to act on its behalf in contacting other services. This 975 requires that the client forward credentials to an intermediate 976 server. The ability for a client to obtain a service ticket to a 977 server conveys no information to the client about whether the server 978 should be trusted to accept delegated credentials. The "ok-as- 979 delegate" flag provides a way for a KDC to communicate local realm 980 policy to a client regarding whether an intermediate server is 981 trusted to accept such credentials. 982 983 The copy of the ticket flags visible to the client may have the "ok- 984 as-delegate" flag set to indicate to the client that the server 985 specified in the ticket has been determined by policy of the realm to 986 be a suitable recipient of delegation. A client can use the presence 987 of this flag to help it make a decision whether to delegate 988 credentials (either grant a proxy or a forwarded ticket-granting 989 ticket) to this server. It is acceptable to ignore the value of this 990 flag. When setting this flag, an administrator should consider the 991 security and placement of the server on which the service will run, 992 as well as whether the service requires the use of delegated 993 credentials. 994 9958.3. Renewable Tickets 996 997 [ adapted KCLAR 2.3. ] 998 999 Renewable tickets can be used to mitigate the consequences of ticket 1000 theft. Applications may desire to hold tickets which can be valid 1001 for long periods of time. However, this can expose their credentials 1002 to potential theft for equally long periods, and those stolen 1003 credentials would be valid until the expiration time of the 1004 ticket(s). Simply using short-lived tickets and obtaining new ones 1005 periodically would require the client to have long-term access to its 1006 1007Yu Expires: Aug 2004 [Page 18] 1008 1009Internet-Draft yu-krb-extensions-00 09 Feb 2004 1010 1011 secret key, an even greater risk. 1012 1013 Renewable tickets have two "expiration times": the first is when the 1014 current instance of the ticket expires, and the second is the latest 1015 permissible value for an individual expiration time. An application 1016 client must periodically (i.e., before it expires) present a 1017 renewable ticket to the KDC, with the "renew" option set in the KDC 1018 request. The KDC will issue a new ticket with a new session key and 1019 a later expiration time. All other fields of the ticket are left 1020 unmodified by the renewal process. When the latest permissible 1021 expiration time arrives, the ticket expires permanently. At each 1022 renewal, the KDC MAY consult a hot-list to determine if the ticket 1023 had been reported stolen since its last renewal; it will refuse to 1024 renew such stolen tickets, and thus the usable lifetime of stolen 1025 tickets is reduced. 1026 1027 The "renewable" flag in a ticket is normally only interpreted by the 1028 ticket-granting service. It can usually be ignored by application 1029 servers. However, some particularly careful application servers MAY 1030 disallow renewable tickets. 1031 1032 If a renewable ticket is not renewed by its expiration time, the KDC 1033 will not renew the ticket. The "renewable" flag is clear by default, 1034 but a client can request it be set by setting the "renewable" option 1035 in the AS-REQ message. If it is set, then the "renew-till" field in 1036 the ticket contains the time after which the ticket may not be 1037 renewed. 1038 10398.4. Postdated Tickets 1040 1041 [ KCLAR 2.4. ] 1042 1043 Applications may occasionally need to obtain tickets for use much 1044 later, e.g., a batch submission system would need tickets to be valid 1045 at the time the batch job is serviced. However, it is dangerous to 1046 hold valid tickets in a batch queue, since they will be on-line 1047 longer and more prone to theft. Postdated tickets provide a way to 1048 obtain these tickets from the KDC at job submission time, but to 1049 leave them "dormant" until they are activated and validated by a 1050 further request of the KDC. If a ticket theft were reported in the 1051 interim, the KDC would refuse to validate the ticket, and the thief 1052 would be foiled. 1053 1054 The "may-postdate" flag in a ticket is normally only interpreted by 1055 the TGS. It can be ignored by application servers. This flag MUST be 1056 set in a ticket-granting ticket in order for the KDC to issue a 1057 postdated ticket based on the presented ticket. It is reset by 1058 default; it MAY be requested by a client by setting the "allow- 1059 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag 1060 does not allow a client to obtain a postdated ticket-granting ticket; 1061 postdated ticket-granting tickets can only by obtained by requesting 1062 1063Yu Expires: Aug 2004 [Page 19] 1064 1065Internet-Draft yu-krb-extensions-00 09 Feb 2004 1066 1067 the postdating in the AS-REQ message. The life (endtime-starttime) 1068 of a postdated ticket will be the remaining life of the ticket- 1069 granting ticket at the time of the request, unless the "renewable" 1070 option is also set, in which case it can be the full life (endtime- 1071 starttime) of the ticket-granting ticket. The KDC MAY limit how far 1072 in the future a ticket may be postdated. 1073 1074 The "postdated" flag indicates that a ticket has been postdated. The 1075 application server can check the authtime field in the ticket to see 1076 when the original authentication occurred. Some services MAY choose 1077 to reject postdated tickets, or they may only accept them within a 1078 certain period after the original authentication. When the KDC issues 1079 a "postdated" ticket, it will also be marked as "invalid", so that 1080 the application client MUST present the ticket to the KDC for 1081 validation before use. 1082 10838.5. Proxiable and Proxy Tickets 1084 1085 [ KCLAR 2.5. ] 1086 1087 At times it may be necessary for a principal to allow a service to 1088 perform an operation on its behalf. The service must be able to take 1089 on the identity of the client, but only for a particular purpose. A 1090 principal can allow a service to take on the principal's identity for 1091 a particular purpose by granting it a proxy. 1092 1093 The process of granting a proxy using the "proxy" and "proxiable" 1094 flags is used to provide credentials for use with specific services. 1095 Though conceptually also a proxy, users wishing to delegate their 1096 identity in a form usable for all purposes MUST use the ticket 1097 forwarding mechanism described in the next section to forward a 1098 ticket-granting ticket. 1099 1100 The "proxiable" flag in a ticket is normally only interpreted by the 1101 ticket-granting service. It can be ignored by application servers. 1102 When set, this flag tells the ticket-granting server that it is OK to 1103 issue a new ticket (but not a ticket-granting ticket) with a 1104 different network address based on this ticket. This flag is set if 1105 requested by the client on initial authentication. By default, the 1106 client will request that it be set when requesting a ticket-granting 1107 ticket, and reset when requesting any other ticket. 1108 1109 This flag allows a client to pass a proxy to a server to perform a 1110 remote request on its behalf (e.g. a print service client can give 1111 the print server a proxy to access the client's files on a particular 1112 file server in order to satisfy a print request). 1113 1114 In order to complicate the use of stolen credentials, Kerberos 1115 tickets may contain a set of network addresses from which they are 1116 valid. When granting a proxy, the client MUST specify the new network 1117 address from which the proxy is to be used, or indicate that the 1118 1119Yu Expires: Aug 2004 [Page 20] 1120 1121Internet-Draft yu-krb-extensions-00 09 Feb 2004 1122 1123 proxy is to be issued for use from any address. 1124 1125 The "proxy" flag is set in a ticket by the TGS when it issues a proxy 1126 ticket. Application servers MAY check this flag and at their option 1127 they MAY require additional authentication from the agent presenting 1128 the proxy in order to provide an audit trail. 1129 11308.6. Forwardable Tickets 1131 1132 [ KCLAR 2.6. ] 1133 11348.7. Transited Realms 1135 1136 [ KCLAR 2.7., plus new stuff ] 1137 11388.8. Authorization Data 1139 11408.9. Encrypted Part of Ticket 1141 1142 The complete definition of the encrypted part is 1143 1144 -- Encrypted part of ticket 1145 EncTicketPart ::= CHOICE { 1146 rfc1510 [APPLICATION 3] EncTicketPart1510, 1147 ext [APPLICATION 5] EncTicketPartExt 1148 } 1149 1150 1151 EncTicketPart1510 ::= SEQUENCE { 1152 -- effectively drops the extension marker 1153 COMPONENTS OF EncTicketPartCommon 1154 } (WITH COMPONENTS { 1155 ..., 1156 -- explicitly force IA5 in strings 1157 crealm (WITH COMPONENTS { ia5 PRESENT }), 1158 cname (WITH COMPONENTS { 1159 ..., 1160 name-string (WITH COMPONENT 1161 (WITH COMPONENTS { ia5 PRESENT })) 1162 }) 1163 }) 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175Yu Expires: Aug 2004 [Page 21] 1176 1177Internet-Draft yu-krb-extensions-00 09 Feb 2004 1178 1179 EncTicketPartExt ::= EncTicketPartCommon 1180 (WITH COMPONENTS { 1181 ..., 1182 -- explicitly force UTF-8 in strings 1183 crealm (WITH COMPONENTS { ia5 ABSENT }), 1184 cname (WITH COMPONENTS { 1185 ..., 1186 name-string (WITH COMPONENT 1187 (WITH COMPONENTS { ia5 ABSENT })) 1188 }), 1189 -- explicitly constrain caddr to be non-empty if present 1190 caddr (SIZE (1..MAX)), 1191 -- explicitly constrain authorization-data to be non-empty 1192 -- if present 1193 authorization-data (SIZE (1..MAX)) 1194 }) 1195 1196 11978.10. Cleartext Part of Ticket 1198 1199 Ticket ::= CHOICE { 1200 rfc1510 [APPLICATION 1] Ticket1510, 1201 ext [APPLICATION 4] Signed { 1202 TicketExt, { key-server }, { ku-Ticket-cksum } 1203 } 1204 } 1205 1206 1207 -- takes a parameter specifying which type gets encrypted 1208 TicketCommon { EncPart } ::= SEQUENCE { 1209 tkt-vno [0] INTEGER (5), 1210 realm [1] Realm, 1211 sname [2] PrincipalName, 1212 enc-part [3] EncryptedData { 1213 EncPart, { key-server }, { ku-Ticket } 1214 }, 1215 extensions [4] TicketExtensions OPTIONAL, 1216 ... 1217 } 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231Yu Expires: Aug 2004 [Page 22] 1232 1233Internet-Draft yu-krb-extensions-00 09 Feb 2004 1234 1235 Ticket1510 ::= SEQUENCE { 1236 -- "COMPONENTS OF" drops the extension marker from 1237 -- TicketCommon 1238 COMPONENTS OF TicketCommon { EncTicketPart1510 } 1239 } (WITH COMPONENTS { 1240 ..., 1241 -- explicitly force IA5 in strings 1242 realm (WITH COMPONENTS { ia5 PRESENT }), 1243 sname (WITH COMPONENTS { 1244 ..., 1245 name-string (WITH COMPONENT 1246 (WITH COMPONENTS { ia5 PRESENT })) 1247 }), 1248 extensions ABSENT 1249 }) 1250 1251 1252 -- APPLICATION tag goes inside Signed{} as well as outside, 1253 -- to prevent possible substitution attacks. 1254 TicketExt ::= [APPLICATION 4] TicketCommon 1255 (WITH COMPONENTS { 1256 ..., 1257 -- explicitly force UTF-8 in strings 1258 realm (WITH COMPONENTS { ia5 ABSENT }), 1259 sname (WITH COMPONENTS { 1260 ..., 1261 name-string (WITH COMPONENT 1262 (WITH COMPONENTS { ia5 ABSENT })) 1263 }) 1264 }) 1265 1266 1267 TEType ::= Int32 1268 1269 TICKETEXTENSION ::= TYPEDHOLE { TEType } 1270 1271 -- ticket extensions: for TicketExt only 1272 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 1273 te-type [0] TICKETEXTENSION.&id 1274 ({TicketExtension-Set}), 1275 te-data [1] OCTET STRING (TICKETEXTENSION.&Type) 1276 ({TicketExtension-Set}{@te-type}) 1277 } 1278 1279 -- no mandatory ticket extensions currently 1280 TicketExtensionSet TICKETEXTENSION ::= { ... } 1281 1282 12839. Credential Acquisition 1284 1285 1286 1287Yu Expires: Aug 2004 [Page 23] 1288 1289Internet-Draft yu-krb-extensions-00 09 Feb 2004 1290 1291 There are two exchanges that can be used for acquiring credentials: 1292 the AS exchange and the TGS exchange. These exchanges have many 1293 similarities, and this document describes them in parallel, noting 1294 which behaviors are specific to one type of exchange. The AS request 1295 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests 1296 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) 1297 are forms of KDC replies (KDC-REP). 1298 12999.1. KDC-REQ 1300 1301 The KDC-REQ has a large number of fields in common between the RFC 1302 1510 and the extensible versions. 1303 1304 KDC-REQ-COMMON ::= SEQUENCE { 1305 -- NOTE: first tag is [1], not [0] 1306 pvno [1] INTEGER (5), 1307 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- 1308 | 12 -- TGS-REQ.rfc1510 -- 1309 | 6 -- AS-REQ.ext -- 1310 | 8 -- TGS-REQ.ext -- ), 1311 padata [3] SEQUENCE OF PA-DATA OPTIONAL 1312 -- NOTE: not empty 1313 } 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343Yu Expires: Aug 2004 [Page 24] 1344 1345Internet-Draft yu-krb-extensions-00 09 Feb 2004 1346 1347 KDC-REQ-BODY-COMMON ::= SEQUENCE { 1348 kdc-options [0] KDCOptions, 1349 cname [1] PrincipalName OPTIONAL 1350 -- Used only in AS-REQ --, 1351 1352 realm [2] Realm 1353 -- Server's realm; also client's in AS-REQ --, 1354 1355 sname [3] PrincipalName OPTIONAL, 1356 from [4] KerberosTime OPTIONAL, 1357 till [5] KerberosTime OPTIONAL 1358 -- was required in rfc1510; 1359 -- still required for compat versions 1360 -- of messages --, 1361 1362 rtime [6] KerberosTime OPTIONAL, 1363 nonce [7] Nonce, 1364 etype [8] SEQUENCE OF EType 1365 -- in preference order --, 1366 1367 addresses [9] HostAddresses OPTIONAL, 1368 enc-authorization-data [10] EncryptedData { 1369 AuthorizationData, { key-session | key-subsession }, 1370 { ku-TGSReqAuthData-subkey | 1371 ku-TGSReqAuthData-sesskey } 1372 } OPTIONAL, 1373 1374 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 1375 -- NOTE: not empty --, 1376 ... 1377 } 1378 1379 1380 Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of 1381 an EncTicketPartCommon. The KDC copies most of them unchanged, 1382 provided that their values meet site policy. 1383 1384 kdc-options 1385 These flags do not correspond directly to "flags" in 1386 EncTicketPartCommon. [ insert mapping table here ] 1387 1388 cname 1389 This field is copied to the "cname" field in 1390 EncTicketPartCommon. The "cname" field is required in an AS- 1391 REQ; the client places its own name here. In a TGS-REQ, the 1392 "cname" in the ticket in the AP-REQ takes precedence. 1393 1394 realm 1395 This field is the server's realm, and also holds the client's 1396 realm in an AS-REQ. 1397 1398 1399Yu Expires: Aug 2004 [Page 25] 1400 1401Internet-Draft yu-krb-extensions-00 09 Feb 2004 1402 1403 The "from", "till", and "rtime" fields correspond to the "starttime", 1404 "endtime", and "renew-till" fields of EncTicketPartCommon. 1405 1406 addresses 1407 This field corresponds to the "caddr" field of 1408 EncTicketPartCommon. 1409 1410 enc-authorization-data 1411 For TGS-REQ, this field contains authorization data encrypted 1412 using either the TGT session key or the AP-REQ subsession key; 1413 these may be copied into the "authorization-data" field of 1414 EncTicketPartCommon if policy permits. 1415 14169.2. PA-DATA 1417 1418 PA-DATA have multiple uses in the Kerberos protocol. They may pre- 1419 authenticate an AS-REQ; they may also modify several of the 1420 encryption keys used in a KDC-REP. PA-DATA may also provide "hints" 1421 to the client about which long-term key (usually password-derived) to 1422 use. PA-DATA may also include "hints" about which pre-authentication 1423 mechanisms to use, or include data for input into a pre- 1424 authentication mechanism. 1425 14269.3. KDC-REQ Processing 1427 1428 Processing of a KDC-REQ proceeds through several steps. An 1429 implementation need not perform these steps exactly as described, as 1430 long as the resulting behavior is as if the steps were performed as 1431 described. The KDC performs replay handling on receipt of the 1432 request; it then validates the request, adjusts timestamps, and 1433 selects the keys used in the reply. It copies data from the request 1434 into the issued ticket, adjusting for policy. The KDC then transmits 1435 the reply to the client. 1436 14379.3.1. Handling Replays 1438 1439 Because Kerberos can run over unreliable transports such as UDP, the 1440 KDC MUST be prepared to retransmit responses in case they are lost. 1441 If a KDC receives a request identical to one it has recently 1442 successfully processed, the KDC MUST respond with an KDC-REP message 1443 rather than a replay error. In order to reduce the amount of 1444 ciphertext given to a potential attacker, KDCs MAY send the same 1445 response generated when the request was first handled. KDCs MUST 1446 obey this replay behavior even if the actual transport in use is 1447 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, 1448 and the entire request is not identical to a recently successfully 1449 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is 1450 appropriate for AP-REQ processing. 1451 1452 1453 1454 1455Yu Expires: Aug 2004 [Page 26] 1456 1457Internet-Draft yu-krb-extensions-00 09 Feb 2004 1458 14599.3.2. Request Validation 1460 14619.3.2.1. AS-REQ Authentication 1462 1463 Site policy determines whether a given client principal is required 1464 to provide some pre-authentication prior to receiving an AS-REP. 1465 Since the default reply key is typically the client's long-term 1466 password-based key, an attacker may easily request known plaintext 1467 (in the form of an AS-REP) upon which to mount a dictionary attack. 1468 Pre-authentication can limit the possibility of such an attack. 1469 1470 If site policy requires pre-authentication for a client principal, 1471 and no pre-authentication is provided, the KDC returns the error 1472 "kdc-err-preauth-required". Accompanying this error are "e-data" 1473 which include hints telling the client which pre-authentication 1474 mechanisms to use, or data for input to pre-authentication mechanisms 1475 (e.g., input to challenge-response systems). If pre-authentication 1476 fails, the KDC returns the error "kdc-err-preauth-failed". 1477 1478 [ may need additional changes based on Sam's preauth draft ] 1479 14809.3.2.2. TGS-REQ Authentication 1481 1482 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- 1483 tgs-req". The KDC MUST validate the checksum in the Authenticator of 1484 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- 1485 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the 1486 request. [ padata not signed by authenticator! ] Any error from the 1487 AP-REQ validation process SHOULD be returned in a KRB-ERROR message. 1488 The service principal in the ticket of the AP-REQ may be a ticket- 1489 granting service principal, or a normal application service 1490 principal. An AP-REQ ticket which is not a ticket-granting ticket 1491 MUST NOT be used to issue a ticket for any service other than the one 1492 named in the ticket. In this case, the "renew", "validate", or 1493 "proxy" [?also forwarded?] option must be set in the request. 1494 14959.3.2.3. Principal Validation 1496 1497 If the client principal in an AS-REQ is unknown, the KDC returns the 1498 error "kdc-err-c-principal-unknown". If the server principal is 1499 unknown, the KDC returns the error "kdc-err-c-principal-unknown". 1500 15019.3.3. Timestamp Handling 1502 1503 [ some aspects of timestamp handling, especially regarding postdating 1504 and renewal, are difficult to read in KCLAR... needs closer 1505 examination here ] 1506 1507 For the AS exchange, the "authtime" of a ticket is set to the local 1508 time at the KDC. For the TGS exchange, the KDC sets the "authtime" 1509 to that of the ticket in the AP-REQ authenticating the TGS-REQ. 1510 1511Yu Expires: Aug 2004 [Page 27] 1512 1513Internet-Draft yu-krb-extensions-00 09 Feb 2004 1514 1515 [?application server can spoof the authtime. security issues for 1516 hot-list?] [ MIT implementation may change authtime of renewed 1517 tickets; needs check... ] 1518 1519 Processing of "starttime" (requested in the "from" field) differs 1520 depending on whether the "postdated" option is set in the request. 1521 If the "postdated" option is not set, and the requested "starttime" 1522 is in the future beyond the window of acceptable clock skew, the KDC 1523 returns the error "kdc-err-cannot-postdate". If the "postdated" 1524 option is not set, and the requested "starttime" is absent or does 1525 not indicate a time in the future beyond the acceptable clock skew, 1526 the KDC sets the "starttime" to the KDC's current time. The 1527 "postdated" option MUST NOT be honored if the ticket is being 1528 requested by TGS-REQ and the "may-postdate" is not set in the TGT. 1529 Otherwise, if the "postdated" option is set, and site policy permits, 1530 the KDC sets the "starttime" as requested, and sets the "invalid" 1531 flag in the new ticket. 1532 15339.3.3.1. AS-REQ Timestamp Processing 1534 1535 The "endtime" of the ticket will be set to the earlier of the 1536 requested "till" time and a time determined by local policy, possibly 1537 determined using factors specific to the realm or principal. For 1538 example, the expiration time MAY be set to the earliest of the 1539 following: 1540 1541 * The expiration time (till) requested. 1542 1543 * The ticket's start time plus the maximum allowable lifetime 1544 associated with the client principal from the authentication 1545 server's database. 1546 1547 * The ticket's start time plus the maximum allowable lifetime 1548 associated with the server principal. 1549 1550 * The ticket's start time plus the maximum lifetime set by the 1551 policy of the local realm. 1552 1553 If the requested expiration time minus the start time (as determined 1554 above) is less than a site-determined minimum lifetime, an error 1555 message with code "kdc-err-never-valid" is returned. If the requested 1556 expiration time for the ticket exceeds what was determined as above, 1557 and if the "renewable-ok" option was requested, then the "renewable" 1558 flag is set in the new ticket, and the "renew-till" value is set as 1559 if the "renewable" option were requested. 1560 1561 If the "renewable" option has been requested or if the "renewable-ok" 1562 option has been set and a renewable ticket is to be issued, then the 1563 renew-till field MAY be set to the earliest of: 1564 1565 1566 1567Yu Expires: Aug 2004 [Page 28] 1568 1569Internet-Draft yu-krb-extensions-00 09 Feb 2004 1570 1571 * Its requested value. 1572 1573 * The start time of the ticket plus the minimum of the two maximum 1574 renewable lifetimes associated with the principals' database 1575 entries. 1576 1577 * The start time of the ticket plus the maximum renewable lifetime 1578 set by the policy of the local realm. 1579 15809.3.3.2. TGS-REQ Timestamp Processing 1581 1582 If the TGS-REQ has the TGT in its AP-REQ, and the TGS-REQ requests an 1583 "endtime" (in the "till" field), then the "endtime" of the new ticket 1584 is set to the minimum of (a) the requested "endtime" value, (b) the 1585 "endtime" in the TGT, and (c) an "endtime" determined by site policy 1586 on ticket lifetimes. If the new ticket is a renewal, the "endtime" 1587 of the new ticket is bounded by (a) the requested "endtime" value, 1588 (b) the value of the "renew-till" value of the old, and (c) the 1589 "starttime" of the new ticket plus the life (endtime - starttime) of 1590 the old ticket. [ the previous sentence is a bit confusing; adapted 1591 from KCLAR 3.3.3. ] 1592 1593 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with 1594 a "starttime", "endtime", or "renew-till" time later than the "renew- 1595 till" time of the TGT. 1596 15979.3.4. Key Selection 1598 1599 Three keys are involved in creating a KDC-REP. The reply key is used 1600 to encrypt the encrypted part of the KDC-REP. The session key is 1601 stored in the encrypted part of the ticket, and is also present in 1602 the part of the reply which is visible to the client. The ticket key 1603 is used to encrypt the ticket. These keys all have initial values 1604 for a given exchange; pre-authentication and other extension 1605 mechanisms may change the value used for any of these keys. 1606 1607 [ again, may need changes based on Sam's preauth draft ] 1608 1609 The set of encryption types the client will understand appears in the 1610 "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set of 1611 possible reply keys and the set of session key encryption types based 1612 on the "etype" field. 1613 1614 For the AS exchange, the reply key is initially a long-term key of 1615 the client, limited to those encryption types specified by the 1616 "etype" field. The KDC SHOULD use the first valid strong "etype" for 1617 which an encryption key is available. For the TGS exchange, the 1618 reply key is initially the subsession key of the Authenticator, or, 1619 if that is not present, the session key of the ticket used to 1620 authenticate the TGS-REQ. 1621 1622 1623Yu Expires: Aug 2004 [Page 29] 1624 1625Internet-Draft yu-krb-extensions-00 09 Feb 2004 1626 1627 The ticket key is initially the long-term key of the service. User- 1628 to-user authentication sets the ticket key to be the session key of 1629 the additional ticket in the request. 1630 1631 The session key is initially randomly generated, and has an 1632 encryption type which both the client and the server will understand. 1633 Typically, the KDC has prior knowledge of which encryption types the 1634 server will understand. It selects the first valid strong "etype" 1635 listed the request which the server also will understand. 1636 16379.3.5. Checking For Revoked Tickets 1638 16399.4. Reply Validation 1640 164110. Application Authentication 1642 164311. Session Key Use 1644 164511.1. KRB-SAFE 1646 164711.2. KRB-PRIV 1648 164911.3. KRB-CRED 1650 165112. Security Considerations 1652 165312.1. Time Synchronization 1654 1655 Time synchronization between the KDC and application servers is 1656 necessary to prevent acceptance of expired tickets. 1657 1658 Time synchronization is needed between application servers and 1659 clients to prevent replay attacks if a replay cache is being used. 1660 If negotiated subsession keys are used to encrypt application data, 1661 replay caches may not be necessary. 1662 166312.2. Replays 1664 166512.3. Principal Name Reuse 1666 1667 See Section 6.2. 1668 166912.4. Password Guessing 1670 167112.5. Forward Secrecy 1672 1673 [from KCLAR 10.; needs some rewriting] 1674 1675 The Kerberos protocol in its basic form does not provide perfect 1676 forward secrecy for communications. If traffic has been recorded by 1677 an eavesdropper, then messages encrypted using the KRB-PRIV message, 1678 1679Yu Expires: Aug 2004 [Page 30] 1680 1681Internet-Draft yu-krb-extensions-00 09 Feb 2004 1682 1683 or messages encrypted using application-specific encryption under 1684 keys exchanged using Kerberos can be decrypted if any of the user's, 1685 application server's, or KDC's key is subsequently discovered. This 1686 is because the session key used to encrypt such messages is 1687 transmitted over the network encrypted in the key of the application 1688 server, and also encrypted under the session key from the user's 1689 ticket-granting ticket when returned to the user in the TGS-REP 1690 message. The session key from the ticket-granting ticket was sent to 1691 the user in the AS-REP message encrypted in the user's secret key, 1692 and embedded in the ticket-granting ticket, which was encrypted in 1693 the key of the KDC. Application requiring perfect forward secrecy 1694 must exchange keys through mechanisms that provide such assurance, 1695 but may use Kerberos for authentication of the encrypted channel 1696 established through such other means. 1697 169812.6. Authorization 1699 1700 As an authentication service, Kerberos provides a means of verifying 1701 the identity of principals on a network. Kerberos does not, by 1702 itself, provide authorization. Applications SHOULD NOT accept the 1703 mere issuance of a service ticket by the Kerberos server as granting 1704 authority to use the service. 1705 170612.7. Login Authentication 1707 1708 Some applications, particularly those which provide login access when 1709 provided with a password, SHOULD NOT treat successful acquisition of 1710 credentials as sufficient proof of the user's identity. An attacker 1711 posing as a user could generate an illegitimate KDC-REP message which 1712 decrypts properly. To authenticate a user logging on to a local 1713 system, the credentials obtained SHOULD be used in a TGS exchange to 1714 obtain credentials for a local service. Successful use of those 1715 credentials to authenticate to the local service assures that the 1716 initially obtained credentials are from a valid KDC. 1717 1718Appendices 1719 1720A. ASN.1 Module (Normative) 1721 1722 KerberosV5Spec3 { 1723 iso(1) identified-organization(3) dod(6) internet(1) 1724 security(5) kerberosV5(2) modules(4) krb5spec3(4) 1725 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735Yu Expires: Aug 2004 [Page 31] 1736 1737Internet-Draft yu-krb-extensions-00 09 Feb 2004 1738 1739 -- OID arc for KerberosV5 1740 -- 1741 -- This OID may be used to identify Kerberos protocol messages 1742 -- encapsulated in other protocols. 1743 -- 1744 -- This OID also designates the OID arc for KerberosV5-related 1745 -- OIDs. 1746 -- 1747 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its 1748 -- OID. 1749 id-krb5 OBJECT IDENTIFIER ::= { 1750 iso(1) identified-organization(3) dod(6) internet(1) 1751 security(5) kerberosV5(2) 1752 } 1753 1754 1755 -- top-level type 1756 -- 1757 -- Applications should not directly reference any types 1758 -- other than KRB-PDU and its component types. 1759 -- 1760 KRB-PDU ::= CHOICE { 1761 ticket Ticket, 1762 as-req AS-REQ, 1763 as-rep AS-REP, 1764 tgs-req TGS-REQ, 1765 tgs-rep TGS-REP, 1766 ap-req AP-REQ, 1767 ap-rep AP-REP, 1768 krb-safe KRB-SAFE, 1769 krb-priv KRB-PRIV, 1770 krb-cred KRB-CRED, 1771 tgt-req TGT-REQ, 1772 krb-error KRB-ERROR, 1773 ... 1774 } 1775 1776 1777 -- 1778 -- *** basic types 1779 -- 1780 1781 1782 -- signed values representable in 32 bits 1783 -- 1784 -- These are often used as assigned numbers for various things. 1785 Int32 ::= INTEGER (-2147483648..2147483647) 1786 1787 -- unsigned 32 bit values 1788 UInt32 ::= INTEGER (0..4294967295) 1789 1790 1791Yu Expires: Aug 2004 [Page 32] 1792 1793Internet-Draft yu-krb-extensions-00 09 Feb 2004 1794 1795 -- microseconds 1796 Microseconds ::= INTEGER (0..999999) 1797 1798 1799 -- sequence numbers 1800 -- 1801 -- We may want to increase this to 2**64 and define a UInt64 1802 -- type. 1803 SeqNum ::= UInt32 1804 1805 1806 -- nonces 1807 -- 1808 -- Likewise, we may want to make this UInt64. 1809 Nonce ::= UInt32 1810 1811 1812 -- must not have fractional seconds 1813 KerberosTime ::= GeneralizedTime 1814 1815 1816 -- used for names and for error messages 1817 KerberosString ::= CHOICE { 1818 ia5 GeneralString (IA5String), 1819 utf8 UTF8String, 1820 ... -- no extension may be sent 1821 -- to an rfc1510 implementation -- 1822 } 1823 1824 1825 -- used for language tags 1826 LangTag ::= PrintableString (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 1827 1828 1829 Realm ::= KerberosString 1830 1831 PrincipalName ::= SEQUENCE { 1832 name-type [0] NameType, 1833 -- May have zero elements, or individual elements may be 1834 -- zero-length, but this is not recommended. 1835 name-string [1] SEQUENCE OF KerberosString 1836 } 1837 1838 -- assigned numbers for name types (used in principal names) 1839 NameType ::= Int32 1840 1841 1842 1843 1844 1845 1846 1847Yu Expires: Aug 2004 [Page 33] 1848 1849Internet-Draft yu-krb-extensions-00 09 Feb 2004 1850 1851 -- Name type not known 1852 nt-unknown NameType ::= 0 1853 -- Just the name of the principal as in DCE, or for users 1854 nt-principal NameType ::= 1 1855 -- Service and other unique instance (krbtgt) 1856 nt-srv-inst NameType ::= 2 1857 -- Service with host name as instance (telnet, rcommands) 1858 nt-srv-hst NameType ::= 3 1859 -- Service with host as remaining components 1860 nt-srv-xhst NameType ::= 4 1861 -- Unique ID 1862 nt-uid NameType ::= 5 1863 -- Encoded X.509 Distingished name [RFC 2253] 1864 nt-x500-principal NameType ::= 6 1865 -- Name in form of SMTP email name (e.g. user@foo.com) 1866 nt-smtp-name NameType ::= 7 1867 -- Enterprise name - may be mapped to principal name 1868 nt-enterprise NameType ::= 10 1869 1870 1871 -- Yet another refinement to kludge around historical 1872 -- implementation bugs... we still send at least 32 bits, but 1873 -- this parameterized type allows us to actually use named bit 1874 -- string syntax to define flags, sort of. 1875 KerberosFlags { NamedBits } 1876 ::= BIT STRING (SIZE (32..MAX)) 1877 (CONSTRAINED BY { 1878 -- must be a valid value of -- NamedBits 1879 -- but if the value to be sent would otherwise be shorter 1880 -- than 32 bits, it must be padded with trailing zero bits 1881 -- to 32 bits. Otherwise, no trailing zero bits may be 1882 -- present. 1883 }) 1884 1885 1886 AddrType ::= Int32 1887 1888 HostAddress ::= SEQUENCE { 1889 addr-type [0] AddrType, 1890 address [1] OCTET STRING 1891 } 1892 1893 -- NOTE: HostAddresses is always used as an OPTIONAL field and 1894 -- should not be a zero-length SEQUENCE OF. 1895 -- 1896 -- The extensible messages explicitly constrain this to be 1897 -- non-empty. 1898 HostAddresses ::= SEQUENCE OF HostAddress 1899 1900 1901 1902 1903Yu Expires: Aug 2004 [Page 34] 1904 1905Internet-Draft yu-krb-extensions-00 09 Feb 2004 1906 1907 -- 1908 -- *** typed hole support 1909 -- 1910 1911 1912 -- Object class for generic typed holes, e.g., padata, 1913 -- authorizationdata. 1914 -- 1915 -- Its parameter specifies the name of integer type used as a 1916 -- unique identifier; usually this type is an aliased Int32. 1917 -- 1918 -- Usually, the &Type field will be an OctetstringHole, but if 1919 -- there is a need to use a non-ASN.1 encoded type, it may be 1920 -- simply an OCTET STRING, possibly with some comments 1921 -- describing its contents. 1922 TYPEDHOLE { IntType } ::= CLASS { 1923 &id-int IntType UNIQUE, 1924 &id-oid RELATIVE-OID UNIQUE OPTIONAL, 1925 &Type, 1926 &desc ObjectDescriptor OPTIONAL 1927 } WITH SYNTAX { 1928 SYNTAX &Type 1929 IDENTIFIED BY &id-int 1930 [ OID &id-oid ] 1931 [ DESCRIPTION &desc ] 1932 } 1933 1934 1935 -- An octet string wrapping another ASN.1 type. 1936 OctetstringHole { Type } ::= OCTET STRING (CONTAINING Type) 1937 1938 1939 -- 1940 -- *** crypto-related types and assignments 1941 -- 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959Yu Expires: Aug 2004 [Page 35] 1960 1961Internet-Draft yu-krb-extensions-00 09 Feb 2004 1962 1963 -- 1964 -- Actual identifier names are provisional and subject to 1965 -- change. 1966 -- 1967 ku-pa-enc-ts KeyUsage ::= 1 1968 ku-Ticket KeyUsage ::= 2 1969 ku-EncASRepPart KeyUsage ::= 3 1970 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 1971 ku-TGSReqAuthData-subkey KeyUsage ::= 5 1972 ku-pa-TGSReq-cksum KeyUsage ::= 6 1973 ku-pa-TGSReq-authenticator KeyUsage ::= 7 1974 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 1975 ku-EncTGSRepPart-subkey KeyUsage ::= 9 1976 ku-Authenticator-cksum KeyUsage ::= 10 1977 ku-APReq-authenticator KeyUsage ::= 11 1978 ku-EncAPRepPart KeyUsage ::= 12 1979 ku-EncKrbPrivPart KeyUsage ::= 13 1980 ku-EncKrbCredPart KeyUsage ::= 14 1981 ku-KrbSafe-cksum KeyUsage ::= 15 1982 ku-ad-KDCIssued-cksum KeyUsage ::= 19 1983 1984 1985 -- The following numbers are provisional... conflicts may exist elsewhere. 1986 ku-Ticket-cksum KeyUsage ::= 25 1987 ku-ASReq-cksum KeyUsage ::= 26 1988 ku-TGSReq-cksum KeyUsage ::= 27 1989 ku-ASRep-cksum KeyUsage ::= 28 1990 ku-TGSRep-cksum KeyUsage ::= 29 1991 ku-APReq-cksum KeyUsage ::= 30 1992 ku-APRep-cksum KeyUsage ::= 31 1993 ku-KrbCred-cksum KeyUsage ::= 32 1994 ku-KrbError-cksum KeyUsage ::= 33 1995 ku-KDCRep-cksum KeyUsage ::= 34 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015Yu Expires: Aug 2004 [Page 36] 2016 2017Internet-Draft yu-krb-extensions-00 09 Feb 2004 2018 2019 -- assigned numbers for encryption schemes 2020 et-des-cbc-crc EType ::= 1 2021 et-des-cbc-md4 EType ::= 2 2022 et-des-cbc-md5 EType ::= 3 2023 -- [reserved] 4 2024 et-des3-cbc-md5 EType ::= 5 2025 -- [reserved] 6 2026 et-des3-cbc-sha1 EType ::= 7 2027 et-dsaWithSHA1-CmsOID EType ::= 9 2028 et-md5WithRSAEncryption-CmsOID EType ::= 10 2029 et-sha1WithRSAEncryption-CmsOID EType ::= 11 2030 et-rc2CBC-EnvOID EType ::= 12 2031 et-rsaEncryption-EnvOID EType ::= 13 2032 et-rsaES-OAEP-ENV-OID EType ::= 14 2033 et-des-ede3-cbc-Env-OID EType ::= 15 2034 et-des3-cbc-sha1-kd EType ::= 16 2035 et-aes128-cts-hmac-sha1-96 EType ::= 17 -- AES 2036 et-aes256-cts-hmac-sha1-96 EType ::= 18 -- AES 2037 et-rc4-hmac EType ::= 23 -- Microsoft 2038 et-rc4-hmac-exp EType ::= 24 -- Microsoft 2039 et-subkey-keymaterial EType ::= 65 -- opaque; PacketCable 2040 2041 2042 -- "Type" specifies which ASN.1 type is encrypted to the 2043 -- ciphertext in the EncryptedData. "Keys" specifies a set of 2044 -- keys of which one key may be used to encrypt the data. 2045 -- "KeyUsages" specifies a set of key usages, one of which may 2046 -- be used to encrypt. 2047 -- 2048 -- None of the parameters is transmitted over the wire. 2049 EncryptedData { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::= 2050 SEQUENCE { 2051 etype [0] EType, 2052 kvno [1] UInt32 OPTIONAL, 2053 cipher [2] OCTET STRING (CONSTRAINED BY { 2054 -- must be encryption of -- 2055 OCTET STRING (CONTAINING Type), 2056 -- with one of the keys -- KeyToUse:Keys, 2057 -- with key usage being one of -- 2058 KeyUsage:KeyUsages 2059 }), 2060 ... 2061 } 2062 2063 -- Assigned numbers denoting encryption mechanisms. 2064 EType ::= Int32 2065 2066 -- Assigned numbers denoting key usages. 2067 KeyUsage ::= UInt32 2068 2069 2070 2071Yu Expires: Aug 2004 [Page 37] 2072 2073Internet-Draft yu-krb-extensions-00 09 Feb 2004 2074 2075 -- KeyToUse identifies which key is to be used to encrypt or 2076 -- sign a given value. 2077 -- 2078 -- Values of KeyToUse are never actually transmitted over the 2079 -- wire, or even used directly by the implementation in any 2080 -- way, as key usages are; it exists primarily to identify 2081 -- which key gets used for what purpose. Thus, the specific 2082 -- numeric values associated with this type are irrelevant. 2083 KeyToUse ::= ENUMERATED { 2084 -- unspecified 2085 key-unspecified, 2086 -- server long term key 2087 key-server, 2088 -- client long term key 2089 key-client, 2090 -- key selected by KDC for encryption of a KDC-REP 2091 key-kdc-rep, 2092 -- session key from ticket 2093 key-session, 2094 -- subsession key negotiated via AP-REQ/AP-REP 2095 key-subsession, 2096 ... 2097 } 2098 2099 2100 EncryptionKey ::= SEQUENCE { 2101 keytype [0] EType, 2102 keyvalue [1] OCTET STRING 2103 } 2104 2105 2106 CksumType ::= Int32 2107 2108 -- The parameters specify which key to use to produce the 2109 -- signature, as well as which key usage to use. The 2110 -- parameters are not actually sent over the wire. 2111 Checksum { KeyToUse:Keys, KeyUsage:KeyUsages } ::= SEQUENCE { 2112 cksumtype [0] CksumType, 2113 checksum [1] OCTET STRING (CONSTRAINED BY { 2114 -- signed using one of the keys -- 2115 KeyToUse:Keys, 2116 -- with key usage being one of -- 2117 KeyUsage:KeyUsages 2118 }) 2119 } 2120 2121 2122 2123 2124 2125 2126 2127Yu Expires: Aug 2004 [Page 38] 2128 2129Internet-Draft yu-krb-extensions-00 09 Feb 2004 2130 2131 -- a Checksum that must contain the checksum of a particular type 2132 ChecksumOf { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::= 2133 Checksum { Keys, KeyUsages } 2134 (WITH COMPONENTS { 2135 ..., 2136 checksum (CONSTRAINED BY { 2137 -- must be checksum of -- 2138 OCTET STRING (CONTAINING Type) 2139 }) 2140 }) 2141 2142 2143 -- parameterized type for wrapping authenticated plaintext 2144 Signed { InnerType, KeyToUse:Keys, KeyUsage:KeyUsages } ::= 2145 SEQUENCE { 2146 cksum [0] ChecksumOf 2147 { InnerType, Keys, KeyUsages } OPTIONAL, 2148 inner [1] InnerType, 2149 ... 2150 } 2151 2152 2153 -- 2154 -- *** Tickets 2155 -- 2156 2157 2158 Ticket ::= CHOICE { 2159 rfc1510 [APPLICATION 1] Ticket1510, 2160 ext [APPLICATION 4] Signed { 2161 TicketExt, { key-server }, { ku-Ticket-cksum } 2162 } 2163 } 2164 2165 2166 -- takes a parameter specifying which type gets encrypted 2167 TicketCommon { EncPart } ::= SEQUENCE { 2168 tkt-vno [0] INTEGER (5), 2169 realm [1] Realm, 2170 sname [2] PrincipalName, 2171 enc-part [3] EncryptedData { 2172 EncPart, { key-server }, { ku-Ticket } 2173 }, 2174 extensions [4] TicketExtensions OPTIONAL, 2175 ... 2176 } 2177 2178 2179 2180 2181 2182 2183Yu Expires: Aug 2004 [Page 39] 2184 2185Internet-Draft yu-krb-extensions-00 09 Feb 2004 2186 2187 Ticket1510 ::= SEQUENCE { 2188 -- "COMPONENTS OF" drops the extension marker from 2189 -- TicketCommon 2190 COMPONENTS OF TicketCommon { EncTicketPart1510 } 2191 } (WITH COMPONENTS { 2192 ..., 2193 -- explicitly force IA5 in strings 2194 realm (WITH COMPONENTS { ia5 PRESENT }), 2195 sname (WITH COMPONENTS { 2196 ..., 2197 name-string (WITH COMPONENT 2198 (WITH COMPONENTS { ia5 PRESENT })) 2199 }), 2200 extensions ABSENT 2201 }) 2202 2203 2204 -- APPLICATION tag goes inside Signed{} as well as outside, 2205 -- to prevent possible substitution attacks. 2206 TicketExt ::= [APPLICATION 4] TicketCommon 2207 (WITH COMPONENTS { 2208 ..., 2209 -- explicitly force UTF-8 in strings 2210 realm (WITH COMPONENTS { ia5 ABSENT }), 2211 sname (WITH COMPONENTS { 2212 ..., 2213 name-string (WITH COMPONENT 2214 (WITH COMPONENTS { ia5 ABSENT })) 2215 }) 2216 }) 2217 2218 2219 -- Encrypted part of ticket 2220 EncTicketPart ::= CHOICE { 2221 rfc1510 [APPLICATION 3] EncTicketPart1510, 2222 ext [APPLICATION 5] EncTicketPartExt 2223 } 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239Yu Expires: Aug 2004 [Page 40] 2240 2241Internet-Draft yu-krb-extensions-00 09 Feb 2004 2242 2243 EncTicketPartCommon ::= SEQUENCE { 2244 flags [0] TicketFlags, 2245 key [1] EncryptionKey, 2246 crealm [2] Realm, 2247 cname [3] PrincipalName, 2248 transited [4] TransitedEncoding, 2249 authtime [5] KerberosTime, 2250 starttime [6] KerberosTime OPTIONAL, 2251 endtime [7] KerberosTime, 2252 renew-till [8] KerberosTime OPTIONAL, 2253 caddr [9] HostAddresses OPTIONAL, 2254 authorization-data [10] AuthorizationData OPTIONAL, 2255 ... 2256 } 2257 2258 2259 EncTicketPart1510 ::= SEQUENCE { 2260 -- effectively drops the extension marker 2261 COMPONENTS OF EncTicketPartCommon 2262 } (WITH COMPONENTS { 2263 ..., 2264 -- explicitly force IA5 in strings 2265 crealm (WITH COMPONENTS { ia5 PRESENT }), 2266 cname (WITH COMPONENTS { 2267 ..., 2268 name-string (WITH COMPONENT 2269 (WITH COMPONENTS { ia5 PRESENT })) 2270 }) 2271 }) 2272 2273 2274 EncTicketPartExt ::= EncTicketPartCommon 2275 (WITH COMPONENTS { 2276 ..., 2277 -- explicitly force UTF-8 in strings 2278 crealm (WITH COMPONENTS { ia5 ABSENT }), 2279 cname (WITH COMPONENTS { 2280 ..., 2281 name-string (WITH COMPONENT 2282 (WITH COMPONENTS { ia5 ABSENT })) 2283 }), 2284 -- explicitly constrain caddr to be non-empty if present 2285 caddr (SIZE (1..MAX)), 2286 -- explicitly constrain authorization-data to be non-empty 2287 -- if present 2288 authorization-data (SIZE (1..MAX)) 2289 }) 2290 2291 2292 2293 2294 2295Yu Expires: Aug 2004 [Page 41] 2296 2297Internet-Draft yu-krb-extensions-00 09 Feb 2004 2298 2299 -- 2300 -- *** Authorization Data 2301 -- 2302 2303 2304 ADType ::= Int32 2305 2306 AUTHDATA ::= TYPEDHOLE { ADType } 2307 2308 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 2309 -- should not be a zero-length SEQUENCE OF. 2310 -- 2311 -- The extensible messages explicitly constrain this to be non-empty. 2312 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2313 ad-type [0] AUTHDATA.&id-int ({Authdata-Set}), 2314 ad-data [1] OCTET STRING (AUTHDATA.&Type) 2315 ({Authdata-Set}{@ad-type}) 2316 } 2317 2318 2319 -- Mandatory AuthorizationData 2320 Authdata-Set AUTHDATA ::= { 2321 ad-if-relevant | 2322 ad-kdcissued | 2323 ad-and-or | 2324 ad-mandatory-for-kdc , 2325 ... 2326 } 2327 2328 2329 ad-if-relevant AUTHDATA ::= { 2330 SYNTAX OctetstringHole { AuthorizationData } 2331 IDENTIFIED BY 1 2332 DESCRIPTION 2333 "Encapsulates another AuthorizationData. 2334 Intended for application servers; receiving application servers 2335 MAY ignore." 2336 } 2337 2338 2339 ad-kdcissued AUTHDATA ::= { 2340 SYNTAX OctetstringHole { AD-KDCIssued } 2341 IDENTIFIED BY 4 2342 DESCRIPTION "KDC-issued privilege attributes" 2343 } 2344 2345 2346 2347 2348 2349 2350 2351Yu Expires: Aug 2004 [Page 42] 2352 2353Internet-Draft yu-krb-extensions-00 09 Feb 2004 2354 2355 AD-KDCIssued ::= SEQUENCE { 2356 ad-checksum [0] ChecksumOf { 2357 AuthorizationData, { key-session }, 2358 { ku-ad-KDCIssued-cksum }}, 2359 i-realm [1] Realm OPTIONAL, 2360 i-sname [2] PrincipalName OPTIONAL, 2361 elements [3] AuthorizationData 2362 } 2363 2364 2365 AD-AND-OR ::= SEQUENCE { 2366 condition-count [0] INTEGER, 2367 elements [1] AuthorizationData 2368 } 2369 2370 2371 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2372 2373 2374 ad-and-or AUTHDATA ::= { 2375 SYNTAX OctetstringHole { AD-AND-OR } 2376 IDENTIFIED BY 5 2377 DESCRIPTION "And/Or" 2378 } 2379 2380 AD-AND-OR ::= SEQUENCE { 2381 condition-count [0] INTEGER, 2382 elements [1] AuthorizationData 2383 } 2384 2385 2386 ad-mandatory-for-kdc AUTHDATA ::= { 2387 SYNTAX OctetstringHole { AuthorizationData } 2388 IDENTIFIED BY 8 2389 DESCRIPTION "KDCs MUST interpret any AuthorizationData 2390 wrapped in this." 2391 } 2392 2393 2394 TrType ::= Int32 -- must be registered 2395 2396 -- encoded Transited field 2397 TransitedEncoding ::= SEQUENCE { 2398 tr-type [0] TrType, 2399 contents [1] OCTET STRING 2400 } 2401 2402 2403 2404 2405 2406 2407Yu Expires: Aug 2004 [Page 43] 2408 2409Internet-Draft yu-krb-extensions-00 09 Feb 2004 2410 2411 TEType ::= Int32 2412 2413 TICKETEXTENSION ::= TYPEDHOLE { TEType } 2414 2415 -- ticket extensions: for TicketExt only 2416 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 2417 te-type [0] TICKETEXTENSION.&id 2418 ({TicketExtension-Set}), 2419 te-data [1] OCTET STRING (TICKETEXTENSION.&Type) 2420 ({TicketExtension-Set}{@te-type}) 2421 } 2422 2423 -- no mandatory ticket extensions currently 2424 TicketExtensionSet TICKETEXTENSION ::= { ... } 2425 2426 2427 TicketFlags ::= KerberosFlags { TicketFlagsBits } 2428 2429 TicketFlagsBits ::= BIT STRING { 2430 reserved (0), 2431 forwardable (1), 2432 forwarded (2), 2433 proxiable (3), 2434 proxy (4), 2435 may-postdate (5), 2436 postdated (6), 2437 invalid (7), 2438 renewable (8), 2439 initial (9), 2440 pre-authent (10), 2441 hw-authent (11), 2442 transited-policy-checked (12), 2443 ok-as-delegate (13), 2444 anonymous (14), 2445 cksummed-ticket (15) 2446 } 2447 2448 2449 -- 2450 -- *** KDC protocol 2451 -- 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463Yu Expires: Aug 2004 [Page 44] 2464 2465Internet-Draft yu-krb-extensions-00 09 Feb 2004 2466 2467 AS-REQ ::= CHOICE { 2468 rfc1510 [APPLICATION 10] KDC-REQ-1510 2469 (WITH COMPONENTS { 2470 ..., 2471 msg-type (10), 2472 -- AS-REQ must include client name 2473 req-body (WITH COMPONENTS { ..., cname PRESENT }) 2474 }), 2475 ext [APPLICATION 6] Signed { 2476 -- APPLICATION tag goes inside Signed{} as well as outside, 2477 -- to prevent possible substitution attacks. 2478 [APPLICATION 6] KDC-REQ-EXT, 2479 -- not sure this is correct key to use; do we even want 2480 -- to sign AS-REQ? 2481 { key-client }, 2482 { ku-ASReq-cksum } 2483 } 2484 (WITH COMPONENTS { 2485 ..., 2486 msg-type (6), 2487 -- AS-REQ must include client name 2488 req-body (WITH COMPONENTS { ..., cname PRESENT }) 2489 }) 2490 } 2491 2492 2493 TGS-REQ ::= CHOICE { 2494 rfc1510 [APPLICATION 12] KDC-REQ-1510 2495 (WITH COMPONENTS { 2496 ..., 2497 msg-type (12), 2498 -- client name optional in TGS-REQ 2499 req-body (WITH COMPONENTS { ..., cname ABSENT }) 2500 }), 2501 ext [APPLICATION 8] Signed { 2502 -- APPLICATION tag goes inside Signed{} as well as outside, 2503 -- to prevent possible substitution attacks. 2504 [APPLICATION 8] KDC-REQ-EXT, 2505 { key-session }, { ku-TGSReq-cksum } 2506 } 2507 (WITH COMPONENTS { 2508 ..., 2509 msg-type (8), 2510 -- client name optional in TGS-REQ 2511 req-body (WITH COMPONENTS { ..., cname ABSENT }) 2512 }) 2513 } 2514 2515 2516 2517 2518 2519Yu Expires: Aug 2004 [Page 45] 2520 2521Internet-Draft yu-krb-extensions-00 09 Feb 2004 2522 2523 KDC-REQ-COMMON ::= SEQUENCE { 2524 -- NOTE: first tag is [1], not [0] 2525 pvno [1] INTEGER (5), 2526 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 -- 2527 | 12 -- TGS-REQ.rfc1510 -- 2528 | 6 -- AS-REQ.ext -- 2529 | 8 -- TGS-REQ.ext -- ), 2530 padata [3] SEQUENCE OF PA-DATA OPTIONAL 2531 -- NOTE: not empty 2532 } 2533 2534 2535 KDC-REQ-1510 ::= SEQUENCE { 2536 COMPONENTS OF KDC-REQ-COMMON, 2537 req-body [4] KDC-REQ-BODY-1510 2538 } (WITH COMPONENTS { ..., msg-type (10 | 12) }) 2539 2540 2541 -- APPLICATION tag goes inside Signed{} as well as outside, 2542 -- to prevent possible substitution attacks. 2543 KDC-REQ-EXT ::= SEQUENCE { 2544 COMPONENTS OF KDC-REQ-COMMON, 2545 req-body [4] KDC-REQ-BODY-EXT, 2546 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF LangTag OPTIONAL, 2547 ... 2548 } (WITH COMPONENTS { 2549 ..., 2550 msg-type (6 | 8), 2551 padata (SIZE (1..MAX)) 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: Aug 2004 [Page 46] 2576 2577Internet-Draft yu-krb-extensions-00 09 Feb 2004 2578 2579 KDC-REQ-BODY-COMMON ::= SEQUENCE { 2580 kdc-options [0] KDCOptions, 2581 cname [1] PrincipalName OPTIONAL 2582 -- Used only in AS-REQ --, 2583 2584 realm [2] Realm 2585 -- Server's realm; also client's in AS-REQ --, 2586 2587 sname [3] PrincipalName OPTIONAL, 2588 from [4] KerberosTime OPTIONAL, 2589 till [5] KerberosTime OPTIONAL 2590 -- was required in rfc1510; 2591 -- still required for compat versions 2592 -- of messages --, 2593 2594 rtime [6] KerberosTime OPTIONAL, 2595 nonce [7] Nonce, 2596 etype [8] SEQUENCE OF EType 2597 -- in preference order --, 2598 2599 addresses [9] HostAddresses OPTIONAL, 2600 enc-authorization-data [10] EncryptedData { 2601 AuthorizationData, { key-session | key-subsession }, 2602 { ku-TGSReqAuthData-subkey | 2603 ku-TGSReqAuthData-sesskey } 2604 } OPTIONAL, 2605 2606 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2607 -- NOTE: not empty --, 2608 ... 2609 } 2610 2611 2612 KDC-REQ-BODY-1510 ::= SEQUENCE { 2613 -- effectively drops the extension marker 2614 COMPONENTS OF KDC-REQ-BODY-COMMON 2615 } (WITH COMPONENTS { 2616 ..., 2617 cname (WITH COMPONENTS { 2618 ..., 2619 name-string (WITH COMPONENT 2620 (WITH COMPONENTS { ia5 PRESENT })) 2621 }), 2622 realm (WITH COMPONENTS { ia5 PRESENT }), 2623 sname (WITH COMPONENTS { 2624 ..., 2625 name-string (WITH COMPONENT 2626 (WITH COMPONENTS { ia5 PRESENT })) 2627 }), 2628 till PRESENT 2629 }) 2630 2631Yu Expires: Aug 2004 [Page 47] 2632 2633Internet-Draft yu-krb-extensions-00 09 Feb 2004 2634 2635 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON 2636 (WITH COMPONENTS { 2637 ..., 2638 cname (WITH COMPONENTS { 2639 ..., 2640 name-string (WITH COMPONENT 2641 (WITH COMPONENTS { ia5 ABSENT })) 2642 }), 2643 realm (WITH COMPONENTS { ia5 ABSENT }), 2644 sname (WITH COMPONENTS { 2645 ..., 2646 name-string (WITH COMPONENT 2647 (WITH COMPONENTS { ia5 ABSENT })) 2648 }), 2649 addresses (SIZE (1..MAX)), 2650 enc-authorization-data (EncryptedData { 2651 AuthorizationData (SIZE (1..MAX)), 2652 { key-session | key-subsession }, 2653 { ku-TGSReqAuthData-subkey | 2654 ku-TGSReqAuthData-sesskey } 2655 }), 2656 additional-tickets (SIZE (1..MAX)) 2657 }) 2658 2659 2660 KDCOptions ::= KerberosFlags { KDCOptionsBits } 2661 KDCOptionsBits ::= BIT STRING { 2662 reserved (0), 2663 forwardable (1), 2664 forwarded (2), 2665 proxiable (3), 2666 proxy (4), 2667 allow-postdate (5), 2668 postdated (6), 2669 unused7 (7), 2670 renewable (8), 2671 unused9 (9), 2672 unused10 (10), 2673 unused11 (11), 2674 unused12 (12), 2675 unused13 (13), 2676 requestanonymous (14), 2677 canonicalize (15), 2678 disable-transited-check (26), 2679 renewable-ok (27), 2680 enc-tkt-in-skey (28), 2681 renew (30), 2682 validate (31) 2683 -- XXX need "need ticket1" flag? 2684 } 2685 2686 2687Yu Expires: Aug 2004 [Page 48] 2688 2689Internet-Draft yu-krb-extensions-00 09 Feb 2004 2690 2691 AS-REP ::= CHOICE { 2692 rfc1510 [APPLICATION 11] KDC-REP-1510 { EncASRepPart } 2693 (WITH COMPONENTS { ..., msg-type (11) }), 2694 ext [APPLICATION 7] Signed { 2695 [APPLICATION 7] KDC-REP-EXT { EncASRepPart }, 2696 { key-reply }, { ku-ASRep-cksum } 2697 } (WITH COMPONENTS { ..., msg-type (7) }) 2698 } 2699 2700 2701 TGS-REP ::= CHOICE { 2702 rfc1510 [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart } 2703 (WITH COMPONENTS { ..., msg-type (13) }), 2704 ext [APPLICATION 9] Signed { 2705 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPart }, 2706 { key-reply }, { ku-TGSRep-cksum } 2707 } (WITH COMPONENTS { ..., msg-type (9) }) 2708 } 2709 2710 2711 KDC-REP-COMMON { EncPart } ::= SEQUENCE { 2712 pvno [0] INTEGER (5), 2713 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 2714 13 -- TGS.rfc1510 -- | 2715 7 -- AS-REP.ext -- | 2716 9 -- TGS-REP.ext -- ), 2717 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 2718 crealm [3] Realm, 2719 cname [4] PrincipalName, 2720 ticket [5] Ticket, 2721 enc-part [6] EncryptedData { 2722 EncPart, 2723 { key-reply }, 2724 -- maybe reach into EncryptedData in AS-REP/TGS-REP definitions 2725 -- to apply constraints on key usages? 2726 { ku-EncASRepPart -- if AS-REP -- | 2727 ku-EncTGSRepPart-subkey -- if TGS-REP and using -- 2728 -- Authenticator session key -- | 2729 ku-EncTGSRepPart-sesskey -- if TGS-REP and using -- 2730 -- subsession key -- } 2731 }, 2732 -- In extensible version, KDC signs original request 2733 -- to avoid replay attacks agaginst client. 2734 req-cksum [7] ChecksumOf { CHOICE { 2735 as-req AS-REQ, 2736 tgs-req TGS-REQ 2737 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 2738 lang-tag [8] LangTag OPTIONAL, 2739 ... 2740 } 2741 2742 2743Yu Expires: Aug 2004 [Page 49] 2744 2745Internet-Draft yu-krb-extensions-00 09 Feb 2004 2746 2747 KDC-REP-1510 { EncPart } ::= SEQUENCE { 2748 -- effectively drops the extension marker 2749 COMPONENTS OF KDC-REP-COMMON { EncPart } 2750 } (WITH COMPONENTS { 2751 ..., 2752 msg-type (11 | 13), 2753 crealm (WITH COMPONENTS { ia5 PRESENT}), 2754 cname (WITH COMPONENTS { 2755 ..., 2756 name-string (WITH COMPONENT 2757 (WITH COMPONENTS { ia5 PRESENT })) 2758 }), 2759 req-cksum ABSENT, 2760 lang-tag ABSENT 2761 }) 2762 2763 2764 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart } 2765 (WITH COMPONENTS { 2766 ..., 2767 msg-type (7 | 9), 2768 crealm (WITH COMPONENTS { ia5 ABSENT }), 2769 cname (WITH COMPONENTS { 2770 ..., 2771 name-string (WITH COMPONENT 2772 (WITH COMPONENTS { ia5 ABSENT })) 2773 }) 2774 }) 2775 2776 2777 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 2778 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 2779 2780 EncKDCRepPart ::= SEQUENCE { 2781 key [0] EncryptionKey, 2782 last-req [1] LastReq, 2783 nonce [2] Nonce, 2784 key-expiration [3] KerberosTime OPTIONAL, 2785 flags [4] TicketFlags, 2786 authtime [5] KerberosTime, 2787 starttime [6] KerberosTime OPTIONAL, 2788 endtime [7] KerberosTime, 2789 renew-till [8] KerberosTime OPTIONAL, 2790 srealm [9] Realm, 2791 sname [10] PrincipalName, 2792 caddr [11] HostAddresses OPTIONAL, 2793 ... -- ASN.1 extensions must be excluded 2794 -- when sending to rfc1510 implementation 2795 } 2796 2797 2798 2799Yu Expires: Aug 2004 [Page 50] 2800 2801Internet-Draft yu-krb-extensions-00 09 Feb 2004 2802 2803 -- convert to use object class? 2804 LRType ::= Int32 2805 LastReq ::= SEQUENCE OF SEQUENCE { 2806 lr-type [0] LRType, 2807 lr-value [1] KerberosTime 2808 } 2809 2810 2811 -- 2812 -- *** preauth 2813 -- 2814 2815 2816 PaDataType ::= Int32 2817 2818 -- TYPEDHOLE class that uses PaDataType as its unique ID type. 2819 PADATA-OBJ ::= TYPEDHOLE { PaDataType } 2820 2821 PA-DATA ::= SEQUENCE { 2822 -- NOTE: first tag is [1], not [0] 2823 padata-type [1] CHOICE { 2824 -- example of possible use of RELATIVE-OIDs 2825 int PADATA-OBJ.&id-int ({PaDataSet}), 2826 oid PADATA-OBJ.&id-oid ({PaDataSet}{@int}) 2827 }, 2828 padata-value [2] OCTET STRING (PADATA-OBJ.&Type) 2829 ({PaDataSet}{@padata-type.int}) 2830 } 2831 2832 2833 PaDataSet PADATA-OBJ ::= { 2834 pa-tgs-req | 2835 pa-enc-timestamp | 2836 pa-etype-info | 2837 pa-etype-info2 | 2838 pa-pw-salt | 2839 pa-as-req , 2840 ... 2841 } 2842 2843 2844 pa-tgs-req PADATA-OBJ ::= { 2845 SYNTAX OctetstringHole { AP-REQ } 2846 IDENTIFIED BY 1 2847 DESCRIPTION 2848 "AP-REQ authenticating a TGS-REQ" 2849 } 2850 2851 2852 2853 2854 2855Yu Expires: Aug 2004 [Page 51] 2856 2857Internet-Draft yu-krb-extensions-00 09 Feb 2004 2858 2859 pa-enc-timestamp PADATA-OBJ ::= { 2860 SYNTAX OctetstringHole { PA-ENC-TIMESTAMP } 2861 IDENTIFIED BY 2 2862 DESCRIPTION 2863 "Encrypted timestamp preauth; 2864 Encryption key used is client's long-term key." 2865 } 2866 2867 PA-ENC-TIMESTAMP ::= EncryptedData { 2868 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } 2869 } 2870 2871 PA-ENC-TS-ENC ::= SEQUENCE { 2872 patimestamp [0] KerberosTime -- client's time --, 2873 pausec [1] Microseconds OPTIONAL 2874 } 2875 2876 2877 pa-etype-info PADATA-OBJ ::= { 2878 SYNTAX OctetstringHole { ETYPE-INFO } 2879 IDENTIFIED BY 11 2880 DESCRIPTION 2881 "Hints returned in AS-REP or KRB-ERROR to help client 2882 choose a password-derived key, either for preauthentication or 2883 for decryption of the reply." 2884 } 2885 2886 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 2887 2888 ETYPE-INFO-ENTRY ::= SEQUENCE { 2889 etype [0] EType, 2890 salt [1] OCTET STRING OPTIONAL 2891 } 2892 2893 2894 pa-etype-info2 PADATA-OBJ ::= { 2895 SYNTAX OctetstringHole { ETYPE-INFO2 } 2896 IDENTIFIED BY 19 2897 DESCRIPTION 2898 "Similar to etype-info, but with parameters provided for 2899 the string-to-key function." 2900 } 2901 2902 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) 2903 OF ETYPE-INFO-ENTRY 2904 2905 ETYPE-INFO2-ENTRY ::= SEQUENCE { 2906 etype [0] EType, 2907 salt [1] KerberosString OPTIONAL, 2908 s2kparams [2] OCTET STRING OPTIONAL 2909 } 2910 2911Yu Expires: Aug 2004 [Page 52] 2912 2913Internet-Draft yu-krb-extensions-00 09 Feb 2004 2914 2915 pa-pw-salt PADATA-OBJ ::= { 2916 SYNTAX OCTET STRING (CONSTRAINED BY { 2917 -- Must consist of the salt string to be used by the 2918 -- client, in an unspecified character encoding. -- }) 2919 IDENTIFIED BY 3 2920 DESCRIPTION 2921 "Obsolescent. Salt for client's long-term key. 2922 Its character encoding is unspecified." 2923 } 2924 2925 2926 pa-as-req PADATA-OBJ ::= { 2927 SYNTAX OctetstringHole { AS-REQ 2928 (WITH COMPONENTS { 2929 ext }) } 2930 IDENTIFIED BY 42 -- provisional 2931 DESCRIPTION 2932 "An extensible AS-REQ may be sent as a padata in a 2933 non-extensible AS-REQ to allow for backwards compatibility." 2934 } 2935 2936 2937 -- 2938 -- *** Application session setup 2939 -- 2940 2941 2942 AP-REQ ::= CHOICE { 2943 rfc1510 [APPLICATION 14] AP-REQ-1510, 2944 ext [APPLICATION 18] Signed { 2945 AP-REQ-EXT, { key-session }, { ku-APReq-cksum } 2946 } 2947 } 2948 2949 2950 AP-REQ-COMMON ::= SEQUENCE { 2951 pvno [0] INTEGER (5), 2952 msg-type [1] INTEGER (14 | 18), 2953 ap-options [2] APOptions, 2954 ticket [3] Ticket, 2955 authenticator [4] EncryptedData { 2956 Authenticator, 2957 { key-session }, 2958 { ku-APReq-authenticator | 2959 ku-pa-TGSReq-authenticator } 2960 }, 2961 extensions [5] ApReqExtensions OPTIONAL, 2962 ... 2963 } 2964 2965 2966 2967Yu Expires: Aug 2004 [Page 53] 2968 2969Internet-Draft yu-krb-extensions-00 09 Feb 2004 2970 2971 AP-REQ-1510 ::= SEQUENCE { 2972 -- effectively drops the extension marker 2973 COMPONENTS OF AP-REQ-COMMON 2974 } (WITH COMPONENTS { 2975 ..., 2976 msg-type (14), 2977 extensions ABSENT 2978 }) 2979 2980 2981 AP-REQ-EXT ::= AP-REQ-COMMON 2982 (WITH COMPONENTS { 2983 ..., 2984 msg-type (18), 2985 -- The following constraints on Authenticator assume that 2986 -- we want to restrict the use of AP-REQ-EXT with TicketExt only, 2987 -- since that is the only way we can enforce UTF-8. 2988 authenticator (EncryptedData { 2989 Authenticator (WITH COMPONENTS { 2990 ..., 2991 crealm (WITH COMPONENTS { ia5 ABSENT }), 2992 cname (WITH COMPONENTS { 2993 ..., 2994 name-string (WITH COMPONENT 2995 (WITH COMPONENTS { ia5 ABSENT })) 2996 }), 2997 authorization-data (SIZE (1..MAX)) 2998 }), { key-session }, { ku-APReq-authenticator }}) 2999 }) 3000 3001 3002 ApReqExtType ::= Int32 3003 3004 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 3005 apReqExt-Type [0] ApReqExtType, 3006 apReqExt-Data [1] OCTET STRING 3007 } 3008 3009 3010 APOptions ::= KerberosFlags { APOptionsBits } 3011 3012 APOptionsBits ::= BIT STRING { 3013 reserved (0), 3014 use-session-key (1), 3015 mutual-required (2) 3016 } 3017 3018 3019 3020 3021 3022 3023Yu Expires: Aug 2004 [Page 54] 3024 3025Internet-Draft yu-krb-extensions-00 09 Feb 2004 3026 3027 -- plaintext of authenticator 3028 Authenticator ::= [APPLICATION 2] SEQUENCE { 3029 authenticator-vno [0] INTEGER (5), 3030 crealm [1] Realm, 3031 cname [2] PrincipalName, 3032 cksum [3] Checksum {{ key-session }, 3033 { ku-Authenticator-cksum | 3034 ku-pa-TGSReq-cksum }} OPTIONAL, 3035 cusec [4] Microseconds, 3036 ctime [5] KerberosTime, 3037 subkey [6] EncryptionKey OPTIONAL, 3038 seq-number [7] SeqNum OPTIONAL, 3039 authorization-data [8] AuthorizationData OPTIONAL 3040 } 3041 3042 3043 AP-REP ::= CHOICE { 3044 rfc1510 [APPLICATION 15] AP-REP-1510, 3045 ext [APPLICATION 19] Signed { 3046 AP-REP-EXT, 3047 { key-session | key-subsession }, { ku-APRep-cksum }} 3048 } 3049 3050 3051 AP-REP-COMMON { EncPart } ::= SEQUENCE { 3052 pvno [0] INTEGER (5), 3053 msg-type [1] INTEGER (15 | 19), 3054 enc-part [2] EncryptedData { 3055 EncPart, 3056 { key-session | key-subsession }, { ku-EncAPRepPart }}, 3057 extensions [3] ApRepExtensions OPTIONAL, 3058 ... 3059 } 3060 3061 3062 AP-REP-1510 ::= SEQUENCE { 3063 -- effectively drops the extension marker 3064 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 } 3065 } (WITH COMPONENTS { 3066 ..., 3067 msg-type (15), 3068 extensions ABSENT 3069 }) 3070 3071 3072 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON { 3073 EncAPRepPartExt } 3074 (WITH COMPONENTS { ..., msg-type (19) }) 3075 3076 3077 3078 3079Yu Expires: Aug 2004 [Page 55] 3080 3081Internet-Draft yu-krb-extensions-00 09 Feb 2004 3082 3083 ApRepExtType ::= Int32 3084 3085 -- convert to use object class? 3086 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 3087 apRepExt-Type [0] ApRepExtType, 3088 apRepExt-Data [1] OCTET STRING 3089 } 3090 3091 3092 EncAPRepPart ::= CHOICE { 3093 rfc1510 [APPLICATION 27] EncAPRepPart1510, 3094 ext [APPLICATION 31] EncAPRepPartExt 3095 } 3096 3097 3098 EncAPRepPart1510 ::= SEQUENCE { 3099 COMPONENTS OF ENCAPRepPartCom 3100 } (WITH COMPONENTS { 3101 ..., 3102 authorization-data ABSENT 3103 }) 3104 3105 3106 EncAPRepPartExt ::= EncAPRepPartCom 3107 3108 3109 EncAPRepPartCom ::= SEQUENCE { 3110 ctime [0] KerberosTime, 3111 cusec [1] Microseconds, 3112 subkey [2] EncryptionKey OPTIONAL, 3113 seq-number [3] SeqNum OPTIONAL, 3114 authorization-data [4] AuthorizationData OPTIONAL, 3115 ... 3116 } 3117 3118 3119 -- 3120 -- *** Application messages 3121 -- 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135Yu Expires: Aug 2004 [Page 56] 3136 3137Internet-Draft yu-krb-extensions-00 09 Feb 2004 3138 3139 -- Do we chew up another tag for KRB-SAFE-EXT? That would allow us to 3140 -- make safe-body optional, allowing for a GSS-MIC sort of message. 3141 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3142 pvno [0] INTEGER (5), 3143 msg-type [1] INTEGER (20), 3144 safe-body [2] KRB-SAFE-BODY, 3145 cksum [3] ChecksumOf { 3146 KRB-SAFE-BODY, 3147 { key-session | key-subsession }, { ku-KrbSafe-cksum }}, 3148 ... -- ASN.1 extensions must be excluded 3149 -- when sending to rfc1510 implementations 3150 } 3151 3152 3153 KRB-SAFE-BODY ::= SEQUENCE { 3154 user-data [0] OCTET STRING, 3155 timestamp [1] KerberosTime OPTIONAL, 3156 usec [2] Microseconds OPTIONAL, 3157 seq-number [3] SeqNum OPTIONAL, 3158 s-address [4] HostAddress, 3159 r-address [5] HostAddress OPTIONAL, 3160 ... -- ASN.1 extensions must be excluded 3161 -- when sending to rfc1510 implementations 3162 } 3163 3164 3165 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3166 pvno [0] INTEGER (5), 3167 msg-type [1] INTEGER (21), 3168 enc-part [3] EncryptedData { 3169 EncKrbPrivPart, 3170 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 3171 ... 3172 } 3173 3174 3175 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 3176 user-data [0] OCTET STRING, 3177 timestamp [1] KerberosTime OPTIONAL, 3178 usec [2] Microseconds OPTIONAL, 3179 seq-number [3] SeqNum OPTIONAL, 3180 s-address [4] HostAddress -- sender's addr --, 3181 r-address [5] HostAddress OPTIONAL -- recip's addr --, 3182 ... -- ASN.1 extensions must be excluded 3183 -- when sending to rfc1510 implementations 3184 } 3185 3186 3187 3188 3189 3190 3191Yu Expires: Aug 2004 [Page 57] 3192 3193Internet-Draft yu-krb-extensions-00 09 Feb 2004 3194 3195 KRB-CRED ::= CHOICE { 3196 rfc1510 [APPLICATION 22] KRB-CRED-1510, 3197 ext [APPLICATION 24] Signed { 3198 KRB-CRED-EXT, 3199 { key-session | key-subsession }, { ku-KrbCred-cksum }} 3200 } 3201 3202 3203 KRB-CRED-COMMON ::= SEQUENCE { 3204 pvno [0] INTEGER (5), 3205 msg-type [1] INTEGER (22 | 24), 3206 tickets [2] SEQUENCE OF Ticket, 3207 enc-part [3] EncryptedData { 3208 EncKrbCredPart, 3209 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 3210 ... 3211 } 3212 3213 3214 KRB-CRED-1510 ::= SEQUENCE { 3215 -- effectively drops the extension marker 3216 COMPONENTS OF KRB-CRED-COMMON 3217 } (WITH COMPONENTS { ..., msg-type (22) }) 3218 3219 3220 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON 3221 (WITH COMPONENTS { ..., msg-type (24) }) 3222 3223 3224 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3225 ticket-info [0] SEQUENCE OF KrbCredInfo, 3226 nonce [1] Nonce OPTIONAL, 3227 timestamp [2] KerberosTime OPTIONAL, 3228 usec [3] Microseconds OPTIONAL, 3229 s-address [4] HostAddress OPTIONAL, 3230 r-address [5] HostAddress OPTIONAL 3231 } 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247Yu Expires: Aug 2004 [Page 58] 3248 3249Internet-Draft yu-krb-extensions-00 09 Feb 2004 3250 3251 KrbCredInfo ::= SEQUENCE { 3252 key [0] EncryptionKey, 3253 prealm [1] Realm OPTIONAL, 3254 pname [2] PrincipalName OPTIONAL, 3255 flags [3] TicketFlags OPTIONAL, 3256 authtime [4] KerberosTime OPTIONAL, 3257 starttime [5] KerberosTime OPTIONAL, 3258 endtime [6] KerberosTime OPTIONAL, 3259 renew-till [7] KerberosTime OPTIONAL, 3260 srealm [8] Realm OPTIONAL, 3261 sname [9] PrincipalName OPTIONAL, 3262 caddr [10] HostAddresses OPTIONAL 3263 } 3264 3265 3266 TGT-REQ ::= [APPLICATION 16] SEQUENCE { 3267 pvno [0] INTEGER (5), 3268 msg-type [1] INTEGER (16), 3269 sname [2] PrincipalName OPTIONAL, 3270 srealm [3] Realm OPTIONAL, 3271 ... 3272 } 3273 3274 3275 -- 3276 -- *** Error messages 3277 -- 3278 3279 3280 ErrCode ::= Int32 3281 3282 KRB-ERROR ::= CHOICE { 3283 rfc1510 [APPLICATION 30] KRB-ERROR-1510, 3284 ext [APPLICATION 23] Signed { 3285 KRB-ERROR-EXT, { ku-KrbError-cksum } } 3286 } 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303Yu Expires: Aug 2004 [Page 59] 3304 3305Internet-Draft yu-krb-extensions-00 09 Feb 2004 3306 3307 KRB-ERROR-COMMON ::= SEQUENCE { 3308 pvno [0] INTEGER (5), 3309 msg-type [1] INTEGER (30 | 23), 3310 ctime [2] KerberosTime OPTIONAL, 3311 cusec [3] Microseconds OPTIONAL, 3312 stime [4] KerberosTime, 3313 susec [5] Microseconds, 3314 error-code [6] ErrCode, 3315 crealm [7] Realm OPTIONAL, 3316 cname [8] PrincipalName OPTIONAL, 3317 realm [9] Realm -- Correct realm --, 3318 sname [10] PrincipalName -- Correct name --, 3319 e-text [11] KerberosString OPTIONAL, 3320 e-data [12] OCTET STRING OPTIONAL, 3321 typed-data [13] TYPED-DATA OPTIONAL, 3322 nonce [14] Nonce OPTIONAL, 3323 lang-tag [15] LangTag OPTIONAL, 3324 ... 3325 } 3326 3327 3328 KRB-ERROR-1510 ::= SEQUENCE { 3329 -- effectively drops the extension marker 3330 COMPONENTS OF KRB-ERROR-COMMON 3331 } (WITH COMPONENTS { 3332 ..., 3333 msg-type (30), 3334 typed-data ABSENT, 3335 nonce ABSENT, 3336 lang-tag ABSENT 3337 }) 3338 3339 3340 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON 3341 (WITH COMPONENTS { ..., msg-type (23) }) 3342 3343 3344 TDType ::= Int32 3345 3346 -- convert to information object class later 3347 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 3348 data-type [0] TDType, 3349 data-value [1] OCTET STRING OPTIONAL 3350 } 3351 3352 3353 END 3354 3355 3356 3357 3358 3359Yu Expires: Aug 2004 [Page 60] 3360 3361Internet-Draft yu-krb-extensions-00 09 Feb 2004 3362 3363B. Kerberos and Character Encodings (Informative) 3364 3365 [adapted from KCLAR 5.2.1] 3366 3367 The original specification of the Kerberos protocol in RFC 1510 uses 3368 GeneralString in numerous places for human-readable string data. 3369 Historical implementations of Kerberos cannot utilize the full power 3370 of GeneralString. This ASN.1 type requires the use of designation 3371 and invocation escape sequences as specified in ISO-2022/ECMA-35 3372 [ISO-2022/ECMA-35] to switch character sets, and the default 3373 character set that is designated as G0 is the ISO-646/ECMA-6 3374 [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S. 3375 ASCII), which mostly works. 3376 3377 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) 3378 and two Control-function code elements (C0..C1). DER previously 3379 prohibited the designation of character sets as any but the G0 and C0 3380 sets. This had the side effect of prohibiting the use of ISO-8859 3381 (ISO Latin) [ISO-8859] character-sets or any other character-sets 3382 that utilize a 96-character set, since it is prohibited by 3383 ISO-2022/ECMA-35 to designate them as the G0 code element. Recent 3384 revisions to the ASN.1 standards resolve this contradiction. 3385 3386 In practice, many implementations treat RFC 1510 GeneralStrings as if 3387 they were 8-bit strings of whichever character set the implementation 3388 defaults to, without regard for correct usage of character-set 3389 designation escape sequences. The default character set is often 3390 determined by the current user's operating system dependent locale. 3391 At least one major implementation places unescaped UTF-8 encoded 3392 Unicode characters in the GeneralString. This failure to conform to 3393 the GeneralString specifications results in interoperability issues 3394 when conflicting character encodings are utilized by the Kerberos 3395 clients, services, and KDC. 3396 3397 This unfortunate situation is the result of improper documentation of 3398 the restrictions of the ASN.1 GeneralString type in prior Kerberos 3399 specifications. 3400 3401 [the following should probably be rewritten and moved into the 3402 principal name section] 3403 3404 For compatibility, implementations MAY choose to accept GeneralString 3405 values that contain characters other than those permitted by 3406 IA5String, but they should be aware that character set designation 3407 codes will likely be absent, and that the encoding should probably be 3408 treated as locale-specific in almost every way. Implementations MAY 3409 also choose to emit GeneralString values that are beyond those 3410 permitted by IA5String, but should be aware that doing so is 3411 extraordinarily risky from an interoperability perspective. 3412 3413 3414 3415Yu Expires: Aug 2004 [Page 61] 3416 3417Internet-Draft yu-krb-extensions-00 09 Feb 2004 3418 3419 Some existing implementations use GeneralString to encode unescaped 3420 locale-specific characters. This is a violation of the ASN.1 3421 standard. Most of these implementations encode US-ASCII in the left- 3422 hand half, so as long the implementation transmits only US-ASCII, the 3423 ASN.1 standard is not violated in this regard. As soon as such an 3424 implementation encodes unescaped locale-specific characters with the 3425 high bit set, it violates the ASN.1 standard. 3426 3427 Other implementations have been known to use GeneralString to contain 3428 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 3429 is a different encoding, not a 94 or 96 character "G" set as defined 3430 by ISO 2022. It is believed that these implementations do not even 3431 use the ISO 2022 escape sequence to change the character encoding. 3432 Even if implementations were to announce the change of encoding by 3433 using that escape sequence, the ASN.1 standard prohibits the use of 3434 any escape sequences other than those used to designate/invoke "G" or 3435 "C" sets allowed by GeneralString. 3436 3437C. Kerberos History (Informative) 3438 3439 [Adapted from KCLAR "BACKGROUND"] 3440 3441 The Kerberos model is based in part on Needham and Schroeder's 3442 trusted third-party authentication protocol [NS78] and on 3443 modifications suggested by Denning and Sacco [DS81]. The original 3444 design and implementation of Kerberos Versions 1 through 4 was the 3445 work of two former Project Athena staff members, Steve Miller of 3446 Digital Equipment Corporation and Clifford Neuman (now at the 3447 Information Sciences Institute of the University of Southern 3448 California), along with Jerome Saltzer, Technical Director of Project 3449 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 3450 members of Project Athena have also contributed to the work on 3451 Kerberos. 3452 3453 Version 5 of the Kerberos protocol (described in this document) has 3454 evolved from Version 4 based on new requirements and desires for 3455 features not available in Version 4. The design of Version 5 of the 3456 Kerberos protocol was led by Clifford Neuman and John Kohl with much 3457 input from the community. The development of the MIT reference 3458 implementation was led at MIT by John Kohl and Theodore Ts'o, with 3459 help and contributed code from many others. Since RFC1510 was issued, 3460 extensions and revisions to the protocol have been proposed by many 3461 individuals. Some of these proposals are reflected in this document. 3462 Where such changes involved significant effort, the document cites 3463 the contribution of the proposer. 3464 3465 Reference implementations of both version 4 and version 5 of Kerberos 3466 are publicly available and commercial implementations have been 3467 developed and are widely used. Details on the differences between 3468 Kerberos Versions 4 and 5 can be found in [KNT94]. 3469 3470 3471Yu Expires: Aug 2004 [Page 62] 3472 3473Internet-Draft yu-krb-extensions-00 09 Feb 2004 3474 3475Normative References 3476 3477 [KCRYPTO] 3478 3479 [RFC2119] 3480 3481 [X680] 3482 3483 [X681] 3484 3485 [X682] 3486 3487 [X683] 3488 3489 [X690] 3490 3491Informative References 3492 3493 [DS81] 3494 3495 [KCLAR] 3496 3497 [KNT94] 3498 3499 [NS78] 3500 3501 [RFC1510] 3502 3503 [RFC1964] 3504 3505 [ISO8859] 3506 3507Acknowledgments 3508 3509 Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-04. 3510 3511Author's Address 3512 3513 Tom Yu 3514 77 Massachusetts Ave 3515 Cambridge, MA 02139 3516 USA 3517 tlyu@mit.edu 3518 3519Full Copyright Statement 3520 3521 Copyright (C) The Internet Society (2004). All Rights Reserved. 3522 3523 This document and translations of it may be copied and furnished to 3524 others, and derivative works that comment on or otherwise explain it 3525 or assist in its implementation may be prepared, copied, published 3526 3527Yu Expires: Aug 2004 [Page 63] 3528 3529Internet-Draft yu-krb-extensions-00 09 Feb 2004 3530 3531 and distributed, in whole or in part, without restriction of any 3532 kind, provided that the above copyright notice and this paragraph are 3533 included on all such copies and derivative works. However, this 3534 document itself may not be modified in any way, such as by removing 3535 the copyright notice or references to the Internet Society or other 3536 Internet organizations, except as needed for the purpose of 3537 developing Internet standards in which case the procedures for 3538 copyrights defined in the Internet Standards process must be 3539 followed, or as required to translate it into languages other than 3540 English. 3541 3542 The limited permissions granted above are perpetual and will not be 3543 revoked by the Internet Society or its successors or assigns. 3544 3545 This document and the information contained herein is provided on an 3546 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3547 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3548 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3549 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3550 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583Yu Expires: Aug 2004 [Page 64] 3584 3585 3586