idnits 2.17.1 draft-ietf-krb-wg-rfc1510ter-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4897. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC4120, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (05 March 2007) is 6261 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'XXX' is mentioned on line 382, but not defined -- Looks like a reference, but probably isn't: '0' on line 4451 -- Looks like a reference, but probably isn't: '1' on line 4452 == Missing Reference: 'RFC 2253' is mentioned on line 3449, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) -- Looks like a reference, but probably isn't: '2' on line 4427 == Missing Reference: 'APPLICATION 3' is mentioned on line 3715, but not defined -- Looks like a reference, but probably isn't: '3' on line 4428 -- Looks like a reference, but probably isn't: '4' on line 4429 -- Looks like a reference, but probably isn't: '5' on line 4430 -- Looks like a reference, but probably isn't: '6' on line 4431 -- Looks like a reference, but probably isn't: '7' on line 4432 -- Looks like a reference, but probably isn't: '8' on line 4433 -- Looks like a reference, but probably isn't: '9' on line 4434 -- Looks like a reference, but probably isn't: '10' on line 4435 == Missing Reference: 'APPLICATION 5' is mentioned on line 3728, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 3686, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 3695, but not defined -- Looks like a reference, but probably isn't: '11' on line 4436 == Missing Reference: 'APPLICATION 10' is mentioned on line 3829, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 3833, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 3842, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 3845, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 4029, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 4030, but not defined == Missing Reference: 'APPLICATION 32' is mentioned on line 4032, but not defined == Missing Reference: 'APPLICATION 33' is mentioned on line 4033, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 3958, but not defined == Missing Reference: 'APPLICATION 7' is mentioned on line 3960, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 3968, but not defined == Missing Reference: 'APPLICATION 9' is mentioned on line 3972, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 2826, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 4408, but not defined -- Looks like a reference, but probably isn't: '12' on line 4437 == Missing Reference: 'APPLICATION 23' is mentioned on line 4424, but not defined -- Looks like a reference, but probably isn't: '13' on line 4439 -- Looks like a reference, but probably isn't: '14' on line 4440 -- Looks like a reference, but probably isn't: '15' on line 4441 == Missing Reference: 'APPLICATION 2' is mentioned on line 4195, but not defined == Missing Reference: 'APPLICATION 35' is mentioned on line 4209, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 4147, but not defined == Missing Reference: 'APPLICATION 18' is mentioned on line 4161, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 4262, but not defined == Missing Reference: 'APPLICATION 31' is mentioned on line 4269, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 4229, but not defined == Missing Reference: 'APPLICATION 19' is mentioned on line 4237, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 4319, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 4329, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 4345, but not defined == Missing Reference: 'APPLICATION 24' is mentioned on line 4355, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 4367, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 4287, but not defined == Missing Reference: 'APPLICATION 34' is mentioned on line 4298, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 4390, but not defined == Missing Reference: 'X690-1997' is mentioned on line 4641, but not defined == Unused Reference: 'Lar96' is defined on line 4824, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X682' -- Possible downref: Non-RFC (?) normative reference: ref. 'X683' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 5 errors (**), 0 flaws (~~), 43 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Tom Yu 3 draft-ietf-krb-wg-rfc1510ter-04.txt MIT 4 Expires: 06 September 2007 05 March 2007 6 The Kerberos Network Authentication Service (Version 5) 8 Status of This Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The IETF Trust (2007). 35 Abstract 37 This document specifies version 5 of the Kerberos network 38 authentication protocol. It obsoletes RFC 4120, and in addition to 39 providing a detailed description of the protocol, it describes a 40 framework to allow for extensions to be made to the protocol without 41 creating interoperability problems. 43 Table of Contents 45 Status of This Memo .............................................. 1 46 Copyright Notice ................................................. 1 47 Abstract ......................................................... 1 48 Table of Contents ................................................ 2 49 1. Introduction ................................................. 4 50 1.1. Kerberos Protocol Overview ................................. 4 51 1.2. Document Organization ...................................... 5 52 2. Compatibility Considerations ................................. 6 53 2.1. Extensibility .............................................. 6 54 2.2. Compatibility with RFC 1510 ................................ 6 55 2.3. Backwards Compatibility .................................... 6 56 2.4. Sending Extensible Messages ................................ 7 57 2.5. Criticality ................................................ 7 58 2.6. Authenticating Cleartext Portions of Messages .............. 8 59 2.7. Capability Negotiation ..................................... 9 60 2.8. Strings .................................................... 10 61 3. Use of ASN.1 in Kerberos ..................................... 10 62 3.1. Module Header .............................................. 11 63 3.2. Top-Level Type ............................................. 11 64 3.3. Previously Unused ASN.1 Notation (informative) ............. 12 65 3.4. New Types .................................................. 12 66 4. Basic Types .................................................. 13 67 4.1. Constrained Integer Types .................................. 13 68 4.2. KerberosTime ............................................... 14 69 4.3. KerberosString ............................................. 14 70 4.4. Language Tags .............................................. 15 71 4.5. KerberosFlags .............................................. 15 72 4.6. Typed Holes ................................................ 16 73 4.7. HostAddress and HostAddresses .............................. 16 74 5. Principals ................................................... 18 75 5.1. Name Types ................................................. 18 76 5.2. Principal Type Definition .................................. 19 77 5.3. Principal Name Reuse ....................................... 20 78 5.4. Best Common Practice Recommendations for the Processing 79 of Principal Names Consisting of Internationalized 80 Domain Names: .......................................... 20 81 5.5. Realm Names ................................................ 21 82 5.6. Best Common Practice Recommendations for the Processing 83 of Internationalized Domain-Style Realm Names: ......... 21 84 5.7. Printable Representations of Principal Names ............... 22 85 5.8. Ticket-Granting Service Principal .......................... 22 86 6. Types Relating to Encryption ................................. 23 87 6.1. Assigned Numbers for Encryption ............................ 23 88 6.2. Which Key to Use ........................................... 26 89 6.3. EncryptionKey .............................................. 27 90 6.4. EncryptedData .............................................. 27 91 6.5. Checksums .................................................. 28 92 7. Tickets ...................................................... 30 93 7.1. Timestamps ................................................. 31 94 7.2. Ticket Flags ............................................... 32 95 7.3. Transited Realms ........................................... 37 96 7.4. Authorization Data ......................................... 37 97 7.5. Encrypted Part of Ticket ................................... 41 98 7.6. Cleartext Part of Ticket ................................... 41 99 8. Credential Acquisition ....................................... 43 100 8.1. KDC-REQ .................................................... 43 101 8.2. PA-DATA .................................................... 50 102 8.3. KDC-REQ Processing ......................................... 50 103 8.4. KDC-REP .................................................... 56 104 8.5. Reply Validation ........................................... 60 105 8.6. IP Transports .............................................. 60 106 9. Errors ....................................................... 63 107 10. Session Key Exchange ........................................ 65 108 10.1. AP-REQ .................................................... 66 109 10.2. AP-REP .................................................... 67 110 11. Session Key Use ............................................. 69 111 11.1. KRB-SAFE .................................................. 69 112 11.2. KRB-PRIV .................................................. 69 113 11.3. KRB-CRED .................................................. 70 114 12. Security Considerations ..................................... 71 115 12.1. Time Synchronization ...................................... 71 116 12.2. Replays ................................................... 72 117 12.3. Principal Name Reuse ...................................... 72 118 12.4. Password Guessing ......................................... 72 119 12.5. Forward Secrecy ........................................... 72 120 12.6. Authorization ............................................. 72 121 12.7. Login Authentication ...................................... 72 122 13. IANA Considerations ......................................... 72 123 14. Acknowledgments ............................................. 73 124 Appendices ....................................................... 73 125 A. ASN.1 Module (Normative) ..................................... 73 126 B. Kerberos and Character Encodings (Informative) ...............109 127 C. Kerberos History (Informative) ...............................110 128 D. Notational Differences from [RFC4120] ........................111 129 Normative References .............................................111 130 Informative References ...........................................112 131 Author's Address .................................................113 132 Full Copyright Statement .........................................113 133 Intellectual Property ............................................113 135 1. Introduction 137 The Kerberos network authentication protocol is a trusted-third-party 138 protocol utilizing symmetric-key cryptography. It assumes that all 139 communications between parties in the protocol may be arbitrarily 140 tampered with or monitored, and that the security of the overall 141 system depends only on the effectiveness of the cryptographic 142 techniques and the secrecy of the cryptographic keys used. The 143 Kerberos protocol authenticates an application client's identity to 144 an application server, and likewise authenticates the application 145 server's identity to the application client. These assurances are 146 made possible by the client and the server sharing secrets with the 147 trusted third party: the Kerberos server, also known as the Key 148 Distribution Center (KDC). In addition, the protocol establishes an 149 ephemeral shared secret (the session key) between the client and the 150 server, allowing the protection of further communications between 151 them. 153 The Kerberos protocol, as originally specified in [RFC1510] and 154 [RFC4120], provides insufficient means for extending the protocol in 155 a backwards-compatible way. This deficiency has caused problems for 156 interoperability. This document describes a framework which enables 157 backwards-compatible extensions to the Kerberos protocol. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 161 to be interpreted as described in [RFC2119]. 163 1.1. Kerberos Protocol Overview 165 Kerberos comprises three main sub-protocols: credentials acquisition, 166 session key exchange, and session key usage. A client acquires 167 credentials by asking the KDC for a credential for a service; the KDC 168 issues the credential, which contains a ticket and a session key. 169 The ticket, containing the client's identity, timestamps, expiration 170 time, and a session key, is a encrypted in a key known to the 171 application server. The KDC encrypts the credential using a key 172 known to the client, and transmits the credential to the client. 174 There are two means of requesting credentials: the Authentication 175 Service (AS) exchange, and the Ticket-Granting Service (TGS) 176 exchange. In the typical AS exchange, a client uses a password- 177 derived key to decrypt the response. In the TGS exchange, the KDC 178 behaves as an application server; the client authenticates to the TGS 179 by using a Ticket-Granting Ticket (TGT). The client usually obtains 180 the TGT by using the AS exchange. 182 Session key exchange consists of the client transmitting the ticket 183 to the application server, accompanied by an authenticator. The 184 authenticator contains a timestamp and additional data encrypted 185 using the ticket's session key. The application server decrypts the 186 ticket, extracting the session key. The application server then uses 187 the session key to decrypt the authenticator. Upon successful 188 decryption of the authenticator, the application server knows that 189 the data in the authenticator were sent by the client named in the 190 associated ticket. Additionally, since authenticators expire more 191 quickly than tickets, the application server has some assurance that 192 the transaction is not a replay. The application server may send an 193 encrypted acknowledgment to the client, verifying its identity to the 194 client. 196 Once session key exchange has occurred, the client and server may use 197 the established session key to protect further traffic. This 198 protection may consist of protection of integrity only, or of 199 protection of confidentiality and integrity. Additional measures 200 exist for a client to securely forward credentials to a server. 202 The entire scheme depends on loosely synchronized clocks. 203 Synchronization of the clock on the KDC with the application server 204 clock allows the application server to accurately determine whether a 205 credential is expired. Likewise, synchronization of the clock on the 206 client with the application server clock prevents replay attacks 207 utilizing the same credential. Careful design of the application 208 protocol may allow replay prevention without requiring client-server 209 clock synchronization. 211 After establishing a session key, application client and the 212 application server can exchange Kerberos protocol messages that use 213 the session key to protect the integrity or confidentiality of 214 communications between the client and the server. Additionally, the 215 client may forward credentials to the application server. 217 The credentials acquisition protocol takes place over specific, 218 defined transports (UDP and TCP). Application protocols define which 219 transport to use for the session key establishment protocol and for 220 messages using the session key; the application may choose to perform 221 its own encapsulation of the Kerberos messages, for example. 223 1.2. Document Organization 225 The remainder of this document begins by describing the general 226 frameworks for protocol extensibility, including whether to interpret 227 unknown extensions as critical. It then defines the protocol 228 messages and exchanges. 230 The definition of the Kerberos protocol uses Abstract Syntax Notation 231 One (ASN.1) [X680], which specifies notation for describing the 232 abstract content of protocol messages. This document defines a 233 number of base types using ASN.1; these base types subsequently 234 appear in multiple types which define actual protocol messages. 235 Definitions of principal names and of tickets, which are central to 236 the protocol, also appear preceding the protocol message definitions. 238 2. Compatibility Considerations 240 2.1. Extensibility 242 In the past, significant interoperability problems have resulted from 243 conflicting assumptions about how the Kerberos protocol can be 244 extended. As the deployed base of Kerberos grows, the ability to 245 extend the Kerberos protocol becomes more important. In order to 246 ensure that vendors and the IETF can extend the protocol while 247 maintaining backwards compatibility, this document outlines a 248 framework for extending Kerberos. 250 Kerberos provides two general mechanisms for protocol extensibility. 251 Many protocol messages, including some defined in RFC 1510, contain 252 typed holes--sub-messages containing an octet string along with an 253 integer that identifies how to interpret the octet string. The 254 integer identifiers are registered centrally, but can be used both 255 for vendor extensions and for extensions standardized in the IETF. 256 This document adds typed holes to a number of messages which 257 previously lacked typed holes. 259 Many new messages defined in this document also contain ASN.1 260 extension markers. These markers allow future revisions of this 261 document to add additional elements to messages, for cases where 262 typed holes are inadequate for some reason. Because tag numbers and 263 position in a sequence need to be coordinated in order to maintain 264 interoperability, implementations MUST NOT include ASN.1 extensions 265 except when those extensions are specified by IETF standards-track 266 documents. 268 2.2. Compatibility with RFC 1510 270 Implementations of RFC 1510 did not use extensible ASN.1 types. 271 Sending additional fields not in RFC 1510 to these implementations 272 results in undefined behavior. Examples of this behavior are known 273 to include discarding messages with no error indications. 275 Where messages have been changed since RFC 1510, ASN.1 CHOICE types 276 are used; one alternative of the CHOICE provides a message which is 277 wire-encoding compatible with RFC 1510, and the other alternative 278 provides the new, extensible message. 280 Implementations sending new messages MUST ensure that the recipient 281 supports these new messages. Along with each extensible message is a 282 guideline for when that message MAY be used. If that guideline is 283 followed, then the recipient is guaranteed to understand the message. 285 2.3. Backwards Compatibility 287 This document describes two sets (for the most part) of ASN.1 types. 288 The first set of types is wire-encoding compatible with RFC 1510 and 290 [RFC4120]. The second set of types is the set of types enabling 291 extensibility. This second set may be referred to as 292 "extensibility-enabled types". [ need to make this consistent 293 throughout? ] 295 A major difference between the new extensibility-enabled types and 296 the types for RFC 1510 compatibility is that the extensibility- 297 enabled types allow for the use of UTF-8 encodings in various 298 character strings in the protocol. Each party in the protocol must 299 have some knowledge of the capabilities of the other parties in the 300 protocol. There are methods for establishing this knowledge without 301 necessarily requiring explicit configuration. 303 An extensibility-enabled client can detect whether a KDC supports the 304 extensibility-enabled types by requesting an extensibility-enabled 305 reply. If the KDC replies with an extensibility-enabled reply, the 306 client knows that the KDC supports extensibility. If the KDC issues 307 an extensibility-enabled ticket, the client knows that the service 308 named in the ticket is extensibility-enabled. 310 2.4. Sending Extensible Messages 312 Care must be taken to make sure that old implementations can 313 understand messages sent to them even if they do not understand an 314 extension that is used. Unless the sender knows the extension is 315 supported, the extension cannot change the semantics of the core 316 message or previously defined extensions. 318 For example, an extension including key information necessary to 319 decrypt the encrypted part of a KDC-REP could only be used in 320 situations where the recipient was known to support the extension. 321 Thus when designing such extensions it is important to provide a way 322 for the recipient to notify the sender of support for the extension. 323 For example in the case of an extension that changes the KDC-REP 324 reply key, the client could indicate support for the extension by 325 including a padata element in the AS-REQ sequence. The KDC should 326 only use the extension if this padata element is present in the AS- 327 REQ. Even if policy requires the use of the extension, it is better 328 to return an error indicating that the extension is required than to 329 use the extension when the recipient may not support it; debugging 330 why implementations do not interoperate is easier when errors are 331 returned. 333 2.5. Criticality 335 Recipients of unknown message extensions (including typed holes, new 336 flags, and ASN.1 extension elements) should preserve the encoding of 337 the extension but otherwise ignore the presence of the extension; 338 i.e., unknown extensions SHOULD be treated as non-critical. If a 339 copy of the message is used later--for example, when a Ticket 340 received in a KDC-REP is later used in an AP-REQ--then the unknown 341 extensions MUST be included. 343 An implementation SHOULD NOT reject a request merely because it does 344 not understand some element of the request. As a related 345 consequence, implementations SHOULD handle communicating with other 346 implementations which do not implement some requested options. This 347 may require designers of options to provide means to determine 348 whether an option has been rejected, not understood, or (perhaps 349 maliciously) deleted or modified in transit. 351 There is one exception to non-criticality described above: if an 352 unknown authorization data element is received by a server either in 353 an AP-REQ or in a Ticket contained in an AP-REQ, then the 354 authentication SHOULD fail. Authorization data is intended to 355 restrict the use of a ticket. If the service cannot determine 356 whether the restriction applies to that service then a security 357 weakness may result if authentication succeeds. Authorization 358 elements meant to be truly optional can be enclosed in the AD-IF- 359 RELEVANT element. 361 Many RFC 1510 implementations ignore unknown authorization data 362 elements. Depending on these implementations to honor authorization 363 data restrictions may create a security weakness. 365 2.6. Authenticating Cleartext Portions of Messages 367 Various denial of service attacks and downgrade attacks against 368 Kerberos are possible unless plaintexts are somehow protected against 369 modification. An early design goal of Kerberos Version 5 was to 370 avoid encrypting more of the authentication exchange that was 371 required. (Version 4 doubly-encrypted the encrypted part of a ticket 372 in a KDC reply, for example.) This minimization of encryption 373 reduces the load on the KDC and busy servers. Also, during the 374 initial design of Version 5, the existence of legal restrictions on 375 the export of cryptography made it desirable to minimize of the 376 number of uses of encryption in the protocol. Unfortunately, 377 performing this minimization created numerous instances of 378 unauthenticated security-relevant plaintext fields. 380 The extensible variants of the messages described in this document 381 wrap the actual message in an ASN.1 sequence containing a keyed 382 checksum of the contents of the message. Guidelines in [XXX] section 383 3 specify when the checksum MUST be included and what key MUST be 384 used. Guidelines on when to include a checksum are never ambiguous: 385 a particular PDU is never correct both with and without a checksum. 386 With the exception of the KRB-ERROR message, receiving 387 implementations MUST reject messages where a checksum is included and 388 not expected or where a checksum is expected but not included. The 389 receiving implementation does not always have sufficient information 390 to know whether a KRB-ERROR should contain a checksum. Even so, 391 KRB-ERROR messages with invalid checksums MUST be rejected and 392 implementations MAY consider the presence or absence of a checksum 393 when evaluating whether to trust the error. 395 This authenticated cleartext protection is provided only in the 396 extensible variants of the messages; it is never used when 397 communicating with an RFC 1510 implementation. 399 2.7. Capability Negotiation 401 Kerberos is a three-party protocol. Each of the three parties 402 involved needs a means of detecting the capabilities supported by the 403 others. Two of the parties, the KDC and the application server, do 404 not communicate directly in the Kerberos protocol. Communicating 405 capabilities from the KDC to the application server requires using a 406 ticket as an intermediary. 408 The main capability requiring negotiation is the support of the 409 extensibility framework described in this document. Negotiation of 410 this capability while remaining compatible with RFC 1510 411 implementations is possible. The main complication is that the 412 client needs to know whether the application server supports the 413 extensibility framework prior to sending any message to the 414 application server. This can be accomplished if the KDC has 415 knowledge of whether an application server supports the extensibility 416 framework. 418 Client software advertizes its capabilities when requesting 419 credentials from the KDC. If the KDC recognizes the capabilities, it 420 acknowledges this fact to the client in its reply. In addition, if 421 the KDC has knowledge that the application server supports certain 422 capabilities, it also communicates this knowledge to the client in 423 its reply. The KDC can encode its own capabilities in the ticket so 424 that the application server may discover these capabilities. The 425 client advertizes its capabilities to the application server when it 426 initiates authentication to the application server. 428 2.7.1. KDC protocol 430 A client may send an AS-REQ-EXT if it has prior knowledge that the 431 KDC in question will accept it. (possibly via a TCP extension?) 432 Otherwise, the client will send an AS-REQ-1510 with the AS-REQ-EXT 433 inside preauthentication data. The client will always know whether 434 to send TGS-REQ-EXT because (as in the application protocol) it knows 435 the type of the associated Ticket. (Note: could be a problem with 436 non-TGT tickets) 438 The KDC will send AS-REP-EXT or TGS-REP-EXT if the client's message 439 is extensible; otherwise, it will send AS-REP-1510 or TGS-REP-1510. 440 The Ticket contained within the AS-REP-EXT or TGS-REP-EXT will be a 441 TicketExt if the application server supports it; otherwise, it will 442 be a Ticket1510. AS-REP-1510 and TGS-REP-1510 always contain a 443 Ticket1510. The EncTicketPart will depend on the server's 444 capability; the client cannot distinguish EncTicketPart1510 from 445 EncTicketPartExt. 447 KDCs within a realm should be uniform in advertized capability for 448 extensible messages. A KDC SHOULD only issue a TicketExt TGT if all 449 KDCs support it. Similarly, a client receiving a TicketExt knows 450 that all instances of the application service will accept extensible 451 messages. 453 2.7.2. Application protocol 455 The client knows whether the application server supports AP-REQ-EXT 456 because it can distinguish Ticket1510 from TicketExt. The server 457 knows the client's capability due to the format of the AP-REQ. 459 2.8. Strings 461 Some implementations of RFC 1510 do not limit princpal names and 462 realm names to ASCII characters. As a result, migration difficulties 463 resulting from legacy non-ASCII principal and realm names can arise. 464 Is it reasonable to assume that any legacy non-ASCII character can be 465 uniquely represented in Unicode? 467 This may result in a situation where various parties of the protocol 468 need to know alternate, possibly multiple, legacy non-ASCII names for 469 principals and also to know how they map into Unicode. An 470 application server needs to know all possible legacy encodings of its 471 name if it receives a "mixed" ticket. (Ticket1510 containing 472 EncTicketPartExt) It also needs to be able to compare a legacy 473 encoding of a client principal against the normalized UTF-8 encoding 474 when checking the client's principal name in the Authenticator 475 against the one contained in the EncTicketPart. This check can be 476 avoided if the application protocol does not require a replay cache. 478 3. Use of ASN.1 in Kerberos 480 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. 481 Even though ASN.1 theoretically allows the description of protocol 482 messages to be independent of the encoding rules used to encode the 483 messages, Kerberos messages MUST be encoded with DER. Subtleties in 484 the semantics of the notation, such as whether tags carry any 485 semantic content to the application, may cause the use of other ASN.1 486 encoding rules to be problematic. 488 Implementors not using existing ASN.1 tools (e.g., compilers or 489 support libraries) are cautioned to thoroughly read and understand 490 the actual ASN.1 specification to ensure correct implementation 491 behavior. There is more complexity in the notation than is 492 immediately obvious, and some tutorials and guides to ASN.1 are 493 misleading or erroneous. Recommended tutorials and guides include 495 [Dub00], [Lar99], though there is still no substitute for reading the 496 actual ASN.1 specification. 498 3.1. Module Header 500 The type definitions in this document assume an ASN.1 module 501 definition of the following form: 503 KerberosV5Spec3 { 504 iso(1) identified-organization(3) dod(6) internet(1) 505 security(5) kerberosV5(2) modules(4) krb5spec3(4) 506 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 508 -- Rest of definitions here 510 END 512 This specifies that the tagging context for the module will be 513 explicit and that automatic tagging is not done. 515 Some other publications [RFC1510] [RFC1964] erroneously specify an 516 object identifier (OID) having an incorrect value of "5" for the 517 "dod" component of the OID. In the case of RFC 1964, use of the 518 "correct" OID value would result in a change in the wire protocol; 519 therefore, the RFC 1964 OID remains unchanged for now. 521 3.2. Top-Level Type 523 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol 524 Data Units or PDUs) which an application may directly reference. 525 Applications SHOULD NOT transmit any types other than those which are 526 alternatives of the KRB-PDU CHOICE. 528 -- top-level type 529 -- 530 -- Applications should not directly reference any types 531 -- other than KRB-PDU and its component types. 532 -- 533 KRB-PDU ::= CHOICE { 534 ticket Ticket, 535 as-req AS-REQ, 536 as-rep AS-REP, 537 tgs-req TGS-REQ, 538 tgs-rep TGS-REP, 539 ap-req AP-REQ, 540 ap-rep AP-REP, 541 krb-safe KRB-SAFE, 542 krb-priv KRB-PRIV, 543 krb-cred KRB-CRED, 544 tgt-req TGT-REQ, 545 krb-error KRB-ERROR, 546 ... 547 } 549 3.3. Previously Unused ASN.1 Notation (informative) 551 Some aspects of ASN.1 notation used in this document were not used in 552 [RFC4120], and may be unfamiliar to some readers. This subsection is 553 informative; for normative definitions of the notation, see the 554 actual ASN.1 specifications [X680], [X682], [X683]. 556 3.3.1. Parameterized Types 558 This document uses ASN.1 parameterized types [X683] to make 559 definitions of types more readable. For some types, some or all of 560 the parameters are advisory, i.e., they are not encoded in any form 561 for transmission in a protocol message. These advisory parameters 562 can describe implementation behavior associated with the type. 564 3.3.2. Constraints 566 This document uses ASN.1 constraints, including the 567 "UserDefinedConstraint" notation [X682]. Some constraints can be 568 handled automatically by tools that can parse them. Uses of the 569 "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will 570 typically need to have behavior manually coded; the notation provides 571 a formalized way of conveying intended implementation behavior. 573 The "WITH COMPONENTS" constraint notation allows constraints to apply 574 to component types of a SEQUENCE type. This constraint notation 575 effectively allows constraints to "reach into" a type to constrain 576 its component types. 578 3.4. New Types 580 This document defines a number of ASN.1 types which are new since 581 [RFC4120]. The names of these types will typically have a suffix 582 like "Ext", indicating that the types are intended to support 583 extensibility. Types original to RFC 1510 and [RFC4120] have been 584 renamed to have a suffix like "1510". The "Ext" and "1510" types 585 often contain a number of common elements, but differ primarily in 586 the way strings are encoded. 588 4. Basic Types 590 These "basic" Kerberos ASN.1 types appear in multiple other Kerberos 591 types. 593 4.1. Constrained Integer Types 595 In RFC 1510, many types contained references to the unconstrained 596 INTEGER type. Since an unconstrained INTEGER can contain almost any 597 possible abstract integer value, most of the unconstrained references 598 to INTEGER in RFC 1510 were constrained to 32 bits or smaller in 599 [RFC4120]. 601 -- signed values representable in 32 bits 602 -- 603 -- These are often used as assigned numbers for various things. 604 Int32 ::= INTEGER (-2147483648..2147483647) 606 The "Int32" type often contains an assigned number identifying the 607 contents of a typed hole. Unless otherwise stated, non-negative 608 values are registered, and negative values are available for local 609 use. 611 -- unsigned 32 bit values 612 UInt32 ::= INTEGER (0..4294967295) 614 The "UInt32" type is used in some places where an unsigned 32-bit 615 integer is needed. 617 -- unsigned 64 bit values 618 UInt64 ::= INTEGER (0..18446744073709551615) 620 The "UInt64" type is used in places where 32 bits of precision may 621 provide inadequate security. 623 -- sequence numbers 624 SeqNum ::= UInt64 626 Sequence numbers were constrained to 32 bits in [RFC4120], but this 627 document allows for 64-bit sequence numbers. 629 -- nonces 630 Nonce ::= UInt64 632 Likewise, nonces were constrained to 32 bits in [RFC4120], but 633 expanded to 64 bits here. 635 -- microseconds 636 Microseconds ::= INTEGER (0..999999) 638 The "microseconds" type is intended to carry the microseconds part of 639 a time value. 641 4.2. KerberosTime 643 KerberosTime ::= GeneralizedTime (CONSTRAINED BY { 644 -- MUST NOT include fractional seconds 645 }) 647 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 648 KerberosTime value MUST NOT include any fractional portions of the 649 seconds. As required by the DER, it further MUST NOT include any 650 separators, and it specifies the UTC time zone (Z). Example: The 651 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 652 November 1985 is "19851106210627Z". 654 4.3. KerberosString 656 -- used for names and for error messages 657 KerberosString ::= CHOICE { 658 ia5 GeneralString (IA5String), 659 utf8 UTF8String, 660 ... -- no extension may be sent 661 -- to an rfc1510 implementation -- 662 } 664 The KerberosString type is used for character strings in various 665 places in the Kerberos protocol. For compatibility with RFC 1510, 666 GeneralString values constrained to IA5String (US-ASCII) are 667 permitted in messages exchanged with RFC 1510 implementations. The 668 new protocol messages contain strings encoded as UTF-8, and these 669 strings MUST be normalized using [RFC4013]. KerberosString values 670 are present in principal names and in error messages. Control 671 characters SHOULD NOT be used in principal names, and used with 672 caution in error messages. 674 -- IA5 choice only; useful for constraints 675 KerberosStringIA5 ::= KerberosString 676 (WITH COMPONENTS { ia5 PRESENT }) 678 -- IA5 excluded; useful for constraints 679 KerberosStringExt ::= KerberosString 680 (WITH COMPONENTS { ia5 ABSENT }) 682 KerberosStringIA5 requires the use of the "ia5" alternative, while 683 KerberosStringExt forbids it. These types appear in ASN.1 684 constraints on messages. 686 For detailed background regarding the history of character string use 687 in Kerberos, as well as discussion of some compatibility issues, see 688 Appendix B. 690 4.4. Language Tags 692 -- used for language tags 693 LangTag ::= PrintableString 694 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 696 The "LangTag" type is used to specify language tags for localization 697 purposes, using the [RFC4646] format. 699 4.5. KerberosFlags 701 For several message types, a specific constrained bit string type, 702 KerberosFlags, is used. 704 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 705 (CONSTRAINED BY { 706 -- MUST be a valid value of -- NamedBits 708 -- but if the value to be sent would be truncated to 709 -- shorter than 32 bits according to DER, the value MUST be 710 -- padded with trailing zero bits to 32 bits. Otherwise, 711 -- no trailing zero bits may be present. 713 }) 715 The actual bit string type encoded in Kerberos messages does not use 716 named bits. The advisory parameter of the KerberosFlags type names a 717 bit string type defined using named bits, whose value is encoded as 718 if it were a bit string with unnamed bits. This practice is 719 necessary because the DER require trailing zero bits to be removed 720 when encoding bit strings defined using named bits. Existing 721 implementations of Kerberos send exactly 32 bits rather than 722 truncating, so the size constraint requires the transmission of at 723 least 32 bits. Trailing zero bits beyond the first 32 bits are 724 truncated. 726 4.6. Typed Holes 728 -- Typed hole identifiers 729 TH-id ::= CHOICE { 730 int32 Int32, 731 rel-oid RELATIVE-OID 732 } 734 The "TH-id" type is a generalized means to identify the contents of a 735 typed hole. The "int32" alternative may be used for simple integer 736 assignments, in the same manner as "Int32", while the "rel-oid" 737 alternative may be used for hierarchical delegation. 739 4.7. HostAddress and HostAddresses 741 AddrType ::= Int32 743 HostAddress ::= SEQUENCE { 744 addr-type [0] AddrType, 745 address [1] OCTET STRING 746 } 748 -- NOTE: HostAddresses is always used as an OPTIONAL field and 749 -- should not be a zero-length SEQUENCE OF. 750 -- 751 -- The extensible messages explicitly constrain this to be 752 -- non-empty. 753 HostAddresses ::= SEQUENCE OF HostAddress 755 addr-type 756 This field specifies the type of address that follows. 758 address 759 This field encodes a single address of the type identified by 760 "addr-type". 762 All negative values for the host address type are reserved for local 763 use. All non-negative values are reserved for officially assigned 764 type fields and interpretations. 766 addr-type | meaning 767 __________|______________ 768 2 | IPv4 769 3 | directional 770 12 | DECnet 771 20 | NetBIOS 772 24 | IPv6 774 4.7.1. Internet (IPv4) Addresses 776 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in 777 MSB order (most significant byte first). The IPv4 loopback address 778 SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is 779 two (2). 781 4.7.2. Internet (IPv6) Addresses 783 IPv6 addresses [RFC4291] are 128-bit (16-octet) quantities, encoded 784 in MSB order (most significant byte first). The type of IPv6 785 addresses is twenty-four (24). The following addresses MUST NOT 786 appear in any Kerberos PDU: 788 * the Unspecified Address 790 * the Loopback Address 792 * Link-Local addresses 794 This restriction applies to the inclusion in the address fields of 795 Kerberos PDUs, but not to the address fields of packets that might 796 carry such PDUs. The restriction is necessary because the use of an 797 address with non-global scope could allow the acceptance of a message 798 sent from a node that may have the same address, but which is not the 799 host intended by the entity that added the restriction. If the 800 link-local address type needs to be used for communication, then the 801 address restriction in tickets must not be used (i.e. addressless 802 tickets must be used). 804 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 805 2. 807 4.7.3. DECnet Phase IV addresses 809 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. 810 The type of DECnet Phase IV addresses is twelve (12). 812 4.7.4. Netbios addresses 814 Netbios addresses are 16-octet addresses typically composed of 1 to 815 15 alphanumeric characters and padded with the US-ASCII SPC character 816 (code 32). The 16th octet MUST be the US-ASCII NUL character (code 817 0). The type of Netbios addresses is twenty (20). 819 4.7.5. Directional Addresses 821 In many environments, including the sender address in KRB-SAFE and 822 KRB-PRIV messages is undesirable because the addresses may be changed 823 in transport by network address translators. However, if these 824 addresses are removed, the messages may be subject to a reflection 825 attack in which a message is reflected back to its originator. The 826 directional address type provides a way to avoid transport addresses 827 and reflection attacks. Directional addresses are encoded as four 828 byte unsigned integers in network byte order. If the message is 829 originated by the party sending the original AP-REQ message, then an 830 address of 0 SHOULD be used. If the message is originated by the 831 party to whom that AP-REQ was sent, then the address 1 SHOULD be 832 used. Applications involving multiple parties can specify the use of 833 other addresses. 835 Directional addresses MUST only be used for the sender address field 836 in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a 837 ticket address or in a AP-REQ message. This address type SHOULD only 838 be used in situations where the sending party knows that the 839 receiving party supports the address type. This generally means that 840 directional addresses may only be used when the application protocol 841 requires their support. Directional addresses are type (3). 843 5. Principals 845 Principals are participants in the Kerberos protocol. A "realm" 846 consists of principals in one administrative domain, served by one 847 KDC (or one replicated set of KDCs). Each principal name has an 848 arbitrary number of components, though typical principal names will 849 only have one or two components. A principal name is meant to be 850 readable by and meaningful to humans, especially in a realm lacking a 851 centrally adminstered authorization infrastructure. 853 5.1. Name Types 855 Each PrincipalName has NameType indicating what sort of name it is. 856 The name-type SHOULD be treated as a hint. Ignoring the name type, 857 no two names can be the same (i.e., at least one of the components, 858 or the realm, must be different). 860 -- assigned numbers for name types (used in principal names) 861 NameType ::= Int32 863 -- Name type not known 864 nt-unknown NameType ::= 0 865 -- Just the name of the principal as in DCE, or for users 866 nt-principal NameType ::= 1 867 -- Service and other unique instance (krbtgt) 868 nt-srv-inst NameType ::= 2 869 -- Service with host name as instance (telnet, rcommands) 870 nt-srv-hst NameType ::= 3 871 -- Service with host as remaining components 872 nt-srv-xhst NameType ::= 4 873 -- Unique ID 874 nt-uid NameType ::= 5 875 -- Encoded X.509 Distingished name [RFC 2253] 876 nt-x500-principal NameType ::= 6 877 -- Name in form of SMTP email name (e.g. user@foo.com) 878 nt-smtp-name NameType ::= 7 879 -- Enterprise name - may be mapped to principal name 880 nt-enterprise NameType ::= 10 881 -- reserved principal names [krb-wg-naming] 882 nt-wellknown NameType ::= 11 884 5.2. Principal Type Definition 886 The "PrincipalName" type takes a parameter to constrain which string 887 type it contains. 889 PrincipalName { StrType } ::= SEQUENCE { 890 name-type [0] NameType, 891 -- May have zero elements, or individual elements may be 892 -- zero-length, but this is NOT RECOMMENDED. 893 name-string [1] SEQUENCE OF KerberosString (StrType) 894 } 896 The constrained types have their own names. 898 -- IA5 only 899 PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } 900 -- IA5 excluded 901 PrincipalNameExt ::= PrincipalName { KerberosStringExt } 902 -- Either one? 903 PrincipalNameEither ::= PrincipalName { KerberosString } 905 name-type 906 hint of the type of name that follows 908 name-string 909 The "name-string" encodes a sequence of components that form a 910 name, each component encoded as a KerberosString. Taken 911 together, a PrincipalName and a Realm form a principal 912 identifier. Most PrincipalNames will have only a few components 913 (typically one or two). 915 5.3. Principal Name Reuse 917 Realm administrators SHOULD use extreme caution when considering 918 reusing a principal name. A service administrator might explicitly 919 enter principal names into a local access control list (ACL) for the 920 service. If such local ACLs exist independently of a centrally 921 administered authorization infrastructure, realm administrators 922 SHOULD NOT reuse principal names until confirming that all extant ACL 923 entries referencing that principal name have been updated. Failure 924 to perform this check can result in a security vulnerability, as a 925 new principal can inadvertently inherit unauthorized privileges upon 926 receiving a reused principal name. An organization whose Kerberos- 927 authenticated services all use a centrally-adminstered authorization 928 infrastructure may not need to take these precautions regarding 929 principal name reuse. 931 5.4. Best Common Practice Recommendations for the Processing of 932 Principal Names Consisting of Internationalized Domain Names: 934 Kerberos principals are often created for the purpose of 935 authenticating a service located on a machine identified by an domain 936 name. Unfortunately, once a principal name is created it is 937 impossible to know the source from which the resulting KerberosString 938 was derived. It is therefore required that principal names 939 containing internationalized domain names be processed via the 940 following procedure: 942 * ensure that the IDN component must be a valid domain name as per 943 the rules of IDNA [RFC3490] 945 * separate the IDN component into labels separated by any of the 946 Full Stop characters 948 * fold all Full Stop characters to Full Stop (0x002E) 950 * for each label (perform all steps): 952 o if the label begins with an ACE prefix as registered with IANA, 953 the prefix will be removed and the rest of the label will be 954 converted from the ACE representation to Unicode [need 955 reference] 957 o if the label consists of one or more internationalized 958 characters separately apply the NamePrep and then the SASLprep 959 string preparation methods. 961 o if the label consists of zero internalizationalized characters, 962 the label is to be lower-cased 964 o if the output of the two methods match, continue on to the next 965 label; otherwise reject the principal name as invalid 967 * the result of a valid principal name component derived from an IDN 968 is the joining of the individual string prepared labels separated 969 by the Full Stop (0x002E) 971 5.5. Realm Names 973 Realm { StrType } ::= KerberosString (StrType) 975 -- IA5 only 976 RealmIA5 ::= Realm { KerberosStringIA5 } 978 -- IA5 excluded 979 RealmExt ::= Realm { KerberosStringExt } 981 -- Either 982 RealmEither ::= Realm { KerberosString } 984 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a 985 character with the code 0 (the US-ASCII NUL). Most realms will 986 usually consist of several components separated by periods (.), in 987 the style of Internet Domain Names, or separated by slashes (/) in 988 the style of X.500 names. 990 5.6. Best Common Practice Recommendations for the Processing of 991 Internationalized Domain-Style Realm Names: 993 Domain Style Realm names are defined as all realm names whose 994 components are separated by Full Stop (0x002E) (aka periods, '.') and 995 contain neither colons, name containing one or more internationalized 996 characters (not included in US-ASCII), this procedure must be used: 998 * the realm name must be a valid domain name as per the rules of 999 IDNA [RFC3490] 1001 * the following string preparation routine must be followed: 1003 - separate the string into components separated by any of the 1004 Full Stop characters 1006 - fold all Full Stop characters to Full Stop (0x002E) 1007 - for each component (perform all steps): 1009 o if the component begins with an ACE prefix as registered 1010 with IANA, the prefix will be removed and the rest of the 1011 component will be converted from the ACE representation to 1012 Unicode [need reference] 1014 o if the component consists of one or more internationalized 1015 characters separately apply the NamePrep and SASLprep string 1016 preparation methods. 1018 if the output of the two methods match, continue on to the 1019 next component; otherwise reject the realm name as invalid 1021 - the result of a valid realm name is the joining of the 1022 individual string prepared components separated by the Full 1023 Stop (0x002E) 1025 In [RFC4120], the recommendation is that all domain style realm names 1026 be represented in uppercase. This recommendation is modified in the 1027 following manner. All components of domain style realm names not 1028 including internationalized characters should be upper-cased. All 1029 components of domain style realm names including internationalized 1030 characters must be lower-cased. (The lower case representation of 1031 internationalized components is enforced by the requirement that the 1032 output of NamePrep and StringPrep string preparation must be 1033 equivalent.) 1035 5.7. Printable Representations of Principal Names 1037 [ perhaps non-normative? ] 1039 The printable form of a principal name consists of the concatenation 1040 of components of the PrincipalName value using the slash character 1041 (/), followed by an at-sign (@), followed by the realm name. Any 1042 occurrence of a backslash (\), slash (/) or at-sign (@) in the 1043 PrincipalName value is quoted by a backslash. 1045 5.8. Ticket-Granting Service Principal 1047 The PrincipalName value corresponding to a ticket-granting service 1048 has two components: the first component is the string "krbtgt", and 1049 the second component is the realm name of the TGS which will accept a 1050 ticket-granting ticket having this service principal name. The realm 1051 name of service always indicates which realm issued the ticket. A 1052 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for 1053 obtaining tickets in the same realm would have the following ASN.1 1054 values for its "realm" and "sname" components, respectively: 1056 -- Example Realm and PrincipalName for a TGS 1058 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" 1060 tgtPrinc1 PrincipalName ::= { 1061 name-type nt-srv-inst, 1062 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } 1063 } 1065 Its printable representation would be written as 1066 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". 1068 5.8.1. Cross-Realm TGS Principals 1070 It is possible for a principal in one realm to authenticate to a 1071 service in another realm. A KDC can issue a cross-realm ticket- 1072 granting ticket to allow one of its principals to authenticate to a 1073 service in a foreign realm. For example, the TGS principal 1074 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a 1075 client principal in the realm A.EXAMPLE.COM to authenticate to a 1076 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM 1077 issues a ticket to a client originating in A.EXAMPLE.COM, the 1078 client's realm name remains "A.EXAMPLE.COM", even though the service 1079 principal will have the realm "B.EXAMPLE.COM". 1081 6. Types Relating to Encryption 1083 Many Kerberos protocol messages contain encrypted encodings of 1084 various data types. Some Kerberos protocol messages also contain 1085 checksums (signatures) of encodings of various types. 1087 6.1. Assigned Numbers for Encryption 1089 Encryption algorithm identifiers and key usages both have assigned 1090 numbers, described in [RFC3961]. 1092 6.1.1. EType 1094 EType is the integer type for assigned numbers for encryption 1095 algorithms. Defined in [RFC3961]. 1097 -- Assigned numbers denoting encryption mechanisms. 1098 EType ::= Int32 1100 -- assigned numbers for encryption schemes 1101 et-des-cbc-crc EType ::= 1 1102 et-des-cbc-md4 EType ::= 2 1103 et-des-cbc-md5 EType ::= 3 1104 -- [reserved] 4 1105 et-des3-cbc-md5 EType ::= 5 1106 -- [reserved] 6 1107 et-des3-cbc-sha1 EType ::= 7 1108 et-dsaWithSHA1-CmsOID EType ::= 9 1109 et-md5WithRSAEncryption-CmsOID EType ::= 10 1110 et-sha1WithRSAEncryption-CmsOID EType ::= 11 1111 et-rc2CBC-EnvOID EType ::= 12 1112 et-rsaEncryption-EnvOID EType ::= 13 1113 et-rsaES-OAEP-ENV-OID EType ::= 14 1114 et-des-ede3-cbc-Env-OID EType ::= 15 1115 et-des3-cbc-sha1-kd EType ::= 16 1116 -- AES 1117 et-aes128-cts-hmac-sha1-96 EType ::= 17 1118 -- AES 1119 et-aes256-cts-hmac-sha1-96 EType ::= 18 1120 -- Microsoft 1121 et-rc4-hmac EType ::= 23 1122 -- Microsoft 1123 et-rc4-hmac-exp EType ::= 24 1124 -- opaque; PacketCable 1125 et-subkey-keymaterial EType ::= 65 1127 6.1.2. Key Usages 1129 KeyUsage is the integer type for assigned numbers for key usages. 1130 Key usage values are inputs to the encryption and decryption 1131 functions described in [RFC3961]. 1133 -- Assigned numbers denoting key usages. 1134 KeyUsage ::= UInt32 1136 -- 1137 -- Actual identifier names are provisional and subject to 1138 -- change. 1139 -- 1140 ku-pa-enc-ts KeyUsage ::= 1 1141 ku-Ticket KeyUsage ::= 2 1142 ku-EncASRepPart KeyUsage ::= 3 1143 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 1144 ku-TGSReqAuthData-subkey KeyUsage ::= 5 1145 ku-pa-TGSReq-cksum KeyUsage ::= 6 1146 ku-pa-TGSReq-authenticator KeyUsage ::= 7 1147 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 1148 ku-EncTGSRepPart-subkey KeyUsage ::= 9 1149 ku-Authenticator-cksum KeyUsage ::= 10 1150 ku-APReq-authenticator KeyUsage ::= 11 1151 ku-EncAPRepPart KeyUsage ::= 12 1152 ku-EncKrbPrivPart KeyUsage ::= 13 1153 ku-EncKrbCredPart KeyUsage ::= 14 1154 ku-KrbSafe-cksum KeyUsage ::= 15 1155 ku-ad-KDCIssued-cksum KeyUsage ::= 19 1156 -- The following numbers are provisional... 1157 -- conflicts may exist elsewhere. 1158 ku-Ticket-cksum KeyUsage ::= 29 1159 ku-ASReq-cksum KeyUsage ::= 30 1160 ku-TGSReq-cksum KeyUsage ::= 31 1161 ku-ASRep-cksum KeyUsage ::= 32 1162 ku-TGSRep-cksum KeyUsage ::= 33 1163 ku-APReq-cksum KeyUsage ::= 34 1164 ku-APRep-cksum KeyUsage ::= 35 1165 ku-KrbCred-cksum KeyUsage ::= 36 1166 ku-KrbError-cksum KeyUsage ::= 37 1167 ku-KDCRep-cksum KeyUsage ::= 38 1169 ku-kg-acceptor-seal KeyUsage ::= 22 1170 ku-kg-acceptor-sign KeyUsage ::= 23 1171 ku-kg-intiator-seal KeyUsage ::= 24 1172 ku-kg-intiator-sign KeyUsage ::= 25 1174 -- KeyUsage values 25..27 used by hardware preauth? 1176 -- for KINK 1177 ku-kink-encrypt KeyUsage ::= 39 1178 ku-kink-cksum KeyUsage ::= 40 1180 -- IAKERB 1181 ku-iakerb-finished KeyUsage ::= 41 1183 6.2. Which Key to Use 1184 -- KeyToUse identifies which key is to be used to encrypt or 1185 -- sign a given value. 1186 -- 1187 -- Values of KeyToUse are never actually transmitted over the 1188 -- wire, or even used directly by the implementation in any 1189 -- way, as key usages are; it exists primarily to identify 1190 -- which key gets used for what purpose. Thus, the specific 1191 -- numeric values associated with this type are irrelevant. 1192 KeyToUse ::= ENUMERATED { 1193 -- unspecified 1194 key-unspecified, 1195 -- server long term key 1196 key-server, 1197 -- client long term key 1198 key-client, 1199 -- key selected by KDC for encryption of a KDC-REP 1200 key-kdc-rep, 1201 -- session key from ticket 1202 key-session, 1203 -- subsession key negotiated via AP-REQ/AP-REP 1204 key-subsession, 1205 ... 1206 } 1208 6.3. EncryptionKey 1210 The "EncryptionKey" type holds an encryption key. 1212 EncryptionKey ::= SEQUENCE { 1213 keytype [0] EType, 1214 keyvalue [1] OCTET STRING 1215 } 1217 keytype 1218 This "EType" identifies the encryption algorithm, described in 1219 [RFC3961]. 1221 keyvalue 1222 Contains the actual key. 1224 6.4. EncryptedData 1226 The "EncryptedData" type contains the encryption of another data 1227 type. The recipient uses fields within EncryptedData to determine 1228 which key to use for decryption. 1230 -- "Type" specifies which ASN.1 type is encrypted to the 1231 -- ciphertext in the EncryptedData. "Keys" specifies a set of 1232 -- keys of which one key may be used to encrypt the data. 1233 -- "KeyUsages" specifies a set of key usages, one of which may 1234 -- be used to encrypt. 1235 -- 1236 -- None of the parameters is transmitted over the wire. 1237 EncryptedData { 1238 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1239 } ::= SEQUENCE { 1240 etype [0] EType, 1241 kvno [1] UInt32 OPTIONAL, 1242 cipher [2] OCTET STRING (CONSTRAINED BY { 1243 -- must be encryption of -- 1244 OCTET STRING (CONTAINING Type), 1245 -- with one of the keys -- KeyToUse:Keys, 1246 -- with key usage being one of -- 1247 KeyUsage:KeyUsages 1248 }), 1249 ... 1250 } 1252 KeyUsages 1253 Advisory parameter indicating which key usage to use when 1254 encrypting the ciphertext. If "KeyUsages" indicate multiple 1255 "KeyUsage" values, the detailed description of the containing 1256 message will indicate which key to use under which conditions. 1258 Type 1259 Advisory parameter indicating the ASN.1 type whose DER encoding 1260 is the plaintext encrypted into the EncryptedData. 1262 Keys 1263 Advisory parameter indicating which key to use to perform the 1264 encryption. If "Keys" indicate multiple "KeyToUse" values, the 1265 detailed description of the containing message will indicate 1266 which key to use under which conditions. 1268 KeyUsages 1269 Advisory parameter indicating which "KeyUsage" value is used to 1270 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, 1271 the detailed description of the containing message will indicate 1272 which key usage to use under which conditions. 1274 6.5. Checksums 1276 Several types contain checksums (actually signatures) of data. 1278 CksumType ::= Int32 1280 -- The parameters specify which key to use to produce the 1281 -- signature, as well as which key usage to use. The 1282 -- parameters are not actually sent over the wire. 1283 Checksum { 1284 KeyToUse:Keys, KeyUsage:KeyUsages 1285 } ::= SEQUENCE { 1286 cksumtype [0] CksumType, 1287 checksum [1] OCTET STRING (CONSTRAINED BY { 1288 -- signed using one of the keys -- 1289 KeyToUse:Keys, 1290 -- with key usage being one of -- 1291 KeyUsage:KeyUsages 1292 }) 1293 } 1295 CksumType 1296 Integer type for assigned numbers for signature algorithms. 1297 Defined in [RFC3961] 1299 Keys 1300 As in EncryptedData 1302 KeyUsages 1303 As in EncryptedData 1305 cksumtype 1306 Signature algorithm used to produce the signature. 1308 checksum 1309 The actual checksum. 1311 6.5.1. ChecksumOf 1313 ChecksumOf is similar to "Checksum", but specifies which type is 1314 signed. 1316 -- a Checksum that must contain the checksum 1317 -- of a particular type 1318 ChecksumOf { 1319 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1320 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 1321 ..., 1322 checksum (CONSTRAINED BY { 1323 -- must be checksum of -- 1324 OCTET STRING (CONTAINING Type) 1325 }) 1326 }) 1328 Type 1329 Indicates the ASN.1 type whose DER encoding is signed. 1331 6.5.2. Signed 1333 Signed is similar to "ChecksumOf", but contains an actual instance of 1334 the type being signed in addition to the signature. 1336 -- parameterized type for wrapping authenticated plaintext 1337 Signed { 1338 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 1339 } ::= SEQUENCE { 1340 cksum [0] ChecksumOf { 1341 InnerType, Keys, KeyUsages 1342 } OPTIONAL, 1343 inner [1] InnerType, 1344 ... 1345 } 1347 7. Tickets 1349 [ A large number of items described here are duplicated in the 1350 sections describing KDC-REQ processing. Should find a way to avoid 1351 this duplication. ] 1353 A ticket binds a principal name to a session key. The important 1354 fields of a ticket are in the encrypted part. 1356 -- Encrypted part of ticket 1357 EncTicketPart ::= CHOICE { 1358 rfc1510 EncTicketPart1510, 1359 ext EncTicketPartExt 1360 } 1362 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { 1363 flags [0] TicketFlags, 1364 key [1] EncryptionKey, 1365 crealm [2] RealmIA5, 1366 cname [3] PrincipalNameIA5, 1367 transited [4] TransitedEncoding, 1368 authtime [5] KerberosTime, 1369 starttime [6] KerberosTime OPTIONAL, 1370 endtime [7] KerberosTime, 1371 renew-till [8] KerberosTime OPTIONAL, 1372 caddr [9] HostAddresses OPTIONAL, 1373 authorization-data [10] AuthorizationData OPTIONAL 1374 } 1375 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { 1376 flags [0] TicketFlags, 1377 key [1] EncryptionKey, 1378 crealm [2] RealmExt, 1379 cname [3] PrincipalNameExt, 1380 transited [4] TransitedEncoding, 1381 authtime [5] KerberosTime, 1382 starttime [6] KerberosTime OPTIONAL, 1383 endtime [7] KerberosTime, 1384 renew-till [8] KerberosTime OPTIONAL, 1385 caddr [9] HostAddresses OPTIONAL, 1386 authorization-data [10] AuthorizationData OPTIONAL, 1387 ..., 1388 } 1390 crealm 1391 This field contains the client's realm. 1393 cname 1394 This field contains the client's name. 1396 caddr 1397 This field lists the network addresses (if absent, all addresses 1398 are permitted) from which the ticket is valid. 1400 Descriptions of the other fields appear in the following sections. 1402 7.1. Timestamps 1404 Three of the ticket timestamps may be requested from the KDC. The 1405 timestamps may differ from those requested, depending on site policy. 1407 authtime 1408 The time at which the client authenticated, as recorded by the 1409 KDC. 1411 starttime 1412 The earliest time when the ticket is valid. If not present, the 1413 ticket is valid starting at the authtime. This is requested as 1414 the "from" field of KDC-REQ-BODY. 1416 endtime 1417 This time is requested in the "till" field of KDC-REQ-BODY. 1418 Contains the time after which the ticket will not be honored 1419 (its expiration time). Note that individual services MAY place 1420 their own limits on the life of a ticket and MAY reject tickets 1421 which have not yet expired. As such, this is really an upper 1422 bound on the expiration time for the ticket. 1424 renew-till 1425 This time is requested in the "rtime" field of KDC-REQ-BODY. It 1426 is only present in tickets that have the "renewable" flag set in 1427 the flags field. It indicates the maximum endtime that may be 1428 included in a renewal. It can be thought of as the absolute 1429 expiration time for the ticket, including all renewals. 1431 7.2. Ticket Flags 1433 A number of flags may be set in the ticket, further defining some of 1434 its capabilities. Some of these flags map to flags in a KDC request. 1436 TicketFlags ::= KerberosFlags { TicketFlagsBits } 1438 TicketFlagsBits ::= BIT STRING { 1439 reserved (0), 1440 forwardable (1), 1441 forwarded (2), 1442 proxiable (3), 1443 proxy (4), 1444 may-postdate (5), 1445 postdated (6), 1446 invalid (7), 1447 renewable (8), 1448 initial (9), 1449 pre-authent (10), 1450 hw-authent (11), 1451 transited-policy-checked (12), 1452 ok-as-delegate (13), 1453 anonymous (14), 1454 cksummed-ticket (15) 1455 } 1457 7.2.1. Flags Relating to Initial Ticket Acquisition 1459 [ adapted RFC4120 2.1. ] 1461 Several flags indicate the details of how the initial ticket was 1462 acquired. 1464 initial 1465 The "initial" flag indicates that a ticket was issued using the 1466 AS protocol, rather than issued based on a ticket-granting 1467 ticket. Application servers (e.g., a password-changing program) 1468 requiring a client's definite knowledge of its secret key can 1469 insist that this flag be set in any tickets they accept, thus 1470 being assured that the client's key was recently presented to 1471 the application client. 1473 pre-authent 1474 The "pre-authent" flag indicates that some sort of pre- 1475 authentication was used during the AS exchange. 1477 hw-authent 1478 The "hw-authent" flag indicates that some sort of hardware-based 1479 pre-authentication occurred during the AS exchange. 1481 Both the "pre-authent" and the "hw-authent" flags may be present with 1482 or without the "initial" flag; such tickets with the "initial" flag 1483 clear are ones which are derived from initial tickets with the "pre- 1484 authent" or "hw-authent" flags set. 1486 7.2.2. Invalid Tickets 1488 [ RFC4120 2.2. ] 1490 The "invalid" flag indicates that a ticket is invalid. Application 1491 servers MUST reject tickets which have this flag set. A postdated 1492 ticket will be issued in this form. Invalid tickets MUST be 1493 validated by the KDC before use, by presenting them to the KDC in a 1494 TGS request with the "validate" option specified. The KDC will only 1495 validate tickets after their starttime has passed. The validation is 1496 required so that postdated tickets which have been stolen before 1497 their starttime can be rendered permanently invalid (through a hot- 1498 list mechanism -- see Section 8.3.2.4). 1500 7.2.3. OK as Delegate 1502 [ RFC4120 2.8. ] 1504 The "ok-as-delegate" flag provides a way for a KDC to communicate 1505 local realm policy to a client regarding whether the service for 1506 which the ticket is issued is trusted to accept delegated 1507 credentials. For some applications, a client may need to delegate 1508 credentials to a service to act on its behalf in contacting other 1509 services. The ability of a client to obtain a service ticket for a 1510 service conveys no information to the client about whether the 1511 service should be trusted to accept delegated credentials. 1513 The copy of the ticket flags visible to the client may have the "ok- 1514 as-delegate" flag set to indicate to the client that the service 1515 specified in the ticket has been determined by policy of the realm to 1516 be a suitable recipient of delegation. A client can use the presence 1517 of this flag to help it make a decision whether to delegate 1518 credentials (either grant a proxy or a forwarded ticket-granting 1519 ticket) to this service. It is acceptable to ignore the value of 1520 this flag. When setting this flag, an administrator should consider 1521 the security and placement of the server on which the service will 1522 run, as well as whether the service requires the use of delegated 1523 credentials. 1525 7.2.4. Renewable Tickets 1527 [ adapted RFC4120 2.3. ] 1529 The "renewable" flag indicates whether the ticket may be renewed. 1531 Renewable tickets can be used to mitigate the consequences of ticket 1532 theft. Applications may desire to hold credentials which can be 1533 valid for long periods of time. However, this can expose the 1534 credentials to potential theft for equally long periods, and those 1535 stolen credentials would be valid until the expiration time of the 1536 ticket(s). Simply using short-lived tickets and obtaining new ones 1537 periodically would require the application to have long-term access 1538 to the client's secret key, which is an even greater risk. 1540 Renewable tickets have two "expiration times": the first is when the 1541 current instance of the ticket expires, and the second is the latest 1542 permissible value for an individual expiration time. An application 1543 client must periodically present an unexpired renewable ticket to the 1544 KDC, setting the "renew" option in the KDC request. The KDC will 1545 issue a new ticket with a new session key and a later expiration 1546 time. All other fields of the ticket are left unmodified by the 1547 renewal process. When the latest permissible expiration time 1548 arrives, the ticket expires permanently. At each renewal, the KDC 1549 MAY consult a hot-list to determine if the ticket had been reported 1550 stolen since its last renewal; it will refuse to renew such stolen 1551 tickets, and thus the usable lifetime of stolen tickets is reduced. 1553 The "renewable" flag in a ticket is normally only interpreted by the 1554 ticket-granting service. It can usually be ignored by application 1555 servers. However, some particularly careful application servers MAY 1556 disallow renewable tickets. 1558 If a renewable ticket is not renewed by its expiration time, the KDC 1559 will not renew the ticket. The "renewable" flag is clear by default, 1560 but a client can request it be set by setting the "renewable" option 1561 in the AS-REQ message. If it is set, then the "renew-till" field in 1562 the ticket contains the time after which the ticket may not be 1563 renewed. 1565 7.2.5. Postdated Tickets 1567 postdated 1568 indicates a ticket which has been postdated 1570 may-postdate 1571 indicates that postdated tickets may be issued based on this 1572 ticket 1574 [ RFC4120 2.4. ] 1575 Applications may occasionally need to obtain tickets for use much 1576 later, e.g., a batch submission system would need tickets to be valid 1577 at the time the batch job is serviced. However, it is dangerous to 1578 hold valid tickets in a batch queue, since they will be on-line 1579 longer and more prone to theft. Postdated tickets provide a way to 1580 obtain these tickets from the KDC at job submission time, but to 1581 leave them "dormant" until they are activated and validated by a 1582 further request of the KDC. If a ticket theft were reported in the 1583 interim, the KDC would refuse to validate the ticket, and the thief 1584 would be foiled. 1586 The "may-postdate" flag in a ticket is normally only interpreted by 1587 the TGS. It can be ignored by application servers. This flag MUST 1588 be set in a ticket-granting ticket in order for the KDC to issue a 1589 postdated ticket based on the presented ticket. It is reset by 1590 default; it MAY be requested by a client by setting the "allow- 1591 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag 1592 does not allow a client to obtain a postdated ticket-granting ticket; 1593 postdated ticket-granting tickets can only by obtained by requesting 1594 the postdating in the AS-REQ message. The life (endtime minus 1595 starttime) of a postdated ticket will be the remaining life of the 1596 ticket-granting ticket at the time of the request, unless the 1597 "renewable" option is also set, in which case it can be the full life 1598 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY 1599 limit how far in the future a ticket may be postdated. 1601 The "postdated" flag indicates that a ticket has been postdated. The 1602 application server can check the authtime field in the ticket to see 1603 when the original authentication occurred. Some services MAY choose 1604 to reject postdated tickets, or they may only accept them within a 1605 certain period after the original authentication. When the KDC 1606 issues a "postdated" ticket, it will also be marked as "invalid", so 1607 that the application client MUST present the ticket to the KDC for 1608 validation before use. 1610 7.2.6. Proxiable and Proxy Tickets 1612 proxy 1613 indicates a proxy ticket 1615 proxiable 1616 indicates that proxy tickets may be issued based on this ticket 1618 [ RFC4120 2.5. ] 1620 It may be necessary for a principal to allow a service to perform an 1621 operation on its behalf. The service must be able to take on the 1622 identity of the client, but only for a particular purpose. A 1623 principal can allow a service to take on the principal's identity for 1624 a particular purpose by granting it a proxy. 1626 The process of granting a proxy using the "proxy" and "proxiable" 1627 flags is used to provide credentials for use with specific services. 1628 Though conceptually also a proxy, users wishing to delegate their 1629 identity in a form usable for all purposes MUST use the ticket 1630 forwarding mechanism described in the next section to forward a 1631 ticket-granting ticket. 1633 The "proxiable" flag in a ticket is normally only interpreted by the 1634 ticket-granting service. It can be ignored by application servers. 1635 When set, this flag tells the ticket-granting server that it is OK to 1636 issue a new ticket (but not a ticket-granting ticket) with a 1637 different network address based on this ticket. This flag is set if 1638 requested by the client on initial authentication. By default, the 1639 client will request that it be set when requesting a ticket-granting 1640 ticket, and reset when requesting any other ticket. 1642 This flag allows a client to pass a proxy to a server to perform a 1643 remote request on its behalf (e.g. a print service client can give 1644 the print server a proxy to access the client's files on a particular 1645 file server in order to satisfy a print request). 1647 In order to complicate the use of stolen credentials, Kerberos 1648 tickets may contain a set of network addresses from which they are 1649 valid. When granting a proxy, the client MUST specify the new 1650 network address from which the proxy is to be used, or indicate that 1651 the proxy is to be issued for use from any address. 1653 The "proxy" flag is set in a ticket by the TGS when it issues a proxy 1654 ticket. Application servers MAY check this flag and at their option 1655 they MAY require additional authentication from the agent presenting 1656 the proxy in order to provide an audit trail. 1658 7.2.7. Forwarded and Forwardable Tickets 1660 forwarded 1661 indicates a forwarded ticket 1663 forwardable 1664 indicates that forwarded tickets may be issued based on this 1665 ticket 1667 [ RFC4120 2.6. ] 1669 Authentication forwarding is an instance of a proxy where the service 1670 that is granted is complete use of the client's identity. An example 1671 where it might be used is when a user logs in to a remote system and 1672 wants authentication to work from that system as if the login were 1673 local. 1675 The "forwardable" flag in a ticket is normally only interpreted by 1676 the ticket-granting service. It can be ignored by application 1677 servers. The "forwardable" flag has an interpretation similar to 1678 that of the "proxiable" flag, except ticket-granting tickets may also 1679 be issued with different network addresses. This flag is reset by 1680 default, but users MAY request that it be set by setting the 1681 "forwardable" option in the AS request when they request their 1682 initial ticket-granting ticket. 1684 This flag allows for authentication forwarding without requiring the 1685 user to enter a password again. If the flag is not set, then 1686 authentication forwarding is not permitted, but the same result can 1687 still be achieved if the user engages in the AS exchange specifying 1688 the requested network addresses and supplies a password. 1690 The "forwarded" flag is set by the TGS when a client presents a 1691 ticket with the "forwardable" flag set and requests a forwarded 1692 ticket by specifying the "forwarded" KDC option and supplying a set 1693 of addresses for the new ticket. It is also set in all tickets 1694 issued based on tickets with the "forwarded" flag set. Application 1695 servers may choose to process "forwarded" tickets differently than 1696 non-forwarded tickets. 1698 If addressless tickets are forwarded from one system to another, 1699 clients SHOULD still use this option to obtain a new TGT in order to 1700 have different session keys on the different systems. 1702 7.3. Transited Realms 1704 [ RFC4120 2.7., plus new stuff ] 1706 7.4. Authorization Data 1708 [ RFC4120 5.2.6. ] 1710 ADType ::= TH-id 1712 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1713 ad-type [0] ADType, 1714 ad-data [1] OCTET STRING 1715 } 1717 ad-type 1718 This field identifies the contents of the ad-data. All negative 1719 values are reserved for local use. Non-negative values are 1720 reserved for registered use. 1722 ad-data 1723 This field contains authorization data to be interpreted 1724 according to the value of the corresponding ad-type field. 1726 Each sequence of ADType and OCTET STRING is referred to as an 1727 authorization element. Elements MAY be application specific, 1728 however, there is a common set of recursive elements that should be 1729 understood by all implementations. These elements contain other 1730 AuthorizationData, and the interpretation of the encapsulating 1731 element determines which enclosed elements must be interpreted, and 1732 which may be ignored. 1734 Depending on the meaning of the encapsulating element, the 1735 encapsulated AuthorizationData may be ignored, interpreted as issued 1736 directly by the KDC, or be stored in a separate plaintext part of the 1737 ticket. The types of the encapsulating elements are specified as 1738 part of the Kerberos protocol because behavior based on these 1739 container elements should be understood across implementations, while 1740 other elements need only be understood by the applications which they 1741 affect. 1743 Authorization data elements are considered critical if present in a 1744 ticket or authenticator. Unless encapsulated in a known 1745 authorization data element modifying the criticality of the elements 1746 it contains, an application server MUST reject the authentication of 1747 a client whose AP-REQ or ticket contains an unrecognized 1748 authorization data element. Authorization data is intended to 1749 restrict the use of a ticket. If the service cannot determine 1750 whether it is the target of a restriction, a security weakness may 1751 exist if the ticket can be used for that service. Authorization 1752 elements that are truly optional can be enclosed in AD-IF-RELEVANT 1753 element. 1755 ad-type | contents of ad-data 1756 ________|_______________________________________ 1757 1 | DER encoding of AD-IF-RELEVANT 1758 4 | DER encoding of AD-KDCIssued 1759 5 | DER encoding of AD-AND-OR 1760 8 | DER encoding of AD-MANDATORY-FOR-KDC 1762 7.4.1. AD-IF-RELEVANT 1764 ad-if-relevant ADType ::= int32 : 1 1766 -- Encapsulates another AuthorizationData. 1767 -- Intended for application servers; receiving application 1768 -- servers MAY ignore. 1769 AD-IF-RELEVANT ::= AuthorizationData 1771 AD elements encapsulated within the if-relevant element are intended 1772 for interpretation only by application servers that understand the 1773 particular ad-type of the embedded element. Application servers that 1774 do not understand the type of an element embedded within the if- 1775 relevant element MAY ignore the uninterpretable element. This element 1776 promotes interoperability across implementations which may have local 1777 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). 1779 7.4.2. AD-KDCIssued 1781 -- KDC-issued privilege attributes 1782 ad-kdcissued ADType ::= int32 : 4 1784 AD-KDCIssued ::= SEQUENCE { 1785 ad-checksum [0] ChecksumOf { 1786 AuthorizationData, { key-session }, 1787 { ku-ad-KDCIssued-cksum }}, 1788 i-realm [1] Realm OPTIONAL, 1789 i-sname [2] PrincipalName OPTIONAL, 1790 elements [3] AuthorizationData 1791 } 1793 ad-checksum 1794 A cryptographic checksum computed over the DER encoding of the 1795 AuthorizationData in the "elements" field, keyed with the 1796 session key. Its checksumtype is the mandatory checksum type 1797 for the encryption type of the session key, and its key usage 1798 value is 19. 1800 i-realm, i-sname 1801 The name of the issuing principal if different from the KDC 1802 itself. This field would be used when the KDC can verify the 1803 authenticity of elements signed by the issuing principal and it 1804 allows this KDC to notify the application server of the validity 1805 of those elements. 1807 elements 1808 AuthorizationData issued by the KDC. 1810 The KDC-issued ad-data field is intended to provide a means for 1811 Kerberos credentials to embed within themselves privilege attributes 1812 and other mechanisms for positive authorization, amplifying the 1813 privileges of the principal beyond what it would have if using 1814 credentials without such an authorization-data element. 1816 This amplification of privileges cannot be provided without this 1817 element because the definition of the authorization-data field allows 1818 elements to be added at will by the bearer of a TGT at the time that 1819 they request service tickets and elements may also be added to a 1820 delegated ticket by inclusion in the authenticator. 1822 For KDC-issued elements this is prevented because the elements are 1823 signed by the KDC by including a checksum encrypted using the 1824 server's key (the same key used to encrypt the ticket -- or a key 1825 derived from that key). AuthorizationData encapsulated with in the 1826 AD-KDCIssued element MUST be ignored by the application server if 1827 this "signature" is not present. Further, AuthorizationData 1828 encapsulated within this element from a ticket-granting ticket MAY be 1829 interpreted by the KDC, and used as a basis according to policy for 1830 including new signed elements within derivative tickets, but they 1831 will not be copied to a derivative ticket directly. If they are 1832 copied directly to a derivative ticket by a KDC that is not aware of 1833 this element, the signature will not be correct for the application 1834 ticket elements, and the field will be ignored by the application 1835 server. 1837 This element and the elements it encapsulates MAY be safely ignored 1838 by applications, application servers, and KDCs that do not implement 1839 this element. 1841 The ad-type for AD-KDC-ISSUED is (4). 1843 7.4.3. AD-AND-OR 1845 ad-and-or ADType ::= int32 : 5 1847 AD-AND-OR ::= SEQUENCE { 1848 condition-count [0] Int32, 1849 elements [1] AuthorizationData 1850 } 1852 When restrictive AD elements are encapsulated within the and-or 1853 element, the and-or element is considered satisfied if and only if at 1854 least the number of encapsulated elements specified in condition- 1855 count are satisfied. Therefore, this element MAY be used to 1856 implement an "or" operation by setting the condition-count field to 1857 1, and it MAY specify an "and" operation by setting the condition 1858 count to the number of embedded elements. Application servers that do 1859 not implement this element MUST reject tickets that contain 1860 authorization data elements of this type. 1862 The ad-type for AD-AND-OR is (5). 1864 7.4.4. AD-MANDATORY-FOR-KDC 1866 -- KDCs MUST interpret any AuthorizationData wrapped in this. 1867 ad-mandatory-for-kdc ADType ::= int32 : 8 1868 AD-MANDATORY-FOR-KDC ::= AuthorizationData 1870 AD elements encapsulated within the mandatory-for-kdc element are to 1871 be interpreted by the KDC. KDCs that do not understand the type of 1872 an element embedded within the mandatory-for-kdc element MUST reject 1873 the request. 1875 The ad-type for AD-MANDATORY-FOR-KDC is (8). 1877 7.5. Encrypted Part of Ticket 1879 The complete definition of the encrypted part is 1881 -- Encrypted part of ticket 1882 EncTicketPart ::= CHOICE { 1883 rfc1510 EncTicketPart1510, 1884 ext EncTicketPartExt 1885 } 1887 The encrypted part of the backwards-compatibility form of a ticket 1888 is: 1890 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { 1891 flags [0] TicketFlags, 1892 key [1] EncryptionKey, 1893 crealm [2] RealmIA5, 1894 cname [3] PrincipalNameIA5, 1895 transited [4] TransitedEncoding, 1896 authtime [5] KerberosTime, 1897 starttime [6] KerberosTime OPTIONAL, 1898 endtime [7] KerberosTime, 1899 renew-till [8] KerberosTime OPTIONAL, 1900 caddr [9] HostAddresses OPTIONAL, 1901 authorization-data [10] AuthorizationData OPTIONAL 1902 } 1904 The encrypted part of the extensible form of a ticket is: 1906 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { 1907 flags [0] TicketFlags, 1908 key [1] EncryptionKey, 1909 crealm [2] RealmExt, 1910 cname [3] PrincipalNameExt, 1911 transited [4] TransitedEncoding, 1912 authtime [5] KerberosTime, 1913 starttime [6] KerberosTime OPTIONAL, 1914 endtime [7] KerberosTime, 1915 renew-till [8] KerberosTime OPTIONAL, 1916 caddr [9] HostAddresses OPTIONAL, 1917 authorization-data [10] AuthorizationData OPTIONAL, 1918 ..., 1919 } 1921 7.6. Cleartext Part of Ticket 1923 The complete definition of Ticket is: 1925 Ticket ::= CHOICE { 1926 rfc1510 Ticket1510, 1927 ext TicketExt 1928 } 1930 The "sname" field provides the name of the target service principal 1931 in cleartext, as a hint to aid the server in choosing the correct 1932 decryption key. 1934 The backwards-compatibility form of Ticket is: 1936 Ticket1510 ::= [APPLICATION 1] SEQUENCE { 1937 tkt-vno [0] INTEGER (5), 1938 realm [1] RealmIA5, 1939 sname [2] PrincipalNameIA5, 1940 enc-part [3] EncryptedData { 1941 EncTicketPart1510, { key-server }, { ku-Ticket } 1942 } 1943 } 1945 The extensible form of Ticket is: 1947 TicketExt ::= [APPLICATION 4] Signed { 1948 [APPLICATION 4] SEQUENCE { 1949 tkt-vno [0] INTEGER (5), 1950 realm [1] RealmExt, 1951 sname [2] PrincipalNameExt, 1952 enc-part [3] EncryptedData { 1953 EncTicketPartExt, { key-server }, { ku-Ticket } 1954 }, 1955 ..., 1956 extensions [4] TicketExtensions OPTIONAL, 1957 ... 1958 }, 1959 { key-ticket }, { ku-Ticket-cksum } 1960 } 1962 TicketExtensions, which may only be present in the extensible form of 1963 Ticket, are a cleartext typed hole for extension use. 1964 AuthorizationData already provides an encrypted typed hole. 1966 TEType ::= TH-id 1968 -- ticket extensions: for TicketExt only 1969 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 1970 te-type [0] TEType, 1971 te-data [1] OCTET STRING 1972 } 1974 A client will only receive an extensible Ticket if the application 1975 server supports extensibility. 1977 8. Credential Acquisition 1979 There are two exchanges that can be used for acquiring credentials: 1980 the AS exchange and the TGS exchange. These exchanges have many 1981 similarities, and this document describes them in parallel, noting 1982 which behaviors are specific to one type of exchange. The AS request 1983 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests 1984 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) 1985 are forms of KDC replies (KDC-REP). 1987 The credentials acquisition protocol operates over specific 1988 transports. Additionally, specific methods exist to permit a client 1989 to discover the KDC host with which to communicate. 1991 8.1. KDC-REQ 1993 The KDC-REQ has a large number of fields in common between the RFC 1994 1510 and the extensible versions. The KDC-REQ type itself is never 1995 directly encoded; it is always a part of a AS-REQ or a TGS-REQ. 1997 KDC-REQ-1510 ::= SEQUENCE { 1998 -- NOTE: first tag is [1], not [0] 1999 pvno [1] INTEGER (5), 2000 msg-type [2] INTEGER ( 10 -- AS-REQ -- 2001 | 12 -- TGS-REQ -- ), 2002 padata [3] SEQUENCE OF PA-DATA OPTIONAL, 2003 req-body [4] KDC-REQ-BODY-1510 2004 } 2005 KDC-REQ-EXT ::= SEQUENCE { 2006 pvno [1] INTEGER (5), 2007 msg-type [2] INTEGER ( 6 -- AS-REQ -- 2008 | 8 -- TGS-REQ -- ), 2009 padata [3] SEQUENCE (SIZE (1..MAX)) 2010 OF PA-DATA OPTIONAL, 2011 req-body [4] KDC-REQ-BODY-EXT, 2012 ... 2013 } 2015 KDC-REQ-BODY-1510 ::= SEQUENCE { 2016 kdc-options [0] KDCOptions, 2017 cname [1] PrincipalNameIA5 OPTIONAL 2018 -- Used only in AS-REQ --, 2020 realm [2] RealmIA5 2021 -- Server's realm; also client's in AS-REQ --, 2023 sname [3] PrincipalNameIA5 OPTIONAL, 2024 from [4] KerberosTime OPTIONAL, 2025 till [5] KerberosTime, 2026 rtime [6] KerberosTime OPTIONAL, 2027 nonce [7] Nonce32, 2028 etype [8] SEQUENCE OF EType 2029 -- in preference order --, 2031 addresses [9] HostAddresses OPTIONAL, 2032 enc-authorization-data [10] EncryptedData { 2033 AuthorizationData, { key-session | key-subsession }, 2034 { ku-TGSReqAuthData-subkey | 2035 ku-TGSReqAuthData-sesskey } 2036 } OPTIONAL, 2038 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2039 -- NOTE: not empty -- 2040 } 2041 KDC-REQ-BODY-EXT ::= SEQUENCE { 2042 kdc-options [0] KDCOptions, 2043 cname [1] PrincipalName OPTIONAL 2044 -- Used only in AS-REQ --, 2046 realm [2] Realm 2047 -- Server's realm; also client's in AS-REQ --, 2049 sname [3] PrincipalName OPTIONAL, 2050 from [4] KerberosTime OPTIONAL, 2051 till [5] KerberosTime OPTIONAL 2052 -- was required in rfc1510; 2053 -- still required for compat versions 2054 -- of messages --, 2056 rtime [6] KerberosTime OPTIONAL, 2057 nonce [7] Nonce, 2058 etype [8] SEQUENCE OF EType 2059 -- in preference order --, 2061 addresses [9] HostAddresses OPTIONAL, 2062 enc-authorization-data [10] EncryptedData { 2063 AuthorizationData, { key-session | key-subsession }, 2064 { ku-TGSReqAuthData-subkey | 2065 ku-TGSReqAuthData-sesskey } 2066 } OPTIONAL, 2068 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2069 -- NOTE: not empty --, 2070 ... 2071 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 2072 LangTag OPTIONAL, 2073 ... 2074 } 2076 Many fields of KDC-REQ-BODY correspond directly to fields of an 2077 EncTicketPart. The KDC copies most of them unchanged, provided that 2078 the requested values meet site policy. 2080 kdc-options 2081 These flags do not correspond directly to "flags" in 2082 EncTicketPart. 2084 cname 2085 This field is copied to the "cname" field in EncTicketPart. The 2086 "cname" field is required in an AS-REQ; the client places its 2087 own name here. In a TGS-REQ, the "cname" in the ticket in the 2088 AP-REQ takes precedence. 2090 realm 2091 This field is the server's realm, and also holds the client's 2092 realm in an AS-REQ. 2094 sname 2095 The "sname" field indicates the server's name. It may be absent 2096 in a TGS-REQ which requests user-to-user authentication, in 2097 which case the "sname" of the issued ticket will be taken from 2098 the included additional ticket. 2100 The "from", "till", and "rtime" fields correspond to the "starttime", 2101 "endtime", and "renew-till" fields of EncTicketPart. 2103 addresses 2104 This field corresponds to the "caddr" field of EncTicketPart. 2106 enc-authorization-data 2107 For TGS-REQ, this field contains authorization data encrypted 2108 using either the TGT session key or the AP-REQ subsession key; 2109 the KDC may copy these into the "authorization-data" field of 2110 EncTicketPart if policy permits. 2112 lang-tags 2113 Only present in the extensible messages. Specifies the set of 2114 languages which the client is willing to accept in error 2115 messages. 2117 KDC options used in a KDC-REQ are: 2119 KDCOptions ::= KerberosFlags { KDCOptionsBits } 2121 KDCOptionsBits ::= BIT STRING { 2122 reserved (0), 2123 forwardable (1), 2124 forwarded (2), 2125 proxiable (3), 2126 proxy (4), 2127 allow-postdate (5), 2128 postdated (6), 2129 unused7 (7), 2130 renewable (8), 2131 unused9 (9), 2132 unused10 (10), 2133 unused11 (11), 2134 unused12 (12), 2135 unused13 (13), 2136 requestanonymous (14), 2137 canonicalize (15), 2138 disable-transited-check (26), 2139 renewable-ok (27), 2140 enc-tkt-in-skey (28), 2141 renew (30), 2142 validate (31) 2143 -- XXX need "need ticket1" flag? 2144 } 2146 Different options apply to different phases of KDC-REQ processing. 2148 The backwards-compatibility form of a KDC-REQ is: 2150 KDC-REQ-1510 ::= SEQUENCE { 2151 -- NOTE: first tag is [1], not [0] 2152 pvno [1] INTEGER (5), 2153 msg-type [2] INTEGER ( 10 -- AS-REQ -- 2154 | 12 -- TGS-REQ -- ), 2155 padata [3] SEQUENCE OF PA-DATA OPTIONAL, 2156 req-body [4] KDC-REQ-BODY-1510 2157 } 2159 The extensible form of a KDC-REQ is: 2161 KDC-REQ-EXT ::= SEQUENCE { 2162 pvno [1] INTEGER (5), 2163 msg-type [2] INTEGER ( 6 -- AS-REQ -- 2164 | 8 -- TGS-REQ -- ), 2165 padata [3] SEQUENCE (SIZE (1..MAX)) 2166 OF PA-DATA OPTIONAL, 2167 req-body [4] KDC-REQ-BODY-EXT, 2168 ... 2169 } 2171 The backwards-compatibility form of a KDC-REQ-BODY is: 2173 KDC-REQ-BODY-1510 ::= SEQUENCE { 2174 kdc-options [0] KDCOptions, 2175 cname [1] PrincipalNameIA5 OPTIONAL 2176 -- Used only in AS-REQ --, 2178 realm [2] RealmIA5 2179 -- Server's realm; also client's in AS-REQ --, 2181 sname [3] PrincipalNameIA5 OPTIONAL, 2182 from [4] KerberosTime OPTIONAL, 2183 till [5] KerberosTime, 2184 rtime [6] KerberosTime OPTIONAL, 2185 nonce [7] Nonce32, 2186 etype [8] SEQUENCE OF EType 2187 -- in preference order --, 2189 addresses [9] HostAddresses OPTIONAL, 2190 enc-authorization-data [10] EncryptedData { 2191 AuthorizationData, { key-session | key-subsession }, 2192 { ku-TGSReqAuthData-subkey | 2193 ku-TGSReqAuthData-sesskey } 2194 } OPTIONAL, 2196 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2197 -- NOTE: not empty -- 2198 } 2200 The extensible form of a KDC-REQ-BODY is: 2202 KDC-REQ-BODY-EXT ::= SEQUENCE { 2203 kdc-options [0] KDCOptions, 2204 cname [1] PrincipalName OPTIONAL 2205 -- Used only in AS-REQ --, 2207 realm [2] Realm 2208 -- Server's realm; also client's in AS-REQ --, 2210 sname [3] PrincipalName OPTIONAL, 2211 from [4] KerberosTime OPTIONAL, 2212 till [5] KerberosTime OPTIONAL 2213 -- was required in rfc1510; 2214 -- still required for compat versions 2215 -- of messages --, 2217 rtime [6] KerberosTime OPTIONAL, 2218 nonce [7] Nonce, 2219 etype [8] SEQUENCE OF EType 2220 -- in preference order --, 2222 addresses [9] HostAddresses OPTIONAL, 2223 enc-authorization-data [10] EncryptedData { 2224 AuthorizationData, { key-session | key-subsession }, 2225 { ku-TGSReqAuthData-subkey | 2226 ku-TGSReqAuthData-sesskey } 2227 } OPTIONAL, 2229 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2230 -- NOTE: not empty --, 2231 ... 2232 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 2233 LangTag OPTIONAL, 2234 ... 2235 } 2237 The AS-REQ is: 2239 AS-REQ ::= CHOICE { 2240 rfc1510 AS-REQ-1510, 2241 ext AS-REQ-EXT 2242 } 2243 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 2244 -- AS-REQ must include client name 2246 AS-REQ-EXT ::= [APPLICATION 6] Signed { 2247 [APPLICATION 6] KDC-REQ-EXT, 2248 { key-client }, { ku-ASReq-cksum } 2249 } 2250 -- AS-REQ must include client name 2252 A client SHOULD NOT send the extensible AS-REQ alternative to a KDC 2253 if the client does not know that the KDC supports the extensibility 2254 framework. A client SHOULD send the extensible AS-REQ alternative in 2255 a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the 2256 AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX 2257 what if their contents conflict? ] 2259 The TGS-REQ is: 2261 TGS-REQ ::= CHOICE { 2262 rfc1510 TGS-REQ-1510, 2263 ext TGS-REQ-EXT 2264 } 2266 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 2268 TGS-REQ-EXT ::= [APPLICATION 8] Signed { 2269 [APPLICATION 8] KDC-REQ-EXT, 2270 { key-session }, { ku-TGSReq-cksum } 2271 } 2273 8.2. PA-DATA 2275 PA-DATA have multiple uses in the Kerberos protocol. They may pre- 2276 authenticate an AS-REQ; they may also modify several of the 2277 encryption keys used in a KDC-REP. PA-DATA may also provide "hints" 2278 to the client about which long-term key (usually password-derived) to 2279 use. PA-DATA may also include "hints" about which pre-authentication 2280 mechanisms to use, or include data for input into a pre- 2281 authentication mechanism. 2283 [ XXX enumerate standard padata here ] 2285 8.3. KDC-REQ Processing 2287 Processing of a KDC-REQ proceeds through several steps. An 2288 implementation need not perform these steps exactly as described, as 2289 long as it behaves as if the steps were performed as described. The 2290 KDC performs replay handling upon receiving the request; it then 2291 validates the request, adjusts timestamps, and selects the keys used 2292 in the reply. It copies data from the request into the issued 2293 ticket, adjusting the values to conform with its policies. The KDC 2294 then transmits the reply to the client. 2296 8.3.1. Handling Replays 2298 Because Kerberos can run over unreliable transports such as UDP, the 2299 KDC MUST be prepared to retransmit responses in case they are lost. 2300 If a KDC receives a request identical to one it has recently 2301 successfully processed, the KDC MUST respond with a KDC-REP message 2302 rather than a replay error. In order to reduce the amount of 2303 ciphertext given to a potential attacker, KDCs MAY send the same 2304 response generated when the request was first handled. KDCs MUST 2305 obey this replay behavior even if the actual transport in use is 2306 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, 2307 and the entire request is not identical to a recently successfully 2308 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is 2309 appropriate for AP-REQ processing. 2311 8.3.2. Request Validation 2313 8.3.2.1. AS-REQ Authentication 2315 Site policy determines whether a given client principal is required 2316 to provide some pre-authentication prior to receiving an AS-REP. 2317 Since the default reply key is typically the client's long-term 2318 password-based key, an attacker may easily request known plaintext 2319 (in the form of an AS-REP) upon which to mount a dictionary attack. 2320 Pre-authentication can limit the possibility of such an attack. 2322 If site policy requires pre-authentication for a client principal, 2323 and no pre-authentication is provided, the KDC returns the error 2324 "kdc-err-preauth-required". Accompanying this error are "e-data" 2325 which include hints telling the client which pre-authentication 2326 mechanisms to use, or data for input to pre-authentication mechanisms 2327 (e.g., input to challenge-response systems). If pre-authentication 2328 fails, the KDC returns the error "kdc-err-preauth-failed". 2330 [ may need additional changes based on Sam's preauth draft ] 2332 8.3.2.2. TGS-REQ Authentication 2334 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- 2335 tgs-req". The KDC MUST validate the checksum in the Authenticator of 2336 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- 2337 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the 2338 request. [ padata not signed by authenticator! ] Any error from the 2339 AP-REQ validation process SHOULD be returned in a KRB-ERROR message. 2340 The service principal in the ticket of the AP-REQ may be a ticket- 2341 granting service principal, or a normal application service 2342 principal. A ticket which is not a ticket-granting ticket MUST NOT 2343 be used to issue a ticket for any service other than the one named in 2344 the ticket. In this case, the "renew", "validate", or "proxy" [?also 2345 forwarded?] option must be set in the request. 2347 8.3.2.3. Principal Validation 2349 If the client principal in an AS-REQ is unknown, the KDC returns the 2350 error "kdc-err-c-principal-unknown". If the server principal in a 2351 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- 2352 unknown". 2354 8.3.2.4. Checking For Revoked or Invalid Tickets 2356 [ RFC4120 3.3.3.1 ] 2358 Whenever a request is made to the ticket-granting server, the 2359 presented ticket(s) is(are) checked against a hot-list of tickets 2360 which have been canceled. This hot-list might be implemented by 2361 storing a range of issue timestamps for "suspect tickets"; if a 2362 presented ticket had an authtime in that range, it would be rejected. 2363 In this way, a stolen ticket-granting ticket or renewable ticket 2364 cannot be used to gain additional tickets (renewals or otherwise) 2365 once the theft has been reported to the KDC for the realm in which 2366 the server resides. Any normal ticket obtained before it was 2367 reported stolen will still be valid (because they require no 2368 interaction with the KDC), but only until their normal expiration 2369 time. If TGTs have been issued for cross-realm authentication, use 2370 of the cross-realm TGT will not be affected unless the hot-list is 2371 propagated to the KDCs for the realms for which such cross-realm 2372 tickets were issued. 2374 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT 2375 issue any ticket unless the TGS-REQ requests the "validate" option. 2377 8.3.3. Timestamp Handling 2379 [ some aspects of timestamp handling, especially regarding postdating 2380 and renewal, are difficult to read in RFC4120... needs closer 2381 examination here ] 2383 Processing of "starttime" (requested in the "from" field) differs 2384 depending on whether the "postdated" option is set in the request. 2385 If the "postdated" option is not set, and the requested "starttime" 2386 is in the future beyond the window of acceptable clock skew, the KDC 2387 returns the error "kdc-err-cannot-postdate". If the "postdated" 2388 option is not set, and the requested "starttime" is absent or does 2389 not indicate a time in the future beyond the acceptable clock skew, 2390 the KDC sets the "starttime" to the KDC's current time. The 2391 "postdated" option MUST NOT be honored if the ticket is being 2392 requested by TGS-REQ and the "may-postdate" is not set in the TGT. 2393 Otherwise, if the "postdated" option is set, and site policy permits, 2394 the KDC sets the "starttime" as requested, and sets the "invalid" 2395 flag in the new ticket. 2397 The "till" field is required in the RFC 1510 version of the KDC-REQ. 2398 If the "till" field is equal to "19700101000000Z" (midnight, January 2399 1, 1970), the KDC SHOULD behave as if the "till" field were absent. 2401 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or 2402 "renew-till" time is later than the "renew-till" time of the ticket 2403 from which it is derived. 2405 8.3.3.1. AS-REQ Timestamp Processing 2407 In the AS exchange, the "authtime" of a ticket is set to the local 2408 time at the KDC. 2410 The "endtime" of the ticket will be set to the earlier of the 2411 requested "till" time and a time determined by local policy, possibly 2412 determined using factors specific to the realm or principal. For 2413 example, the expiration time MAY be set to the earliest of the 2414 following: 2416 * the expiration time ("till" value) requested 2418 * the ticket's start time plus the maximum allowable lifetime 2419 associated with the client principal from the authentication 2420 server's database 2422 * the ticket's start time plus the maximum allowable lifetime 2423 associated with the server principal 2425 * the ticket's start time plus the maximum lifetime set by the 2426 policy of the local realm 2428 If the requested expiration time minus the start time (as determined 2429 above) is less than a site-determined minimum lifetime, an error 2430 message with code "kdc-err-never-valid" is returned. If the 2431 requested expiration time for the ticket exceeds what was determined 2432 as above, and if the "renewable-ok" option was requested, then the 2433 "renewable" flag is set in the new ticket, and the "renew-till" value 2434 is set as if the "renewable" option were requested. 2436 If the "renewable" option has been requested or if the "renewable-ok" 2437 option has been set and a renewable ticket is to be issued, then the 2438 "renew-till" field MAY be set to the earliest of: 2440 * its requested value 2442 * the start time of the ticket plus the minimum of the two maximum 2443 renewable lifetimes associated with the principals' database 2444 entries 2446 * the start time of the ticket plus the maximum renewable lifetime 2447 set by the policy of the local realm 2449 8.3.3.2. TGS-REQ Timestamp Processing 2451 In the TGS exchange, the KDC sets the "authtime" to that of the 2452 ticket in the AP-REQ authenticating the TGS-REQ. [?application 2453 server can print a ticket for itself with a spoofed authtime. 2454 security issues for hot-list?] [ MIT implementation may change 2455 authtime of renewed tickets; needs check... ] 2456 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ 2457 requests an "endtime" (in the "till" field), then the "endtime" of 2458 the new ticket is set to the minimum of 2460 * the requested "endtime" value, 2462 * the "endtime" in the TGT, and 2464 * an "endtime" determined by site policy on ticket lifetimes. 2466 If the new ticket is a renewal, the "endtime" of the new ticket is 2467 bounded by the minimum of 2469 * the requested "endtime" value, 2471 * the value of the "renew-till" value of the old, 2473 * the "starttime" of the new ticket plus the lifetime (endtime 2474 minus starttime) of the old ticket, i.e., the lifetime of the 2475 new ticket may not exceed that of the ticket being renewed [ 2476 adapted from RFC4120 3.3.3. ], and 2478 * an "endtime" determined by site policy on ticket lifetimes. 2480 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with 2481 a "starttime", "endtime", or "renew-till" time later than the 2482 "renew-till" time of the TGT. 2484 8.3.4. Handling Transited Realms 2486 The KDC checks the ticket in a TGS-REQ against site policy, unless 2487 the "disable-transited-check" option is set in the TGS-REQ. If site 2488 policy permits the transit path in the TGS-REQ ticket, the KDC sets 2489 the "transited-policy-checked" flag in the issued ticket. If the 2490 "disable-transited-check" option is set, the issued ticket will have 2491 the "transited-policy-checked" flag cleared. 2493 8.3.5. Address Processing The requested "addresses" in the KDC-REQ are 2494 copied into the issued ticket. If the "addresses" field is absent or 2495 empty in a TGS-REQ, the KDC copies addresses from the ticket in the 2496 TGS-REQ into the issued ticket, unless the either "forwarded" or 2497 "proxy" option is set. If the "forwarded" option is set, and the 2498 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies 2499 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the 2500 issued ticket. The KDC behaves similarly if the "proxy" option is 2501 set in the TGS-REQ and the "proxiable" flag is set in the ticket. 2502 The "proxy" option will not be honored on requests for additional 2503 ticket-granting tickets. 2505 8.3.6. Ticket Flag Processing 2507 Many kdc-options request that the KDC set a corresponding flag in the 2508 issued ticket. kdc-options marked with an asterisk (*) in the 2509 following table do not directly request the corresponding ticket flag 2510 and therefore require special handling. 2512 kdc-option | ticket flag affected 2513 ________________________|__________________________ 2514 forwardable | forwardable 2515 forwarded | forwarded 2516 proxiable | proxiable 2517 proxy | proxy 2518 allow-postdate | may-postdate 2519 postdated | postdated 2520 renewable | renewable 2521 requestanonymous | anonymous 2522 canonicalize | - 2523 disable-transited-check*| transited-policy-checked 2524 renewable-ok* | renewable 2525 enc-tkt-in-skey | - 2526 renew | - 2527 validate* | invalid 2529 forwarded 2530 The KDC sets the "forwarded" flag in the issued ticket if the 2531 "forwarded" option is set in the TGS-REQ and the "forwardable" 2532 flag is set in the TGS-REQ ticket. 2534 proxy 2535 The KDC sets the "proxy" flag in the issued ticket if the 2536 "proxy" option is set in the TGS-REQ and the "proxiable" flag is 2537 set in the TGS-REQ ticket. 2539 disable-transited-check 2540 The handling of the "disable-transited-check" kdc-option is 2541 described in Section 8.3.4. 2543 renewable-ok 2544 The handling of the "renewable-ok" kdc-option is described in 2545 Section 8.3.3.1. 2547 enc-tkt-in-skey 2548 This flag modifies ticket key selection to use the session key 2549 of an additional ticket included in the TGS-REQ, for the purpose 2550 of user-to-user authentication. 2552 validate 2553 If the "validate" kdc-option is set in a TGS-REQ, and the 2554 "starttime" has passed, the KDC will clear the "invalid" bit on 2555 the ticket before re-issuing it. 2557 8.3.7. Key Selection 2559 Three keys are involved in creating a KDC-REP. The reply key 2560 encrypts the encrypted part of the KDC-REP. The session key is 2561 stored in the encrypted part of the ticket, and is also present in 2562 the encrypted part of the KDC-REP so that the client can retrieve it. 2563 The ticket key is used to encrypt the ticket. These keys all have 2564 initial values for a given exchange; pre-authentication and other 2565 extension mechanisms may change the value used for any of these keys. 2567 [ again, may need changes based on Sam's preauth draft ] 2569 8.3.7.1. Reply Key and Session Key Selection 2571 The set of encryption types which the client will understand appears 2572 in the "etype" field of KDC-REQ-BODY. The KDC limits the set of 2573 possible reply keys and the set of session key encryption types based 2574 on the "etype" field. 2576 For the AS exchange, the reply key is initially a long-term key of 2577 the client, limited to those encryption types listed in the "etype" 2578 field. The KDC SHOULD use the first valid strong "etype" for which 2579 an encryption key is available. For the TGS exchange, the reply key 2580 is initially the subsession key of the Authenticator. If the 2581 Authenticator subsesion key is absent, the reply key is initially the 2582 session key of the ticket used to authenticate the TGS-REQ. 2584 The session key is initially randomly generated, and has an 2585 encryption type which both the client and the server will understand. 2586 Typically, the KDC has prior knowledge of which encryption types the 2587 server will understand. It selects the first valid strong "etype" 2588 listed the request which the server also will understand. 2590 8.3.7.2. Ticket Key Selection 2592 The ticket key is initially the long-term key of the service. The 2593 "enc-tkt-in-skey" option requests user-to-user authentication, where 2594 the ticket encryption key of the issued ticket is set equal to the 2595 session key of the additional ticket in the request. 2597 8.4. KDC-REP 2599 The important parts of the KDC-REP are encrypted. 2601 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 2602 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 2604 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 2605 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 2607 EncKDCRepPart1510 ::= SEQUENCE { 2608 key [0] EncryptionKey, 2609 last-req [1] LastReq, 2610 nonce [2] Nonce32, 2611 key-expiration [3] KerberosTime OPTIONAL, 2612 flags [4] TicketFlags, 2613 authtime [5] KerberosTime, 2614 starttime [6] KerberosTime OPTIONAL, 2615 endtime [7] KerberosTime, 2616 renew-till [8] KerberosTime OPTIONAL, 2617 srealm [9] RealmIA5, 2618 sname [10] PrincipalNameIA5, 2619 caddr [11] HostAddresses OPTIONAL 2620 } 2622 EncKDCRepPartExt ::= SEQUENCE { 2623 key [0] EncryptionKey, 2624 last-req [1] LastReq, 2625 nonce [2] Nonce, 2626 key-expiration [3] KerberosTime OPTIONAL, 2627 flags [4] TicketFlags, 2628 authtime [5] KerberosTime, 2629 starttime [6] KerberosTime OPTIONAL, 2630 endtime [7] KerberosTime, 2631 renew-till [8] KerberosTime OPTIONAL, 2632 srealm [9] Realm, 2633 sname [10] PrincipalName, 2634 caddr [11] HostAddresses OPTIONAL, 2635 ... 2636 } 2638 Most of the fields of EncKDCRepPartCom are duplicates of the 2639 corresponding fields in the returned ticket. 2641 KDC-REP-1510 { EncPart } ::= SEQUENCE { 2642 pvno [0] INTEGER (5), 2643 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 2644 13 -- TGS.rfc1510 -- ), 2645 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 2646 crealm [3] RealmIA5, 2647 cname [4] PrincipalNameIA5, 2648 ticket [5] Ticket, 2650 enc-part [6] EncryptedData { 2651 EncPart, 2652 { key-reply }, 2653 -- maybe reach into EncryptedData in AS-REP/TGS-REP 2654 -- definitions to apply constraints on key usages? 2655 { ku-EncASRepPart -- if AS-REP -- | 2656 ku-EncTGSRepPart-subkey -- if TGS-REP and 2657 -- using Authenticator 2658 -- session key -- | 2659 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 2660 -- subsession key -- } 2661 } 2662 } 2663 KDC-REP-EXT { EncPart } ::= SEQUENCE { 2664 pvno [0] INTEGER (5), 2665 msg-type [1] INTEGER (7 -- AS-REP.ext -- | 2666 9 -- TGS-REP.ext -- ), 2667 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 2668 crealm [3] RealmExt, 2669 cname [4] PrincipalNameExt, 2670 ticket [5] Ticket, 2672 enc-part [6] EncryptedData { 2673 EncPart, 2674 { key-reply }, 2675 -- maybe reach into EncryptedData in AS-REP/TGS-REP 2676 -- definitions to apply constraints on key usages? 2677 { ku-EncASRepPart -- if AS-REP -- | 2678 ku-EncTGSRepPart-subkey -- if TGS-REP and 2679 -- using Authenticator 2680 -- session key -- | 2681 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 2682 -- subsession key -- } 2683 }, 2685 ..., 2686 -- In extensible version, KDC signs original request 2687 -- to avoid replay attacks against client. 2688 req-cksum [7] ChecksumOf { CHOICE { 2689 as-req AS-REQ, 2690 tgs-req TGS-REQ 2691 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 2692 lang-tag [8] LangTag OPTIONAL, 2693 ... 2694 } 2696 req-cksum 2697 Signature of the original request using the reply key, to avoid 2698 replay attacks against the client, among other things. Only 2699 present in the extensible version of KDC-REP. 2701 AS-REP ::= CHOICE { 2702 rfc1510 AS-REP-1510, 2703 ext AS-REP-EXT 2704 } 2705 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 2706 AS-REP-EXT ::= [APPLICATION 7] Signed { 2707 [APPLICATION 7] KDC-REP-EXT, 2708 { key-reply }, { ku-ASRep-cksum } 2709 } 2710 TGS-REP ::= CHOICE { 2711 rfc1510 TGS-REP-1510, 2712 ext TGS-REP-EXT 2713 } 2714 TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { 2715 EncTGSRepPart1510 } 2717 TGS-REP-EXT ::= [APPLICATION 9] Signed { 2718 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 2719 { key-reply }, { ku-TGSRep-cksum } 2720 } 2722 The extensible versions of AS-REQ and TGS-REQ are signed with the 2723 reply key, to prevent an attacker from performing a delayed denial- 2724 of-service attack by substituting the ticket. 2726 8.5. Reply Validation 2728 [ signature verification ] 2730 8.6. IP Transports 2732 [ RFC4120 7.2 ] 2734 Kerberos defines two IP transport mechanisms for the credentials 2735 acquisition protocol: UDP/IP and TCP/IP. 2737 8.6.1. UDP/IP transport 2739 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 2740 requests and SHOULD listen for such requests on port 88 (decimal) 2741 unless specifically configured to listen on an alternative UDP port. 2742 Alternate ports MAY be used when running multiple KDCs for multiple 2743 realms on the same host. 2745 Kerberos clients supporting IP transports SHOULD support the sending 2746 of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to 2747 identify the IP address and port to which they will send their 2748 request. 2750 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 2751 transport, the client shall send a UDP datagram containing only an 2752 encoding of the request to the KDC. The KDC will respond with a reply 2753 datagram containing only an encoding of the reply message (either a 2754 KRB-ERROR or a KDC-REP) to the sending port at the sender's IP 2755 address. The response to a request made through UDP/IP transport MUST 2756 also use UDP/IP transport. If the response can not be handled using 2757 UDP (for example because it is too large), the KDC MUST return "krb- 2758 err-response-too-big", forcing the client to retry the request using 2759 the TCP transport. 2761 8.6.2. TCP/IP transport 2763 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 2764 requests and SHOULD listen for such requests on port 88 (decimal) 2765 unless specifically configured to listen on an alternate TCP port. 2766 Alternate ports MAY be used when running multiple KDCs for multiple 2767 realms on the same host. 2769 Clients MUST support the sending of TCP requests, but MAY choose to 2770 initially try a request using the UDP transport. Clients SHOULD use 2771 KDC discovery (Section 8.6.3) to identify the IP address and port to 2772 which they will send their request. 2774 Implementation note: Some extensions to the Kerberos protocol will 2775 not succeed if any client or KDC not supporting the TCP transport is 2776 involved. Implementations of RFC 1510 were not required to support 2777 TCP/IP transports. 2779 When the KDC-REQ message is sent to the KDC over a TCP stream, the 2780 response (KDC-REP or KRB-ERROR message) MUST be returned to the 2781 client on the same TCP stream that was established for the request. 2782 The KDC MAY close the TCP stream after sending a response, but MAY 2783 leave the stream open for a reasonable period of time if it expects a 2784 followup. Care must be taken in managing TCP/IP connections on the 2785 KDC to prevent denial of service attacks based on the number of open 2786 TCP/IP connections. 2788 The client MUST be prepared to have the stream closed by the KDC at 2789 anytime after the receipt of a response. A stream closure SHOULD NOT 2790 be treated as a fatal error. Instead, if multiple exchanges are 2791 required (e.g., certain forms of pre-authentication) the client may 2792 need to establish a new connection when it is ready to send 2793 subsequent messages. A client MAY close the stream after receiving a 2794 response, and SHOULD close the stream if it does not expect to send 2795 followup messages. 2797 A client MAY send multiple requests before receiving responses, 2798 though it must be prepared to handle the connection being closed 2799 after the first response. 2801 Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over 2802 the TCP stream is preceded by the length of the request as 4 octets 2803 in network byte order. The high bit of the length is reserved for 2804 future expansion and MUST currently be set to zero. If a KDC that 2805 does not understand how to interpret a set high bit of the length 2806 encoding receives a request with the high order bit of the length 2807 set, it MUST return a KRB-ERROR message with the error "krb-err- 2808 field-toolong" and MUST close the TCP stream. 2810 If multiple requests are sent over a single TCP connection, and the 2811 KDC sends multiple responses, the KDC is not required to send the 2812 responses in the order of the corresponding requests. This may 2813 permit some implementations to send each response as soon as it is 2814 ready even if earlier requests are still being processed (for 2815 example, waiting for a response from an external device or database). 2817 8.6.3. KDC Discovery on IP Networks 2819 Kerberos client implementations MUST provide a means for the client 2820 to determine the location of the Kerberos Key Distribution Centers 2821 (KDCs). Traditionally, Kerberos implementations have stored such 2822 configuration information in a file on each client machine. 2823 Experience has shown this method of storing configuration information 2824 presents problems with out-of-date information and scaling problems, 2825 especially when using cross-realm authentication. This section 2826 describes a method for using the Domain Name System [RFC 1035] for 2827 storing KDC location information. 2829 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 2831 In Kerberos, realm names are case sensitive. While it is strongly 2832 encouraged that all realm names be all upper case this recommendation 2833 has not been adopted by all sites. Some sites use all lower case 2834 names and other use mixed case. DNS, on the other hand, is case 2835 insensitive for queries. Since the realm names "MYREALM", "myrealm", 2836 and "MyRealm" are all different, but resolve the same in the domain 2837 name system, it is necessary that only one of the possible 2838 combinations of upper and lower case characters be used in realm 2839 names. 2841 8.6.3.2. DNS SRV records for KDC location 2843 KDC location information is to be stored using the DNS SRV RR [RFC 2844 2782]. The format of this RR is as follows: 2846 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target 2848 The Service name for Kerberos is always "kerberos". 2850 The Proto can be one of "udp", "tcp". If these SRV records are to be 2851 used, both "udp" and "tcp" records MUST be specified for all KDC 2852 deployments. 2854 The Realm is the Kerberos realm that this record corresponds to. The 2855 realm MUST be a domain style realm name. 2857 TTL, Class, SRV, Priority, Weight, and Target have the standard 2858 meaning as defined in RFC 2782. 2860 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV 2861 records SHOULD be the value assigned to "kerberos" by the Internet 2862 Assigned Number Authority: 88 (decimal) unless the KDC is configured 2863 to listen on an alternate TCP port. 2865 Implementation note: Many existing client implementations do not 2866 support KDC Discovery and are configured to send requests to the IANA 2867 assigned port (88 decimal), so it is strongly recommended that KDCs 2868 be configured to listen on that port. 2870 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 2872 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 2873 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 2874 should be directed to kdc1.example.com first as per the specified 2875 priority. Weights are not used in these sample records. 2877 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 2878 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 2879 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 2880 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 2882 9. Errors 2884 The KRB-ERROR message is returned by the KDC if an error occurs 2885 during credentials acquisition. It may also be returned by an 2886 application server if an error occurs during authentication. 2888 ErrCode ::= Int32 2890 KRB-ERROR ::= CHOICE { 2891 rfc1510 KRB-ERROR-1510, 2892 ext KRB-ERROR-EXT 2893 } 2895 The extensible KRB-ERROR is only signed if there has been a key 2896 negotiated with its recipient. KRB-ERROR messages sent in response 2897 to AS-REQ messages will probably not be signed unless a 2898 preauthentication mechanism has negotiated a key. (Signing using a 2899 client's long-term key can expose ciphertext to dictionary attacks.) 2900 KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE { 2901 pvno [0] INTEGER (5), 2902 msg-type [1] INTEGER (30), 2903 ctime [2] KerberosTime OPTIONAL, 2904 cusec [3] Microseconds OPTIONAL, 2905 stime [4] KerberosTime, 2906 susec [5] Microseconds, 2907 error-code [6] ErrCode, 2908 crealm [7] RealmIA5 OPTIONAL, 2909 cname [8] PrincipalNameIA5 OPTIONAL, 2910 realm [9] RealmIA5 -- Correct realm --, 2911 sname [10] PrincipalNameIA5 -- Correct name --, 2912 e-text [11] KerberosString OPTIONAL, 2913 e-data [12] OCTET STRING OPTIONAL 2914 } 2916 KRB-ERROR-EXT ::= [APPLICATION 23] Signed { 2917 [APPLICATION 23] SEQUENCE{ 2918 pvno [0] INTEGER (5), 2919 msg-type [1] INTEGER (23), 2920 ctime [2] KerberosTime OPTIONAL, 2921 cusec [3] Microseconds OPTIONAL, 2922 stime [4] KerberosTime, 2923 susec [5] Microseconds, 2924 error-code [6] ErrCode, 2925 crealm [7] Realm OPTIONAL, 2926 cname [8] PrincipalName OPTIONAL, 2927 realm [9] Realm -- Correct realm --, 2928 sname [10] PrincipalName -- Correct name --, 2929 e-text [11] KerberosString OPTIONAL, 2930 e-data [12] OCTET STRING OPTIONAL, 2931 ..., 2932 typed-data [13] TYPED-DATA OPTIONAL, 2933 nonce [14] Nonce OPTIONAL, 2934 lang-tag [15] LangTag OPTIONAL, 2935 ... 2936 }, { }, { ku-KrbError-cksum } 2937 } 2939 ctime, cusec 2940 Client's time, if known from a KDC-REQ or AP-REQ. 2942 stime, susec 2943 KDC or application server's current time. 2945 error-code 2946 Numeric error code designating the error. 2948 crealm, cname 2949 Client's realm and name, if known. 2951 realm, sname 2952 server's realm and name. [ XXX what if these aren't known? ] 2954 e-text 2955 Human-readable text providing additional details for the error. 2957 e-data 2958 This field contains additional data about the error for use by 2959 the client to help it recover from or handle the error. If the 2960 "error-code" is "kdc-err-preauth-required", then the e-data 2961 field will contain an encoding of a sequence of padata fields, 2962 each corresponding to an acceptable pre-authentication method 2963 and optionally containing data for the method: 2965 METHOD-DATA ::= SEQUENCE OF PA-DATA 2967 For error codes defined in this document other than "kdc-err- 2968 preauth-required", the format and contents of the e-data field 2969 are implementation-defined. Similarly, for future error codes, 2970 the format and contents of the e-data field are implementation- 2971 defined unless specified. 2973 lang-tag 2974 Indicates the language of the message in the "e-text" field. It 2975 is only present in the extensible KRB-ERROR. 2977 nonce 2978 is the nonce from a KDC-REQ. It is only present in the 2979 extensible KRB-ERROR. 2981 typed-data 2982 TYPED-DATA is a typed hole allowing for additional data to be 2983 returned in error conditions, since "e-data" is insufficiently 2984 flexible for some purposes. TYPED-DATA is only present in the 2985 extensible KRB-ERROR. 2987 TDType ::= TH-id 2989 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 2990 data-type [0] TDType, 2991 data-value [1] OCTET STRING OPTIONAL 2992 } 2994 10. Session Key Exchange 2996 Session key exchange consists of the AP-REQ and AP-REP messages. The 2997 client sends the AP-REQ message, and the service responds with an 2998 AP-REP message if mutual authentication is desired. Following 2999 session key exchange, the client and service share a secret session 3000 key, or possibly a subsesion key, which can be used to protect 3001 further communications. Additionally, the session key exchange 3002 process can establish initial sequence numbers which the client and 3003 service can use to detect replayed messages. 3005 10.1. AP-REQ 3007 An AP-REQ message contains a ticket and a authenticator. The 3008 authenticator is ciphertext encrypted with the session key contained 3009 in the ticket. The plaintext contents of the authenticator are: 3011 -- plaintext of authenticator 3012 Authenticator1510 ::= [APPLICATION 2] SEQUENCE { 3013 authenticator-vno [0] INTEGER (5), 3014 crealm [1] RealmIA5, 3015 cname [2] PrincipalNameIA5, 3016 cksum [3] Checksum {{ key-session }, 3017 { ku-Authenticator-cksum | 3018 ku-pa-TGSReq-cksum }} OPTIONAL, 3019 cusec [4] Microseconds, 3020 ctime [5] KerberosTime, 3021 subkey [6] EncryptionKey OPTIONAL, 3022 seq-number [7] SeqNum32 OPTIONAL, 3023 authorization-data [8] AuthorizationData OPTIONAL 3024 } 3026 AuthenticatorExt ::= [APPLICATION 35] SEQUENCE { 3027 authenticator-vno [0] INTEGER (5), 3028 crealm [1] RealmExt, 3029 cname [2] PrincipalNameExt, 3030 cksum [3] Checksum {{ key-session }, 3031 { ku-Authenticator-cksum | 3032 ku-pa-TGSReq-cksum }} OPTIONAL, 3033 cusec [4] Microseconds, 3034 ctime [5] KerberosTime, 3035 subkey [6] EncryptionKey OPTIONAL, 3036 seq-number [7] SeqNum OPTIONAL, 3037 authorization-data [8] AuthorizationData OPTIONAL, 3038 ... 3039 } 3041 The complete definition of AP-REQ is: 3043 AP-REQ ::= CHOICE { 3044 rfc1510 AP-REQ-1510, 3045 ext AP-REQ-EXT 3046 } 3048 AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE { 3049 pvno [0] INTEGER (5), 3050 msg-type [1] INTEGER (14), 3051 ap-options [2] APOptions, 3052 ticket [3] Ticket1510, 3053 authenticator [4] EncryptedData { 3054 Authenticator1510, 3055 { key-session }, 3056 { ku-APReq-authenticator | 3057 ku-pa-TGSReq-authenticator } 3058 } 3059 } 3061 AP-REQ-EXT ::= [APPLICATION 18] Signed { 3062 [APPLICATION 18] SEQUENCE { 3063 pvno [0] INTEGER (5), 3064 msg-type [1] INTEGER (18), 3065 ap-options [2] APOptions, 3066 ticket [3] Ticket, 3067 authenticator [4] EncryptedData { 3068 AuthenticatorExt, 3069 { key-session }, 3070 { ku-APReq-authenticator | 3071 ku-pa-TGSReq-authenticator } 3072 }, 3073 ..., 3074 extensions [5] ApReqExtensions OPTIONAL, 3075 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 3076 OF LangTag OPTIONAL, 3077 ... 3078 }, { key-session }, { ku-APReq-cksum } 3079 } 3081 APOptions ::= KerberosFlags { APOptionsBits } 3083 APOptionsBits ::= BIT STRING { 3084 reserved (0), 3085 use-session-key (1), 3086 mutual-required (2) 3087 } 3089 10.2. AP-REP 3091 An AP-REP message provides mutual authentication of the service to 3092 the client. 3094 EncAPRepPart ::= CHOICE { 3095 rfc1510 EncAPRepPart1510, 3096 ext EncAPRepPartExt 3097 } 3099 EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE { 3100 ctime [0] KerberosTime, 3101 cusec [1] Microseconds, 3102 subkey [2] EncryptionKey OPTIONAL, 3103 seq-number [3] SeqNum32 OPTIONAL 3104 } 3106 EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE { 3107 ctime [0] KerberosTime, 3108 cusec [1] Microseconds, 3109 subkey [2] EncryptionKey OPTIONAL, 3110 seq-number [3] SeqNum OPTIONAL, 3111 ..., 3112 authorization-data [4] AuthorizationData OPTIONAL, 3113 ... 3114 } 3116 AP-REP ::= CHOICE { 3117 rfc1510 AP-REP-1510, 3118 ext AP-REP-EXT 3119 } 3121 AP-REP-1510 ::= [APPLICATION 15] SEQUENCE { 3122 pvno [0] INTEGER (5), 3123 msg-type [1] INTEGER (15), 3124 enc-part [2] EncryptedData { 3125 EncApRepPart1510, 3126 { key-session | key-subsession }, { ku-EncAPRepPart }} 3127 } 3128 AP-REP-EXT ::= [APPLICATION 19] Signed { 3129 [APPLICATION 19] SEQUENCE { 3130 pvno [0] INTEGER (5), 3131 msg-type [1] INTEGER (19), 3132 enc-part [2] EncryptedData { 3133 EncAPRepPartExt, 3134 { key-session | key-subsession }, 3135 { ku-EncAPRepPart }}, 3136 ..., 3137 extensions [3] ApRepExtensions OPTIONAL, 3138 ... 3139 }, { key-session | key-subsession }, { ku-APRep-cksum } 3140 } 3142 11. Session Key Use 3144 Once a session key has been established, the client and server can 3145 use several kinds of messages to securely transmit data. KRB-SAFE 3146 provides integrity protection for application data, while KRB-PRIV 3147 provides confidentiality along with integrity protection. The KRB- 3148 CRED message provides a means of securely forwarding credentials from 3149 the client host to the server host. 3151 11.1. KRB-SAFE 3153 The KRB-SAFE message provides integrity protection for an included 3154 cleartext message. 3156 KRB-SAFE ::= CHOICE { 3157 rfc1510 KRB-SAFE-1510, 3158 ext KRB-SAFE-EXT 3159 } 3161 KRB-SAFE-BODY ::= SEQUENCE { 3162 user-data [0] OCTET STRING, 3163 timestamp [1] KerberosTime OPTIONAL, 3164 usec [2] Microseconds OPTIONAL, 3165 seq-number [3] SeqNum OPTIONAL, 3166 s-address [4] HostAddress, 3167 r-address [5] HostAddress OPTIONAL, 3168 ... -- ASN.1 extensions must be excluded 3169 -- when sending to rfc1510 implementations 3170 } 3172 11.2. KRB-PRIV 3174 The KRB-PRIV message provides confidentiality and integrity 3175 protection. 3177 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3178 pvno [0] INTEGER (5), 3179 msg-type [1] INTEGER (21), 3180 enc-part [3] EncryptedData { 3181 EncKrbPrivPart, 3182 { key-session | key-subsession }, 3183 { ku-EncKrbPrivPart }}, 3184 ... 3185 } 3187 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 3188 user-data [0] OCTET STRING, 3189 timestamp [1] KerberosTime OPTIONAL, 3190 usec [2] Microseconds OPTIONAL, 3191 seq-number [3] SeqNum OPTIONAL, 3192 s-address [4] HostAddress -- sender's addr --, 3193 r-address [5] HostAddress OPTIONAL -- recip's addr --, 3194 ... -- ASN.1 extensions must be excluded 3195 -- when sending to rfc1510 implementations 3196 } 3198 11.3. KRB-CRED 3200 The KRB-CRED message provides a means of securely transferring 3201 credentials from the client to the service. 3203 KRB-CRED ::= CHOICE { 3204 rfc1510 KRB-CRED-1510, 3205 ext KRB-CRED-EXT 3206 } 3208 KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { 3209 pvno [0] INTEGER (5), 3210 msg-type [1] INTEGER (22), 3211 tickets [2] SEQUENCE OF Ticket, 3212 enc-part [3] EncryptedData { 3213 EncKrbCredPart, 3214 { key-session | key-subsession }, 3215 { ku-EncKrbCredPart }} 3216 } 3217 KRB-CRED-EXT ::= [APPLICATION 24] Signed { 3218 [APPLICATION 24] SEQUENCE { 3219 pvno [0] INTEGER (5), 3220 msg-type [1] INTEGER (24), 3221 tickets [2] SEQUENCE OF Ticket, 3222 enc-part [3] EncryptedData { 3223 EncKrbCredPart, 3224 { key-session | key-subsession }, 3225 { ku-EncKrbCredPart }}, 3226 ... 3227 }, { key-session | key-subsession }, { ku-KrbCred-cksum } 3228 } 3230 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3231 ticket-info [0] SEQUENCE OF KrbCredInfo, 3232 nonce [1] Nonce OPTIONAL, 3233 timestamp [2] KerberosTime OPTIONAL, 3234 usec [3] Microseconds OPTIONAL, 3235 s-address [4] HostAddress OPTIONAL, 3236 r-address [5] HostAddress OPTIONAL 3237 } 3239 KrbCredInfo ::= SEQUENCE { 3240 key [0] EncryptionKey, 3241 prealm [1] Realm OPTIONAL, 3242 pname [2] PrincipalName OPTIONAL, 3243 flags [3] TicketFlags OPTIONAL, 3244 authtime [4] KerberosTime OPTIONAL, 3245 starttime [5] KerberosTime OPTIONAL, 3246 endtime [6] KerberosTime OPTIONAL, 3247 renew-till [7] KerberosTime OPTIONAL, 3248 srealm [8] Realm OPTIONAL, 3249 sname [9] PrincipalName OPTIONAL, 3250 caddr [10] HostAddresses OPTIONAL 3251 } 3253 12. Security Considerations 3255 12.1. Time Synchronization 3257 Time synchronization between the KDC and application servers is 3258 necessary to prevent acceptance of expired tickets. 3260 Time synchronization is needed between application servers and 3261 clients to prevent replay attacks if a replay cache is being used. 3262 If negotiated subsession keys are used to encrypt application data, 3263 replay caches may not be necessary. 3265 12.2. Replays 3267 12.3. Principal Name Reuse 3269 See Section 5.3. 3271 12.4. Password Guessing 3273 12.5. Forward Secrecy 3275 [from RFC4120 10.; needs some rewriting] 3277 The Kerberos protocol in its basic form does not provide perfect 3278 forward secrecy for communications. If traffic has been recorded by 3279 an eavesdropper, then messages encrypted using the KRB-PRIV message, 3280 or messages encrypted using application-specific encryption under 3281 keys exchanged using Kerberos can be decrypted if any of the user's, 3282 application server's, or KDC's key is subsequently discovered. This 3283 is because the session key used to encrypt such messages is 3284 transmitted over the network encrypted in the key of the application 3285 server, and also encrypted under the session key from the user's 3286 ticket-granting ticket when returned to the user in the TGS-REP 3287 message. The session key from the ticket-granting ticket was sent to 3288 the user in the AS-REP message encrypted in the user's secret key, 3289 and embedded in the ticket-granting ticket, which was encrypted in 3290 the key of the KDC. Application requiring perfect forward secrecy 3291 must exchange keys through mechanisms that provide such assurance, 3292 but may use Kerberos for authentication of the encrypted channel 3293 established through such other means. 3295 12.6. Authorization 3297 As an authentication service, Kerberos provides a means of verifying 3298 the identity of principals on a network. Kerberos does not, by 3299 itself, provide authorization. Applications SHOULD NOT accept the 3300 mere issuance of a service ticket by the Kerberos server as granting 3301 authority to use the service. 3303 12.7. Login Authentication 3305 Some applications, particularly those which provide login access when 3306 provided with a password, SHOULD NOT treat successful acquisition of 3307 credentials as sufficient proof of the user's identity. An attacker 3308 posing as a user could generate an illegitimate KDC-REP message which 3309 decrypts properly. To authenticate a user logging on to a local 3310 system, the credentials obtained SHOULD be used in a TGS exchange to 3311 obtain credentials for a local service. Successful use of those 3312 credentials to authenticate to the local service assures that the 3313 initially obtained credentials are from a valid KDC. 3315 13. IANA Considerations 3317 [ needs more work ] 3319 Each use of Int32 in this document defines a number space. [ XXX 3320 enumerate these ] Negative numbers are reserved for private use; 3321 local and experimental extensions should use these values. Zero is 3322 reserved and may not be assigned. 3324 Typed hole contents may be identified by either Int32 values or by 3325 RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical 3326 namespace, assignments to the top level of the RELATIVE-OID space may 3327 be made on a first-come, first-served basis. 3329 14. Acknowledgments 3331 Much of the text here is adapted from RFC 4120. The description of 3332 the general form of the extensibility framework was derived from text 3333 by Sam Hartman. Some text concerning internationalization of 3334 internationalized domain names in principal names and realm names was 3335 contributed by Jeffrey Altman and Jeffrey Hutzelman. 3337 Appendices 3339 A. ASN.1 Module (Normative) 3341 KerberosV5Spec3 { 3342 iso(1) identified-organization(3) dod(6) internet(1) 3343 security(5) kerberosV5(2) modules(4) krb5spec3(4) 3344 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 3346 -- OID arc for KerberosV5 3347 -- 3348 -- This OID may be used to identify Kerberos protocol messages 3349 -- encapsulated in other protocols. 3350 -- 3351 -- This OID also designates the OID arc for KerberosV5-related 3352 -- OIDs. 3353 -- 3354 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its 3355 -- OID. 3356 id-krb5 OBJECT IDENTIFIER ::= { 3357 iso(1) identified-organization(3) dod(6) internet(1) 3358 security(5) kerberosV5(2) 3359 } 3360 -- top-level type 3361 -- 3362 -- Applications should not directly reference any types 3363 -- other than KRB-PDU and its component types. 3364 -- 3365 KRB-PDU ::= CHOICE { 3366 ticket Ticket, 3367 as-req AS-REQ, 3368 as-rep AS-REP, 3369 tgs-req TGS-REQ, 3370 tgs-rep TGS-REP, 3371 ap-req AP-REQ, 3372 ap-rep AP-REP, 3373 krb-safe KRB-SAFE, 3374 krb-priv KRB-PRIV, 3375 krb-cred KRB-CRED, 3376 tgt-req TGT-REQ, 3377 krb-error KRB-ERROR, 3378 ... 3379 } 3381 -- 3382 -- *** basic types 3383 -- 3385 -- signed values representable in 32 bits 3386 -- 3387 -- These are often used as assigned numbers for various things. 3388 Int32 ::= INTEGER (-2147483648..2147483647) 3390 -- Typed hole identifiers 3391 TH-id ::= CHOICE { 3392 int32 Int32, 3393 rel-oid RELATIVE-OID 3394 } 3396 -- unsigned 32 bit values 3397 UInt32 ::= INTEGER (0..4294967295) 3399 -- unsigned 64 bit values 3400 UInt64 ::= INTEGER (0..18446744073709551615) 3402 -- sequence numbers 3403 SeqNum ::= UInt64 3404 -- nonces 3405 Nonce ::= UInt64 3407 -- microseconds 3408 Microseconds ::= INTEGER (0..999999) 3410 KerberosTime ::= GeneralizedTime (CONSTRAINED BY { 3411 -- MUST NOT include fractional seconds 3412 }) 3414 -- used for names and for error messages 3415 KerberosString ::= CHOICE { 3416 ia5 GeneralString (IA5String), 3417 utf8 UTF8String, 3418 ... -- no extension may be sent 3419 -- to an rfc1510 implementation -- 3420 } 3422 -- IA5 choice only; useful for constraints 3423 KerberosStringIA5 ::= KerberosString 3424 (WITH COMPONENTS { ia5 PRESENT }) 3426 -- IA5 excluded; useful for constraints 3427 KerberosStringExt ::= KerberosString 3428 (WITH COMPONENTS { ia5 ABSENT }) 3430 -- used for language tags 3431 LangTag ::= PrintableString 3432 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 3434 -- assigned numbers for name types (used in principal names) 3435 NameType ::= Int32 3437 -- Name type not known 3438 nt-unknown NameType ::= 0 3439 -- Just the name of the principal as in DCE, or for users 3440 nt-principal NameType ::= 1 3441 -- Service and other unique instance (krbtgt) 3442 nt-srv-inst NameType ::= 2 3443 -- Service with host name as instance (telnet, rcommands) 3444 nt-srv-hst NameType ::= 3 3445 -- Service with host as remaining components 3446 nt-srv-xhst NameType ::= 4 3447 -- Unique ID 3448 nt-uid NameType ::= 5 3449 -- Encoded X.509 Distingished name [RFC 2253] 3450 nt-x500-principal NameType ::= 6 3451 -- Name in form of SMTP email name (e.g. user@foo.com) 3452 nt-smtp-name NameType ::= 7 3453 -- Enterprise name - may be mapped to principal name 3454 nt-enterprise NameType ::= 10 3455 -- reserved principal names [krb-wg-naming] 3456 nt-wellknown NameType ::= 11 3458 PrincipalName { StrType } ::= SEQUENCE { 3459 name-type [0] NameType, 3460 -- May have zero elements, or individual elements may be 3461 -- zero-length, but this is NOT RECOMMENDED. 3462 name-string [1] SEQUENCE OF KerberosString (StrType) 3463 } 3465 -- IA5 only 3466 PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } 3467 -- IA5 excluded 3468 PrincipalNameExt ::= PrincipalName { KerberosStringExt } 3469 -- Either one? 3470 PrincipalNameEither ::= PrincipalName { KerberosString } 3471 Realm { StrType } ::= KerberosString (StrType) 3473 -- IA5 only 3474 RealmIA5 ::= Realm { KerberosStringIA5 } 3476 -- IA5 excluded 3477 RealmExt ::= Realm { KerberosStringExt } 3479 -- Either 3480 RealmEither ::= Realm { KerberosString } 3482 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 3483 (CONSTRAINED BY { 3484 -- MUST be a valid value of -- NamedBits 3486 -- but if the value to be sent would be truncated to 3487 -- shorter than 32 bits according to DER, the value MUST be 3488 -- padded with trailing zero bits to 32 bits. Otherwise, 3489 -- no trailing zero bits may be present. 3491 }) 3493 AddrType ::= Int32 3495 HostAddress ::= SEQUENCE { 3496 addr-type [0] AddrType, 3497 address [1] OCTET STRING 3498 } 3500 -- NOTE: HostAddresses is always used as an OPTIONAL field and 3501 -- should not be a zero-length SEQUENCE OF. 3502 -- 3503 -- The extensible messages explicitly constrain this to be 3504 -- non-empty. 3505 HostAddresses ::= SEQUENCE OF HostAddress 3507 -- 3508 -- *** crypto-related types and assignments 3509 -- 3510 -- Assigned numbers denoting encryption mechanisms. 3511 EType ::= Int32 3513 -- assigned numbers for encryption schemes 3514 et-des-cbc-crc EType ::= 1 3515 et-des-cbc-md4 EType ::= 2 3516 et-des-cbc-md5 EType ::= 3 3517 -- [reserved] 4 3518 et-des3-cbc-md5 EType ::= 5 3519 -- [reserved] 6 3520 et-des3-cbc-sha1 EType ::= 7 3521 et-dsaWithSHA1-CmsOID EType ::= 9 3522 et-md5WithRSAEncryption-CmsOID EType ::= 10 3523 et-sha1WithRSAEncryption-CmsOID EType ::= 11 3524 et-rc2CBC-EnvOID EType ::= 12 3525 et-rsaEncryption-EnvOID EType ::= 13 3526 et-rsaES-OAEP-ENV-OID EType ::= 14 3527 et-des-ede3-cbc-Env-OID EType ::= 15 3528 et-des3-cbc-sha1-kd EType ::= 16 3529 -- AES 3530 et-aes128-cts-hmac-sha1-96 EType ::= 17 3531 -- AES 3532 et-aes256-cts-hmac-sha1-96 EType ::= 18 3533 -- Microsoft 3534 et-rc4-hmac EType ::= 23 3535 -- Microsoft 3536 et-rc4-hmac-exp EType ::= 24 3537 -- opaque; PacketCable 3538 et-subkey-keymaterial EType ::= 65 3539 -- Assigned numbers denoting key usages. 3540 KeyUsage ::= UInt32 3542 -- 3543 -- Actual identifier names are provisional and subject to 3544 -- change. 3545 -- 3546 ku-pa-enc-ts KeyUsage ::= 1 3547 ku-Ticket KeyUsage ::= 2 3548 ku-EncASRepPart KeyUsage ::= 3 3549 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 3550 ku-TGSReqAuthData-subkey KeyUsage ::= 5 3551 ku-pa-TGSReq-cksum KeyUsage ::= 6 3552 ku-pa-TGSReq-authenticator KeyUsage ::= 7 3553 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 3554 ku-EncTGSRepPart-subkey KeyUsage ::= 9 3555 ku-Authenticator-cksum KeyUsage ::= 10 3556 ku-APReq-authenticator KeyUsage ::= 11 3557 ku-EncAPRepPart KeyUsage ::= 12 3558 ku-EncKrbPrivPart KeyUsage ::= 13 3559 ku-EncKrbCredPart KeyUsage ::= 14 3560 ku-KrbSafe-cksum KeyUsage ::= 15 3561 ku-ad-KDCIssued-cksum KeyUsage ::= 19 3562 -- The following numbers are provisional... 3563 -- conflicts may exist elsewhere. 3564 ku-Ticket-cksum KeyUsage ::= 29 3565 ku-ASReq-cksum KeyUsage ::= 30 3566 ku-TGSReq-cksum KeyUsage ::= 31 3567 ku-ASRep-cksum KeyUsage ::= 32 3568 ku-TGSRep-cksum KeyUsage ::= 33 3569 ku-APReq-cksum KeyUsage ::= 34 3570 ku-APRep-cksum KeyUsage ::= 35 3571 ku-KrbCred-cksum KeyUsage ::= 36 3572 ku-KrbError-cksum KeyUsage ::= 37 3573 ku-KDCRep-cksum KeyUsage ::= 38 3575 ku-kg-acceptor-seal KeyUsage ::= 22 3576 ku-kg-acceptor-sign KeyUsage ::= 23 3577 ku-kg-intiator-seal KeyUsage ::= 24 3578 ku-kg-intiator-sign KeyUsage ::= 25 3580 -- KeyUsage values 25..27 used by hardware preauth? 3582 -- for KINK 3583 ku-kink-encrypt KeyUsage ::= 39 3584 ku-kink-cksum KeyUsage ::= 40 3586 -- IAKERB 3587 ku-iakerb-finished KeyUsage ::= 41 3588 -- KeyToUse identifies which key is to be used to encrypt or 3589 -- sign a given value. 3590 -- 3591 -- Values of KeyToUse are never actually transmitted over the 3592 -- wire, or even used directly by the implementation in any 3593 -- way, as key usages are; it exists primarily to identify 3594 -- which key gets used for what purpose. Thus, the specific 3595 -- numeric values associated with this type are irrelevant. 3596 KeyToUse ::= ENUMERATED { 3597 -- unspecified 3598 key-unspecified, 3599 -- server long term key 3600 key-server, 3601 -- client long term key 3602 key-client, 3603 -- key selected by KDC for encryption of a KDC-REP 3604 key-kdc-rep, 3605 -- session key from ticket 3606 key-session, 3607 -- subsession key negotiated via AP-REQ/AP-REP 3608 key-subsession, 3609 ... 3610 } 3612 EncryptionKey ::= SEQUENCE { 3613 keytype [0] EType, 3614 keyvalue [1] OCTET STRING 3615 } 3616 -- "Type" specifies which ASN.1 type is encrypted to the 3617 -- ciphertext in the EncryptedData. "Keys" specifies a set of 3618 -- keys of which one key may be used to encrypt the data. 3619 -- "KeyUsages" specifies a set of key usages, one of which may 3620 -- be used to encrypt. 3621 -- 3622 -- None of the parameters is transmitted over the wire. 3623 EncryptedData { 3624 Type, KeyToUse:Keys, KeyUsage:KeyUsages 3625 } ::= SEQUENCE { 3626 etype [0] EType, 3627 kvno [1] UInt32 OPTIONAL, 3628 cipher [2] OCTET STRING (CONSTRAINED BY { 3629 -- must be encryption of -- 3630 OCTET STRING (CONTAINING Type), 3631 -- with one of the keys -- KeyToUse:Keys, 3632 -- with key usage being one of -- 3633 KeyUsage:KeyUsages 3634 }), 3635 ... 3636 } 3638 CksumType ::= Int32 3640 -- The parameters specify which key to use to produce the 3641 -- signature, as well as which key usage to use. The 3642 -- parameters are not actually sent over the wire. 3643 Checksum { 3644 KeyToUse:Keys, KeyUsage:KeyUsages 3645 } ::= SEQUENCE { 3646 cksumtype [0] CksumType, 3647 checksum [1] OCTET STRING (CONSTRAINED BY { 3648 -- signed using one of the keys -- 3649 KeyToUse:Keys, 3650 -- with key usage being one of -- 3651 KeyUsage:KeyUsages 3652 }) 3653 } 3654 -- a Checksum that must contain the checksum 3655 -- of a particular type 3656 ChecksumOf { 3657 Type, KeyToUse:Keys, KeyUsage:KeyUsages 3658 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 3659 ..., 3660 checksum (CONSTRAINED BY { 3661 -- must be checksum of -- 3662 OCTET STRING (CONTAINING Type) 3663 }) 3664 }) 3666 -- parameterized type for wrapping authenticated plaintext 3667 Signed { 3668 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 3669 } ::= SEQUENCE { 3670 cksum [0] ChecksumOf { 3671 InnerType, Keys, KeyUsages 3672 } OPTIONAL, 3673 inner [1] InnerType, 3674 ... 3675 } 3677 -- 3678 -- *** Tickets 3679 -- 3681 Ticket ::= CHOICE { 3682 rfc1510 Ticket1510, 3683 ext TicketExt 3684 } 3686 Ticket1510 ::= [APPLICATION 1] SEQUENCE { 3687 tkt-vno [0] INTEGER (5), 3688 realm [1] RealmIA5, 3689 sname [2] PrincipalNameIA5, 3690 enc-part [3] EncryptedData { 3691 EncTicketPart1510, { key-server }, { ku-Ticket } 3692 } 3693 } 3694 TicketExt ::= [APPLICATION 4] Signed { 3695 [APPLICATION 4] SEQUENCE { 3696 tkt-vno [0] INTEGER (5), 3697 realm [1] RealmExt, 3698 sname [2] PrincipalNameExt, 3699 enc-part [3] EncryptedData { 3700 EncTicketPartExt, { key-server }, { ku-Ticket } 3701 }, 3702 ..., 3703 extensions [4] TicketExtensions OPTIONAL, 3704 ... 3705 }, 3706 { key-ticket }, { ku-Ticket-cksum } 3707 } 3709 -- Encrypted part of ticket 3710 EncTicketPart ::= CHOICE { 3711 rfc1510 EncTicketPart1510, 3712 ext EncTicketPartExt 3713 } 3715 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { 3716 flags [0] TicketFlags, 3717 key [1] EncryptionKey, 3718 crealm [2] RealmIA5, 3719 cname [3] PrincipalNameIA5, 3720 transited [4] TransitedEncoding, 3721 authtime [5] KerberosTime, 3722 starttime [6] KerberosTime OPTIONAL, 3723 endtime [7] KerberosTime, 3724 renew-till [8] KerberosTime OPTIONAL, 3725 caddr [9] HostAddresses OPTIONAL, 3726 authorization-data [10] AuthorizationData OPTIONAL 3727 } 3728 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { 3729 flags [0] TicketFlags, 3730 key [1] EncryptionKey, 3731 crealm [2] RealmExt, 3732 cname [3] PrincipalNameExt, 3733 transited [4] TransitedEncoding, 3734 authtime [5] KerberosTime, 3735 starttime [6] KerberosTime OPTIONAL, 3736 endtime [7] KerberosTime, 3737 renew-till [8] KerberosTime OPTIONAL, 3738 caddr [9] HostAddresses OPTIONAL, 3739 authorization-data [10] AuthorizationData OPTIONAL, 3740 ..., 3741 } 3743 -- 3744 -- *** Authorization Data 3745 -- 3747 ADType ::= TH-id 3749 AuthorizationData ::= SEQUENCE OF SEQUENCE { 3750 ad-type [0] ADType, 3751 ad-data [1] OCTET STRING 3752 } 3754 ad-if-relevant ADType ::= int32 : 1 3756 -- Encapsulates another AuthorizationData. 3757 -- Intended for application servers; receiving application 3758 -- servers MAY ignore. 3759 AD-IF-RELEVANT ::= AuthorizationData 3761 -- KDC-issued privilege attributes 3762 ad-kdcissued ADType ::= int32 : 4 3764 AD-KDCIssued ::= SEQUENCE { 3765 ad-checksum [0] ChecksumOf { 3766 AuthorizationData, { key-session }, 3767 { ku-ad-KDCIssued-cksum }}, 3768 i-realm [1] Realm OPTIONAL, 3769 i-sname [2] PrincipalName OPTIONAL, 3770 elements [3] AuthorizationData 3771 } 3772 ad-and-or ADType ::= int32 : 5 3774 AD-AND-OR ::= SEQUENCE { 3775 condition-count [0] Int32, 3776 elements [1] AuthorizationData 3777 } 3779 -- KDCs MUST interpret any AuthorizationData wrapped in this. 3780 ad-mandatory-for-kdc ADType ::= int32 : 8 3781 AD-MANDATORY-FOR-KDC ::= AuthorizationData 3783 ad-initial-verified-cas ADType ::= int32 : 9 3785 TrType ::= TH-id -- must be registered 3787 -- encoded Transited field 3788 TransitedEncoding ::= SEQUENCE { 3789 tr-type [0] TrType, 3790 contents [1] OCTET STRING 3791 } 3793 TEType ::= TH-id 3795 -- ticket extensions: for TicketExt only 3796 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 3797 te-type [0] TEType, 3798 te-data [1] OCTET STRING 3799 } 3800 TicketFlags ::= KerberosFlags { TicketFlagsBits } 3802 TicketFlagsBits ::= BIT STRING { 3803 reserved (0), 3804 forwardable (1), 3805 forwarded (2), 3806 proxiable (3), 3807 proxy (4), 3808 may-postdate (5), 3809 postdated (6), 3810 invalid (7), 3811 renewable (8), 3812 initial (9), 3813 pre-authent (10), 3814 hw-authent (11), 3815 transited-policy-checked (12), 3816 ok-as-delegate (13), 3817 anonymous (14), 3818 cksummed-ticket (15) 3819 } 3821 -- 3822 -- *** KDC protocol 3823 -- 3825 AS-REQ ::= CHOICE { 3826 rfc1510 AS-REQ-1510, 3827 ext AS-REQ-EXT 3828 } 3829 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 3830 -- AS-REQ must include client name 3832 AS-REQ-EXT ::= [APPLICATION 6] Signed { 3833 [APPLICATION 6] KDC-REQ-EXT, 3834 { key-client }, { ku-ASReq-cksum } 3835 } 3836 -- AS-REQ must include client name 3837 TGS-REQ ::= CHOICE { 3838 rfc1510 TGS-REQ-1510, 3839 ext TGS-REQ-EXT 3840 } 3842 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 3844 TGS-REQ-EXT ::= [APPLICATION 8] Signed { 3845 [APPLICATION 8] KDC-REQ-EXT, 3846 { key-session }, { ku-TGSReq-cksum } 3847 } 3849 KDC-REQ-1510 ::= SEQUENCE { 3850 -- NOTE: first tag is [1], not [0] 3851 pvno [1] INTEGER (5), 3852 msg-type [2] INTEGER ( 10 -- AS-REQ -- 3853 | 12 -- TGS-REQ -- ), 3854 padata [3] SEQUENCE OF PA-DATA OPTIONAL, 3855 req-body [4] KDC-REQ-BODY-1510 3856 } 3858 KDC-REQ-EXT ::= SEQUENCE { 3859 pvno [1] INTEGER (5), 3860 msg-type [2] INTEGER ( 6 -- AS-REQ -- 3861 | 8 -- TGS-REQ -- ), 3862 padata [3] SEQUENCE (SIZE (1..MAX)) 3863 OF PA-DATA OPTIONAL, 3864 req-body [4] KDC-REQ-BODY-EXT, 3865 ... 3866 } 3867 KDC-REQ-BODY-1510 ::= SEQUENCE { 3868 kdc-options [0] KDCOptions, 3869 cname [1] PrincipalNameIA5 OPTIONAL 3870 -- Used only in AS-REQ --, 3872 realm [2] RealmIA5 3873 -- Server's realm; also client's in AS-REQ --, 3875 sname [3] PrincipalNameIA5 OPTIONAL, 3876 from [4] KerberosTime OPTIONAL, 3877 till [5] KerberosTime, 3878 rtime [6] KerberosTime OPTIONAL, 3879 nonce [7] Nonce32, 3880 etype [8] SEQUENCE OF EType 3881 -- in preference order --, 3883 addresses [9] HostAddresses OPTIONAL, 3884 enc-authorization-data [10] EncryptedData { 3885 AuthorizationData, { key-session | key-subsession }, 3886 { ku-TGSReqAuthData-subkey | 3887 ku-TGSReqAuthData-sesskey } 3888 } OPTIONAL, 3890 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3891 -- NOTE: not empty -- 3892 } 3893 KDC-REQ-BODY-EXT ::= SEQUENCE { 3894 kdc-options [0] KDCOptions, 3895 cname [1] PrincipalName OPTIONAL 3896 -- Used only in AS-REQ --, 3898 realm [2] Realm 3899 -- Server's realm; also client's in AS-REQ --, 3901 sname [3] PrincipalName OPTIONAL, 3902 from [4] KerberosTime OPTIONAL, 3903 till [5] KerberosTime OPTIONAL 3904 -- was required in rfc1510; 3905 -- still required for compat versions 3906 -- of messages --, 3908 rtime [6] KerberosTime OPTIONAL, 3909 nonce [7] Nonce, 3910 etype [8] SEQUENCE OF EType 3911 -- in preference order --, 3913 addresses [9] HostAddresses OPTIONAL, 3914 enc-authorization-data [10] EncryptedData { 3915 AuthorizationData, { key-session | key-subsession }, 3916 { ku-TGSReqAuthData-subkey | 3917 ku-TGSReqAuthData-sesskey } 3918 } OPTIONAL, 3920 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3921 -- NOTE: not empty --, 3922 ... 3923 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 3924 LangTag OPTIONAL, 3925 ... 3926 } 3927 KDCOptions ::= KerberosFlags { KDCOptionsBits } 3929 KDCOptionsBits ::= BIT STRING { 3930 reserved (0), 3931 forwardable (1), 3932 forwarded (2), 3933 proxiable (3), 3934 proxy (4), 3935 allow-postdate (5), 3936 postdated (6), 3937 unused7 (7), 3938 renewable (8), 3939 unused9 (9), 3940 unused10 (10), 3941 unused11 (11), 3942 unused12 (12), 3943 unused13 (13), 3944 requestanonymous (14), 3945 canonicalize (15), 3946 disable-transited-check (26), 3947 renewable-ok (27), 3948 enc-tkt-in-skey (28), 3949 renew (30), 3950 validate (31) 3951 -- XXX need "need ticket1" flag? 3952 } 3954 AS-REP ::= CHOICE { 3955 rfc1510 AS-REP-1510, 3956 ext AS-REP-EXT 3957 } 3958 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 3959 AS-REP-EXT ::= [APPLICATION 7] Signed { 3960 [APPLICATION 7] KDC-REP-EXT, 3961 { key-reply }, { ku-ASRep-cksum } 3962 } 3964 TGS-REP ::= CHOICE { 3965 rfc1510 TGS-REP-1510, 3966 ext TGS-REP-EXT 3967 } 3968 TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { 3969 EncTGSRepPart1510 } 3971 TGS-REP-EXT ::= [APPLICATION 9] Signed { 3972 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 3973 { key-reply }, { ku-TGSRep-cksum } 3974 } 3975 KDC-REP-1510 { EncPart } ::= SEQUENCE { 3976 pvno [0] INTEGER (5), 3977 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 3978 13 -- TGS.rfc1510 -- ), 3979 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 3980 crealm [3] RealmIA5, 3981 cname [4] PrincipalNameIA5, 3982 ticket [5] Ticket, 3984 enc-part [6] EncryptedData { 3985 EncPart, 3986 { key-reply }, 3987 -- maybe reach into EncryptedData in AS-REP/TGS-REP 3988 -- definitions to apply constraints on key usages? 3989 { ku-EncASRepPart -- if AS-REP -- | 3990 ku-EncTGSRepPart-subkey -- if TGS-REP and 3991 -- using Authenticator 3992 -- session key -- | 3993 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 3994 -- subsession key -- } 3995 } 3996 } 3997 KDC-REP-EXT { EncPart } ::= SEQUENCE { 3998 pvno [0] INTEGER (5), 3999 msg-type [1] INTEGER (7 -- AS-REP.ext -- | 4000 9 -- TGS-REP.ext -- ), 4001 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 4002 crealm [3] RealmExt, 4003 cname [4] PrincipalNameExt, 4004 ticket [5] Ticket, 4006 enc-part [6] EncryptedData { 4007 EncPart, 4008 { key-reply }, 4009 -- maybe reach into EncryptedData in AS-REP/TGS-REP 4010 -- definitions to apply constraints on key usages? 4011 { ku-EncASRepPart -- if AS-REP -- | 4012 ku-EncTGSRepPart-subkey -- if TGS-REP and 4013 -- using Authenticator 4014 -- session key -- | 4015 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 4016 -- subsession key -- } 4017 }, 4019 ..., 4020 -- In extensible version, KDC signs original request 4021 -- to avoid replay attacks against client. 4022 req-cksum [7] ChecksumOf { CHOICE { 4023 as-req AS-REQ, 4024 tgs-req TGS-REQ 4025 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 4026 lang-tag [8] LangTag OPTIONAL, 4027 ... 4028 } 4029 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 4030 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 4032 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 4033 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 4035 EncKDCRepPart1510 ::= SEQUENCE { 4036 key [0] EncryptionKey, 4037 last-req [1] LastReq, 4038 nonce [2] Nonce32, 4039 key-expiration [3] KerberosTime OPTIONAL, 4040 flags [4] TicketFlags, 4041 authtime [5] KerberosTime, 4042 starttime [6] KerberosTime OPTIONAL, 4043 endtime [7] KerberosTime, 4044 renew-till [8] KerberosTime OPTIONAL, 4045 srealm [9] RealmIA5, 4046 sname [10] PrincipalNameIA5, 4047 caddr [11] HostAddresses OPTIONAL 4048 } 4050 EncKDCRepPartExt ::= SEQUENCE { 4051 key [0] EncryptionKey, 4052 last-req [1] LastReq, 4053 nonce [2] Nonce, 4054 key-expiration [3] KerberosTime OPTIONAL, 4055 flags [4] TicketFlags, 4056 authtime [5] KerberosTime, 4057 starttime [6] KerberosTime OPTIONAL, 4058 endtime [7] KerberosTime, 4059 renew-till [8] KerberosTime OPTIONAL, 4060 srealm [9] Realm, 4061 sname [10] PrincipalName, 4062 caddr [11] HostAddresses OPTIONAL, 4063 ... 4064 } 4066 LRType ::= TH-id 4067 LastReq ::= SEQUENCE OF SEQUENCE { 4068 lr-type [0] LRType, 4069 lr-value [1] KerberosTime 4070 } 4072 -- 4073 -- *** preauth 4074 -- 4075 PaDataType ::= TH-id 4076 PaDataOID ::= RELATIVE-OID 4078 PA-DATA ::= SEQUENCE { 4079 -- NOTE: first tag is [1], not [0] 4080 padata-type [1] PaDataType, 4081 padata-value [2] OCTET STRING 4082 } 4084 -- AP-REQ authenticating a TGS-REQ 4085 pa-tgs-req PaDataType ::= int32 : 1 4086 PA-TGS-REQ ::= AP-REQ 4088 -- Encrypted timestamp preauth 4089 -- Encryption key used is client's long-term key. 4090 pa-enc-timestamp PaDataType ::= int32 : 2 4092 PA-ENC-TIMESTAMP ::= EncryptedData { 4093 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } 4094 } 4096 PA-ENC-TS-ENC ::= SEQUENCE { 4097 patimestamp [0] KerberosTime -- client's time --, 4098 pausec [1] Microseconds OPTIONAL 4099 } 4101 -- Hints returned in AS-REP or KRB-ERROR to help client 4102 -- choose a password-derived key, either for preauthentication 4103 -- or for decryption of the reply. 4104 pa-etype-info PaDataType ::= int32 : 11 4106 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 4108 ETYPE-INFO-ENTRY ::= SEQUENCE { 4109 etype [0] EType, 4110 salt [1] OCTET STRING OPTIONAL 4111 } 4112 -- Similar to etype-info, but with parameters provided for 4113 -- the string-to-key function. 4114 pa-etype-info2 PaDataType ::= int32 : 19 4116 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) 4117 OF ETYPE-INFO-ENTRY 4119 ETYPE-INFO2-ENTRY ::= SEQUENCE { 4120 etype [0] EType, 4121 salt [1] KerberosString OPTIONAL, 4122 s2kparams [2] OCTET STRING OPTIONAL 4123 } 4125 -- Obsolescent. Salt for client long-term key 4126 -- Its character encoding is unspecified. 4127 pa-pw-salt PaDataType ::= int32 : 3 4129 -- The "padata-value" does not encode an ASN.1 type. 4130 -- Instead, "padata-value" must consist of the salt string to 4131 -- be used by the client, in an unspecified character 4132 -- encoding. 4134 -- An extensible AS-REQ may be sent as a padata in a 4135 -- non-extensible AS-REQ to allow for backwards compatibility. 4136 pa-as-req PaDataType ::= int32 : 42 -- provisional 4137 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) 4139 -- 4140 -- *** Session key exchange 4141 -- 4143 AP-REQ ::= CHOICE { 4144 rfc1510 AP-REQ-1510, 4145 ext AP-REQ-EXT 4146 } 4147 AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE { 4148 pvno [0] INTEGER (5), 4149 msg-type [1] INTEGER (14), 4150 ap-options [2] APOptions, 4151 ticket [3] Ticket1510, 4152 authenticator [4] EncryptedData { 4153 Authenticator1510, 4154 { key-session }, 4155 { ku-APReq-authenticator | 4156 ku-pa-TGSReq-authenticator } 4157 } 4158 } 4160 AP-REQ-EXT ::= [APPLICATION 18] Signed { 4161 [APPLICATION 18] SEQUENCE { 4162 pvno [0] INTEGER (5), 4163 msg-type [1] INTEGER (18), 4164 ap-options [2] APOptions, 4165 ticket [3] Ticket, 4166 authenticator [4] EncryptedData { 4167 AuthenticatorExt, 4168 { key-session }, 4169 { ku-APReq-authenticator | 4170 ku-pa-TGSReq-authenticator } 4171 }, 4172 ..., 4173 extensions [5] ApReqExtensions OPTIONAL, 4174 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 4175 OF LangTag OPTIONAL, 4176 ... 4177 }, { key-session }, { ku-APReq-cksum } 4178 } 4180 ApReqExtType ::= TH-id 4182 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4183 apReqExt-Type [0] ApReqExtType, 4184 apReqExt-Data [1] OCTET STRING 4185 } 4187 APOptions ::= KerberosFlags { APOptionsBits } 4189 APOptionsBits ::= BIT STRING { 4190 reserved (0), 4191 use-session-key (1), 4192 mutual-required (2) 4193 } 4194 -- plaintext of authenticator 4195 Authenticator1510 ::= [APPLICATION 2] SEQUENCE { 4196 authenticator-vno [0] INTEGER (5), 4197 crealm [1] RealmIA5, 4198 cname [2] PrincipalNameIA5, 4199 cksum [3] Checksum {{ key-session }, 4200 { ku-Authenticator-cksum | 4201 ku-pa-TGSReq-cksum }} OPTIONAL, 4202 cusec [4] Microseconds, 4203 ctime [5] KerberosTime, 4204 subkey [6] EncryptionKey OPTIONAL, 4205 seq-number [7] SeqNum32 OPTIONAL, 4206 authorization-data [8] AuthorizationData OPTIONAL 4207 } 4209 AuthenticatorExt ::= [APPLICATION 35] SEQUENCE { 4210 authenticator-vno [0] INTEGER (5), 4211 crealm [1] RealmExt, 4212 cname [2] PrincipalNameExt, 4213 cksum [3] Checksum {{ key-session }, 4214 { ku-Authenticator-cksum | 4215 ku-pa-TGSReq-cksum }} OPTIONAL, 4216 cusec [4] Microseconds, 4217 ctime [5] KerberosTime, 4218 subkey [6] EncryptionKey OPTIONAL, 4219 seq-number [7] SeqNum OPTIONAL, 4220 authorization-data [8] AuthorizationData OPTIONAL, 4221 ... 4222 } 4224 AP-REP ::= CHOICE { 4225 rfc1510 AP-REP-1510, 4226 ext AP-REP-EXT 4227 } 4229 AP-REP-1510 ::= [APPLICATION 15] SEQUENCE { 4230 pvno [0] INTEGER (5), 4231 msg-type [1] INTEGER (15), 4232 enc-part [2] EncryptedData { 4233 EncApRepPart1510, 4234 { key-session | key-subsession }, { ku-EncAPRepPart }} 4235 } 4236 AP-REP-EXT ::= [APPLICATION 19] Signed { 4237 [APPLICATION 19] SEQUENCE { 4238 pvno [0] INTEGER (5), 4239 msg-type [1] INTEGER (19), 4240 enc-part [2] EncryptedData { 4241 EncAPRepPartExt, 4242 { key-session | key-subsession }, 4243 { ku-EncAPRepPart }}, 4244 ..., 4245 extensions [3] ApRepExtensions OPTIONAL, 4246 ... 4247 }, { key-session | key-subsession }, { ku-APRep-cksum } 4248 } 4250 ApRepExtType ::= TH-id 4252 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4253 apRepExt-Type [0] ApRepExtType, 4254 apRepExt-Data [1] OCTET STRING 4255 } 4257 EncAPRepPart ::= CHOICE { 4258 rfc1510 EncAPRepPart1510, 4259 ext EncAPRepPartExt 4260 } 4262 EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE { 4263 ctime [0] KerberosTime, 4264 cusec [1] Microseconds, 4265 subkey [2] EncryptionKey OPTIONAL, 4266 seq-number [3] SeqNum32 OPTIONAL 4267 } 4269 EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE { 4270 ctime [0] KerberosTime, 4271 cusec [1] Microseconds, 4272 subkey [2] EncryptionKey OPTIONAL, 4273 seq-number [3] SeqNum OPTIONAL, 4274 ..., 4275 authorization-data [4] AuthorizationData OPTIONAL, 4276 ... 4277 } 4278 -- 4279 -- *** Application messages 4280 -- 4282 KRB-SAFE ::= CHOICE { 4283 rfc1510 KRB-SAFE-1510, 4284 ext KRB-SAFE-EXT 4285 } 4287 KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE { 4288 pvno [0] INTEGER (5), 4289 msg-type [1] INTEGER (20), 4290 safe-body [2] KRB-SAFE-BODY, 4291 cksum [3] ChecksumOf { 4292 KRB-SAFE-BODY, 4293 { key-session | key-subsession }, { ku-KrbSafe-cksum }} 4294 } 4296 -- Has safe-body optional to allow for GSS-MIC type 4297 -- functionality 4298 KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE { 4299 pvno [0] INTEGER (5), 4300 msg-type [1] INTEGER (20), 4301 safe-body [2] KRB-SAFE-BODY OPTIONAL, 4302 cksum [3] ChecksumOf { 4303 KRB-SAFE-BODY, 4304 { key-session | key-subsession }, 4305 { ku-KrbSafe-cksum }}, 4306 ... 4307 } 4309 KRB-SAFE-BODY ::= SEQUENCE { 4310 user-data [0] OCTET STRING, 4311 timestamp [1] KerberosTime OPTIONAL, 4312 usec [2] Microseconds OPTIONAL, 4313 seq-number [3] SeqNum OPTIONAL, 4314 s-address [4] HostAddress, 4315 r-address [5] HostAddress OPTIONAL, 4316 ... -- ASN.1 extensions must be excluded 4317 -- when sending to rfc1510 implementations 4318 } 4319 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4320 pvno [0] INTEGER (5), 4321 msg-type [1] INTEGER (21), 4322 enc-part [3] EncryptedData { 4323 EncKrbPrivPart, 4324 { key-session | key-subsession }, 4325 { ku-EncKrbPrivPart }}, 4326 ... 4327 } 4329 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4330 user-data [0] OCTET STRING, 4331 timestamp [1] KerberosTime OPTIONAL, 4332 usec [2] Microseconds OPTIONAL, 4333 seq-number [3] SeqNum OPTIONAL, 4334 s-address [4] HostAddress -- sender's addr --, 4335 r-address [5] HostAddress OPTIONAL -- recip's addr --, 4336 ... -- ASN.1 extensions must be excluded 4337 -- when sending to rfc1510 implementations 4338 } 4340 KRB-CRED ::= CHOICE { 4341 rfc1510 KRB-CRED-1510, 4342 ext KRB-CRED-EXT 4343 } 4345 KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { 4346 pvno [0] INTEGER (5), 4347 msg-type [1] INTEGER (22), 4348 tickets [2] SEQUENCE OF Ticket, 4349 enc-part [3] EncryptedData { 4350 EncKrbCredPart, 4351 { key-session | key-subsession }, 4352 { ku-EncKrbCredPart }} 4353 } 4354 KRB-CRED-EXT ::= [APPLICATION 24] Signed { 4355 [APPLICATION 24] SEQUENCE { 4356 pvno [0] INTEGER (5), 4357 msg-type [1] INTEGER (24), 4358 tickets [2] SEQUENCE OF Ticket, 4359 enc-part [3] EncryptedData { 4360 EncKrbCredPart, 4361 { key-session | key-subsession }, 4362 { ku-EncKrbCredPart }}, 4363 ... 4364 }, { key-session | key-subsession }, { ku-KrbCred-cksum } 4365 } 4367 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4368 ticket-info [0] SEQUENCE OF KrbCredInfo, 4369 nonce [1] Nonce OPTIONAL, 4370 timestamp [2] KerberosTime OPTIONAL, 4371 usec [3] Microseconds OPTIONAL, 4372 s-address [4] HostAddress OPTIONAL, 4373 r-address [5] HostAddress OPTIONAL 4374 } 4376 KrbCredInfo ::= SEQUENCE { 4377 key [0] EncryptionKey, 4378 prealm [1] Realm OPTIONAL, 4379 pname [2] PrincipalName OPTIONAL, 4380 flags [3] TicketFlags OPTIONAL, 4381 authtime [4] KerberosTime OPTIONAL, 4382 starttime [5] KerberosTime OPTIONAL, 4383 endtime [6] KerberosTime OPTIONAL, 4384 renew-till [7] KerberosTime OPTIONAL, 4385 srealm [8] Realm OPTIONAL, 4386 sname [9] PrincipalName OPTIONAL, 4387 caddr [10] HostAddresses OPTIONAL 4388 } 4390 TGT-REQ ::= [APPLICATION 16] SEQUENCE { 4391 pvno [0] INTEGER (5), 4392 msg-type [1] INTEGER (16), 4393 sname [2] PrincipalName OPTIONAL, 4394 srealm [3] Realm OPTIONAL, 4395 ... 4396 } 4397 -- 4398 -- *** Error messages 4399 -- 4401 ErrCode ::= Int32 4403 KRB-ERROR ::= CHOICE { 4404 rfc1510 KRB-ERROR-1510, 4405 ext KRB-ERROR-EXT 4406 } 4408 KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE { 4409 pvno [0] INTEGER (5), 4410 msg-type [1] INTEGER (30), 4411 ctime [2] KerberosTime OPTIONAL, 4412 cusec [3] Microseconds OPTIONAL, 4413 stime [4] KerberosTime, 4414 susec [5] Microseconds, 4415 error-code [6] ErrCode, 4416 crealm [7] RealmIA5 OPTIONAL, 4417 cname [8] PrincipalNameIA5 OPTIONAL, 4418 realm [9] RealmIA5 -- Correct realm --, 4419 sname [10] PrincipalNameIA5 -- Correct name --, 4420 e-text [11] KerberosString OPTIONAL, 4421 e-data [12] OCTET STRING OPTIONAL 4422 } 4423 KRB-ERROR-EXT ::= [APPLICATION 23] Signed { 4424 [APPLICATION 23] SEQUENCE{ 4425 pvno [0] INTEGER (5), 4426 msg-type [1] INTEGER (23), 4427 ctime [2] KerberosTime OPTIONAL, 4428 cusec [3] Microseconds OPTIONAL, 4429 stime [4] KerberosTime, 4430 susec [5] Microseconds, 4431 error-code [6] ErrCode, 4432 crealm [7] Realm OPTIONAL, 4433 cname [8] PrincipalName OPTIONAL, 4434 realm [9] Realm -- Correct realm --, 4435 sname [10] PrincipalName -- Correct name --, 4436 e-text [11] KerberosString OPTIONAL, 4437 e-data [12] OCTET STRING OPTIONAL, 4438 ..., 4439 typed-data [13] TYPED-DATA OPTIONAL, 4440 nonce [14] Nonce OPTIONAL, 4441 lang-tag [15] LangTag OPTIONAL, 4442 ... 4443 }, { }, { ku-KrbError-cksum } 4444 } 4446 METHOD-DATA ::= SEQUENCE OF PA-DATA 4448 TDType ::= TH-id 4450 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4451 data-type [0] TDType, 4452 data-value [1] OCTET STRING OPTIONAL 4453 } 4455 td-dh-parameters TDType ::= int32 : 109 4456 -- iakerb 4457 td-iakerb-finished TDType ::= int32 : 110 4458 -- pkinit-alg-agility 4459 td-cms-data-digest-algorithms TDType ::= int32 : 111 4460 -- pkinit-alg-agility 4461 td-cert-digest-algorithms TDType ::= int32 : 112 4462 -- 4463 -- *** Error codes 4464 -- 4466 -- No error 4467 kdc-err-none ErrCode ::= 0 4468 -- Client's entry in database has expired 4469 kdc-err-name-exp ErrCode ::= 1 4470 -- Server's entry in database has expired 4471 kdc-err-service-exp ErrCode ::= 2 4472 -- Requested protocol version number not supported 4473 kdc-err-bad-pvno ErrCode ::= 3 4474 -- Client's key encrypted in old master key 4475 kdc-err-c-old-mast-kvno ErrCode ::= 4 4476 -- Server's key encrypted in old master key 4477 kdc-err-s-old-mast-kvno ErrCode ::= 5 4478 -- Client not found in Kerberos database 4479 kdc-err-c-principal-unknown ErrCode ::= 6 4480 -- Server not found in Kerberos database 4481 kdc-err-s-principal-unknown ErrCode ::= 7 4482 -- Multiple principal entries in database 4483 kdc-err-principal-not-unique ErrCode ::= 8 4484 -- The client or server has a null key 4485 kdc-err-null-key ErrCode ::= 9 4486 -- Ticket not eligible for postdating 4487 kdc-err-cannot-postdate ErrCode ::= 10 4488 -- Requested start time is later than end time 4489 kdc-err-never-valid ErrCode ::= 11 4490 -- KDC policy rejects request 4491 kdc-err-policy ErrCode ::= 12 4492 -- KDC cannot accommodate requested option 4493 kdc-err-badoption ErrCode ::= 13 4494 -- KDC has no support for encryption type 4495 kdc-err-etype-nosupp ErrCode ::= 14 4496 -- KDC has no support for checksum type 4497 kdc-err-sumtype-nosupp ErrCode ::= 15 4498 -- KDC has no support for padata type 4499 kdc-err-padata-type-nosupp ErrCode ::= 16 4500 -- KDC has no support for transited type 4501 kdc-err-trtype-nosupp ErrCode ::= 17 4502 -- Clients credentials have been revoked 4503 kdc-err-client-revoked ErrCode ::= 18 4504 -- Credentials for server have been revoked 4505 kdc-err-service-revoked ErrCode ::= 19 4506 -- TGT has been revoked 4507 kdc-err-tgt-revoked ErrCode ::= 20 4508 -- Client not yet valid - try again later 4509 kdc-err-client-notyet ErrCode ::= 21 4510 -- Server not yet valid - try again later 4511 kdc-err-service-notyet ErrCode ::= 22 4512 -- Password has expired - change password to reset 4513 kdc-err-key-expired ErrCode ::= 23 4514 -- Pre-authentication information was invalid 4515 kdc-err-preauth-failed ErrCode ::= 24 4516 -- Additional pre-authenticationrequired 4517 kdc-err-preauth-required ErrCode ::= 25 4518 -- Requested server and ticket don't match 4519 kdc-err-server-nomatch ErrCode ::= 26 4520 -- Server principal valid for user2user only 4521 kdc-err-must-use-user2user ErrCode ::= 27 4522 -- KDC Policy rejects transited path 4523 kdc-err-path-not-accpeted ErrCode ::= 28 4524 -- A service is not available 4525 kdc-err-svc-unavailable ErrCode ::= 29 4526 -- Integrity check on decrypted field failed 4527 krb-ap-err-bad-integrity ErrCode ::= 31 4528 -- Ticket expired 4529 krb-ap-err-tkt-expired ErrCode ::= 32 4530 -- Ticket not yet valid 4531 krb-ap-err-tkt-nyv ErrCode ::= 33 4532 -- Request is a replay 4533 krb-ap-err-repeat ErrCode ::= 34 4534 -- The ticket isn't for us 4535 krb-ap-err-not-us ErrCode ::= 35 4536 -- Ticket and authenticator don't match 4537 krb-ap-err-badmatch ErrCode ::= 36 4538 -- Clock skew too great 4539 krb-ap-err-skew ErrCode ::= 37 4540 -- Incorrect net address 4541 krb-ap-err-badaddr ErrCode ::= 38 4542 -- Protocol version mismatch 4543 krb-ap-err-badversion ErrCode ::= 39 4544 -- Invalid msg type 4545 krb-ap-err-msg-type ErrCode ::= 40 4546 -- Message stream modified 4547 krb-ap-err-modified ErrCode ::= 41 4548 -- Message out of order 4549 krb-ap-err-badorder ErrCode ::= 42 4550 -- Specified version of key is not available 4551 krb-ap-err-badkeyver ErrCode ::= 44 4552 -- Service key not available 4553 krb-ap-err-nokey ErrCode ::= 45 4554 -- Mutual authentication failed 4555 krb-ap-err-mut-fail ErrCode ::= 46 4556 -- Incorrect message direction 4557 krb-ap-err-baddirection ErrCode ::= 47 4558 -- Alternative authentication method required 4559 krb-ap-err-method ErrCode ::= 48 4560 -- Incorrect sequence number in message 4561 krb-ap-err-badseq ErrCode ::= 49 4562 -- Inappropriate type of checksum in message 4563 krb-ap-err-inapp-cksum ErrCode ::= 50 4564 -- Policy rejects transited path 4565 krb-ap-path-not-accepted ErrCode ::= 51 4566 -- Response too big for UDP, retry with TCP 4567 krb-err-response-too-big ErrCode ::= 52 4568 -- Generic error (description in e-text) 4569 krb-err-generic ErrCode ::= 60 4570 -- Field is too long for this implementation 4571 krb-err-field-toolong ErrCode ::= 61 4572 -- Reserved for PKINIT 4573 kdc-error-client-not-trusted ErrCode ::= 62 4574 -- Reserved for PKINIT 4575 kdc-error-kdc-not-trusted ErrCode ::= 63 4576 -- Reserved for PKINIT 4577 kdc-error-invalid-sig ErrCode ::= 64 4578 -- Reserved for PKINIT 4579 kdc-err-key-too-weak ErrCode ::= 65 4580 -- Reserved for PKINIT 4581 kdc-err-certificate-mismatch ErrCode ::= 66 4582 -- No TGT available to validate USER-TO-USER 4583 krb-ap-err-no-tgt ErrCode ::= 67 4584 -- USER-TO-USER TGT issued different KDC 4585 kdc-err-wrong-realm ErrCode ::= 68 4586 -- Ticket must be for USER-TO-USER 4587 krb-ap-err-user-to-user-required ErrCode ::= 69 4588 -- Reserved for PKINIT 4589 kdc-err-cant-verify-certificate ErrCode ::= 70 4590 -- Reserved for PKINIT 4591 kdc-err-invalid-certificate ErrCode ::= 71 4592 -- Reserved for PKINIT 4593 kdc-err-revoked-certificate ErrCode ::= 72 4594 -- Reserved for PKINIT 4595 kdc-err-revocation-status-unknown ErrCode ::= 73 4596 -- Reserved for PKINIT 4597 kdc-err-revocation-status-unavailable ErrCode ::= 74 4598 -- Reserved for PKINIT 4599 kdc-err-client-name-mismatch ErrCode ::= 75 4600 -- Reserved for PKINIT 4601 kdc-err-kdc-name-mismatch ErrCode ::= 76 4602 -- Reserved for PKINIT 4603 kdc-err-inconsistent-key-purpose ErrCode ::= 77 4604 -- Reserved for PKINIT 4605 kdc-err-digest-in-cert-not-accepted ErrCode ::= 78 4606 -- Reserved for PKINIT 4607 kdc-err-pa-checksum-must-be-included ErrCode ::= 79 4608 -- Reserved for PKINIT 4609 kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80 4610 -- Reserved for PKINIT 4611 kdc-err-public-key-encryption-not-supported ErrCode ::= 81 4612 -- [krb-wg-naming] 4613 krb-ap-err-wellknown-principal-name-unsupported ErrCode ::= 82 4614 -- [krb-wg-naming] 4615 krb-ap-err-wellknown-realm-name-not-supported ErrCode ::= 83 4616 -- [krb-wg-naming] 4617 krb-ap-err-reserved-principal-name-unknown ErrCode ::= 84 4618 -- IAKERB proxy could not find a KDC 4619 krb-ap-err-iakerb-kdc-not-found ErrCode ::= 85 4620 -- KDC did not respond to IAKERB proxy 4621 krb-ap-err-iakerb-kdc-no-response ErrCode ::= 86 4623 END 4625 B. Kerberos and Character Encodings (Informative) 4627 [adapted from RFC4120 5.2.1] 4629 The original specification of the Kerberos protocol in RFC 1510 uses 4630 GeneralString in numerous places for human-readable string data. 4631 Historical implementations of Kerberos cannot utilize the full power 4632 of GeneralString. This ASN.1 type requires the use of designation 4633 and invocation escape sequences as specified in ISO 2022 | ECMA-35 4634 [ISO2022] to switch character sets, and the default character set 4635 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] 4636 International Reference Version (IRV) (aka U.S. ASCII), which mostly 4637 works. 4639 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3) 4640 and two Control-function code elements (C0..C1). DER previously 4641 [X690-1997] prohibited the designation of character sets as any but 4642 the G0 and C0 sets. This had the side effect of prohibiting the use 4643 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any 4644 other character-sets that utilize a 96-character set, since it is 4645 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code 4646 element. Recent revisions to the ASN.1 standards resolve this 4647 contradiction. 4649 In practice, many implementations treat RFC 1510 GeneralStrings as if 4650 they were 8-bit strings of whichever character set the implementation 4651 defaults to, without regard for correct usage of character-set 4652 designation escape sequences. The default character set is often 4653 determined by the current user's operating system dependent locale. 4654 At least one major implementation places unescaped UTF-8 encoded 4655 Unicode characters in the GeneralString. This failure to conform to 4656 the GeneralString specifications results in interoperability issues 4657 when conflicting character encodings are utilized by the Kerberos 4658 clients, services, and KDC. 4660 This unfortunate situation is the result of improper documentation of 4661 the restrictions of the ASN.1 GeneralString type in prior Kerberos 4662 specifications. 4664 [the following should probably be rewritten and moved into the 4665 principal name section] 4667 For compatibility, implementations MAY choose to accept GeneralString 4668 values that contain characters other than those permitted by 4669 IA5String, but they should be aware that character set designation 4670 codes will likely be absent, and that the encoding should probably be 4671 treated as locale-specific in almost every way. Implementations MAY 4672 also choose to emit GeneralString values that are beyond those 4673 permitted by IA5String, but should be aware that doing so is 4674 extraordinarily risky from an interoperability perspective. 4676 Some existing implementations use GeneralString to encode unescaped 4677 locale-specific characters. This is a violation of the ASN.1 4678 standard. Most of these implementations encode US-ASCII in the left- 4679 hand half, so as long the implementation transmits only US-ASCII, the 4680 ASN.1 standard is not violated in this regard. As soon as such an 4681 implementation encodes unescaped locale-specific characters with the 4682 high bit set, it violates the ASN.1 standard. 4684 Other implementations have been known to use GeneralString to contain 4685 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 4686 is a different encoding, not a 94 or 96 character "G" set as defined 4687 by ISO 2022. It is believed that these implementations do not even 4688 use the ISO 2022 escape sequence to change the character encoding. 4689 Even if implementations were to announce the change of encoding by 4690 using that escape sequence, the ASN.1 standard prohibits the use of 4691 any escape sequences other than those used to designate/invoke "G" or 4692 "C" sets allowed by GeneralString. 4694 C. Kerberos History (Informative) 4696 [Adapted from RFC4120 "BACKGROUND"] 4698 The Kerberos model is based in part on Needham and Schroeder's 4699 trusted third-party authentication protocol [NS78] and on 4700 modifications suggested by Denning and Sacco [DS81]. The original 4701 design and implementation of Kerberos Versions 1 through 4 was the 4702 work of two former Project Athena staff members, Steve Miller of 4703 Digital Equipment Corporation and Clifford Neuman (now at the 4704 Information Sciences Institute of the University of Southern 4705 California), along with Jerome Saltzer, Technical Director of Project 4706 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 4707 members of Project Athena have also contributed to the work on 4708 Kerberos. 4710 Version 5 of the Kerberos protocol (described in this document) has 4711 evolved from Version 4 based on new requirements and desires for 4712 features not available in Version 4. The design of Version 5 of the 4713 Kerberos protocol was led by Clifford Neuman and John Kohl with much 4714 input from the community. The development of the MIT reference 4715 implementation was led at MIT by John Kohl and Theodore Ts'o, with 4716 help and contributed code from many others. Since RFC1510 was 4717 issued, extensions and revisions to the protocol have been proposed 4718 by many individuals. Some of these proposals are reflected in this 4719 document. Where such changes involved significant effort, the 4720 document cites the contribution of the proposer. 4722 Reference implementations of both version 4 and version 5 of Kerberos 4723 are publicly available and commercial implementations have been 4724 developed and are widely used. Details on the differences between 4725 Kerberos Versions 4 and 5 can be found in [KNT94]. 4727 D. Notational Differences from [RFC4120] 4729 [ possible point for discussion ] 4731 [RFC4120] uses notational conventions slightly different from this 4732 document. As a derivative of RFC 1510, the text of [RFC4120] uses 4733 C-language style identifier names for defined values. In ASN.1 4734 notation, identifiers referencing defined values must begin with a 4735 lowercase letter and contain hyphen (-) characters rather than 4736 underscore (_) characters, while identifiers referencing types begin 4737 with an uppercase letter. [RFC4120] and RFC 1510 use all-uppercase 4738 identifiers with underscores to identify defined values. This has 4739 the potential to create confusion, but neither document defines 4740 values using actual ASN.1 value-assignment notation. 4742 It is debatable whether it is advantageous to write all identifier 4743 names (regardless of their ASN.1 token type) in all-uppercase letters 4744 for the purpose of emphasis in running text. The alternative is to 4745 use double-quote characters (") when ambiguity is possible. 4747 Normative References 4749 [RFC2119] 4750 S. Bradner, "Key words for use in RFC's to Indicate Requirement 4751 Levels", RFC 2119, March 1997. 4753 [RFC3490] 4754 P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing 4755 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 4757 [RFC3961] 4758 K. Raeburn, "Encryption and Checksum Specifications for Kerberos 4759 5", RFC 3961, February 2005. 4761 [RFC4013] 4762 Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names 4763 and passwords", RFC 4013, February 2005. 4765 [RFC4291] 4766 R. Hinden and S. Deering, "IP Version 6 Addressing 4767 Architecture", RFC 4291, February 2006. 4769 [RFC4646] 4770 A. Philllips and M. Davis, "Tags for Identifying Languages", 4771 RFC 4646, January 2001. 4773 [X680] 4774 "Information technology -- Abstract Syntax Notation One (ASN.1): 4775 Specification of basic notation", ITU-T Recommendation X.680 4776 (2002) | ISO/IEC 8824-1:2002. 4778 [X682] 4779 "Information technology -- Abstract Syntax Notation One (ASN.1): 4780 Constraint specification", ITU-T Recommendation X.682 (2002) | 4781 ISO/IEC 8824-3:2002. 4783 [X683] 4784 "Information technology -- Abstract Syntax Notation One (ASN.1): 4785 Parameterization of ASN.1 specifications", ITU-T Recommendation 4786 X.683 (2002) | ISO/IEC 8824-4:2002. 4788 [X690] 4789 "Information technology -- ASN.1 encoding Rules: Specification 4790 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 4791 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 4792 X.690 (2002) | ISO/IEC 8825-1:2002. 4794 Informative References 4796 [DS81] 4797 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 4798 Distribution Protocols," Communications of the ACM, Vol. 24(8), 4799 pp. 533-536 (August 1981). 4801 [Dub00] 4802 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous 4803 Systems", Elsevier-Morgan Kaufmann, 2000. 4804 4806 [ISO646] 4807 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. 4809 [ISO2022] 4810 "Information technology -- Character code structure and 4811 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. 4813 [ISO8859-1] 4814 "Information technology -- 8-bit single-byte coded graphic 4815 character sets -- Part 1: Latin alphabet No. 1", 4816 ISO/IEC 8859-1:1998. 4818 [KNT94] 4819 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 4820 Evolution of the Kerberos Authentication System". In 4821 Distributed Open Systems, pages 78-94. IEEE Computer Society 4822 Press, 1994. 4824 [Lar96] 4825 John Larmouth, "Understanding OSI", International Thomson 4826 Computer Press, 1996. 4827 4829 [Lar99] 4830 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann, 4831 1999. 4833 [NS78] 4834 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 4835 Authentication in Large Networks of Computers", Communications 4836 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 4838 [RFC1510] 4839 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication 4840 Service (v5)", RFC1510, September 1993, Status: Proposed 4841 Standard. 4843 [RFC1964] 4844 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 4845 June 1996, Status: Proposed Standard. 4847 [RFC4120] 4848 C. Neuman, T. Yu, S. Hartman, K. Raeburn, "The Kerberos Network 4849 Authentication Service (V5)", RFC 4120, July 2005. 4851 Author's Address 4853 Tom Yu 4854 77 Massachusetts Ave 4855 Cambridge, MA 02139 4856 USA 4857 tlyu@mit.edu 4859 Full Copyright Statement 4861 Copyright (C) The IETF Trust (2007). 4863 This document is subject to the rights, licenses and restrictions 4864 contained in BCP 78, and except as set forth therein, the authors 4865 retain all their rights. 4867 This document and the information contained herein are provided on an 4868 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4869 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4870 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4871 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4872 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4873 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4875 Intellectual Property 4877 The IETF takes no position regarding the validity or scope of any 4878 Intellectual Property Rights or other rights that might be claimed to 4879 pertain to the implementation or use of the technology described in 4880 this document or the extent to which any license under such rights 4881 might or might not be available; nor does it represent that it has 4882 made any independent effort to identify any such rights. Information 4883 on the procedures with respect to rights in RFC documents can be 4884 found in BCP 78 and BCP 79. 4886 Copies of IPR disclosures made to the IETF Secretariat and any 4887 assurances of licenses to be made available, or the result of an 4888 attempt made to obtain a general license or permission for the use of 4889 such proprietary rights by implementers or users of this 4890 specification can be obtained from the IETF on-line IPR repository at 4891 http://www.ietf.org/ipr. 4893 The IETF invites any interested party to bring to its attention any 4894 copyrights, patents or patent applications, or other proprietary 4895 rights that may cover technology that may be required to implement 4896 this standard. Please address the information to the IETF at 4897 ietf-ipr@ietf.org.