idnits 2.17.1 draft-ietf-krb-wg-rfc1510ter-02.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 on line 4790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4814. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 4782), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (23 October 2005) is 6761 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 427, but not defined == Missing Reference: 'RFC3066' is mentioned on line 691, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Looks like a reference, but probably isn't: '0' on line 4400 -- Looks like a reference, but probably isn't: '1' on line 4401 == Missing Reference: 'RFC2373' is mentioned on line 777, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Missing Reference: 'RFC 2253' is mentioned on line 3422, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'RFC3490' is mentioned on line 991, but not defined ** Obsolete undefined reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Looks like a reference, but probably isn't: '2' on line 4376 == Missing Reference: 'APPLICATION 3' is mentioned on line 3672, but not defined -- Looks like a reference, but probably isn't: '3' on line 4377 -- Looks like a reference, but probably isn't: '4' on line 4378 -- Looks like a reference, but probably isn't: '5' on line 4379 -- Looks like a reference, but probably isn't: '6' on line 4380 -- Looks like a reference, but probably isn't: '7' on line 4381 -- Looks like a reference, but probably isn't: '8' on line 4382 -- Looks like a reference, but probably isn't: '9' on line 4383 -- Looks like a reference, but probably isn't: '10' on line 4384 == Missing Reference: 'APPLICATION 5' is mentioned on line 3685, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 3643, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 3652, but not defined -- Looks like a reference, but probably isn't: '11' on line 4385 == Missing Reference: 'APPLICATION 10' is mentioned on line 3786, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 3790, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 3799, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 3802, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 3982, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 3983, but not defined == Missing Reference: 'APPLICATION 32' is mentioned on line 3985, but not defined == Missing Reference: 'APPLICATION 33' is mentioned on line 3986, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 3913, but not defined == Missing Reference: 'APPLICATION 7' is mentioned on line 3915, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 3923, but not defined == Missing Reference: 'APPLICATION 9' is mentioned on line 3925, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 2803, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 4356, but not defined -- Looks like a reference, but probably isn't: '12' on line 4386 == Missing Reference: 'APPLICATION 23' is mentioned on line 4373, but not defined -- Looks like a reference, but probably isn't: '13' on line 4388 -- Looks like a reference, but probably isn't: '14' on line 4389 -- Looks like a reference, but probably isn't: '15' on line 4390 == Missing Reference: 'APPLICATION 2' is mentioned on line 4148, but not defined == Missing Reference: 'APPLICATION 35' is mentioned on line 4162, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 4100, but not defined == Missing Reference: 'APPLICATION 18' is mentioned on line 4114, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 4214, but not defined == Missing Reference: 'APPLICATION 31' is mentioned on line 4221, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 4182, but not defined == Missing Reference: 'APPLICATION 19' is mentioned on line 4190, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 4270, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 4278, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 4295, but not defined == Missing Reference: 'APPLICATION 24' is mentioned on line 4305, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 4316, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 4239, but not defined == Missing Reference: 'APPLICATION 34' is mentioned on line 4249, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 4338, but not defined == Missing Reference: 'X690-1997' is mentioned on line 4560, but not defined == Unused Reference: 'RFC2119' is defined on line 4679, but no explicit reference was found in the text == Unused Reference: 'RFC3660' is defined on line 4683, but no explicit reference was found in the text == Unused Reference: 'Lar96' is defined on line 4741, but no explicit reference was found in the text == Unused Reference: 'X690-2002' is defined on line 4764, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO646' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO2022' ** Downref: Normative reference to an Informational RFC: RFC 3660 -- 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: 12 errors (**), 0 flaws (~~), 49 warnings (==), 30 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-02.txt MIT 4 Expires: 26 April 2006 23 October 2005 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 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes version 5 of the Kerberos network 40 authentication protocol. It describes a framework to allow for 41 extensions to be made to the protocol without creating 42 interoperability problems. 44 Key Words for Requirements 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 48 to be interpreted as described in RFC 2119. 50 Table of Contents 52 Status of This Memo .............................................. 1 53 Copyright Notice ................................................. 1 54 Abstract ......................................................... 1 55 Key Words for Requirements ....................................... 1 56 Table of Contents ................................................ 2 57 1. Introduction ................................................. 5 58 1.1. Kerberos Protocol Overview ................................. 5 59 1.2. Document Organization ...................................... 6 60 2. Compatibility Considerations ................................. 6 61 2.1. Extensibility .............................................. 6 62 2.2. Compatibility with RFC 1510 ................................ 7 63 2.3. Backwards Compatibility .................................... 7 64 2.4. Sending Extensible Messages ................................ 8 65 2.5. Criticality ................................................ 8 66 2.6. Authenticating Cleartext Portions of Messages .............. 9 67 2.7. Capability Negotiation ..................................... 10 68 3. Use of ASN.1 in Kerberos ..................................... 10 69 3.1. Module Header .............................................. 11 70 3.2. Top-Level Type ............................................. 11 71 3.3. Previously Unused ASN.1 Notation (informative) ............. 12 72 3.3.1. Parameterized Types ...................................... 12 73 3.3.2. Constraints .............................................. 12 74 3.4. New Types .................................................. 12 75 4. Basic Types .................................................. 12 76 4.1. Constrained Integer Types .................................. 12 77 4.2. KerberosTime ............................................... 13 78 4.3. KerberosString ............................................. 14 79 4.4. Language Tags .............................................. 14 80 4.5. KerberosFlags .............................................. 14 81 4.6. Typed Holes ................................................ 15 82 4.7. HostAddress and HostAddresses .............................. 15 83 4.7.1. Internet (IPv4) Addresses ................................ 16 84 4.7.2. Internet (IPv6) Addresses ................................ 16 85 4.7.3. DECnet Phase IV addresses ................................ 17 86 4.7.4. Netbios addresses ........................................ 17 87 4.7.5. Directional Addresses .................................... 17 88 5. Principals ................................................... 17 89 5.1. Name Types ................................................. 17 90 5.2. Principal Type Definition .................................. 18 91 5.3. Principal Name Reuse ....................................... 19 92 5.4. Best Common Practice Recommendations for the Processing 93 of Principal Names Consisting of Internationalized 94 Domain Names: ........................................... 19 95 5.5. Realm Names ................................................ 20 96 5.6. Best Common Practice Recommendations for the Processing 97 of Internationalized Domain-Style Realm Names: .......... 20 98 5.7. Printable Representations of Principal Names ............... 21 99 5.8. Ticket-Granting Service Principal .......................... 21 100 5.8.1. Cross-Realm TGS Principals ............................... 22 101 6. Types Relating to Encryption ................................. 22 102 6.1. Assigned Numbers for Encryption ............................ 22 103 6.1.1. EType .................................................... 22 104 6.1.2. Key Usages ............................................... 23 105 6.2. Which Key to Use ........................................... 24 106 6.3. EncryptionKey .............................................. 25 107 6.4. EncryptedData .............................................. 25 108 6.5. Checksums .................................................. 26 109 6.5.1. ChecksumOf ............................................... 27 110 6.5.2. Signed ................................................... 28 111 7. Tickets ...................................................... 28 112 7.1. Timestamps ................................................. 29 113 7.2. Ticket Flags ............................................... 30 114 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 30 115 7.2.2. Invalid Tickets .......................................... 31 116 7.2.3. OK as Delegate ........................................... 31 117 7.2.4. Renewable Tickets ........................................ 32 118 7.2.5. Postdated Tickets ........................................ 32 119 7.2.6. Proxiable and Proxy Tickets .............................. 33 120 7.2.7. Forwarded and Forwardable Tickets ........................ 34 121 7.3. Transited Realms ........................................... 35 122 7.4. Authorization Data ......................................... 35 123 7.4.1. AD-IF-RELEVANT ........................................... 36 124 7.4.2. AD-KDCIssued ............................................. 37 125 7.4.3. AD-AND-OR ................................................ 38 126 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 38 127 7.5. Encrypted Part of Ticket ................................... 39 128 7.6. Cleartext Part of Ticket ................................... 39 129 8. Credential Acquisition ....................................... 41 130 8.1. KDC-REQ .................................................... 41 131 8.2. PA-DATA .................................................... 48 132 8.3. KDC-REQ Processing ......................................... 48 133 8.3.1. Handling Replays ......................................... 48 134 8.3.2. Request Validation ....................................... 49 135 8.3.2.1. AS-REQ Authentication .................................. 49 136 8.3.2.2. TGS-REQ Authentication ................................. 49 137 8.3.2.3. Principal Validation ................................... 49 138 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 49 139 8.3.3. Timestamp Handling ....................................... 50 140 8.3.3.1. AS-REQ Timestamp Processing ............................ 50 141 8.3.3.2. TGS-REQ Timestamp Processing ........................... 51 142 8.3.4. Handling Transited Realms ................................ 52 143 8.3.5. Address Processing ....................................... 52 144 8.3.6. Ticket Flag Processing ................................... 52 145 8.3.7. Key Selection ............................................ 54 146 8.3.7.1. Reply Key and Session Key Selection .................... 54 147 8.3.7.2. Ticket Key Selection ................................... 54 148 8.4. KDC-REP .................................................... 54 149 8.5. Reply Validation ........................................... 58 150 8.6. IP Transports .............................................. 58 151 8.6.1. UDP/IP transport ......................................... 58 152 8.6.2. TCP/IP transport ......................................... 58 153 8.6.3. KDC Discovery on IP Networks ............................. 60 154 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 60 155 8.6.3.2. DNS SRV records for KDC location ....................... 60 156 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP 157 Networks ............................................ 61 158 9. Errors ....................................................... 61 159 10. Session Key Exchange ........................................ 63 160 10.1. AP-REQ .................................................... 64 161 10.2. AP-REP .................................................... 65 162 11. Session Key Use ............................................. 67 163 11.1. KRB-SAFE .................................................. 67 164 11.2. KRB-PRIV .................................................. 67 165 11.3. KRB-CRED .................................................. 68 166 12. Security Considerations ..................................... 69 167 12.1. Time Synchronization ...................................... 69 168 12.2. Replays ................................................... 69 169 12.3. Principal Name Reuse ...................................... 70 170 12.4. Password Guessing ......................................... 70 171 12.5. Forward Secrecy ........................................... 70 172 12.6. Authorization ............................................. 70 173 12.7. Login Authentication ...................................... 70 174 13. IANA Considerations ......................................... 70 175 14. Acknowledgments ............................................. 71 176 Appendices ....................................................... 71 177 A. ASN.1 Module (Normative) ..................................... 71 178 B. Kerberos and Character Encodings (Informative) ...............103 179 C. Kerberos History (Informative) ...............................104 180 D. Notational Differences from [KCLAR] ..........................105 181 Normative References .............................................106 182 Informative References ...........................................106 183 Author's Address .................................................108 184 Copyright Statement ..............................................108 185 Intellectual Property Statement ..................................108 187 1. Introduction 189 The Kerberos network authentication protocol is a trusted-third-party 190 protocol utilizing symmetric-key cryptography. It assumes that all 191 communications between parties in the protocol may be arbitrarily 192 tampered with or monitored, and that the security of the overall 193 system depends only on the effectiveness of the cryptographic 194 techniques and the secrecy of the cryptographic keys used. The 195 Kerberos protocol authenticates an application client's identity to 196 an application server, and likewise authenticates the application 197 server's identity to the application client. These assurances are 198 made possible by the client and the server sharing secrets with the 199 trusted third party: the Kerberos server, also known as the Key 200 Distribution Center (KDC). In addition, the protocol establishes an 201 ephemeral shared secret (the session key) between the client and the 202 server, allowing the protection of further communications between 203 them. 205 The Kerberos protocol, as originally specified, provides insufficient 206 means for extending the protocol in a backwards-compatible way. This 207 deficiency has caused problems for interoperability. This document 208 describes a framework which enables backwards-compatible extensions 209 to the Kerberos protocol. 211 1.1. Kerberos Protocol Overview 213 Kerberos comprises three main sub-protocols: credentials acquisition, 214 session key exchange, and session key usage. A client acquires 215 credentials by asking the KDC for a credential for a service; the KDC 216 issues the credential, which contains a ticket and a session key. 217 The ticket, containing the client's identity, timestamps, expiration 218 time, and a session key, is a encrypted in a key known to the 219 application server. The KDC encrypts the credential using a key 220 known to the client, and transmits the credential to the client. 222 There are two means of requesting credentials: the Authentication 223 Service (AS) exchange, and the Ticket-Granting Service (TGS) 224 exchange. In the typical AS exchange, a client uses a password- 225 derived key to decrypt the response. In the TGS exchange, the KDC 226 behaves as an application server; the client authenticates to the TGS 227 by using a Ticket-Granting Ticket (TGT). The client usually obtains 228 the TGT by using the AS exchange. 230 Session key exchange consists of the client transmitting the ticket 231 to the application server, accompanied by an authenticator. The 232 authenticator contains a timestamp and additional data encrypted 233 using the ticket's session key. The application server decrypts the 234 ticket, extracting the session key. The application server then uses 235 the session key to decrypt the authenticator. Upon successful 236 decryption of the authenticator, the application server knows that 237 the data in the authenticator were sent by the client named in the 238 associated ticket. Additionally, since authenticators expire more 239 quickly than tickets, the application server has some assurance that 240 the transaction is not a replay. The application server may send an 241 encrypted acknowledgment to the client, verifying its identity to the 242 client. 244 Once session key exchange has occurred, the client and server may use 245 the established session key to protect further traffic. This 246 protection may consist of protection of integrity only, or of 247 protection of confidentiality and integrity. Additional measures 248 exist for a client to securely forward credentials to a server. 250 The entire scheme depends on loosely synchronized clocks. 251 Synchronization of the clock on the KDC with the application server 252 clock allows the application server to accurately determine whether a 253 credential is expired. Likewise, synchronization of the clock on the 254 client with the application server clock prevents replay attacks 255 utilizing the same credential. Careful design of the application 256 protocol may allow replay prevention without requiring client-server 257 clock synchronization. 259 After establishing a session key, application client and the 260 application server can exchange Kerberos protocol messages that use 261 the session key to protect the integrity or confidentiality of 262 communications between the client and the server. Additionally, the 263 client may forward credentials to the application server. 265 The credentials acquisition protocol takes place over specific, 266 defined transports (UDP and TCP). Application protocols define which 267 transport to use for the session key establishment protocol and for 268 messages using the session key; the application may choose to perform 269 its own encapsulation of the Kerberos messages, for example. 271 1.2. Document Organization 273 The remainder of this document begins by describing the general 274 frameworks for protocol extensibility, including whether to interpret 275 unknown extensions as critical. It then defines the protocol 276 messages and exchanges. 278 The definition of the Kerberos protocol uses Abstract Syntax Notation 279 One (ASN.1) [X680], which specifies notation for describing the 280 abstract content of protocol messages. This document defines a 281 number of base types using ASN.1; these base types subsequently 282 appear in multiple types which define actual protocol messages. 283 Definitions of principal names and of tickets, which are central to 284 the protocol, also appear preceding the protocol message definitions. 286 2. Compatibility Considerations 287 2.1. Extensibility 289 In the past, significant interoperability problems have resulted from 290 conflicting assumptions about how the Kerberos protocol can be 291 extended. As the deployed base of Kerberos grows, the ability to 292 extend the Kerberos protocol becomes more important. In order to 293 ensure that vendors and the IETF can extend the protocol while 294 maintaining backwards compatibility, this document outlines a 295 framework for extending Kerberos. 297 Kerberos provides two general mechanisms for protocol extensibility. 298 Many protocol messages, including some defined in RFC 1510, contain 299 typed holes--sub-messages containing an octet string along with an 300 integer that identifies how to interpret the octet string. The 301 integer identifiers are registered centrally, but can be used both 302 for vendor extensions and for extensions standardized in the IETF. 303 This document adds typed holes to a number of messages which 304 previously lacked typed holes. 306 Many new messages defined in this document also contain ASN.1 307 extension markers. These markers allow future revisions of this 308 document to add additional elements to messages, for cases where 309 typed holes are inadequate for some reason. Because tag numbers and 310 position in a sequence need to be coordinated in order to maintain 311 interoperability, implementations MUST NOT include ASN.1 extensions 312 except when those extensions are specified by IETF standards-track 313 documents. 315 2.2. Compatibility with RFC 1510 317 Implementations of RFC 1510 did not use extensible ASN.1 types. 318 Sending additional fields not in RFC 1510 to these implementations 319 results in undefined behavior. Examples of this behavior are known 320 to include discarding messages with no error indications. 322 Where messages have been changed since RFC 1510, ASN.1 CHOICE types 323 are used; one alternative of the CHOICE provides a message which is 324 wire-encoding compatible with RFC 1510, and the other alternative 325 provides the new, extensible message. 327 Implementations sending new messages MUST ensure that the recipient 328 supports these new messages. Along with each extensible message is a 329 guideline for when that message MAY be used. If that guideline is 330 followed, then the recipient is guaranteed to understand the message. 332 2.3. Backwards Compatibility 334 This document describes two sets (for the most part) of ASN.1 types. 335 The first set of types is wire-encoding compatible with RFC 1510 and 336 [KCLAR]. The second set of types is the set of types enabling 337 extensibility. This second set may be referred to as "extensibility- 338 enabled types". [ need to make this consistent throughout? ] 340 A major difference between the new extensibility-enabled types and 341 the types for RFC 1510 compatibility is that the extensibility- 342 enabled types allow for the use of UTF-8 encodings in various 343 character strings in the protocol. Each party in the protocol must 344 have some knowledge of the capabilities of the other parties in the 345 protocol. There are methods for establishing this knowledge without 346 necessarily requiring explicit configuration. 348 An extensibility-enabled client can detect whether a KDC supports the 349 extensibility-enabled types by requesting an extensibility-enabled 350 reply. If the KDC replies with an extensibility-enabled reply, the 351 client knows that the KDC supports extensibility. If the KDC issues 352 an extensibility-enabled ticket, the client knows that the service 353 named in the ticket is extensibility-enabled. 355 2.4. Sending Extensible Messages 357 Care must be taken to make sure that old implementations can 358 understand messages sent to them even if they do not understand an 359 extension that is used. Unless the sender knows the extension is 360 supported, the extension cannot change the semantics of the core 361 message or previously defined extensions. 363 For example, an extension including key information necessary to 364 decrypt the encrypted part of a KDC-REP could only be used in 365 situations where the recipient was known to support the extension. 366 Thus when designing such extensions it is important to provide a way 367 for the recipient to notify the sender of support for the extension. 368 For example in the case of an extension that changes the KDC-REP 369 reply key, the client could indicate support for the extension by 370 including a padata element in the AS-REQ sequence. The KDC should 371 only use the extension if this padata element is present in the AS- 372 REQ. Even if policy requires the use of the extension, it is better 373 to return an error indicating that the extension is required than to 374 use the extension when the recipient may not support it; debugging 375 why implementations do not interoperate is easier when errors are 376 returned. 378 2.5. Criticality 380 Recipients of unknown message extensions (including typed holes, new 381 flags, and ASN.1 extension elements) should preserve the encoding of 382 the extension but otherwise ignore the presence of the extension; 383 i.e., unknown extensions SHOULD be treated as non-critical. If a 384 copy of the message is used later--for example, when a Ticket 385 received in a KDC-REP is later used in an AP-REQ--then the unknown 386 extensions MUST be included. 388 An implementation SHOULD NOT reject a request merely because it does 389 not understand some element of the request. As a related 390 consequence, implementations SHOULD handle communicating with other 391 implementations which do not implement some requested options. This 392 may require designers of options to provide means to determine 393 whether an option has been rejected, not understood, or (perhaps 394 maliciously) deleted or modified in transit. 396 There is one exception to non-criticality described above: if an 397 unknown authorization data element is received by a server either in 398 an AP-REQ or in a Ticket contained in an AP-REQ, then the 399 authentication SHOULD fail. Authorization data is intended to 400 restrict the use of a ticket. If the service cannot determine 401 whether the restriction applies to that service then a security 402 weakness may result if authentication succeeds. Authorization 403 elements meant to be truly optional can be enclosed in the AD-IF- 404 RELEVANT element. 406 Many RFC 1510 implementations ignore unknown authorization data 407 elements. Depending on these implementations to honor authorization 408 data restrictions may create a security weakness. 410 2.6. Authenticating Cleartext Portions of Messages 412 Various denial of service attacks and downgrade attacks against 413 Kerberos are possible unless plaintexts are somehow protected against 414 modification. An early design goal of Kerberos Version 5 was to 415 avoid encrypting more of the authentication exchange that was 416 required. (Version 4 doubly-encrypted the encrypted part of a ticket 417 in a KDC reply, for example.) This minimization of encryption 418 reduces the load on the KDC and busy servers. Also, during the 419 initial design of Version 5, the existence of legal restrictions on 420 the export of cryptography made it desirable to minimize of the 421 number of uses of encryption in the protocol. Unfortunately, 422 performing this minimization created numerous instances of 423 unauthenticated security-relevant plaintext fields. 425 The extensible variants of the messages described in this document 426 wrap the actual message in an ASN.1 sequence containing a keyed 427 checksum of the contents of the message. Guidelines in [XXX] section 428 3 specify when the checksum MUST be included and what key MUST be 429 used. Guidelines on when to include a checksum are never ambiguous: 430 a particular PDU is never correct both with and without a checksum. 431 With the exception of the KRB-ERROR message, receiving 432 implementations MUST reject messages where a checksum is included and 433 not expected or where a checksum is expected but not included. The 434 receiving implementation does not always have sufficient information 435 to know whether a KRB-ERROR should contain a checksum. Even so, KRB- 436 ERROR messages with invalid checksums MUST be rejected and 437 implementations MAY consider the presence or absence of a checksum 438 when evaluating whether to trust the error. 440 This authenticated cleartext protection is provided only in the 441 extensible variants of the messages; it is never used when 442 communicating with an RFC 1510 implementation. 444 2.7. Capability Negotiation 446 Kerberos is a three-party protocol. Each of the three parties 447 involved needs a means of detecting the capabilities supported by the 448 others. Two of the parties, the KDC and the application server, do 449 not communicate directly in the Kerberos protocol. Communicating 450 capabilities from the KDC to the application server requires using a 451 ticket as an intermediary. 453 The main capability requiring negotiation is the support of the 454 extensibility framework described in this document. Negotiation of 455 this capability while remaining compatible with RFC 1510 456 implementations is possible. The main complication is that the 457 client needs to know whether the application server supports the 458 extensibility framework prior to sending any message to the 459 application server. This can be accomplished if the KDC has 460 knowledge of whether an application server supports the extensibility 461 framework. 463 Client software advertizes its capabilities when requesting 464 credentials from the KDC. If the KDC recognizes the capabilities, it 465 acknowledges this fact to the client in its reply. In addition, if 466 the KDC has knowledge that the application server supports certain 467 capabilities, it also communicates this knowledge to the client in 468 its reply. The KDC can encode its own capabilities in the ticket so 469 that the application server may discover these capabilities. The 470 client advertizes its capabilities to the application server when it 471 initiates authentication to the application server. 473 3. Use of ASN.1 in Kerberos 475 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. 476 Even though ASN.1 theoretically allows the description of protocol 477 messages to be independent of the encoding rules used to encode the 478 messages, Kerberos messages MUST be encoded with DER. Subtleties in 479 the semantics of the notation, such as whether tags carry any 480 semantic content to the application, may cause the use of other ASN.1 481 encoding rules to be problematic. 483 Implementors not using existing ASN.1 tools (e.g., compilers or 484 support libraries) are cautioned to thoroughly read and understand 485 the actual ASN.1 specification to ensure correct implementation 486 behavior. There is more complexity in the notation than is 487 immediately obvious, and some tutorials and guides to ASN.1 are 488 misleading or erroneous. Recommended tutorials and guides include 489 [Dub00], [Lar99], though there is still no substitute for reading the 490 actual ASN.1 specification. 492 3.1. Module Header 494 The type definitions in this document assume an ASN.1 module 495 definition of the following form: 497 KerberosV5Spec3 { 498 iso(1) identified-organization(3) dod(6) internet(1) 499 security(5) kerberosV5(2) modules(4) krb5spec3(4) 500 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 502 -- Rest of definitions here 504 END 506 This specifies that the tagging context for the module will be 507 explicit and that automatic tagging is not done. 509 Some other publications [RFC1510] [RFC1964] erroneously specify an 510 object identifier (OID) having an incorrect value of "5" for the 511 "dod" component of the OID. In the case of RFC 1964, use of the 512 "correct" OID value would result in a change in the wire protocol; 513 therefore, the RFC 1964 OID remains unchanged for now. 515 3.2. Top-Level Type 517 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol 518 Data Units or PDUs) which an application may directly reference. 519 Applications SHOULD NOT transmit any types other than those which are 520 alternatives of the KRB-PDU CHOICE. 522 -- top-level type 523 -- 524 -- Applications should not directly reference any types 525 -- other than KRB-PDU and its component types. 526 -- 527 KRB-PDU ::= CHOICE { 528 ticket Ticket, 529 as-req AS-REQ, 530 as-rep AS-REP, 531 tgs-req TGS-REQ, 532 tgs-rep TGS-REP, 533 ap-req AP-REQ, 534 ap-rep AP-REP, 535 krb-safe KRB-SAFE, 536 krb-priv KRB-PRIV, 537 krb-cred KRB-CRED, 538 tgt-req TGT-REQ, 539 krb-error KRB-ERROR, 540 ... 541 } 543 3.3. Previously Unused ASN.1 Notation (informative) 545 Some aspects of ASN.1 notation used in this document were not used in 546 [KCLAR], and may be unfamiliar to some readers. This subsection is 547 informative; for normative definitions of the notation, see the 548 actual ASN.1 specifications [X680], [X682], [X683]. 550 3.3.1. Parameterized Types 552 This document uses ASN.1 parameterized types [X683] to make 553 definitions of types more readable. For some types, some or all of 554 the parameters are advisory, i.e., they are not encoded in any form 555 for transmission in a protocol message. These advisory parameters 556 can describe implementation behavior associated with the type. 558 3.3.2. Constraints 560 This document uses ASN.1 constraints, including the 561 "UserDefinedConstraint" notation [X682]. Some constraints can be 562 handled automatically by tools that can parse them. Uses of the 563 "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will 564 typically need to have behavior manually coded; the notation provides 565 a formalized way of conveying intended implementation behavior. 567 The "WITH COMPONENTS" constraint notation allows constraints to apply 568 to component types of a SEQUENCE type. This constraint notation 569 effectively allows constraints to "reach into" a type to constrain 570 its component types. 572 3.4. New Types 574 This document defines a number of ASN.1 types which are new since 575 [KCLAR]. The names of these types will typically have a suffix like 576 "Ext", indicating that the types are intended to support 577 extensibility. Types original to RFC 1510 and [KCLAR] have been 578 renamed to have a suffix like "1510". The "Ext" and "1510" types 579 often contain a number of common elements, but differ primarily in 580 the way strings are encoded. 582 4. Basic Types 584 These "basic" Kerberos ASN.1 types appear in multiple other Kerberos 585 types. 587 4.1. Constrained Integer Types 589 In RFC 1510, many types contained references to the unconstrained 590 INTEGER type. Since an unconstrained INTEGER can contain almost any 591 possible abstract integer value, most of the unconstrained references 592 to INTEGER in RFC 1510 were constrained to 32 bits or smaller in 593 [KCLAR]. 595 -- signed values representable in 32 bits 596 -- 597 -- These are often used as assigned numbers for various things. 598 Int32 ::= INTEGER (-2147483648..2147483647) 600 The "Int32" type often contains an assigned number identifying the 601 contents of a typed hole. Unless otherwise stated, non-negative 602 values are registered, and negative values are available for local 603 use. 605 -- unsigned 32 bit values 606 UInt32 ::= INTEGER (0..4294967295) 608 The "UInt32" type is used in some places where an unsigned 32-bit 609 integer is needed. 611 -- unsigned 64 bit values 612 UInt64 ::= INTEGER (0..18446744073709551615) 614 The "UInt64" type is used in places where 32 bits of precision may 615 provide inadequate security. 617 -- sequence numbers 618 SeqNum ::= UInt64 620 Sequence numbers were constrained to 32 bits in [KCLAR], but this 621 document allows for 64-bit sequence numbers. 623 -- nonces 624 Nonce ::= UInt64 626 Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded 627 to 64 bits here. 629 -- microseconds 630 Microseconds ::= INTEGER (0..999999) 632 The "microseconds" type is intended to carry the microseconds part of 633 a time value. 635 4.2. KerberosTime 637 KerberosTime ::= GeneralizedTime (CONSTRAINED BY { 638 -- MUST NOT include fractional seconds 639 }) 641 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 642 KerberosTime value MUST NOT include any fractional portions of the 643 seconds. As required by the DER, it further MUST NOT include any 644 separators, and it specifies the UTC time zone (Z). Example: The 645 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 646 November 1985 is "19851106210627Z". 648 4.3. KerberosString 650 -- used for names and for error messages 651 KerberosString ::= CHOICE { 652 ia5 GeneralString (IA5String), 653 utf8 UTF8String, 654 ... -- no extension may be sent 655 -- to an rfc1510 implementation -- 656 } 658 The KerberosString type is used for character strings in various 659 places in the Kerberos protocol. For compatibility with RFC 1510, 660 GeneralString values constrained to IA5String (US-ASCII) are 661 permitted in messages exchanged with RFC 1510 implementations. The 662 new protocol messages contain strings encoded as UTF-8, and these 663 strings MUST be normalized using [SASLPREP]. KerberosString values 664 are present in principal names and in error messages. Control 665 characters SHOULD NOT be used in principal names, and used with 666 caution in error messages. 668 -- IA5 choice only; useful for constraints 669 KerberosStringIA5 ::= KerberosString 670 (WITH COMPONENTS { ia5 PRESENT }) 672 -- IA5 excluded; useful for constraints 673 KerberosStringExt ::= KerberosString 674 (WITH COMPONENTS { ia5 ABSENT }) 676 KerberosStringIA5 requires the use of the "ia5" alternative, while 677 KerberosStringExt forbids it. These types appear in ASN.1 678 constraints on messages. 680 For detailed background regarding the history of character string use 681 in Kerberos, as well as discussion of some compatibility issues, see 682 Appendix B. 684 4.4. Language Tags 686 -- used for language tags 687 LangTag ::= PrintableString 688 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 690 The "LangTag" type is used to specify language tags for localization 691 purposes, using the [RFC3066] format. 693 4.5. KerberosFlags 695 For several message types, a specific constrained bit string type, 696 KerberosFlags, is used. 698 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 699 (CONSTRAINED BY { 700 -- MUST be a valid value of -- NamedBits 701 -- but if the value to be sent would be truncated to shorter 702 -- than 32 bits according to DER, the value MUST be padded 703 -- with trailing zero bits to 32 bits. Otherwise, no 704 -- trailing zero bits may be present. 706 }) 708 The actual bit string type encoded in Kerberos messages does not use 709 named bits. The advisory parameter of the KerberosFlags type names a 710 bit string type defined using named bits, whose value is encoded as 711 if it were a bit string with unnamed bits. This practice is 712 necessary because the DER require trailing zero bits to be removed 713 when encoding bit strings defined using named bits. Existing 714 implementations of Kerberos send exactly 32 bits rather than 715 truncating, so the size constraint requires the transmission of at 716 least 32 bits. Trailing zero bits beyond the first 32 bits are 717 truncated. 719 4.6. Typed Holes 721 -- Typed hole identifiers 722 TH-id ::= CHOICE { 723 int32 Int32, 724 rel-oid RELATIVE-OID 725 } 727 The "TH-id" type is a generalized means to identify the contents of a 728 typed hole. The "int32" alternative may be used for simple integer 729 assignments, in the same manner as "Int32", while the "rel-oid" 730 alternative may be used for hierarchical delegation. 732 4.7. HostAddress and HostAddresses 734 AddrType ::= Int32 736 HostAddress ::= SEQUENCE { 737 addr-type [0] AddrType, 738 address [1] OCTET STRING 739 } 741 -- NOTE: HostAddresses is always used as an OPTIONAL field and 742 -- should not be a zero-length SEQUENCE OF. 743 -- 744 -- The extensible messages explicitly constrain this to be 745 -- non-empty. 746 HostAddresses ::= SEQUENCE OF HostAddress 748 addr-type 749 This field specifies the type of address that follows. 751 address 752 This field encodes a single address of the type identified by 753 "addr-type". 755 All negative values for the host address type are reserved for local 756 use. All non-negative values are reserved for officially assigned 757 type fields and interpretations. 759 | 760 addr-type | meaning 761 -----------+-------------- 762 2 | IPv4 763 3 | directional 764 12 | DECnet 765 20 | NetBIOS 766 24 | IPv6 768 4.7.1. Internet (IPv4) Addresses 770 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in 771 MSB order (most significant byte first). The IPv4 loopback address 772 SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is 773 two (2). 775 4.7.2. Internet (IPv6) Addresses 777 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded 778 in MSB order (most significant byte first). The type of IPv6 779 addresses is twenty-four (24). The following addresses MUST NOT 780 appear in any Kerberos PDU: 782 * the Unspecified Address 784 * the Loopback Address 786 * Link-Local addresses 788 This restriction applies to the inclusion in the address fields of 789 Kerberos PDUs, but not to the address fields of packets that might 790 carry such PDUs. The restriction is necessary because the use of an 791 address with non-global scope could allow the acceptance of a message 792 sent from a node that may have the same address, but which is not the 793 host intended by the entity that added the restriction. If the link- 794 local address type needs to be used for communication, then the 795 address restriction in tickets must not be used (i.e. addressless 796 tickets must be used). 798 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 799 2. 801 4.7.3. DECnet Phase IV addresses 803 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. 804 The type of DECnet Phase IV addresses is twelve (12). 806 4.7.4. Netbios addresses 808 Netbios addresses are 16-octet addresses typically composed of 1 to 809 15 alphanumeric characters and padded with the US-ASCII SPC character 810 (code 32). The 16th octet MUST be the US-ASCII NUL character (code 811 0). The type of Netbios addresses is twenty (20). 813 4.7.5. Directional Addresses 815 In many environments, including the sender address in KRB-SAFE and 816 KRB-PRIV messages is undesirable because the addresses may be changed 817 in transport by network address translators. However, if these 818 addresses are removed, the messages may be subject to a reflection 819 attack in which a message is reflected back to its originator. The 820 directional address type provides a way to avoid transport addresses 821 and reflection attacks. Directional addresses are encoded as four 822 byte unsigned integers in network byte order. If the message is 823 originated by the party sending the original AP-REQ message, then an 824 address of 0 SHOULD be used. If the message is originated by the 825 party to whom that AP-REQ was sent, then the address 1 SHOULD be 826 used. Applications involving multiple parties can specify the use of 827 other addresses. 829 Directional addresses MUST only be used for the sender address field 830 in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a 831 ticket address or in a AP-REQ message. This address type SHOULD only 832 be used in situations where the sending party knows that the 833 receiving party supports the address type. This generally means that 834 directional addresses may only be used when the application protocol 835 requires their support. Directional addresses are type (3). 837 5. Principals 839 Principals are participants in the Kerberos protocol. A "realm" 840 consists of principals in one administrative domain, served by one 841 KDC (or one replicated set of KDCs). Each principal name has an 842 arbitrary number of components, though typical principal names will 843 only have one or two components. A principal name is meant to be 844 readable by and meaningful to humans, especially in a realm lacking a 845 centrally adminstered authorization infrastructure. 847 5.1. Name Types 849 Each PrincipalName has NameType indicating what sort of name it is. 850 The name-type SHOULD be treated as a hint. Ignoring the name type, 851 no two names can be the same (i.e., at least one of the components, 852 or the realm, must be different). 854 -- assigned numbers for name types (used in principal names) 855 NameType ::= Int32 857 -- Name type not known 858 nt-unknown NameType ::= 0 859 -- Just the name of the principal as in DCE, or for users 860 nt-principal NameType ::= 1 861 -- Service and other unique instance (krbtgt) 862 nt-srv-inst NameType ::= 2 863 -- Service with host name as instance (telnet, rcommands) 864 nt-srv-hst NameType ::= 3 865 -- Service with host as remaining components 866 nt-srv-xhst NameType ::= 4 867 -- Unique ID 868 nt-uid NameType ::= 5 869 -- Encoded X.509 Distingished name [RFC 2253] 870 nt-x500-principal NameType ::= 6 871 -- Name in form of SMTP email name (e.g. user@foo.com) 872 nt-smtp-name NameType ::= 7 873 -- Enterprise name - may be mapped to principal name 874 nt-enterprise NameType ::= 10 876 5.2. Principal Type Definition 878 The "PrincipalName" type takes a parameter to constrain which string 879 type it contains. 881 PrincipalName { StrType } ::= SEQUENCE { 882 name-type [0] NameType, 883 -- May have zero elements, or individual elements may be 884 -- zero-length, but this is NOT RECOMMENDED. 885 name-string [1] SEQUENCE OF KerberosString (StrType) 886 } 888 The constrained types have their own names. 890 -- IA5 only 891 PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } 892 -- IA5 excluded 893 PrincipalNameExt ::= PrincipalName { KerberosStringExt } 894 -- Either one? 895 PrincipalNameEither ::= PrincipalName { KerberosString } 897 name-type 898 hint of the type of name that follows 900 name-string 901 The "name-string" encodes a sequence of components that form a 902 name, each component encoded as a KerberosString. Taken 903 together, a PrincipalName and a Realm form a principal 904 identifier. Most PrincipalNames will have only a few components 905 (typically one or two). 907 5.3. Principal Name Reuse 909 Realm administrators SHOULD use extreme caution when considering 910 reusing a principal name. A service administrator might explicitly 911 enter principal names into a local access control list (ACL) for the 912 service. If such local ACLs exist independently of a centrally 913 administered authorization infrastructure, realm administrators 914 SHOULD NOT reuse principal names until confirming that all extant ACL 915 entries referencing that principal name have been updated. Failure 916 to perform this check can result in a security vulnerability, as a 917 new principal can inadvertently inherit unauthorized privileges upon 918 receiving a reused principal name. An organization whose Kerberos- 919 authenticated services all use a centrally-adminstered authorization 920 infrastructure may not need to take these precautions regarding 921 principal name reuse. 923 5.4. Best Common Practice Recommendations for the Processing of 924 Principal Names Consisting of Internationalized Domain Names: 926 Kerberos principals are often created for the purpose of 927 authenticating a service located on a machine identified by an domain 928 name. Unfortunately, once a principal name is created it is 929 impossible to know the source from which the resulting KerberosString 930 was derived. It is therefore required that principal names 931 containing internationalized domain names be processed via the 932 following procedure: 934 * ensure that the IDN component must be a valid domain name as per 935 the rules of IDNA [RFC3490] 937 * separate the IDN component into labels separated by any of the 938 Full Stop characters 940 * fold all Full Stop characters to Full Stop (0x002E) 942 * for each label (perform all steps): 944 o if the label begins with an ACE prefix as registered with IANA, 945 the prefix will be removed and the rest of the label will be 946 converted from the ACE representation to Unicode [need 947 reference] 949 o if the label consists of one or more internationalized 950 characters separately apply the NamePrep and then the SASLprep 951 string preparation methods. 953 o if the label consists of zero internalizationalized characters, 954 the label is to be lower-cased 956 o if the output of the two methods match, continue on to the next 957 label; otherwise reject the principal name as invalid 959 * the result of a valid principal name component derived from an IDN 960 is the joining of the individual string prepared labels separated 961 by the Full Stop (0x002E) 963 5.5. Realm Names 965 Realm { StrType } ::= KerberosString (StrType) 967 -- IA5 only 968 RealmIA5 ::= Realm { KerberosStringIA5 } 970 -- IA5 excluded 971 RealmExt ::= Realm { KerberosStringExt } 973 -- Either 974 RealmEither ::= Realm { KerberosString } 976 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a 977 character with the code 0 (the US-ASCII NUL). Most realms will 978 usually consist of several components separated by periods (.), in 979 the style of Internet Domain Names, or separated by slashes (/) in 980 the style of X.500 names. 982 5.6. Best Common Practice Recommendations for the Processing of 983 Internationalized Domain-Style Realm Names: 985 Domain Style Realm names are defined as all realm names whose 986 components are separated by Full Stop (0x002E) (aka periods, '.') and 987 contain neither colons, name containing one or more internationalized 988 characters (not included in US-ASCII), this procedure must be used: 990 * the realm name must be a valid domain name as per the rules of 991 IDNA [RFC3490] 993 * the following string preparation routine must be followed: 995 - separate the string into components separated by any of the 996 Full Stop characters 998 - fold all Full Stop characters to Full Stop (0x002E) 1000 - for each component (perform all steps): 1002 o if the component begins with an ACE prefix as registered 1003 with IANA, the prefix will be removed and the rest of the 1004 component will be converted from the ACE representation to 1005 Unicode [need reference] 1007 o if the component consists of one or more internationalized 1008 characters separately apply the NamePrep and SASLprep string 1009 preparation methods. 1011 if the output of the two methods match, continue on to the 1012 next component; otherwise reject the realm name as invalid 1014 - 1015 the result of a valid realm name is the joining of the 1016 individual string prepared components separated by the Full 1017 Stop (0x002E) 1019 In [KCLAR], the recommendation is that all domain style realm names 1020 be represented in uppercase. This recommendation is modified in the 1021 following manner. All components of domain style realm names not 1022 including internationalized characters should be upper-cased. All 1023 components of domain style realm names including internationalized 1024 characters must be lower-cased. (The lower case representation of 1025 internationalized components is enforced by the requirement that the 1026 output of NamePrep and StringPrep string preparation must be 1027 equivalent.) 1029 5.7. Printable Representations of Principal Names 1031 [ perhaps non-normative? ] 1033 The printable form of a principal name consists of the concatenation 1034 of components of the PrincipalName value using the slash character 1035 (/), followed by an at-sign (@), followed by the realm name. Any 1036 occurrence of a backslash (\), slash (/) or at-sign (@) in the 1037 PrincipalName value is quoted by a backslash. 1039 5.8. Ticket-Granting Service Principal 1041 The PrincipalName value corresponding to a ticket-granting service 1042 has two components: the first component is the string "krbtgt", and 1043 the second component is the realm name of the TGS which will accept a 1044 ticket-granting ticket having this service principal name. The realm 1045 name of service always indicates which realm issued the ticket. A 1046 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for 1047 obtaining tickets in the same realm would have the following ASN.1 1048 values for its "realm" and "sname" components, respectively: 1050 -- Example Realm and PrincipalName for a TGS 1052 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" 1054 tgtPrinc1 PrincipalName ::= { 1055 name-type nt-srv-inst, 1056 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } 1057 } 1059 Its printable representation would be written as 1060 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". 1062 5.8.1. Cross-Realm TGS Principals 1064 It is possible for a principal in one realm to authenticate to a 1065 service in another realm. A KDC can issue a cross-realm ticket- 1066 granting ticket to allow one of its principals to authenticate to a 1067 service in a foreign realm. For example, the TGS principal 1068 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a 1069 client principal in the realm A.EXAMPLE.COM to authenticate to a 1070 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM 1071 issues a ticket to a client originating in A.EXAMPLE.COM, the 1072 client's realm name remains "A.EXAMPLE.COM", even though the service 1073 principal will have the realm "B.EXAMPLE.COM". 1075 6. Types Relating to Encryption 1077 Many Kerberos protocol messages contain encrypted encodings of 1078 various data types. Some Kerberos protocol messages also contain 1079 checksums (signatures) of encodings of various types. 1081 6.1. Assigned Numbers for Encryption 1083 Encryption algorithm identifiers and key usages both have assigned 1084 numbers, described in [KCRYPTO]. 1086 6.1.1. EType 1088 EType is the integer type for assigned numbers for encryption 1089 algorithms. Defined in [KCRYPTO]. 1091 -- Assigned numbers denoting encryption mechanisms. 1092 EType ::= Int32 1094 -- assigned numbers for encryption schemes 1095 et-des-cbc-crc EType ::= 1 1096 et-des-cbc-md4 EType ::= 2 1097 et-des-cbc-md5 EType ::= 3 1098 -- [reserved] 4 1099 et-des3-cbc-md5 EType ::= 5 1100 -- [reserved] 6 1101 et-des3-cbc-sha1 EType ::= 7 1102 et-dsaWithSHA1-CmsOID EType ::= 9 1103 et-md5WithRSAEncryption-CmsOID EType ::= 10 1104 et-sha1WithRSAEncryption-CmsOID EType ::= 11 1105 et-rc2CBC-EnvOID EType ::= 12 1106 et-rsaEncryption-EnvOID EType ::= 13 1107 et-rsaES-OAEP-ENV-OID EType ::= 14 1108 et-des-ede3-cbc-Env-OID EType ::= 15 1109 et-des3-cbc-sha1-kd EType ::= 16 1110 -- AES 1111 et-aes128-cts-hmac-sha1-96 EType ::= 17 1112 -- AES 1113 et-aes256-cts-hmac-sha1-96 EType ::= 18 1114 -- Microsoft 1115 et-rc4-hmac EType ::= 23 1116 -- Microsoft 1117 et-rc4-hmac-exp EType ::= 24 1118 -- opaque; PacketCable 1119 et-subkey-keymaterial EType ::= 65 1121 6.1.2. Key Usages 1123 KeyUsage is the integer type for assigned numbers for key usages. 1124 Key usage values are inputs to the encryption and decryption 1125 functions described in [KCRYPTO]. 1127 -- Assigned numbers denoting key usages. 1128 KeyUsage ::= UInt32 1130 -- 1131 -- Actual identifier names are provisional and subject to 1132 -- change. 1133 -- 1134 ku-pa-enc-ts KeyUsage ::= 1 1135 ku-Ticket KeyUsage ::= 2 1136 ku-EncASRepPart KeyUsage ::= 3 1137 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 1138 ku-TGSReqAuthData-subkey KeyUsage ::= 5 1139 ku-pa-TGSReq-cksum KeyUsage ::= 6 1140 ku-pa-TGSReq-authenticator KeyUsage ::= 7 1141 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 1142 ku-EncTGSRepPart-subkey KeyUsage ::= 9 1143 ku-Authenticator-cksum KeyUsage ::= 10 1144 ku-APReq-authenticator KeyUsage ::= 11 1145 ku-EncAPRepPart KeyUsage ::= 12 1146 ku-EncKrbPrivPart KeyUsage ::= 13 1147 ku-EncKrbCredPart KeyUsage ::= 14 1148 ku-KrbSafe-cksum KeyUsage ::= 15 1149 ku-ad-KDCIssued-cksum KeyUsage ::= 19 1151 -- The following numbers are provisional... 1152 -- conflicts may exist elsewhere. 1153 ku-Ticket-cksum KeyUsage ::= 25 1154 ku-ASReq-cksum KeyUsage ::= 26 1155 ku-TGSReq-cksum KeyUsage ::= 27 1156 ku-ASRep-cksum KeyUsage ::= 28 1157 ku-TGSRep-cksum KeyUsage ::= 29 1158 ku-APReq-cksum KeyUsage ::= 30 1159 ku-APRep-cksum KeyUsage ::= 31 1160 ku-KrbCred-cksum KeyUsage ::= 32 1161 ku-KrbError-cksum KeyUsage ::= 33 1162 ku-KDCRep-cksum KeyUsage ::= 34 1164 6.2. Which Key to Use 1165 -- KeyToUse identifies which key is to be used to encrypt or 1166 -- sign a given value. 1167 -- 1168 -- Values of KeyToUse are never actually transmitted over the 1169 -- wire, or even used directly by the implementation in any 1170 -- way, as key usages are; it exists primarily to identify 1171 -- which key gets used for what purpose. Thus, the specific 1172 -- numeric values associated with this type are irrelevant. 1173 KeyToUse ::= ENUMERATED { 1174 -- unspecified 1175 key-unspecified, 1176 -- server long term key 1177 key-server, 1178 -- client long term key 1179 key-client, 1180 -- key selected by KDC for encryption of a KDC-REP 1181 key-kdc-rep, 1182 -- session key from ticket 1183 key-session, 1184 -- subsession key negotiated via AP-REQ/AP-REP 1185 key-subsession, 1186 ... 1187 } 1189 6.3. EncryptionKey 1191 The "EncryptionKey" type holds an encryption key. 1193 EncryptionKey ::= SEQUENCE { 1194 keytype [0] EType, 1195 keyvalue [1] OCTET STRING 1196 } 1198 keytype 1199 This "EType" identifies the encryption algorithm, described in 1200 [KCRYPTO]. 1202 keyvalue 1203 Contains the actual key. 1205 6.4. EncryptedData 1207 The "EncryptedData" type contains the encryption of another data 1208 type. The recipient uses fields within EncryptedData to determine 1209 which key to use for decryption. 1211 -- "Type" specifies which ASN.1 type is encrypted to the 1212 -- ciphertext in the EncryptedData. "Keys" specifies a set of 1213 -- keys of which one key may be used to encrypt the data. 1214 -- "KeyUsages" specifies a set of key usages, one of which may 1215 -- be used to encrypt. 1216 -- 1217 -- None of the parameters is transmitted over the wire. 1218 EncryptedData { 1219 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1220 } ::= SEQUENCE { 1221 etype [0] EType, 1222 kvno [1] UInt32 OPTIONAL, 1223 cipher [2] OCTET STRING (CONSTRAINED BY { 1224 -- must be encryption of -- 1225 OCTET STRING (CONTAINING Type), 1226 -- with one of the keys -- KeyToUse:Keys, 1227 -- with key usage being one of -- 1228 KeyUsage:KeyUsages 1229 }), 1230 ... 1231 } 1233 KeyUsages 1234 Advisory parameter indicating which key usage to use when 1235 encrypting the ciphertext. If "KeyUsages" indicate multiple 1236 "KeyUsage" values, the detailed description of the containing 1237 message will indicate which key to use under which conditions. 1239 Type 1240 Advisory parameter indicating the ASN.1 type whose DER encoding 1241 is the plaintext encrypted into the EncryptedData. 1243 Keys 1244 Advisory parameter indicating which key to use to perform the 1245 encryption. If "Keys" indicate multiple "KeyToUse" values, the 1246 detailed description of the containing message will indicate 1247 which key to use under which conditions. 1249 KeyUsages 1250 Advisory parameter indicating which "KeyUsage" value is used to 1251 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, 1252 the detailed description of the containing message will indicate 1253 which key usage to use under which conditions. 1255 6.5. Checksums 1257 Several types contain checksums (actually signatures) of data. 1259 CksumType ::= Int32 1261 -- The parameters specify which key to use to produce the 1262 -- signature, as well as which key usage to use. The 1263 -- parameters are not actually sent over the wire. 1264 Checksum { 1265 KeyToUse:Keys, KeyUsage:KeyUsages 1266 } ::= SEQUENCE { 1267 cksumtype [0] CksumType, 1268 checksum [1] OCTET STRING (CONSTRAINED BY { 1269 -- signed using one of the keys -- 1270 KeyToUse:Keys, 1271 -- with key usage being one of -- 1272 KeyUsage:KeyUsages 1273 }) 1274 } 1276 CksumType 1277 Integer type for assigned numbers for signature algorithms. 1278 Defined in [KCRYPTO] 1280 Keys 1281 As in EncryptedData 1283 KeyUsages 1284 As in EncryptedData 1286 cksumtype 1287 Signature algorithm used to produce the signature. 1289 checksum 1290 The actual checksum. 1292 6.5.1. ChecksumOf 1294 ChecksumOf is similar to "Checksum", but specifies which type is 1295 signed. 1297 -- a Checksum that must contain the checksum 1298 -- of a particular type 1299 ChecksumOf { 1300 Type, KeyToUse:Keys, KeyUsage:KeyUsages 1301 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 1302 ..., 1303 checksum (CONSTRAINED BY { 1304 -- must be checksum of -- 1305 OCTET STRING (CONTAINING Type) 1306 }) 1307 }) 1309 Type 1310 Indicates the ASN.1 type whose DER encoding is signed. 1312 6.5.2. Signed 1314 Signed is similar to "ChecksumOf", but contains an actual instance of 1315 the type being signed in addition to the signature. 1317 -- parameterized type for wrapping authenticated plaintext 1318 Signed { 1319 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 1320 } ::= SEQUENCE { 1321 cksum [0] ChecksumOf { 1322 InnerType, Keys, KeyUsages 1323 } OPTIONAL, 1324 inner [1] InnerType, 1325 ... 1326 } 1328 7. Tickets 1330 [ A large number of items described here are duplicated in the 1331 sections describing KDC-REQ processing. Should find a way to avoid 1332 this duplication. ] 1334 A ticket binds a principal name to a session key. The important 1335 fields of a ticket are in the encrypted part. 1337 -- Encrypted part of ticket 1338 EncTicketPart ::= CHOICE { 1339 rfc1510 EncTicketPart1510, 1340 ext EncTicketPartExt 1341 } 1343 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { 1344 flags [0] TicketFlags, 1345 key [1] EncryptionKey, 1346 crealm [2] RealmIA5, 1347 cname [3] PrincipalNameIA5, 1348 transited [4] TransitedEncoding, 1349 authtime [5] KerberosTime, 1350 starttime [6] KerberosTime OPTIONAL, 1351 endtime [7] KerberosTime, 1352 renew-till [8] KerberosTime OPTIONAL, 1353 caddr [9] HostAddresses OPTIONAL, 1354 authorization-data [10] AuthorizationData OPTIONAL 1355 } 1356 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { 1357 flags [0] TicketFlags, 1358 key [1] EncryptionKey, 1359 crealm [2] RealmExt, 1360 cname [3] PrincipalNameExt, 1361 transited [4] TransitedEncoding, 1362 authtime [5] KerberosTime, 1363 starttime [6] KerberosTime OPTIONAL, 1364 endtime [7] KerberosTime, 1365 renew-till [8] KerberosTime OPTIONAL, 1366 caddr [9] HostAddresses OPTIONAL, 1367 authorization-data [10] AuthorizationData OPTIONAL, 1368 ..., 1369 } 1371 crealm 1372 This field contains the client's realm. 1374 cname 1375 This field contains the client's name. 1377 caddr 1378 This field lists the network addresses (if absent, all addresses 1379 are permitted) from which the ticket is valid. 1381 Descriptions of the other fields appear in the following sections. 1383 7.1. Timestamps 1385 Three of the ticket timestamps may be requested from the KDC. The 1386 timestamps may differ from those requested, depending on site policy. 1388 authtime 1389 The time at which the client authenticated, as recorded by the 1390 KDC. 1392 starttime 1393 The earliest time when the ticket is valid. If not present, the 1394 ticket is valid starting at the authtime. This is requested as 1395 the "from" field of KDC-REQ-BODY. 1397 endtime 1398 This time is requested in the "till" field of KDC-REQ-BODY. 1399 Contains the time after which the ticket will not be honored 1400 (its expiration time). Note that individual services MAY place 1401 their own limits on the life of a ticket and MAY reject tickets 1402 which have not yet expired. As such, this is really an upper 1403 bound on the expiration time for the ticket. 1405 renew-till 1406 This time is requested in the "rtime" field of KDC-REQ-BODY. It 1407 is only present in tickets that have the "renewable" flag set in 1408 the flags field. It indicates the maximum endtime that may be 1409 included in a renewal. It can be thought of as the absolute 1410 expiration time for the ticket, including all renewals. 1412 7.2. Ticket Flags 1414 A number of flags may be set in the ticket, further defining some of 1415 its capabilities. Some of these flags map to flags in a KDC request. 1417 TicketFlags ::= KerberosFlags { TicketFlagsBits } 1419 TicketFlagsBits ::= BIT STRING { 1420 reserved (0), 1421 forwardable (1), 1422 forwarded (2), 1423 proxiable (3), 1424 proxy (4), 1425 may-postdate (5), 1426 postdated (6), 1427 invalid (7), 1428 renewable (8), 1429 initial (9), 1430 pre-authent (10), 1431 hw-authent (11), 1432 transited-policy-checked (12), 1433 ok-as-delegate (13), 1434 anonymous (14), 1435 cksummed-ticket (15) 1436 } 1438 7.2.1. Flags Relating to Initial Ticket Acquisition 1440 [ adapted KCLAR 2.1. ] 1442 Several flags indicate the details of how the initial ticket was 1443 acquired. 1445 initial 1446 The "initial" flag indicates that a ticket was issued using the 1447 AS protocol, rather than issued based on a ticket-granting 1448 ticket. Application servers (e.g., a password-changing program) 1449 requiring a client's definite knowledge of its secret key can 1450 insist that this flag be set in any tickets they accept, thus 1451 being assured that the client's key was recently presented to 1452 the application client. 1454 pre-authent 1455 The "pre-authent" flag indicates that some sort of pre- 1456 authentication was used during the AS exchange. 1458 hw-authent 1459 The "hw-authent" flag indicates that some sort of hardware-based 1460 pre-authentication occurred during the AS exchange. 1462 Both the "pre-authent" and the "hw-authent" flags may be present with 1463 or without the "initial" flag; such tickets with the "initial" flag 1464 clear are ones which are derived from initial tickets with the "pre- 1465 authent" or "hw-authent" flags set. 1467 7.2.2. Invalid Tickets 1469 [ KCLAR 2.2. ] 1471 The "invalid" flag indicates that a ticket is invalid. Application 1472 servers MUST reject tickets which have this flag set. A postdated 1473 ticket will be issued in this form. Invalid tickets MUST be 1474 validated by the KDC before use, by presenting them to the KDC in a 1475 TGS request with the "validate" option specified. The KDC will only 1476 validate tickets after their starttime has passed. The validation is 1477 required so that postdated tickets which have been stolen before 1478 their starttime can be rendered permanently invalid (through a hot- 1479 list mechanism -- see Section 8.3.2.4). 1481 7.2.3. OK as Delegate 1483 [ KCLAR 2.8. ] 1485 The "ok-as-delegate" flag provides a way for a KDC to communicate 1486 local realm policy to a client regarding whether the service for 1487 which the ticket is issued is trusted to accept delegated 1488 credentials. For some applications, a client may need to delegate 1489 credentials to a service to act on its behalf in contacting other 1490 services. The ability of a client to obtain a service ticket for a 1491 service conveys no information to the client about whether the 1492 service should be trusted to accept delegated credentials. 1494 The copy of the ticket flags visible to the client may have the "ok- 1495 as-delegate" flag set to indicate to the client that the service 1496 specified in the ticket has been determined by policy of the realm to 1497 be a suitable recipient of delegation. A client can use the presence 1498 of this flag to help it make a decision whether to delegate 1499 credentials (either grant a proxy or a forwarded ticket-granting 1500 ticket) to this service. It is acceptable to ignore the value of 1501 this flag. When setting this flag, an administrator should consider 1502 the security and placement of the server on which the service will 1503 run, as well as whether the service requires the use of delegated 1504 credentials. 1506 7.2.4. Renewable Tickets 1508 [ adapted KCLAR 2.3. ] 1510 The "renewable" flag indicates whether the ticket may be renewed. 1512 Renewable tickets can be used to mitigate the consequences of ticket 1513 theft. Applications may desire to hold credentials which can be 1514 valid for long periods of time. However, this can expose the 1515 credentials to potential theft for equally long periods, and those 1516 stolen credentials would be valid until the expiration time of the 1517 ticket(s). Simply using short-lived tickets and obtaining new ones 1518 periodically would require the application to have long-term access 1519 to the client's secret key, which is an even greater risk. 1521 Renewable tickets have two "expiration times": the first is when the 1522 current instance of the ticket expires, and the second is the latest 1523 permissible value for an individual expiration time. An application 1524 client must periodically present an unexpired renewable ticket to the 1525 KDC, setting the "renew" option in the KDC request. The KDC will 1526 issue a new ticket with a new session key and a later expiration 1527 time. All other fields of the ticket are left unmodified by the 1528 renewal process. When the latest permissible expiration time 1529 arrives, the ticket expires permanently. At each renewal, the KDC 1530 MAY consult a hot-list to determine if the ticket had been reported 1531 stolen since its last renewal; it will refuse to renew such stolen 1532 tickets, and thus the usable lifetime of stolen tickets is reduced. 1534 The "renewable" flag in a ticket is normally only interpreted by the 1535 ticket-granting service. It can usually be ignored by application 1536 servers. However, some particularly careful application servers MAY 1537 disallow renewable tickets. 1539 If a renewable ticket is not renewed by its expiration time, the KDC 1540 will not renew the ticket. The "renewable" flag is clear by default, 1541 but a client can request it be set by setting the "renewable" option 1542 in the AS-REQ message. If it is set, then the "renew-till" field in 1543 the ticket contains the time after which the ticket may not be 1544 renewed. 1546 7.2.5. Postdated Tickets 1548 postdated 1549 indicates a ticket which has been postdated 1551 may-postdate 1552 indicates that postdated tickets may be issued based on this 1553 ticket 1555 [ KCLAR 2.4. ] 1556 Applications may occasionally need to obtain tickets for use much 1557 later, e.g., a batch submission system would need tickets to be valid 1558 at the time the batch job is serviced. However, it is dangerous to 1559 hold valid tickets in a batch queue, since they will be on-line 1560 longer and more prone to theft. Postdated tickets provide a way to 1561 obtain these tickets from the KDC at job submission time, but to 1562 leave them "dormant" until they are activated and validated by a 1563 further request of the KDC. If a ticket theft were reported in the 1564 interim, the KDC would refuse to validate the ticket, and the thief 1565 would be foiled. 1567 The "may-postdate" flag in a ticket is normally only interpreted by 1568 the TGS. It can be ignored by application servers. This flag MUST 1569 be set in a ticket-granting ticket in order for the KDC to issue a 1570 postdated ticket based on the presented ticket. It is reset by 1571 default; it MAY be requested by a client by setting the "allow- 1572 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag 1573 does not allow a client to obtain a postdated ticket-granting ticket; 1574 postdated ticket-granting tickets can only by obtained by requesting 1575 the postdating in the AS-REQ message. The life (endtime minus 1576 starttime) of a postdated ticket will be the remaining life of the 1577 ticket-granting ticket at the time of the request, unless the 1578 "renewable" option is also set, in which case it can be the full life 1579 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY 1580 limit how far in the future a ticket may be postdated. 1582 The "postdated" flag indicates that a ticket has been postdated. The 1583 application server can check the authtime field in the ticket to see 1584 when the original authentication occurred. Some services MAY choose 1585 to reject postdated tickets, or they may only accept them within a 1586 certain period after the original authentication. When the KDC 1587 issues a "postdated" ticket, it will also be marked as "invalid", so 1588 that the application client MUST present the ticket to the KDC for 1589 validation before use. 1591 7.2.6. Proxiable and Proxy Tickets 1593 proxy 1594 indicates a proxy ticket 1596 proxiable 1597 indicates that proxy tickets may be issued based on this ticket 1599 [ KCLAR 2.5. ] 1601 It may be necessary for a principal to allow a service to perform an 1602 operation on its behalf. The service must be able to take on the 1603 identity of the client, but only for a particular purpose. A 1604 principal can allow a service to take on the principal's identity for 1605 a particular purpose by granting it a proxy. 1607 The process of granting a proxy using the "proxy" and "proxiable" 1608 flags is used to provide credentials for use with specific services. 1609 Though conceptually also a proxy, users wishing to delegate their 1610 identity in a form usable for all purposes MUST use the ticket 1611 forwarding mechanism described in the next section to forward a 1612 ticket-granting ticket. 1614 The "proxiable" flag in a ticket is normally only interpreted by the 1615 ticket-granting service. It can be ignored by application servers. 1616 When set, this flag tells the ticket-granting server that it is OK to 1617 issue a new ticket (but not a ticket-granting ticket) with a 1618 different network address based on this ticket. This flag is set if 1619 requested by the client on initial authentication. By default, the 1620 client will request that it be set when requesting a ticket-granting 1621 ticket, and reset when requesting any other ticket. 1623 This flag allows a client to pass a proxy to a server to perform a 1624 remote request on its behalf (e.g. a print service client can give 1625 the print server a proxy to access the client's files on a particular 1626 file server in order to satisfy a print request). 1628 In order to complicate the use of stolen credentials, Kerberos 1629 tickets may contain a set of network addresses from which they are 1630 valid. When granting a proxy, the client MUST specify the new 1631 network address from which the proxy is to be used, or indicate that 1632 the proxy is to be issued for use from any address. 1634 The "proxy" flag is set in a ticket by the TGS when it issues a proxy 1635 ticket. Application servers MAY check this flag and at their option 1636 they MAY require additional authentication from the agent presenting 1637 the proxy in order to provide an audit trail. 1639 7.2.7. Forwarded and Forwardable Tickets 1641 forwarded 1642 indicates a forwarded ticket 1644 forwardable 1645 indicates that forwarded tickets may be issued based on this 1646 ticket 1648 [ KCLAR 2.6. ] 1650 Authentication forwarding is an instance of a proxy where the service 1651 that is granted is complete use of the client's identity. An example 1652 where it might be used is when a user logs in to a remote system and 1653 wants authentication to work from that system as if the login were 1654 local. 1656 The "forwardable" flag in a ticket is normally only interpreted by 1657 the ticket-granting service. It can be ignored by application 1658 servers. The "forwardable" flag has an interpretation similar to 1659 that of the "proxiable" flag, except ticket-granting tickets may also 1660 be issued with different network addresses. This flag is reset by 1661 default, but users MAY request that it be set by setting the 1662 "forwardable" option in the AS request when they request their 1663 initial ticket-granting ticket. 1665 This flag allows for authentication forwarding without requiring the 1666 user to enter a password again. If the flag is not set, then 1667 authentication forwarding is not permitted, but the same result can 1668 still be achieved if the user engages in the AS exchange specifying 1669 the requested network addresses and supplies a password. 1671 The "forwarded" flag is set by the TGS when a client presents a 1672 ticket with the "forwardable" flag set and requests a forwarded 1673 ticket by specifying the "forwarded" KDC option and supplying a set 1674 of addresses for the new ticket. It is also set in all tickets 1675 issued based on tickets with the "forwarded" flag set. Application 1676 servers may choose to process "forwarded" tickets differently than 1677 non-forwarded tickets. 1679 If addressless tickets are forwarded from one system to another, 1680 clients SHOULD still use this option to obtain a new TGT in order to 1681 have different session keys on the different systems. 1683 7.3. Transited Realms 1685 [ KCLAR 2.7., plus new stuff ] 1687 7.4. Authorization Data 1689 [ KCLAR 5.2.6. ] 1691 ADType ::= TH-id 1693 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1694 ad-type [0] ADType, 1695 ad-data [1] OCTET STRING 1696 } 1698 ad-type 1699 This field identifies the contents of the ad-data. All negative 1700 values are reserved for local use. Non-negative values are 1701 reserved for registered use. 1703 ad-data 1704 This field contains authorization data to be interpreted 1705 according to the value of the corresponding ad-type field. 1707 Each sequence of ADType and OCTET STRING is referred to as an 1708 authorization element. Elements MAY be application specific, 1709 however, there is a common set of recursive elements that should be 1710 understood by all implementations. These elements contain other 1711 AuthorizationData, and the interpretation of the encapsulating 1712 element determines which enclosed elements must be interpreted, and 1713 which may be ignored. 1715 Depending on the meaning of the encapsulating element, the 1716 encapsulated AuthorizationData may be ignored, interpreted as issued 1717 directly by the KDC, or be stored in a separate plaintext part of the 1718 ticket. The types of the encapsulating elements are specified as 1719 part of the Kerberos protocol because behavior based on these 1720 container elements should be understood across implementations, while 1721 other elements need only be understood by the applications which they 1722 affect. 1724 Authorization data elements are considered critical if present in a 1725 ticket or authenticator. Unless encapsulated in a known 1726 authorization data element modifying the criticality of the elements 1727 it contains, an application server MUST reject the authentication of 1728 a client whose AP-REQ or ticket contains an unrecognized 1729 authorization data element. Authorization data is intended to 1730 restrict the use of a ticket. If the service cannot determine 1731 whether it is the target of a restriction, a security weakness may 1732 exist if the ticket can be used for that service. Authorization 1733 elements that are truly optional can be enclosed in AD-IF-RELEVANT 1734 element. 1736 | 1737 ad-type | contents of ad-data 1738 ---------+--------------------------------------- 1739 1 | DER encoding of AD-IF-RELEVANT 1740 4 | DER encoding of AD-KDCIssued 1741 5 | DER encoding of AD-AND-OR 1742 8 | DER encoding of AD-MANDATORY-FOR-KDC 1744 7.4.1. AD-IF-RELEVANT 1746 ad-if-relevant ADType ::= int32 : 1 1748 -- Encapsulates another AuthorizationData. 1749 -- Intended for application servers; receiving application servers 1750 -- MAY ignore. 1751 AD-IF-RELEVANT ::= AuthorizationData 1753 AD elements encapsulated within the if-relevant element are intended 1754 for interpretation only by application servers that understand the 1755 particular ad-type of the embedded element. Application servers that 1756 do not understand the type of an element embedded within the if- 1757 relevant element MAY ignore the uninterpretable element. This element 1758 promotes interoperability across implementations which may have local 1759 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). 1761 7.4.2. AD-KDCIssued 1763 -- KDC-issued privilege attributes 1764 ad-kdcissued ADType ::= int32 : 4 1766 AD-KDCIssued ::= SEQUENCE { 1767 ad-checksum [0] ChecksumOf { 1768 AuthorizationData, { key-session }, 1769 { ku-ad-KDCIssued-cksum }}, 1770 i-realm [1] Realm OPTIONAL, 1771 i-sname [2] PrincipalName OPTIONAL, 1772 elements [3] AuthorizationData 1773 } 1775 ad-checksum 1776 A cryptographic checksum computed over the DER encoding of the 1777 AuthorizationData in the "elements" field, keyed with the 1778 session key. Its checksumtype is the mandatory checksum type 1779 for the encryption type of the session key, and its key usage 1780 value is 19. 1782 i-realm, i-sname 1783 The name of the issuing principal if different from the KDC 1784 itself. This field would be used when the KDC can verify the 1785 authenticity of elements signed by the issuing principal and it 1786 allows this KDC to notify the application server of the validity 1787 of those elements. 1789 elements 1790 AuthorizationData issued by the KDC. 1792 The KDC-issued ad-data field is intended to provide a means for 1793 Kerberos credentials to embed within themselves privilege attributes 1794 and other mechanisms for positive authorization, amplifying the 1795 privileges of the principal beyond what it would have if using 1796 credentials without such an authorization-data element. 1798 This amplification of privileges cannot be provided without this 1799 element because the definition of the authorization-data field allows 1800 elements to be added at will by the bearer of a TGT at the time that 1801 they request service tickets and elements may also be added to a 1802 delegated ticket by inclusion in the authenticator. 1804 For KDC-issued elements this is prevented because the elements are 1805 signed by the KDC by including a checksum encrypted using the 1806 server's key (the same key used to encrypt the ticket -- or a key 1807 derived from that key). AuthorizationData encapsulated with in the 1808 AD-KDCIssued element MUST be ignored by the application server if 1809 this "signature" is not present. Further, AuthorizationData 1810 encapsulated within this element from a ticket-granting ticket MAY be 1811 interpreted by the KDC, and used as a basis according to policy for 1812 including new signed elements within derivative tickets, but they 1813 will not be copied to a derivative ticket directly. If they are 1814 copied directly to a derivative ticket by a KDC that is not aware of 1815 this element, the signature will not be correct for the application 1816 ticket elements, and the field will be ignored by the application 1817 server. 1819 This element and the elements it encapsulates MAY be safely ignored 1820 by applications, application servers, and KDCs that do not implement 1821 this element. 1823 The ad-type for AD-KDC-ISSUED is (4). 1825 7.4.3. AD-AND-OR 1827 ad-and-or ADType ::= int32 : 5 1829 AD-AND-OR ::= SEQUENCE { 1830 condition-count [0] Int32, 1831 elements [1] AuthorizationData 1832 } 1834 When restrictive AD elements are encapsulated within the and-or 1835 element, the and-or element is considered satisfied if and only if at 1836 least the number of encapsulated elements specified in condition- 1837 count are satisfied. Therefore, this element MAY be used to 1838 implement an "or" operation by setting the condition-count field to 1839 1, and it MAY specify an "and" operation by setting the condition 1840 count to the number of embedded elements. Application servers that do 1841 not implement this element MUST reject tickets that contain 1842 authorization data elements of this type. 1844 The ad-type for AD-AND-OR is (5). 1846 7.4.4. AD-MANDATORY-FOR-KDC 1848 -- KDCs MUST interpret any AuthorizationData wrapped in this. 1849 ad-mandatory-for-kdc ADType ::= int32 : 8 1850 AD-MANDATORY-FOR-KDC ::= AuthorizationData 1852 AD elements encapsulated within the mandatory-for-kdc element are to 1853 be interpreted by the KDC. KDCs that do not understand the type of 1854 an element embedded within the mandatory-for-kdc element MUST reject 1855 the request. 1857 The ad-type for AD-MANDATORY-FOR-KDC is (8). 1859 7.5. Encrypted Part of Ticket 1861 The complete definition of the encrypted part is 1863 -- Encrypted part of ticket 1864 EncTicketPart ::= CHOICE { 1865 rfc1510 EncTicketPart1510, 1866 ext EncTicketPartExt 1867 } 1869 The encrypted part of the backwards-compatibility form of a ticket 1870 is: 1872 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { 1873 flags [0] TicketFlags, 1874 key [1] EncryptionKey, 1875 crealm [2] RealmIA5, 1876 cname [3] PrincipalNameIA5, 1877 transited [4] TransitedEncoding, 1878 authtime [5] KerberosTime, 1879 starttime [6] KerberosTime OPTIONAL, 1880 endtime [7] KerberosTime, 1881 renew-till [8] KerberosTime OPTIONAL, 1882 caddr [9] HostAddresses OPTIONAL, 1883 authorization-data [10] AuthorizationData OPTIONAL 1884 } 1886 The encrypted part of the extensible form of a ticket is: 1888 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { 1889 flags [0] TicketFlags, 1890 key [1] EncryptionKey, 1891 crealm [2] RealmExt, 1892 cname [3] PrincipalNameExt, 1893 transited [4] TransitedEncoding, 1894 authtime [5] KerberosTime, 1895 starttime [6] KerberosTime OPTIONAL, 1896 endtime [7] KerberosTime, 1897 renew-till [8] KerberosTime OPTIONAL, 1898 caddr [9] HostAddresses OPTIONAL, 1899 authorization-data [10] AuthorizationData OPTIONAL, 1900 ..., 1901 } 1903 7.6. Cleartext Part of Ticket 1905 The complete definition of Ticket is: 1907 Ticket ::= CHOICE { 1908 rfc1510 Ticket1510, 1909 ext TicketExt 1910 } 1912 The "sname" field provides the name of the target service principal 1913 in cleartext, as a hint to aid the server in choosing the correct 1914 decryption key. 1916 The backwards-compatibility form of Ticket is: 1918 Ticket1510 ::= [APPLICATION 1] SEQUENCE { 1919 tkt-vno [0] INTEGER (5), 1920 realm [1] RealmIA5, 1921 sname [2] PrincipalNameIA5, 1922 enc-part [3] EncryptedData { 1923 EncTicketPart1510, { key-server }, { ku-Ticket } 1924 } 1925 } 1927 The extensible form of Ticket is: 1929 TicketExt ::= [APPLICATION 4] Signed { 1930 [APPLICATION 4] SEQUENCE { 1931 tkt-vno [0] INTEGER (5), 1932 realm [1] RealmExt, 1933 sname [2] PrincipalNameExt, 1934 enc-part [3] EncryptedData { 1935 EncTicketPartExt, { key-server }, { ku-Ticket } 1936 }, 1937 ..., 1938 extensions [4] TicketExtensions OPTIONAL, 1939 ... 1940 }, 1941 { key-ticket }, { ku-Ticket-cksum } 1942 } 1944 TicketExtensions, which may only be present in the extensible form of 1945 Ticket, are a cleartext typed hole for extension use. 1946 AuthorizationData already provides an encrypted typed hole. 1948 TEType ::= TH-id 1950 -- ticket extensions: for TicketExt only 1951 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 1952 te-type [0] TEType, 1953 te-data [1] OCTET STRING 1954 } 1956 A client will only receive an extensible Ticket if the application 1957 server supports extensibility. 1959 8. Credential Acquisition 1961 There are two exchanges that can be used for acquiring credentials: 1962 the AS exchange and the TGS exchange. These exchanges have many 1963 similarities, and this document describes them in parallel, noting 1964 which behaviors are specific to one type of exchange. The AS request 1965 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests 1966 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) 1967 are forms of KDC replies (KDC-REP). 1969 The credentials acquisition protocol operates over specific 1970 transports. Additionally, specific methods exist to permit a client 1971 to discover the KDC host with which to communicate. 1973 8.1. KDC-REQ 1975 The KDC-REQ has a large number of fields in common between the RFC 1976 1510 and the extensible versions. The KDC-REQ type itself is never 1977 directly encoded; it is always a part of a AS-REQ or a TGS-REQ. 1979 KDC-REQ-1510 ::= SEQUENCE { 1980 -- NOTE: first tag is [1], not [0] 1981 pvno [1] INTEGER (5), 1982 msg-type [2] INTEGER ( 10 -- AS-REQ -- 1983 | 12 -- TGS-REQ -- ), 1984 padata [3] SEQUENCE OF PA-DATA OPTIONAL, 1985 req-body [4] KDC-REQ-BODY-1510 1986 } 1988 KDC-REQ-EXT ::= SEQUENCE { 1989 pvno [1] INTEGER (5), 1990 msg-type [2] INTEGER ( 6 -- AS-REQ -- 1991 | 8 -- TGS-REQ -- ), 1992 padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, 1993 req-body [4] KDC-REQ-BODY-EXT, 1994 ... 1995 } 1996 KDC-REQ-BODY-1510 ::= SEQUENCE { 1997 kdc-options [0] KDCOptions, 1998 cname [1] PrincipalNameIA5 OPTIONAL 1999 -- Used only in AS-REQ --, 2001 realm [2] RealmIA5 2002 -- Server's realm; also client's in AS-REQ --, 2004 sname [3] PrincipalNameIA5 OPTIONAL, 2005 from [4] KerberosTime OPTIONAL, 2006 till [5] KerberosTime, 2007 rtime [6] KerberosTime OPTIONAL, 2008 nonce [7] Nonce32, 2009 etype [8] SEQUENCE OF EType 2010 -- in preference order --, 2012 addresses [9] HostAddresses OPTIONAL, 2013 enc-authorization-data [10] EncryptedData { 2014 AuthorizationData, { key-session | key-subsession }, 2015 { ku-TGSReqAuthData-subkey | 2016 ku-TGSReqAuthData-sesskey } 2017 } OPTIONAL, 2019 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2020 -- NOTE: not empty -- 2021 } 2022 KDC-REQ-BODY-EXT ::= SEQUENCE { 2023 kdc-options [0] KDCOptions, 2024 cname [1] PrincipalName OPTIONAL 2025 -- Used only in AS-REQ --, 2027 realm [2] Realm 2028 -- Server's realm; also client's in AS-REQ --, 2030 sname [3] PrincipalName OPTIONAL, 2031 from [4] KerberosTime OPTIONAL, 2032 till [5] KerberosTime OPTIONAL 2033 -- was required in rfc1510; 2034 -- still required for compat versions 2035 -- of messages --, 2037 rtime [6] KerberosTime OPTIONAL, 2038 nonce [7] Nonce, 2039 etype [8] SEQUENCE OF EType 2040 -- in preference order --, 2042 addresses [9] HostAddresses OPTIONAL, 2043 enc-authorization-data [10] EncryptedData { 2044 AuthorizationData, { key-session | key-subsession }, 2045 { ku-TGSReqAuthData-subkey | 2046 ku-TGSReqAuthData-sesskey } 2047 } OPTIONAL, 2049 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2050 -- NOTE: not empty --, 2051 ... 2052 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 2053 LangTag OPTIONAL, 2054 ... 2055 } 2057 Many fields of KDC-REQ-BODY correspond directly to fields of an 2058 EncTicketPart. The KDC copies most of them unchanged, provided that 2059 the requested values meet site policy. 2061 kdc-options 2062 These flags do not correspond directly to "flags" in 2063 EncTicketPart. 2065 cname 2066 This field is copied to the "cname" field in EncTicketPart. The 2067 "cname" field is required in an AS-REQ; the client places its 2068 own name here. In a TGS-REQ, the "cname" in the ticket in the 2069 AP-REQ takes precedence. 2071 realm 2072 This field is the server's realm, and also holds the client's 2073 realm in an AS-REQ. 2075 sname 2076 The "sname" field indicates the server's name. It may be absent 2077 in a TGS-REQ which requests user-to-user authentication, in 2078 which case the "sname" of the issued ticket will be taken from 2079 the included additional ticket. 2081 The "from", "till", and "rtime" fields correspond to the "starttime", 2082 "endtime", and "renew-till" fields of EncTicketPart. 2084 addresses 2085 This field corresponds to the "caddr" field of EncTicketPart. 2087 enc-authorization-data 2088 For TGS-REQ, this field contains authorization data encrypted 2089 using either the TGT session key or the AP-REQ subsession key; 2090 the KDC may copy these into the "authorization-data" field of 2091 EncTicketPart if policy permits. 2093 lang-tags 2094 Only present in the extensible messages. Specifies the set of 2095 languages which the client is willing to accept in error 2096 messages. 2098 KDC options used in a KDC-REQ are: 2100 KDCOptions ::= KerberosFlags { KDCOptionsBits } 2102 KDCOptionsBits ::= BIT STRING { 2103 reserved (0), 2104 forwardable (1), 2105 forwarded (2), 2106 proxiable (3), 2107 proxy (4), 2108 allow-postdate (5), 2109 postdated (6), 2110 unused7 (7), 2111 renewable (8), 2112 unused9 (9), 2113 unused10 (10), 2114 unused11 (11), 2115 unused12 (12), 2116 unused13 (13), 2117 requestanonymous (14), 2118 canonicalize (15), 2119 disable-transited-check (26), 2120 renewable-ok (27), 2121 enc-tkt-in-skey (28), 2122 renew (30), 2123 validate (31) 2124 -- XXX need "need ticket1" flag? 2125 } 2127 Different options apply to different phases of KDC-REQ processing. 2129 The backwards-compatibility form of a KDC-REQ is: 2131 KDC-REQ-1510 ::= SEQUENCE { 2132 -- NOTE: first tag is [1], not [0] 2133 pvno [1] INTEGER (5), 2134 msg-type [2] INTEGER ( 10 -- AS-REQ -- 2135 | 12 -- TGS-REQ -- ), 2136 padata [3] SEQUENCE OF PA-DATA OPTIONAL, 2137 req-body [4] KDC-REQ-BODY-1510 2138 } 2140 The extensible form of a KDC-REQ is: 2142 KDC-REQ-EXT ::= SEQUENCE { 2143 pvno [1] INTEGER (5), 2144 msg-type [2] INTEGER ( 6 -- AS-REQ -- 2145 | 8 -- TGS-REQ -- ), 2146 padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, 2147 req-body [4] KDC-REQ-BODY-EXT, 2148 ... 2149 } 2151 The backwards-compatibility form of a KDC-REQ-BODY is: 2153 KDC-REQ-BODY-1510 ::= SEQUENCE { 2154 kdc-options [0] KDCOptions, 2155 cname [1] PrincipalNameIA5 OPTIONAL 2156 -- Used only in AS-REQ --, 2158 realm [2] RealmIA5 2159 -- Server's realm; also client's in AS-REQ --, 2161 sname [3] PrincipalNameIA5 OPTIONAL, 2162 from [4] KerberosTime OPTIONAL, 2163 till [5] KerberosTime, 2164 rtime [6] KerberosTime OPTIONAL, 2165 nonce [7] Nonce32, 2166 etype [8] SEQUENCE OF EType 2167 -- in preference order --, 2169 addresses [9] HostAddresses OPTIONAL, 2170 enc-authorization-data [10] EncryptedData { 2171 AuthorizationData, { key-session | key-subsession }, 2172 { ku-TGSReqAuthData-subkey | 2173 ku-TGSReqAuthData-sesskey } 2174 } OPTIONAL, 2176 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2177 -- NOTE: not empty -- 2178 } 2180 The extensible form of a KDC-REQ-BODY is: 2182 KDC-REQ-BODY-EXT ::= SEQUENCE { 2183 kdc-options [0] KDCOptions, 2184 cname [1] PrincipalName OPTIONAL 2185 -- Used only in AS-REQ --, 2187 realm [2] Realm 2188 -- Server's realm; also client's in AS-REQ --, 2190 sname [3] PrincipalName OPTIONAL, 2191 from [4] KerberosTime OPTIONAL, 2192 till [5] KerberosTime OPTIONAL 2193 -- was required in rfc1510; 2194 -- still required for compat versions 2195 -- of messages --, 2197 rtime [6] KerberosTime OPTIONAL, 2198 nonce [7] Nonce, 2199 etype [8] SEQUENCE OF EType 2200 -- in preference order --, 2202 addresses [9] HostAddresses OPTIONAL, 2203 enc-authorization-data [10] EncryptedData { 2204 AuthorizationData, { key-session | key-subsession }, 2205 { ku-TGSReqAuthData-subkey | 2206 ku-TGSReqAuthData-sesskey } 2207 } OPTIONAL, 2209 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2210 -- NOTE: not empty --, 2211 ... 2212 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 2213 LangTag OPTIONAL, 2214 ... 2215 } 2217 The AS-REQ is: 2219 AS-REQ ::= CHOICE { 2220 rfc1510 AS-REQ-1510, 2221 ext AS-REQ-EXT 2222 } 2223 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 2224 -- AS-REQ must include client name 2226 AS-REQ-EXT ::= [APPLICATION 6] Signed { 2227 [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum } 2228 } 2229 -- AS-REQ must include client name 2231 A client SHOULD NOT send the extensible AS-REQ alternative to a KDC 2232 if the client does not know that the KDC supports the extensibility 2233 framework. A client SHOULD send the extensible AS-REQ alternative in 2234 a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the 2235 AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX 2236 what if their contents conflict? ] 2238 The TGS-REQ is: 2240 TGS-REQ ::= CHOICE { 2241 rfc1510 TGS-REQ-1510, 2242 ext TGS-REQ-EXT 2243 } 2245 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 2247 TGS-REQ-EXT ::= [APPLICATION 8] Signed { 2248 [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum } 2249 } 2251 8.2. PA-DATA 2253 PA-DATA have multiple uses in the Kerberos protocol. They may pre- 2254 authenticate an AS-REQ; they may also modify several of the 2255 encryption keys used in a KDC-REP. PA-DATA may also provide "hints" 2256 to the client about which long-term key (usually password-derived) to 2257 use. PA-DATA may also include "hints" about which pre-authentication 2258 mechanisms to use, or include data for input into a pre- 2259 authentication mechanism. 2261 [ XXX enumerate standard padata here ] 2263 8.3. KDC-REQ Processing 2265 Processing of a KDC-REQ proceeds through several steps. An 2266 implementation need not perform these steps exactly as described, as 2267 long as it behaves as if the steps were performed as described. The 2268 KDC performs replay handling upon receiving the request; it then 2269 validates the request, adjusts timestamps, and selects the keys used 2270 in the reply. It copies data from the request into the issued 2271 ticket, adjusting the values to conform with its policies. The KDC 2272 then transmits the reply to the client. 2274 8.3.1. Handling Replays 2276 Because Kerberos can run over unreliable transports such as UDP, the 2277 KDC MUST be prepared to retransmit responses in case they are lost. 2278 If a KDC receives a request identical to one it has recently 2279 successfully processed, the KDC MUST respond with a KDC-REP message 2280 rather than a replay error. In order to reduce the amount of 2281 ciphertext given to a potential attacker, KDCs MAY send the same 2282 response generated when the request was first handled. KDCs MUST 2283 obey this replay behavior even if the actual transport in use is 2284 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, 2285 and the entire request is not identical to a recently successfully 2286 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is 2287 appropriate for AP-REQ processing. 2289 8.3.2. Request Validation 2291 8.3.2.1. AS-REQ Authentication 2293 Site policy determines whether a given client principal is required 2294 to provide some pre-authentication prior to receiving an AS-REP. 2295 Since the default reply key is typically the client's long-term 2296 password-based key, an attacker may easily request known plaintext 2297 (in the form of an AS-REP) upon which to mount a dictionary attack. 2298 Pre-authentication can limit the possibility of such an attack. 2300 If site policy requires pre-authentication for a client principal, 2301 and no pre-authentication is provided, the KDC returns the error 2302 "kdc-err-preauth-required". Accompanying this error are "e-data" 2303 which include hints telling the client which pre-authentication 2304 mechanisms to use, or data for input to pre-authentication mechanisms 2305 (e.g., input to challenge-response systems). If pre-authentication 2306 fails, the KDC returns the error "kdc-err-preauth-failed". 2308 [ may need additional changes based on Sam's preauth draft ] 2310 8.3.2.2. TGS-REQ Authentication 2312 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- 2313 tgs-req". The KDC MUST validate the checksum in the Authenticator of 2314 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- 2315 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the 2316 request. [ padata not signed by authenticator! ] Any error from the 2317 AP-REQ validation process SHOULD be returned in a KRB-ERROR message. 2318 The service principal in the ticket of the AP-REQ may be a ticket- 2319 granting service principal, or a normal application service 2320 principal. A ticket which is not a ticket-granting ticket MUST NOT 2321 be used to issue a ticket for any service other than the one named in 2322 the ticket. In this case, the "renew", "validate", or "proxy" [?also 2323 forwarded?] option must be set in the request. 2325 8.3.2.3. Principal Validation 2327 If the client principal in an AS-REQ is unknown, the KDC returns the 2328 error "kdc-err-c-principal-unknown". If the server principal in a 2329 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- 2330 unknown". 2332 8.3.2.4. Checking For Revoked or Invalid Tickets 2334 [ KCLAR 3.3.3.1 ] 2336 Whenever a request is made to the ticket-granting server, the 2337 presented ticket(s) is(are) checked against a hot-list of tickets 2338 which have been canceled. This hot-list might be implemented by 2339 storing a range of issue timestamps for "suspect tickets"; if a 2340 presented ticket had an authtime in that range, it would be rejected. 2341 In this way, a stolen ticket-granting ticket or renewable ticket 2342 cannot be used to gain additional tickets (renewals or otherwise) 2343 once the theft has been reported to the KDC for the realm in which 2344 the server resides. Any normal ticket obtained before it was 2345 reported stolen will still be valid (because they require no 2346 interaction with the KDC), but only until their normal expiration 2347 time. If TGTs have been issued for cross-realm authentication, use 2348 of the cross-realm TGT will not be affected unless the hot-list is 2349 propagated to the KDCs for the realms for which such cross-realm 2350 tickets were issued. 2352 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT 2353 issue any ticket unless the TGS-REQ requests the "validate" option. 2355 8.3.3. Timestamp Handling 2357 [ some aspects of timestamp handling, especially regarding postdating 2358 and renewal, are difficult to read in KCLAR... needs closer 2359 examination here ] 2361 Processing of "starttime" (requested in the "from" field) differs 2362 depending on whether the "postdated" option is set in the request. 2363 If the "postdated" option is not set, and the requested "starttime" 2364 is in the future beyond the window of acceptable clock skew, the KDC 2365 returns the error "kdc-err-cannot-postdate". If the "postdated" 2366 option is not set, and the requested "starttime" is absent or does 2367 not indicate a time in the future beyond the acceptable clock skew, 2368 the KDC sets the "starttime" to the KDC's current time. The 2369 "postdated" option MUST NOT be honored if the ticket is being 2370 requested by TGS-REQ and the "may-postdate" is not set in the TGT. 2371 Otherwise, if the "postdated" option is set, and site policy permits, 2372 the KDC sets the "starttime" as requested, and sets the "invalid" 2373 flag in the new ticket. 2375 The "till" field is required in the RFC 1510 version of the KDC-REQ. 2376 If the "till" field is equal to "19700101000000Z" (midnight, January 2377 1, 1970), the KDC SHOULD behave as if the "till" field were absent. 2379 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or 2380 "renew-till" time is later than the "renew-till" time of the ticket 2381 from which it is derived. 2383 8.3.3.1. AS-REQ Timestamp Processing 2385 In the AS exchange, the "authtime" of a ticket is set to the local 2386 time at the KDC. 2388 The "endtime" of the ticket will be set to the earlier of the 2389 requested "till" time and a time determined by local policy, possibly 2390 determined using factors specific to the realm or principal. For 2391 example, the expiration time MAY be set to the earliest of the 2392 following: 2394 * the expiration time ("till" value) requested 2396 * the ticket's start time plus the maximum allowable lifetime 2397 associated with the client principal from the authentication 2398 server's database 2400 * the ticket's start time plus the maximum allowable lifetime 2401 associated with the server principal 2403 * the ticket's start time plus the maximum lifetime set by the 2404 policy of the local realm 2406 If the requested expiration time minus the start time (as determined 2407 above) is less than a site-determined minimum lifetime, an error 2408 message with code "kdc-err-never-valid" is returned. If the 2409 requested expiration time for the ticket exceeds what was determined 2410 as above, and if the "renewable-ok" option was requested, then the 2411 "renewable" flag is set in the new ticket, and the "renew-till" value 2412 is set as if the "renewable" option were requested. 2414 If the "renewable" option has been requested or if the "renewable-ok" 2415 option has been set and a renewable ticket is to be issued, then the 2416 "renew-till" field MAY be set to the earliest of: 2418 * its requested value 2420 * the start time of the ticket plus the minimum of the two maximum 2421 renewable lifetimes associated with the principals' database 2422 entries 2424 * the start time of the ticket plus the maximum renewable lifetime 2425 set by the policy of the local realm 2427 8.3.3.2. TGS-REQ Timestamp Processing 2429 In the TGS exchange, the KDC sets the "authtime" to that of the 2430 ticket in the AP-REQ authenticating the TGS-REQ. [?application 2431 server can print a ticket for itself with a spoofed authtime. 2432 security issues for hot-list?] [ MIT implementation may change 2433 authtime of renewed tickets; needs check... ] 2434 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ 2435 requests an "endtime" (in the "till" field), then the "endtime" of 2436 the new ticket is set to the minimum of 2438 * the requested "endtime" value, 2440 * the "endtime" in the TGT, and 2442 * an "endtime" determined by site policy on ticket lifetimes. 2444 If the new ticket is a renewal, the "endtime" of the new ticket is 2445 bounded by the minimum of 2447 * the requested "endtime" value, 2449 * the value of the "renew-till" value of the old, 2451 * the "starttime" of the new ticket plus the lifetime (endtime 2452 minus starttime) of the old ticket, i.e., the lifetime of the 2453 new ticket may not exceed that of the ticket being renewed [ 2454 adapted from KCLAR 3.3.3. ], and 2456 * an "endtime" determined by site policy on ticket lifetimes. 2458 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with 2459 a "starttime", "endtime", or "renew-till" time later than the "renew- 2460 till" time of the TGT. 2462 8.3.4. Handling Transited Realms 2464 The KDC checks the ticket in a TGS-REQ against site policy, unless 2465 the "disable-transited-check" option is set in the TGS-REQ. If site 2466 policy permits the transit path in the TGS-REQ ticket, the KDC sets 2467 the "transited-policy-checked" flag in the issued ticket. If the 2468 "disable-transited-check" option is set, the issued ticket will have 2469 the "transited-policy-checked" flag cleared. 2471 8.3.5. Address Processing The requested "addresses" in the KDC-REQ are 2472 copied into the issued ticket. If the "addresses" field is absent or 2473 empty in a TGS-REQ, the KDC copies addresses from the ticket in the 2474 TGS-REQ into the issued ticket, unless the either "forwarded" or 2475 "proxy" option is set. If the "forwarded" option is set, and the 2476 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies 2477 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the 2478 issued ticket. The KDC behaves similarly if the "proxy" option is 2479 set in the TGS-REQ and the "proxiable" flag is set in the ticket. 2480 The "proxy" option will not be honored on requests for additional 2481 ticket-granting tickets. 2483 8.3.6. Ticket Flag Processing 2485 Many kdc-options request that the KDC set a corresponding flag in the 2486 issued ticket. kdc-options marked with an asterisk (*) in the 2487 following table do not directly request the corresponding ticket flag 2488 and therefore require special handling. 2490 | 2491 kdc-option | ticket flag affected 2492 -------------------------+-------------------------- 2493 forwardable | forwardable 2494 forwarded | forwarded 2495 proxiable | proxiable 2496 proxy | proxy 2497 allow-postdate | may-postdate 2498 postdated | postdated 2499 renewable | renewable 2500 requestanonymous | anonymous 2501 canonicalize | - 2502 disable-transited-check* | transited-policy-checked 2503 renewable-ok* | renewable 2504 enc-tkt-in-skey | - 2505 renew | - 2506 validate* | invalid 2508 forwarded 2509 The KDC sets the "forwarded" flag in the issued ticket if the 2510 "forwarded" option is set in the TGS-REQ and the "forwardable" 2511 flag is set in the TGS-REQ ticket. 2513 proxy 2514 The KDC sets the "proxy" flag in the issued ticket if the 2515 "proxy" option is set in the TGS-REQ and the "proxiable" flag is 2516 set in the TGS-REQ ticket. 2518 disable-transited-check 2519 The handling of the "disable-transited-check" kdc-option is 2520 described in Section 8.3.4. 2522 renewable-ok 2523 The handling of the "renewable-ok" kdc-option is described in 2524 Section 8.3.3.1. 2526 enc-tkt-in-skey 2527 This flag modifies ticket key selection to use the session key 2528 of an additional ticket included in the TGS-REQ, for the purpose 2529 of user-to-user authentication. 2531 validate 2532 If the "validate" kdc-option is set in a TGS-REQ, and the 2533 "starttime" has passed, the KDC will clear the "invalid" bit on 2534 the ticket before re-issuing it. 2536 8.3.7. Key Selection 2538 Three keys are involved in creating a KDC-REP. The reply key 2539 encrypts the encrypted part of the KDC-REP. The session key is 2540 stored in the encrypted part of the ticket, and is also present in 2541 the encrypted part of the KDC-REP so that the client can retrieve it. 2542 The ticket key is used to encrypt the ticket. These keys all have 2543 initial values for a given exchange; pre-authentication and other 2544 extension mechanisms may change the value used for any of these keys. 2546 [ again, may need changes based on Sam's preauth draft ] 2548 8.3.7.1. Reply Key and Session Key Selection 2550 The set of encryption types which the client will understand appears 2551 in the "etype" field of KDC-REQ-BODY. The KDC limits the set of 2552 possible reply keys and the set of session key encryption types based 2553 on the "etype" field. 2555 For the AS exchange, the reply key is initially a long-term key of 2556 the client, limited to those encryption types listed in the "etype" 2557 field. The KDC SHOULD use the first valid strong "etype" for which 2558 an encryption key is available. For the TGS exchange, the reply key 2559 is initially the subsession key of the Authenticator. If the 2560 Authenticator subsesion key is absent, the reply key is initially the 2561 session key of the ticket used to authenticate the TGS-REQ. 2563 The session key is initially randomly generated, and has an 2564 encryption type which both the client and the server will understand. 2565 Typically, the KDC has prior knowledge of which encryption types the 2566 server will understand. It selects the first valid strong "etype" 2567 listed the request which the server also will understand. 2569 8.3.7.2. Ticket Key Selection 2571 The ticket key is initially the long-term key of the service. The 2572 "enc-tkt-in-skey" option requests user-to-user authentication, where 2573 the ticket encryption key of the issued ticket is set equal to the 2574 session key of the additional ticket in the request. 2576 8.4. KDC-REP 2578 The important parts of the KDC-REP are encrypted. 2580 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 2581 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 2583 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 2584 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 2586 EncKDCRepPart1510 ::= SEQUENCE { 2587 key [0] EncryptionKey, 2588 last-req [1] LastReq, 2589 nonce [2] Nonce32, 2590 key-expiration [3] KerberosTime OPTIONAL, 2591 flags [4] TicketFlags, 2592 authtime [5] KerberosTime, 2593 starttime [6] KerberosTime OPTIONAL, 2594 endtime [7] KerberosTime, 2595 renew-till [8] KerberosTime OPTIONAL, 2596 srealm [9] RealmIA5, 2597 sname [10] PrincipalNameIA5, 2598 caddr [11] HostAddresses OPTIONAL 2599 } 2601 EncKDCRepPartExt ::= SEQUENCE { 2602 key [0] EncryptionKey, 2603 last-req [1] LastReq, 2604 nonce [2] Nonce, 2605 key-expiration [3] KerberosTime OPTIONAL, 2606 flags [4] TicketFlags, 2607 authtime [5] KerberosTime, 2608 starttime [6] KerberosTime OPTIONAL, 2609 endtime [7] KerberosTime, 2610 renew-till [8] KerberosTime OPTIONAL, 2611 srealm [9] Realm, 2612 sname [10] PrincipalName, 2613 caddr [11] HostAddresses OPTIONAL, 2614 ... 2615 } 2617 Most of the fields of EncKDCRepPartCom are duplicates of the 2618 corresponding fields in the returned ticket. 2620 KDC-REP-1510 { EncPart } ::= SEQUENCE { 2621 pvno [0] INTEGER (5), 2622 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 2623 13 -- TGS.rfc1510 -- ), 2624 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 2625 crealm [3] RealmIA5, 2626 cname [4] PrincipalNameIA5, 2627 ticket [5] Ticket, 2629 enc-part [6] EncryptedData { 2630 EncPart, 2631 { key-reply }, 2632 -- maybe reach into EncryptedData in AS-REP/TGS-REP 2633 -- definitions to apply constraints on key usages? 2634 { ku-EncASRepPart -- if AS-REP -- | 2635 ku-EncTGSRepPart-subkey -- if TGS-REP and 2636 -- using Authenticator 2637 -- session key -- | 2638 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 2639 -- subsession key -- } 2640 } 2641 } 2642 KDC-REP-EXT { EncPart } ::= SEQUENCE { 2643 pvno [0] INTEGER (5), 2644 msg-type [1] INTEGER (7 -- AS-REP.ext -- | 2645 9 -- TGS-REP.ext -- ), 2646 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 2647 crealm [3] RealmExt, 2648 cname [4] PrincipalNameExt, 2649 ticket [5] Ticket, 2651 enc-part [6] EncryptedData { 2652 EncPart, 2653 { key-reply }, 2654 -- maybe reach into EncryptedData in AS-REP/TGS-REP 2655 -- definitions to apply constraints on key usages? 2656 { ku-EncASRepPart -- if AS-REP -- | 2657 ku-EncTGSRepPart-subkey -- if TGS-REP and 2658 -- using Authenticator 2659 -- session key -- | 2660 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 2661 -- subsession key -- } 2662 }, 2664 ..., 2665 -- In extensible version, KDC signs original request 2666 -- to avoid replay attacks against client. 2667 req-cksum [7] ChecksumOf { CHOICE { 2668 as-req AS-REQ, 2669 tgs-req TGS-REQ 2670 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 2671 lang-tag [8] LangTag OPTIONAL, 2672 ... 2673 } 2675 req-cksum 2676 Signature of the original request using the reply key, to avoid 2677 replay attacks against the client, among other things. Only 2678 present in the extensible version of KDC-REP. 2680 AS-REP ::= CHOICE { 2681 rfc1510 AS-REP-1510, 2682 ext AS-REP-EXT 2683 } 2684 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 2685 AS-REP-EXT ::= [APPLICATION 7] Signed { 2686 [APPLICATION 7] KDC-REP-EXT, 2687 { key-reply }, { ku-ASRep-cksum } 2688 } 2689 TGS-REP ::= CHOICE { 2690 rfc1510 TGS-REP-1510, 2691 ext TGS-REP-EXT 2692 } 2693 TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 } 2694 TGS-REP-EXT ::= [APPLICATION 9] Signed { 2695 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 2696 { key-reply }, { ku-TGSRep-cksum } 2697 } 2699 The extensible versions of AS-REQ and TGS-REQ are signed with the 2700 reply key, to prevent an attacker from performing a delayed denial- 2701 of-service attack by substituting the ticket. 2703 8.5. Reply Validation 2705 [ signature verification ] 2707 8.6. IP Transports 2709 [ KCLAR 7.2 ] 2711 Kerberos defines two IP transport mechanisms for the credentials 2712 acquisition protocol: UDP/IP and TCP/IP. 2714 8.6.1. UDP/IP transport 2716 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 2717 requests and SHOULD listen for such requests on port 88 (decimal) 2718 unless specifically configured to listen on an alternative UDP port. 2719 Alternate ports MAY be used when running multiple KDCs for multiple 2720 realms on the same host. 2722 Kerberos clients supporting IP transports SHOULD support the sending 2723 of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to 2724 identify the IP address and port to which they will send their 2725 request. 2727 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 2728 transport, the client shall send a UDP datagram containing only an 2729 encoding of the request to the KDC. The KDC will respond with a reply 2730 datagram containing only an encoding of the reply message (either a 2731 KRB-ERROR or a KDC-REP) to the sending port at the sender's IP 2732 address. The response to a request made through UDP/IP transport MUST 2733 also use UDP/IP transport. If the response can not be handled using 2734 UDP (for example because it is too large), the KDC MUST return "krb- 2735 err-response-too-big", forcing the client to retry the request using 2736 the TCP transport. 2738 8.6.2. TCP/IP transport 2740 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 2741 requests and SHOULD listen for such requests on port 88 (decimal) 2742 unless specifically configured to listen on an alternate TCP port. 2743 Alternate ports MAY be used when running multiple KDCs for multiple 2744 realms on the same host. 2746 Clients MUST support the sending of TCP requests, but MAY choose to 2747 initially try a request using the UDP transport. Clients SHOULD use 2748 KDC discovery (Section 8.6.3) to identify the IP address and port to 2749 which they will send their request. 2751 Implementation note: Some extensions to the Kerberos protocol will 2752 not succeed if any client or KDC not supporting the TCP transport is 2753 involved. Implementations of RFC 1510 were not required to support 2754 TCP/IP transports. 2756 When the KDC-REQ message is sent to the KDC over a TCP stream, the 2757 response (KDC-REP or KRB-ERROR message) MUST be returned to the 2758 client on the same TCP stream that was established for the request. 2759 The KDC MAY close the TCP stream after sending a response, but MAY 2760 leave the stream open for a reasonable period of time if it expects a 2761 followup. Care must be taken in managing TCP/IP connections on the 2762 KDC to prevent denial of service attacks based on the number of open 2763 TCP/IP connections. 2765 The client MUST be prepared to have the stream closed by the KDC at 2766 anytime after the receipt of a response. A stream closure SHOULD NOT 2767 be treated as a fatal error. Instead, if multiple exchanges are 2768 required (e.g., certain forms of pre-authentication) the client may 2769 need to establish a new connection when it is ready to send 2770 subsequent messages. A client MAY close the stream after receiving a 2771 response, and SHOULD close the stream if it does not expect to send 2772 followup messages. 2774 A client MAY send multiple requests before receiving responses, 2775 though it must be prepared to handle the connection being closed 2776 after the first response. 2778 Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over 2779 the TCP stream is preceded by the length of the request as 4 octets 2780 in network byte order. The high bit of the length is reserved for 2781 future expansion and MUST currently be set to zero. If a KDC that 2782 does not understand how to interpret a set high bit of the length 2783 encoding receives a request with the high order bit of the length 2784 set, it MUST return a KRB-ERROR message with the error "krb-err- 2785 field-toolong" and MUST close the TCP stream. 2787 If multiple requests are sent over a single TCP connection, and the 2788 KDC sends multiple responses, the KDC is not required to send the 2789 responses in the order of the corresponding requests. This may 2790 permit some implementations to send each response as soon as it is 2791 ready even if earlier requests are still being processed (for 2792 example, waiting for a response from an external device or database). 2794 8.6.3. KDC Discovery on IP Networks 2796 Kerberos client implementations MUST provide a means for the client 2797 to determine the location of the Kerberos Key Distribution Centers 2798 (KDCs). Traditionally, Kerberos implementations have stored such 2799 configuration information in a file on each client machine. 2800 Experience has shown this method of storing configuration information 2801 presents problems with out-of-date information and scaling problems, 2802 especially when using cross-realm authentication. This section 2803 describes a method for using the Domain Name System [RFC 1035] for 2804 storing KDC location information. 2806 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 2808 In Kerberos, realm names are case sensitive. While it is strongly 2809 encouraged that all realm names be all upper case this recommendation 2810 has not been adopted by all sites. Some sites use all lower case 2811 names and other use mixed case. DNS, on the other hand, is case 2812 insensitive for queries. Since the realm names "MYREALM", "myrealm", 2813 and "MyRealm" are all different, but resolve the same in the domain 2814 name system, it is necessary that only one of the possible 2815 combinations of upper and lower case characters be used in realm 2816 names. 2818 8.6.3.2. DNS SRV records for KDC location 2820 KDC location information is to be stored using the DNS SRV RR [RFC 2821 2782]. The format of this RR is as follows: 2823 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target 2825 The Service name for Kerberos is always "kerberos". 2827 The Proto can be one of "udp", "tcp". If these SRV records are to be 2828 used, both "udp" and "tcp" records MUST be specified for all KDC 2829 deployments. 2831 The Realm is the Kerberos realm that this record corresponds to. The 2832 realm MUST be a domain style realm name. 2834 TTL, Class, SRV, Priority, Weight, and Target have the standard 2835 meaning as defined in RFC 2782. 2837 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV 2838 records SHOULD be the value assigned to "kerberos" by the Internet 2839 Assigned Number Authority: 88 (decimal) unless the KDC is configured 2840 to listen on an alternate TCP port. 2842 Implementation note: Many existing client implementations do not 2843 support KDC Discovery and are configured to send requests to the IANA 2844 assigned port (88 decimal), so it is strongly recommended that KDCs 2845 be configured to listen on that port. 2847 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 2849 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 2850 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 2851 should be directed to kdc1.example.com first as per the specified 2852 priority. Weights are not used in these sample records. 2854 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 2855 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 2856 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 2857 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 2859 9. Errors 2861 The KRB-ERROR message is returned by the KDC if an error occurs 2862 during credentials acquisition. It may also be returned by an 2863 application server if an error occurs during authentication. 2865 ErrCode ::= Int32 2867 KRB-ERROR ::= CHOICE { 2868 rfc1510 KRB-ERROR-1510, 2869 ext KRB-ERROR-EXT 2870 } 2872 The extensible KRB-ERROR is only signed if there has been a key 2873 negotiated with its recipient. KRB-ERROR messages sent in response 2874 to AS-REQ messages will probably not be signed unless a 2875 preauthentication mechanism has negotiated a key. (Signing using a 2876 client's long-term key can expose ciphertext to dictionary attacks.) 2877 KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE { 2878 pvno [0] INTEGER (5), 2879 msg-type [1] INTEGER (30), 2880 ctime [2] KerberosTime OPTIONAL, 2881 cusec [3] Microseconds OPTIONAL, 2882 stime [4] KerberosTime, 2883 susec [5] Microseconds, 2884 error-code [6] ErrCode, 2885 crealm [7] RealmIA5 OPTIONAL, 2886 cname [8] PrincipalNameIA5 OPTIONAL, 2887 realm [9] RealmIA5 -- Correct realm --, 2888 sname [10] PrincipalNameIA5 -- Correct name --, 2889 e-text [11] KerberosString OPTIONAL, 2890 e-data [12] OCTET STRING OPTIONAL 2891 } 2893 KRB-ERROR-EXT ::= [APPLICATION 23] Signed { 2894 [APPLICATION 23] SEQUENCE{ 2895 pvno [0] INTEGER (5), 2896 msg-type [1] INTEGER (23), 2897 ctime [2] KerberosTime OPTIONAL, 2898 cusec [3] Microseconds OPTIONAL, 2899 stime [4] KerberosTime, 2900 susec [5] Microseconds, 2901 error-code [6] ErrCode, 2902 crealm [7] Realm OPTIONAL, 2903 cname [8] PrincipalName OPTIONAL, 2904 realm [9] Realm -- Correct realm --, 2905 sname [10] PrincipalName -- Correct name --, 2906 e-text [11] KerberosString OPTIONAL, 2907 e-data [12] OCTET STRING OPTIONAL, 2908 ..., 2909 typed-data [13] TYPED-DATA OPTIONAL, 2910 nonce [14] Nonce OPTIONAL, 2911 lang-tag [15] LangTag OPTIONAL, 2912 ... 2913 }, { }, { ku-KrbError-cksum } 2914 } 2916 ctime, cusec 2917 Client's time, if known from a KDC-REQ or AP-REQ. 2919 stime, susec 2920 KDC or application server's current time. 2922 error-code 2923 Numeric error code designating the error. 2925 crealm, cname 2926 Client's realm and name, if known. 2928 realm, sname 2929 server's realm and name. [ XXX what if these aren't known? ] 2931 e-text 2932 Human-readable text providing additional details for the error. 2934 e-data 2935 This field contains additional data about the error for use by 2936 the client to help it recover from or handle the error. If the 2937 "error-code" is "kdc-err-preauth-required", then the e-data 2938 field will contain an encoding of a sequence of padata fields, 2939 each corresponding to an acceptable pre-authentication method 2940 and optionally containing data for the method: 2942 METHOD-DATA ::= SEQUENCE OF PA-DATA 2944 For error codes defined in this document other than "kdc-err- 2945 preauth-required", the format and contents of the e-data field 2946 are implementation-defined. Similarly, for future error codes, 2947 the format and contents of the e-data field are implementation- 2948 defined unless specified. 2950 lang-tag 2951 Indicates the language of the message in the "e-text" field. It 2952 is only present in the extensible KRB-ERROR. 2954 nonce 2955 is the nonce from a KDC-REQ. It is only present in the 2956 extensible KRB-ERROR. 2958 typed-data 2959 TYPED-DATA is a typed hole allowing for additional data to be 2960 returned in error conditions, since "e-data" is insufficiently 2961 flexible for some purposes. TYPED-DATA is only present in the 2962 extensible KRB-ERROR. 2964 TDType ::= TH-id 2966 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 2967 data-type [0] TDType, 2968 data-value [1] OCTET STRING OPTIONAL 2969 } 2971 10. Session Key Exchange 2972 Session key exchange consists of the AP-REQ and AP-REP messages. The 2973 client sends the AP-REQ message, and the service responds with an AP- 2974 REP message if mutual authentication is desired. Following session 2975 key exchange, the client and service share a secret session key, or 2976 possibly a subsesion key, which can be used to protect further 2977 communications. Additionally, the session key exchange process can 2978 establish initial sequence numbers which the client and service can 2979 use to detect replayed messages. 2981 10.1. AP-REQ 2983 An AP-REQ message contains a ticket and a authenticator. The 2984 authenticator is ciphertext encrypted with the session key contained 2985 in the ticket. The plaintext contents of the authenticator are: 2987 -- plaintext of authenticator 2988 Authenticator1510 ::= [APPLICATION 2] SEQUENCE { 2989 authenticator-vno [0] INTEGER (5), 2990 crealm [1] RealmIA5, 2991 cname [2] PrincipalNameIA5, 2992 cksum [3] Checksum {{ key-session }, 2993 { ku-Authenticator-cksum | 2994 ku-pa-TGSReq-cksum }} OPTIONAL, 2995 cusec [4] Microseconds, 2996 ctime [5] KerberosTime, 2997 subkey [6] EncryptionKey OPTIONAL, 2998 seq-number [7] SeqNum32 OPTIONAL, 2999 authorization-data [8] AuthorizationData OPTIONAL 3000 } 3002 AuthenticatorExt ::= [APPLICATION 35] SEQUENCE { 3003 authenticator-vno [0] INTEGER (5), 3004 crealm [1] RealmExt, 3005 cname [2] PrincipalNameExt, 3006 cksum [3] Checksum {{ key-session }, 3007 { ku-Authenticator-cksum | 3008 ku-pa-TGSReq-cksum }} OPTIONAL, 3009 cusec [4] Microseconds, 3010 ctime [5] KerberosTime, 3011 subkey [6] EncryptionKey OPTIONAL, 3012 seq-number [7] SeqNum OPTIONAL, 3013 authorization-data [8] AuthorizationData OPTIONAL, 3014 ... 3015 } 3017 The complete definition of AP-REQ is: 3019 AP-REQ ::= CHOICE { 3020 rfc1510 AP-REQ-1510, 3021 ext AP-REQ-EXT 3022 } 3023 AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE { 3024 pvno [0] INTEGER (5), 3025 msg-type [1] INTEGER (14), 3026 ap-options [2] APOptions, 3027 ticket [3] Ticket1510, 3028 authenticator [4] EncryptedData { 3029 Authenticator1510, 3030 { key-session }, 3031 { ku-APReq-authenticator | 3032 ku-pa-TGSReq-authenticator } 3033 } 3034 } 3036 AP-REQ-EXT ::= [APPLICATION 18] Signed { 3037 [APPLICATION 18] SEQUENCE { 3038 pvno [0] INTEGER (5), 3039 msg-type [1] INTEGER (18), 3040 ap-options [2] APOptions, 3041 ticket [3] Ticket, 3042 authenticator [4] EncryptedData { 3043 AuthenticatorExt, 3044 { key-session }, 3045 { ku-APReq-authenticator | 3046 ku-pa-TGSReq-authenticator } 3047 }, 3048 ..., 3049 extensions [5] ApReqExtensions OPTIONAL, 3050 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 3051 OF LangTag OPTIONAL, 3052 ... 3053 }, { key-session }, { ku-APReq-cksum } 3054 } 3056 APOptions ::= KerberosFlags { APOptionsBits } 3058 APOptionsBits ::= BIT STRING { 3059 reserved (0), 3060 use-session-key (1), 3061 mutual-required (2) 3062 } 3064 10.2. AP-REP 3066 An AP-REP message provides mutual authentication of the service to 3067 the client. 3069 EncAPRepPart ::= CHOICE { 3070 rfc1510 EncAPRepPart1510, 3071 ext EncAPRepPartExt 3072 } 3074 EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE { 3075 ctime [0] KerberosTime, 3076 cusec [1] Microseconds, 3077 subkey [2] EncryptionKey OPTIONAL, 3078 seq-number [3] SeqNum32 OPTIONAL 3079 } 3081 EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE { 3082 ctime [0] KerberosTime, 3083 cusec [1] Microseconds, 3084 subkey [2] EncryptionKey OPTIONAL, 3085 seq-number [3] SeqNum OPTIONAL, 3086 ..., 3087 authorization-data [4] AuthorizationData OPTIONAL, 3088 ... 3089 } 3091 AP-REP ::= CHOICE { 3092 rfc1510 AP-REP-1510, 3093 ext AP-REP-EXT 3094 } 3096 AP-REP-1510 ::= [APPLICATION 15] SEQUENCE { 3097 pvno [0] INTEGER (5), 3098 msg-type [1] INTEGER (15), 3099 enc-part [2] EncryptedData { 3100 EncApRepPart1510, 3101 { key-session | key-subsession }, { ku-EncAPRepPart }} 3102 } 3103 AP-REP-EXT ::= [APPLICATION 19] Signed { 3104 [APPLICATION 19] SEQUENCE { 3105 pvno [0] INTEGER (5), 3106 msg-type [1] INTEGER (19), 3107 enc-part [2] EncryptedData { 3108 EncAPRepPartExt, 3109 { key-session | key-subsession }, { ku-EncAPRepPart }}, 3110 ..., 3111 extensions [3] ApRepExtensions OPTIONAL, 3112 ... 3113 }, { key-session | key-subsession }, { ku-APRep-cksum } 3114 } 3116 11. Session Key Use 3118 Once a session key has been established, the client and server can 3119 use several kinds of messages to securely transmit data. KRB-SAFE 3120 provides integrity protection for application data, while KRB-PRIV 3121 provides confidentiality along with integrity protection. The KRB- 3122 CRED message provides a means of securely forwarding credentials from 3123 the client host to the server host. 3125 11.1. KRB-SAFE 3127 The KRB-SAFE message provides integrity protection for an included 3128 cleartext message. 3130 KRB-SAFE ::= CHOICE { 3131 rfc1510 KRB-SAFE-1510, 3132 ext KRB-SAFE-EXT 3133 } 3135 KRB-SAFE-BODY ::= SEQUENCE { 3136 user-data [0] OCTET STRING, 3137 timestamp [1] KerberosTime OPTIONAL, 3138 usec [2] Microseconds OPTIONAL, 3139 seq-number [3] SeqNum OPTIONAL, 3140 s-address [4] HostAddress, 3141 r-address [5] HostAddress OPTIONAL, 3142 ... -- ASN.1 extensions must be excluded 3143 -- when sending to rfc1510 implementations 3144 } 3146 11.2. KRB-PRIV 3148 The KRB-PRIV message provides confidentiality and integrity 3149 protection. 3151 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3152 pvno [0] INTEGER (5), 3153 msg-type [1] INTEGER (21), 3154 enc-part [3] EncryptedData { 3155 EncKrbPrivPart, 3156 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 3157 ... 3158 } 3160 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 3161 user-data [0] OCTET STRING, 3162 timestamp [1] KerberosTime OPTIONAL, 3163 usec [2] Microseconds OPTIONAL, 3164 seq-number [3] SeqNum OPTIONAL, 3165 s-address [4] HostAddress -- sender's addr --, 3166 r-address [5] HostAddress OPTIONAL -- recip's addr --, 3167 ... -- ASN.1 extensions must be excluded 3168 -- when sending to rfc1510 implementations 3169 } 3171 11.3. KRB-CRED 3173 The KRB-CRED message provides a means of securely transferring 3174 credentials from the client to the service. 3176 KRB-CRED ::= CHOICE { 3177 rfc1510 KRB-CRED-1510, 3178 ext KRB-CRED-EXT 3180 } 3182 KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { 3183 pvno [0] INTEGER (5), 3184 msg-type [1] INTEGER (22), 3185 tickets [2] SEQUENCE OF Ticket, 3186 enc-part [3] EncryptedData { 3187 EncKrbCredPart, 3188 { key-session | key-subsession }, { ku-EncKrbCredPart }} 3189 } 3190 KRB-CRED-EXT ::= [APPLICATION 24] Signed { 3191 [APPLICATION 24] SEQUENCE { 3192 pvno [0] INTEGER (5), 3193 msg-type [1] INTEGER (24), 3194 tickets [2] SEQUENCE OF Ticket, 3195 enc-part [3] EncryptedData { 3196 EncKrbCredPart, 3197 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 3198 ... 3199 }, { key-session | key-subsession }, { ku-KrbCred-cksum } 3200 } 3202 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3203 ticket-info [0] SEQUENCE OF KrbCredInfo, 3204 nonce [1] Nonce OPTIONAL, 3205 timestamp [2] KerberosTime OPTIONAL, 3206 usec [3] Microseconds OPTIONAL, 3207 s-address [4] HostAddress OPTIONAL, 3208 r-address [5] HostAddress OPTIONAL 3209 } 3211 KrbCredInfo ::= SEQUENCE { 3212 key [0] EncryptionKey, 3213 prealm [1] Realm OPTIONAL, 3214 pname [2] PrincipalName OPTIONAL, 3215 flags [3] TicketFlags OPTIONAL, 3216 authtime [4] KerberosTime OPTIONAL, 3217 starttime [5] KerberosTime OPTIONAL, 3218 endtime [6] KerberosTime OPTIONAL, 3219 renew-till [7] KerberosTime OPTIONAL, 3220 srealm [8] Realm OPTIONAL, 3221 sname [9] PrincipalName OPTIONAL, 3222 caddr [10] HostAddresses OPTIONAL 3223 } 3225 12. Security Considerations 3227 12.1. Time Synchronization 3229 Time synchronization between the KDC and application servers is 3230 necessary to prevent acceptance of expired tickets. 3232 Time synchronization is needed between application servers and 3233 clients to prevent replay attacks if a replay cache is being used. 3234 If negotiated subsession keys are used to encrypt application data, 3235 replay caches may not be necessary. 3237 12.2. Replays 3239 12.3. Principal Name Reuse 3241 See Section 5.3. 3243 12.4. Password Guessing 3245 12.5. Forward Secrecy 3247 [from KCLAR 10.; needs some rewriting] 3249 The Kerberos protocol in its basic form does not provide perfect 3250 forward secrecy for communications. If traffic has been recorded by 3251 an eavesdropper, then messages encrypted using the KRB-PRIV message, 3252 or messages encrypted using application-specific encryption under 3253 keys exchanged using Kerberos can be decrypted if any of the user's, 3254 application server's, or KDC's key is subsequently discovered. This 3255 is because the session key used to encrypt such messages is 3256 transmitted over the network encrypted in the key of the application 3257 server, and also encrypted under the session key from the user's 3258 ticket-granting ticket when returned to the user in the TGS-REP 3259 message. The session key from the ticket-granting ticket was sent to 3260 the user in the AS-REP message encrypted in the user's secret key, 3261 and embedded in the ticket-granting ticket, which was encrypted in 3262 the key of the KDC. Application requiring perfect forward secrecy 3263 must exchange keys through mechanisms that provide such assurance, 3264 but may use Kerberos for authentication of the encrypted channel 3265 established through such other means. 3267 12.6. Authorization 3269 As an authentication service, Kerberos provides a means of verifying 3270 the identity of principals on a network. Kerberos does not, by 3271 itself, provide authorization. Applications SHOULD NOT accept the 3272 mere issuance of a service ticket by the Kerberos server as granting 3273 authority to use the service. 3275 12.7. Login Authentication 3277 Some applications, particularly those which provide login access when 3278 provided with a password, SHOULD NOT treat successful acquisition of 3279 credentials as sufficient proof of the user's identity. An attacker 3280 posing as a user could generate an illegitimate KDC-REP message which 3281 decrypts properly. To authenticate a user logging on to a local 3282 system, the credentials obtained SHOULD be used in a TGS exchange to 3283 obtain credentials for a local service. Successful use of those 3284 credentials to authenticate to the local service assures that the 3285 initially obtained credentials are from a valid KDC. 3287 13. IANA Considerations 3289 [ needs more work ] 3291 Each use of Int32 in this document defines a number space. [ XXX 3292 enumerate these ] Negative numbers are reserved for private use; 3293 local and experimental extensions should use these values. Zero is 3294 reserved and may not be assigned. 3296 Typed hole contents may be identified by either Int32 values or by 3297 RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical 3298 namespace, assignments to the top level of the RELATIVE-OID space may 3299 be made on a first-come, first-served basis. 3301 14. Acknowledgments 3303 Much of the text here is adapted from draft-ietf-krb-wg-kerberos- 3304 clarifications-07. The description of the general form of the 3305 extensibility framework was derived from text by Sam Hartman. Some 3306 text concerning internationalization of internationalized domain 3307 names in principal names and realm names was contributed by Jeffrey 3308 Altman and Jeffrey Hutzelman. 3310 Appendices 3312 A. ASN.1 Module (Normative) 3314 KerberosV5Spec3 { 3315 iso(1) identified-organization(3) dod(6) internet(1) 3316 security(5) kerberosV5(2) modules(4) krb5spec3(4) 3317 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 3319 -- OID arc for KerberosV5 3320 -- 3321 -- This OID may be used to identify Kerberos protocol messages 3322 -- encapsulated in other protocols. 3323 -- 3324 -- This OID also designates the OID arc for KerberosV5-related 3325 -- OIDs. 3326 -- 3327 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its 3328 -- OID. 3329 id-krb5 OBJECT IDENTIFIER ::= { 3330 iso(1) identified-organization(3) dod(6) internet(1) 3331 security(5) kerberosV5(2) 3332 } 3333 -- top-level type 3334 -- 3335 -- Applications should not directly reference any types 3336 -- other than KRB-PDU and its component types. 3337 -- 3338 KRB-PDU ::= CHOICE { 3339 ticket Ticket, 3340 as-req AS-REQ, 3341 as-rep AS-REP, 3342 tgs-req TGS-REQ, 3343 tgs-rep TGS-REP, 3344 ap-req AP-REQ, 3345 ap-rep AP-REP, 3346 krb-safe KRB-SAFE, 3347 krb-priv KRB-PRIV, 3348 krb-cred KRB-CRED, 3349 tgt-req TGT-REQ, 3350 krb-error KRB-ERROR, 3351 ... 3352 } 3354 -- 3355 -- *** basic types 3356 -- 3358 -- signed values representable in 32 bits 3359 -- 3360 -- These are often used as assigned numbers for various things. 3361 Int32 ::= INTEGER (-2147483648..2147483647) 3363 -- Typed hole identifiers 3364 TH-id ::= CHOICE { 3365 int32 Int32, 3366 rel-oid RELATIVE-OID 3367 } 3369 -- unsigned 32 bit values 3370 UInt32 ::= INTEGER (0..4294967295) 3372 -- unsigned 64 bit values 3373 UInt64 ::= INTEGER (0..18446744073709551615) 3375 -- sequence numbers 3376 SeqNum ::= UInt64 3377 -- nonces 3378 Nonce ::= UInt64 3380 -- microseconds 3381 Microseconds ::= INTEGER (0..999999) 3383 KerberosTime ::= GeneralizedTime (CONSTRAINED BY { 3384 -- MUST NOT include fractional seconds 3385 }) 3387 -- used for names and for error messages 3388 KerberosString ::= CHOICE { 3389 ia5 GeneralString (IA5String), 3390 utf8 UTF8String, 3391 ... -- no extension may be sent 3392 -- to an rfc1510 implementation -- 3393 } 3395 -- IA5 choice only; useful for constraints 3396 KerberosStringIA5 ::= KerberosString 3397 (WITH COMPONENTS { ia5 PRESENT }) 3399 -- IA5 excluded; useful for constraints 3400 KerberosStringExt ::= KerberosString 3401 (WITH COMPONENTS { ia5 ABSENT }) 3403 -- used for language tags 3404 LangTag ::= PrintableString 3405 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) 3407 -- assigned numbers for name types (used in principal names) 3408 NameType ::= Int32 3410 -- Name type not known 3411 nt-unknown NameType ::= 0 3412 -- Just the name of the principal as in DCE, or for users 3413 nt-principal NameType ::= 1 3414 -- Service and other unique instance (krbtgt) 3415 nt-srv-inst NameType ::= 2 3416 -- Service with host name as instance (telnet, rcommands) 3417 nt-srv-hst NameType ::= 3 3418 -- Service with host as remaining components 3419 nt-srv-xhst NameType ::= 4 3420 -- Unique ID 3421 nt-uid NameType ::= 5 3422 -- Encoded X.509 Distingished name [RFC 2253] 3423 nt-x500-principal NameType ::= 6 3424 -- Name in form of SMTP email name (e.g. user@foo.com) 3425 nt-smtp-name NameType ::= 7 3426 -- Enterprise name - may be mapped to principal name 3427 nt-enterprise NameType ::= 10 3429 PrincipalName { StrType } ::= SEQUENCE { 3430 name-type [0] NameType, 3431 -- May have zero elements, or individual elements may be 3432 -- zero-length, but this is NOT RECOMMENDED. 3433 name-string [1] SEQUENCE OF KerberosString (StrType) 3434 } 3436 -- IA5 only 3437 PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } 3438 -- IA5 excluded 3439 PrincipalNameExt ::= PrincipalName { KerberosStringExt } 3440 -- Either one? 3441 PrincipalNameEither ::= PrincipalName { KerberosString } 3443 Realm { StrType } ::= KerberosString (StrType) 3445 -- IA5 only 3446 RealmIA5 ::= Realm { KerberosStringIA5 } 3448 -- IA5 excluded 3449 RealmExt ::= Realm { KerberosStringExt } 3451 -- Either 3452 RealmEither ::= Realm { KerberosString } 3453 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) 3454 (CONSTRAINED BY { 3455 -- MUST be a valid value of -- NamedBits 3456 -- but if the value to be sent would be truncated to shorter 3457 -- than 32 bits according to DER, the value MUST be padded 3458 -- with trailing zero bits to 32 bits. Otherwise, no 3459 -- trailing zero bits may be present. 3461 }) 3463 AddrType ::= Int32 3465 HostAddress ::= SEQUENCE { 3466 addr-type [0] AddrType, 3467 address [1] OCTET STRING 3468 } 3470 -- NOTE: HostAddresses is always used as an OPTIONAL field and 3471 -- should not be a zero-length SEQUENCE OF. 3472 -- 3473 -- The extensible messages explicitly constrain this to be 3474 -- non-empty. 3475 HostAddresses ::= SEQUENCE OF HostAddress 3477 -- 3478 -- *** crypto-related types and assignments 3479 -- 3480 -- Assigned numbers denoting encryption mechanisms. 3481 EType ::= Int32 3483 -- assigned numbers for encryption schemes 3484 et-des-cbc-crc EType ::= 1 3485 et-des-cbc-md4 EType ::= 2 3486 et-des-cbc-md5 EType ::= 3 3487 -- [reserved] 4 3488 et-des3-cbc-md5 EType ::= 5 3489 -- [reserved] 6 3490 et-des3-cbc-sha1 EType ::= 7 3491 et-dsaWithSHA1-CmsOID EType ::= 9 3492 et-md5WithRSAEncryption-CmsOID EType ::= 10 3493 et-sha1WithRSAEncryption-CmsOID EType ::= 11 3494 et-rc2CBC-EnvOID EType ::= 12 3495 et-rsaEncryption-EnvOID EType ::= 13 3496 et-rsaES-OAEP-ENV-OID EType ::= 14 3497 et-des-ede3-cbc-Env-OID EType ::= 15 3498 et-des3-cbc-sha1-kd EType ::= 16 3499 -- AES 3500 et-aes128-cts-hmac-sha1-96 EType ::= 17 3501 -- AES 3502 et-aes256-cts-hmac-sha1-96 EType ::= 18 3503 -- Microsoft 3504 et-rc4-hmac EType ::= 23 3505 -- Microsoft 3506 et-rc4-hmac-exp EType ::= 24 3507 -- opaque; PacketCable 3508 et-subkey-keymaterial EType ::= 65 3509 -- Assigned numbers denoting key usages. 3510 KeyUsage ::= UInt32 3512 -- 3513 -- Actual identifier names are provisional and subject to 3514 -- change. 3515 -- 3516 ku-pa-enc-ts KeyUsage ::= 1 3517 ku-Ticket KeyUsage ::= 2 3518 ku-EncASRepPart KeyUsage ::= 3 3519 ku-TGSReqAuthData-sesskey KeyUsage ::= 4 3520 ku-TGSReqAuthData-subkey KeyUsage ::= 5 3521 ku-pa-TGSReq-cksum KeyUsage ::= 6 3522 ku-pa-TGSReq-authenticator KeyUsage ::= 7 3523 ku-EncTGSRepPart-sesskey KeyUsage ::= 8 3524 ku-EncTGSRepPart-subkey KeyUsage ::= 9 3525 ku-Authenticator-cksum KeyUsage ::= 10 3526 ku-APReq-authenticator KeyUsage ::= 11 3527 ku-EncAPRepPart KeyUsage ::= 12 3528 ku-EncKrbPrivPart KeyUsage ::= 13 3529 ku-EncKrbCredPart KeyUsage ::= 14 3530 ku-KrbSafe-cksum KeyUsage ::= 15 3531 ku-ad-KDCIssued-cksum KeyUsage ::= 19 3533 -- The following numbers are provisional... 3534 -- conflicts may exist elsewhere. 3535 ku-Ticket-cksum KeyUsage ::= 25 3536 ku-ASReq-cksum KeyUsage ::= 26 3537 ku-TGSReq-cksum KeyUsage ::= 27 3538 ku-ASRep-cksum KeyUsage ::= 28 3539 ku-TGSRep-cksum KeyUsage ::= 29 3540 ku-APReq-cksum KeyUsage ::= 30 3541 ku-APRep-cksum KeyUsage ::= 31 3542 ku-KrbCred-cksum KeyUsage ::= 32 3543 ku-KrbError-cksum KeyUsage ::= 33 3544 ku-KDCRep-cksum KeyUsage ::= 34 3545 -- KeyToUse identifies which key is to be used to encrypt or 3546 -- sign a given value. 3547 -- 3548 -- Values of KeyToUse are never actually transmitted over the 3549 -- wire, or even used directly by the implementation in any 3550 -- way, as key usages are; it exists primarily to identify 3551 -- which key gets used for what purpose. Thus, the specific 3552 -- numeric values associated with this type are irrelevant. 3553 KeyToUse ::= ENUMERATED { 3554 -- unspecified 3555 key-unspecified, 3556 -- server long term key 3557 key-server, 3558 -- client long term key 3559 key-client, 3560 -- key selected by KDC for encryption of a KDC-REP 3561 key-kdc-rep, 3562 -- session key from ticket 3563 key-session, 3564 -- subsession key negotiated via AP-REQ/AP-REP 3565 key-subsession, 3566 ... 3567 } 3569 EncryptionKey ::= SEQUENCE { 3570 keytype [0] EType, 3571 keyvalue [1] OCTET STRING 3572 } 3573 -- "Type" specifies which ASN.1 type is encrypted to the 3574 -- ciphertext in the EncryptedData. "Keys" specifies a set of 3575 -- keys of which one key may be used to encrypt the data. 3576 -- "KeyUsages" specifies a set of key usages, one of which may 3577 -- be used to encrypt. 3578 -- 3579 -- None of the parameters is transmitted over the wire. 3580 EncryptedData { 3581 Type, KeyToUse:Keys, KeyUsage:KeyUsages 3582 } ::= SEQUENCE { 3583 etype [0] EType, 3584 kvno [1] UInt32 OPTIONAL, 3585 cipher [2] OCTET STRING (CONSTRAINED BY { 3586 -- must be encryption of -- 3587 OCTET STRING (CONTAINING Type), 3588 -- with one of the keys -- KeyToUse:Keys, 3589 -- with key usage being one of -- 3590 KeyUsage:KeyUsages 3591 }), 3592 ... 3593 } 3595 CksumType ::= Int32 3597 -- The parameters specify which key to use to produce the 3598 -- signature, as well as which key usage to use. The 3599 -- parameters are not actually sent over the wire. 3600 Checksum { 3601 KeyToUse:Keys, KeyUsage:KeyUsages 3602 } ::= SEQUENCE { 3603 cksumtype [0] CksumType, 3604 checksum [1] OCTET STRING (CONSTRAINED BY { 3605 -- signed using one of the keys -- 3606 KeyToUse:Keys, 3607 -- with key usage being one of -- 3608 KeyUsage:KeyUsages 3609 }) 3610 } 3611 -- a Checksum that must contain the checksum 3612 -- of a particular type 3613 ChecksumOf { 3614 Type, KeyToUse:Keys, KeyUsage:KeyUsages 3615 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { 3616 ..., 3617 checksum (CONSTRAINED BY { 3618 -- must be checksum of -- 3619 OCTET STRING (CONTAINING Type) 3620 }) 3621 }) 3623 -- parameterized type for wrapping authenticated plaintext 3624 Signed { 3625 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages 3626 } ::= SEQUENCE { 3627 cksum [0] ChecksumOf { 3628 InnerType, Keys, KeyUsages 3629 } OPTIONAL, 3630 inner [1] InnerType, 3631 ... 3632 } 3634 -- 3635 -- *** Tickets 3636 -- 3638 Ticket ::= CHOICE { 3639 rfc1510 Ticket1510, 3640 ext TicketExt 3641 } 3643 Ticket1510 ::= [APPLICATION 1] SEQUENCE { 3644 tkt-vno [0] INTEGER (5), 3645 realm [1] RealmIA5, 3646 sname [2] PrincipalNameIA5, 3647 enc-part [3] EncryptedData { 3648 EncTicketPart1510, { key-server }, { ku-Ticket } 3649 } 3650 } 3651 TicketExt ::= [APPLICATION 4] Signed { 3652 [APPLICATION 4] SEQUENCE { 3653 tkt-vno [0] INTEGER (5), 3654 realm [1] RealmExt, 3655 sname [2] PrincipalNameExt, 3656 enc-part [3] EncryptedData { 3657 EncTicketPartExt, { key-server }, { ku-Ticket } 3658 }, 3659 ..., 3660 extensions [4] TicketExtensions OPTIONAL, 3661 ... 3662 }, 3663 { key-ticket }, { ku-Ticket-cksum } 3664 } 3666 -- Encrypted part of ticket 3667 EncTicketPart ::= CHOICE { 3668 rfc1510 EncTicketPart1510, 3669 ext EncTicketPartExt 3670 } 3672 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { 3673 flags [0] TicketFlags, 3674 key [1] EncryptionKey, 3675 crealm [2] RealmIA5, 3676 cname [3] PrincipalNameIA5, 3677 transited [4] TransitedEncoding, 3678 authtime [5] KerberosTime, 3679 starttime [6] KerberosTime OPTIONAL, 3680 endtime [7] KerberosTime, 3681 renew-till [8] KerberosTime OPTIONAL, 3682 caddr [9] HostAddresses OPTIONAL, 3683 authorization-data [10] AuthorizationData OPTIONAL 3684 } 3685 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { 3686 flags [0] TicketFlags, 3687 key [1] EncryptionKey, 3688 crealm [2] RealmExt, 3689 cname [3] PrincipalNameExt, 3690 transited [4] TransitedEncoding, 3691 authtime [5] KerberosTime, 3692 starttime [6] KerberosTime OPTIONAL, 3693 endtime [7] KerberosTime, 3694 renew-till [8] KerberosTime OPTIONAL, 3695 caddr [9] HostAddresses OPTIONAL, 3696 authorization-data [10] AuthorizationData OPTIONAL, 3697 ..., 3698 } 3700 -- 3701 -- *** Authorization Data 3702 -- 3704 ADType ::= TH-id 3706 AuthorizationData ::= SEQUENCE OF SEQUENCE { 3707 ad-type [0] ADType, 3708 ad-data [1] OCTET STRING 3709 } 3711 ad-if-relevant ADType ::= int32 : 1 3713 -- Encapsulates another AuthorizationData. 3714 -- Intended for application servers; receiving application servers 3715 -- MAY ignore. 3716 AD-IF-RELEVANT ::= AuthorizationData 3718 -- KDC-issued privilege attributes 3719 ad-kdcissued ADType ::= int32 : 4 3721 AD-KDCIssued ::= SEQUENCE { 3722 ad-checksum [0] ChecksumOf { 3723 AuthorizationData, { key-session }, 3724 { ku-ad-KDCIssued-cksum }}, 3725 i-realm [1] Realm OPTIONAL, 3726 i-sname [2] PrincipalName OPTIONAL, 3727 elements [3] AuthorizationData 3728 } 3729 ad-and-or ADType ::= int32 : 5 3731 AD-AND-OR ::= SEQUENCE { 3732 condition-count [0] Int32, 3733 elements [1] AuthorizationData 3734 } 3736 -- KDCs MUST interpret any AuthorizationData wrapped in this. 3737 ad-mandatory-for-kdc ADType ::= int32 : 8 3738 AD-MANDATORY-FOR-KDC ::= AuthorizationData 3740 ad-initial-verified-cas ADType ::= int32 : 9 3742 TrType ::= TH-id -- must be registered 3744 -- encoded Transited field 3745 TransitedEncoding ::= SEQUENCE { 3746 tr-type [0] TrType, 3747 contents [1] OCTET STRING 3748 } 3750 TEType ::= TH-id 3752 -- ticket extensions: for TicketExt only 3753 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 3754 te-type [0] TEType, 3755 te-data [1] OCTET STRING 3756 } 3757 TicketFlags ::= KerberosFlags { TicketFlagsBits } 3759 TicketFlagsBits ::= BIT STRING { 3760 reserved (0), 3761 forwardable (1), 3762 forwarded (2), 3763 proxiable (3), 3764 proxy (4), 3765 may-postdate (5), 3766 postdated (6), 3767 invalid (7), 3768 renewable (8), 3769 initial (9), 3770 pre-authent (10), 3771 hw-authent (11), 3772 transited-policy-checked (12), 3773 ok-as-delegate (13), 3774 anonymous (14), 3775 cksummed-ticket (15) 3776 } 3778 -- 3779 -- *** KDC protocol 3780 -- 3782 AS-REQ ::= CHOICE { 3783 rfc1510 AS-REQ-1510, 3784 ext AS-REQ-EXT 3785 } 3786 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 3787 -- AS-REQ must include client name 3789 AS-REQ-EXT ::= [APPLICATION 6] Signed { 3790 [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum } 3791 } 3792 -- AS-REQ must include client name 3794 TGS-REQ ::= CHOICE { 3795 rfc1510 TGS-REQ-1510, 3796 ext TGS-REQ-EXT 3797 } 3799 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 3801 TGS-REQ-EXT ::= [APPLICATION 8] Signed { 3802 [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum } 3803 } 3804 KDC-REQ-1510 ::= SEQUENCE { 3805 -- NOTE: first tag is [1], not [0] 3806 pvno [1] INTEGER (5), 3807 msg-type [2] INTEGER ( 10 -- AS-REQ -- 3808 | 12 -- TGS-REQ -- ), 3809 padata [3] SEQUENCE OF PA-DATA OPTIONAL, 3810 req-body [4] KDC-REQ-BODY-1510 3811 } 3813 KDC-REQ-EXT ::= SEQUENCE { 3814 pvno [1] INTEGER (5), 3815 msg-type [2] INTEGER ( 6 -- AS-REQ -- 3816 | 8 -- TGS-REQ -- ), 3817 padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, 3818 req-body [4] KDC-REQ-BODY-EXT, 3819 ... 3820 } 3822 KDC-REQ-BODY-1510 ::= SEQUENCE { 3823 kdc-options [0] KDCOptions, 3824 cname [1] PrincipalNameIA5 OPTIONAL 3825 -- Used only in AS-REQ --, 3827 realm [2] RealmIA5 3828 -- Server's realm; also client's in AS-REQ --, 3830 sname [3] PrincipalNameIA5 OPTIONAL, 3831 from [4] KerberosTime OPTIONAL, 3832 till [5] KerberosTime, 3833 rtime [6] KerberosTime OPTIONAL, 3834 nonce [7] Nonce32, 3835 etype [8] SEQUENCE OF EType 3836 -- in preference order --, 3838 addresses [9] HostAddresses OPTIONAL, 3839 enc-authorization-data [10] EncryptedData { 3840 AuthorizationData, { key-session | key-subsession }, 3841 { ku-TGSReqAuthData-subkey | 3842 ku-TGSReqAuthData-sesskey } 3843 } OPTIONAL, 3845 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3846 -- NOTE: not empty -- 3847 } 3848 KDC-REQ-BODY-EXT ::= SEQUENCE { 3849 kdc-options [0] KDCOptions, 3850 cname [1] PrincipalName OPTIONAL 3851 -- Used only in AS-REQ --, 3853 realm [2] Realm 3854 -- Server's realm; also client's in AS-REQ --, 3856 sname [3] PrincipalName OPTIONAL, 3857 from [4] KerberosTime OPTIONAL, 3858 till [5] KerberosTime OPTIONAL 3859 -- was required in rfc1510; 3860 -- still required for compat versions 3861 -- of messages --, 3863 rtime [6] KerberosTime OPTIONAL, 3864 nonce [7] Nonce, 3865 etype [8] SEQUENCE OF EType 3866 -- in preference order --, 3868 addresses [9] HostAddresses OPTIONAL, 3869 enc-authorization-data [10] EncryptedData { 3870 AuthorizationData, { key-session | key-subsession }, 3871 { ku-TGSReqAuthData-subkey | 3872 ku-TGSReqAuthData-sesskey } 3873 } OPTIONAL, 3875 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3876 -- NOTE: not empty --, 3877 ... 3878 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF 3879 LangTag OPTIONAL, 3880 ... 3881 } 3882 KDCOptions ::= KerberosFlags { KDCOptionsBits } 3884 KDCOptionsBits ::= BIT STRING { 3885 reserved (0), 3886 forwardable (1), 3887 forwarded (2), 3888 proxiable (3), 3889 proxy (4), 3890 allow-postdate (5), 3891 postdated (6), 3892 unused7 (7), 3893 renewable (8), 3894 unused9 (9), 3895 unused10 (10), 3896 unused11 (11), 3897 unused12 (12), 3898 unused13 (13), 3899 requestanonymous (14), 3900 canonicalize (15), 3901 disable-transited-check (26), 3902 renewable-ok (27), 3903 enc-tkt-in-skey (28), 3904 renew (30), 3905 validate (31) 3906 -- XXX need "need ticket1" flag? 3907 } 3909 AS-REP ::= CHOICE { 3910 rfc1510 AS-REP-1510, 3911 ext AS-REP-EXT 3912 } 3913 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 3914 AS-REP-EXT ::= [APPLICATION 7] Signed { 3915 [APPLICATION 7] KDC-REP-EXT, 3916 { key-reply }, { ku-ASRep-cksum } 3917 } 3919 TGS-REP ::= CHOICE { 3920 rfc1510 TGS-REP-1510, 3921 ext TGS-REP-EXT 3922 } 3923 TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 } 3924 TGS-REP-EXT ::= [APPLICATION 9] Signed { 3925 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, 3926 { key-reply }, { ku-TGSRep-cksum } 3927 } 3928 KDC-REP-1510 { EncPart } ::= SEQUENCE { 3929 pvno [0] INTEGER (5), 3930 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | 3931 13 -- TGS.rfc1510 -- ), 3932 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 3933 crealm [3] RealmIA5, 3934 cname [4] PrincipalNameIA5, 3935 ticket [5] Ticket, 3937 enc-part [6] EncryptedData { 3938 EncPart, 3939 { key-reply }, 3940 -- maybe reach into EncryptedData in AS-REP/TGS-REP 3941 -- definitions to apply constraints on key usages? 3942 { ku-EncASRepPart -- if AS-REP -- | 3943 ku-EncTGSRepPart-subkey -- if TGS-REP and 3944 -- using Authenticator 3945 -- session key -- | 3946 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 3947 -- subsession key -- } 3948 } 3949 } 3950 KDC-REP-EXT { EncPart } ::= SEQUENCE { 3951 pvno [0] INTEGER (5), 3952 msg-type [1] INTEGER (7 -- AS-REP.ext -- | 3953 9 -- TGS-REP.ext -- ), 3954 padata [2] SEQUENCE OF PA-DATA OPTIONAL, 3955 crealm [3] RealmExt, 3956 cname [4] PrincipalNameExt, 3957 ticket [5] Ticket, 3959 enc-part [6] EncryptedData { 3960 EncPart, 3961 { key-reply }, 3962 -- maybe reach into EncryptedData in AS-REP/TGS-REP 3963 -- definitions to apply constraints on key usages? 3964 { ku-EncASRepPart -- if AS-REP -- | 3965 ku-EncTGSRepPart-subkey -- if TGS-REP and 3966 -- using Authenticator 3967 -- session key -- | 3968 ku-EncTGSRepPart-sesskey -- if TGS-REP and using 3969 -- subsession key -- } 3970 }, 3972 ..., 3973 -- In extensible version, KDC signs original request 3974 -- to avoid replay attacks against client. 3975 req-cksum [7] ChecksumOf { CHOICE { 3976 as-req AS-REQ, 3977 tgs-req TGS-REQ 3978 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, 3979 lang-tag [8] LangTag OPTIONAL, 3980 ... 3981 } 3982 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 3983 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 3985 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt 3986 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt 3988 EncKDCRepPart1510 ::= SEQUENCE { 3989 key [0] EncryptionKey, 3990 last-req [1] LastReq, 3991 nonce [2] Nonce32, 3992 key-expiration [3] KerberosTime OPTIONAL, 3993 flags [4] TicketFlags, 3994 authtime [5] KerberosTime, 3995 starttime [6] KerberosTime OPTIONAL, 3996 endtime [7] KerberosTime, 3997 renew-till [8] KerberosTime OPTIONAL, 3998 srealm [9] RealmIA5, 3999 sname [10] PrincipalNameIA5, 4000 caddr [11] HostAddresses OPTIONAL 4001 } 4003 EncKDCRepPartExt ::= SEQUENCE { 4004 key [0] EncryptionKey, 4005 last-req [1] LastReq, 4006 nonce [2] Nonce, 4007 key-expiration [3] KerberosTime OPTIONAL, 4008 flags [4] TicketFlags, 4009 authtime [5] KerberosTime, 4010 starttime [6] KerberosTime OPTIONAL, 4011 endtime [7] KerberosTime, 4012 renew-till [8] KerberosTime OPTIONAL, 4013 srealm [9] Realm, 4014 sname [10] PrincipalName, 4015 caddr [11] HostAddresses OPTIONAL, 4016 ... 4017 } 4019 LRType ::= TH-id 4020 LastReq ::= SEQUENCE OF SEQUENCE { 4021 lr-type [0] LRType, 4022 lr-value [1] KerberosTime 4023 } 4025 -- 4026 -- *** preauth 4027 -- 4028 PaDataType ::= TH-id 4029 PaDataOID ::= RELATIVE-OID 4031 PA-DATA ::= SEQUENCE { 4032 -- NOTE: first tag is [1], not [0] 4033 padata-type [1] PaDataType, 4034 padata-value [2] OCTET STRING 4035 } 4037 -- AP-REQ authenticating a TGS-REQ 4038 pa-tgs-req PaDataType ::= int32 : 1 4039 PA-TGS-REQ ::= AP-REQ 4041 -- Encrypted timestamp preauth 4042 -- Encryption key used is client's long-term key. 4043 pa-enc-timestamp PaDataType ::= int32 : 2 4045 PA-ENC-TIMESTAMP ::= EncryptedData { 4046 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } 4047 } 4049 PA-ENC-TS-ENC ::= SEQUENCE { 4050 patimestamp [0] KerberosTime -- client's time --, 4051 pausec [1] Microseconds OPTIONAL 4052 } 4054 -- Hints returned in AS-REP or KRB-ERROR to help client 4055 -- choose a password-derived key, either for preauthentication 4056 -- or for decryption of the reply. 4057 pa-etype-info PaDataType ::= int32 : 11 4059 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 4061 ETYPE-INFO-ENTRY ::= SEQUENCE { 4062 etype [0] EType, 4063 salt [1] OCTET STRING OPTIONAL 4064 } 4065 -- Similar to etype-info, but with parameters provided for 4066 -- the string-to-key function. 4067 pa-etype-info2 PaDataType ::= int32 : 19 4069 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) 4070 OF ETYPE-INFO-ENTRY 4072 ETYPE-INFO2-ENTRY ::= SEQUENCE { 4073 etype [0] EType, 4074 salt [1] KerberosString OPTIONAL, 4075 s2kparams [2] OCTET STRING OPTIONAL 4076 } 4078 -- Obsolescent. Salt for client long-term key 4079 -- Its character encoding is unspecified. 4080 pa-pw-salt PaDataType ::= int32 : 3 4082 -- The "padata-value" does not encode an ASN.1 type. 4083 -- Instead, "padata-value" must consist of the salt string to 4084 -- be used by the client, in an unspecified character 4085 -- encoding. 4087 -- An extensible AS-REQ may be sent as a padata in a 4088 -- non-extensible AS-REQ to allow for backwards compatibility. 4089 pa-as-req PaDataType ::= int32 : 42 -- provisional 4090 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) 4092 -- 4093 -- *** Session key exchange 4094 -- 4096 AP-REQ ::= CHOICE { 4097 rfc1510 AP-REQ-1510, 4098 ext AP-REQ-EXT 4099 } 4100 AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE { 4101 pvno [0] INTEGER (5), 4102 msg-type [1] INTEGER (14), 4103 ap-options [2] APOptions, 4104 ticket [3] Ticket1510, 4105 authenticator [4] EncryptedData { 4106 Authenticator1510, 4107 { key-session }, 4108 { ku-APReq-authenticator | 4109 ku-pa-TGSReq-authenticator } 4110 } 4111 } 4113 AP-REQ-EXT ::= [APPLICATION 18] Signed { 4114 [APPLICATION 18] SEQUENCE { 4115 pvno [0] INTEGER (5), 4116 msg-type [1] INTEGER (18), 4117 ap-options [2] APOptions, 4118 ticket [3] Ticket, 4119 authenticator [4] EncryptedData { 4120 AuthenticatorExt, 4121 { key-session }, 4122 { ku-APReq-authenticator | 4123 ku-pa-TGSReq-authenticator } 4124 }, 4125 ..., 4126 extensions [5] ApReqExtensions OPTIONAL, 4127 lang-tag [6] SEQUENCE (SIZE (1..MAX)) 4128 OF LangTag OPTIONAL, 4129 ... 4130 }, { key-session }, { ku-APReq-cksum } 4131 } 4133 ApReqExtType ::= TH-id 4135 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4136 apReqExt-Type [0] ApReqExtType, 4137 apReqExt-Data [1] OCTET STRING 4138 } 4140 APOptions ::= KerberosFlags { APOptionsBits } 4142 APOptionsBits ::= BIT STRING { 4143 reserved (0), 4144 use-session-key (1), 4145 mutual-required (2) 4146 } 4147 -- plaintext of authenticator 4148 Authenticator1510 ::= [APPLICATION 2] SEQUENCE { 4149 authenticator-vno [0] INTEGER (5), 4150 crealm [1] RealmIA5, 4151 cname [2] PrincipalNameIA5, 4152 cksum [3] Checksum {{ key-session }, 4153 { ku-Authenticator-cksum | 4154 ku-pa-TGSReq-cksum }} OPTIONAL, 4155 cusec [4] Microseconds, 4156 ctime [5] KerberosTime, 4157 subkey [6] EncryptionKey OPTIONAL, 4158 seq-number [7] SeqNum32 OPTIONAL, 4159 authorization-data [8] AuthorizationData OPTIONAL 4160 } 4162 AuthenticatorExt ::= [APPLICATION 35] SEQUENCE { 4163 authenticator-vno [0] INTEGER (5), 4164 crealm [1] RealmExt, 4165 cname [2] PrincipalNameExt, 4166 cksum [3] Checksum {{ key-session }, 4167 { ku-Authenticator-cksum | 4168 ku-pa-TGSReq-cksum }} OPTIONAL, 4169 cusec [4] Microseconds, 4170 ctime [5] KerberosTime, 4171 subkey [6] EncryptionKey OPTIONAL, 4172 seq-number [7] SeqNum OPTIONAL, 4173 authorization-data [8] AuthorizationData OPTIONAL, 4174 ... 4175 } 4177 AP-REP ::= CHOICE { 4178 rfc1510 AP-REP-1510, 4179 ext AP-REP-EXT 4180 } 4182 AP-REP-1510 ::= [APPLICATION 15] SEQUENCE { 4183 pvno [0] INTEGER (5), 4184 msg-type [1] INTEGER (15), 4185 enc-part [2] EncryptedData { 4186 EncApRepPart1510, 4187 { key-session | key-subsession }, { ku-EncAPRepPart }} 4188 } 4189 AP-REP-EXT ::= [APPLICATION 19] Signed { 4190 [APPLICATION 19] SEQUENCE { 4191 pvno [0] INTEGER (5), 4192 msg-type [1] INTEGER (19), 4193 enc-part [2] EncryptedData { 4194 EncAPRepPartExt, 4195 { key-session | key-subsession }, { ku-EncAPRepPart }}, 4196 ..., 4197 extensions [3] ApRepExtensions OPTIONAL, 4198 ... 4199 }, { key-session | key-subsession }, { ku-APRep-cksum } 4200 } 4202 ApRepExtType ::= TH-id 4204 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { 4205 apRepExt-Type [0] ApRepExtType, 4206 apRepExt-Data [1] OCTET STRING 4207 } 4209 EncAPRepPart ::= CHOICE { 4210 rfc1510 EncAPRepPart1510, 4211 ext EncAPRepPartExt 4212 } 4214 EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE { 4215 ctime [0] KerberosTime, 4216 cusec [1] Microseconds, 4217 subkey [2] EncryptionKey OPTIONAL, 4218 seq-number [3] SeqNum32 OPTIONAL 4219 } 4221 EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE { 4222 ctime [0] KerberosTime, 4223 cusec [1] Microseconds, 4224 subkey [2] EncryptionKey OPTIONAL, 4225 seq-number [3] SeqNum OPTIONAL, 4226 ..., 4227 authorization-data [4] AuthorizationData OPTIONAL, 4228 ... 4229 } 4231 -- 4232 -- *** Application messages 4233 -- 4234 KRB-SAFE ::= CHOICE { 4235 rfc1510 KRB-SAFE-1510, 4236 ext KRB-SAFE-EXT 4237 } 4239 KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE { 4240 pvno [0] INTEGER (5), 4241 msg-type [1] INTEGER (20), 4242 safe-body [2] KRB-SAFE-BODY, 4243 cksum [3] ChecksumOf { 4244 KRB-SAFE-BODY, 4245 { key-session | key-subsession }, { ku-KrbSafe-cksum }} 4246 } 4248 -- Has safe-body optional to allow for GSS-MIC type functionality 4249 KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE { 4250 pvno [0] INTEGER (5), 4251 msg-type [1] INTEGER (20), 4252 safe-body [2] KRB-SAFE-BODY OPTIONAL, 4253 cksum [3] ChecksumOf { 4254 KRB-SAFE-BODY, 4255 { key-session | key-subsession }, { ku-KrbSafe-cksum }}, 4256 ... 4257 } 4259 KRB-SAFE-BODY ::= SEQUENCE { 4260 user-data [0] OCTET STRING, 4261 timestamp [1] KerberosTime OPTIONAL, 4262 usec [2] Microseconds OPTIONAL, 4263 seq-number [3] SeqNum OPTIONAL, 4264 s-address [4] HostAddress, 4265 r-address [5] HostAddress OPTIONAL, 4266 ... -- ASN.1 extensions must be excluded 4267 -- when sending to rfc1510 implementations 4268 } 4270 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4271 pvno [0] INTEGER (5), 4272 msg-type [1] INTEGER (21), 4273 enc-part [3] EncryptedData { 4274 EncKrbPrivPart, 4275 { key-session | key-subsession }, { ku-EncKrbPrivPart }}, 4276 ... 4277 } 4278 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4279 user-data [0] OCTET STRING, 4280 timestamp [1] KerberosTime OPTIONAL, 4281 usec [2] Microseconds OPTIONAL, 4282 seq-number [3] SeqNum OPTIONAL, 4283 s-address [4] HostAddress -- sender's addr --, 4284 r-address [5] HostAddress OPTIONAL -- recip's addr --, 4285 ... -- ASN.1 extensions must be excluded 4286 -- when sending to rfc1510 implementations 4287 } 4289 KRB-CRED ::= CHOICE { 4290 rfc1510 KRB-CRED-1510, 4291 ext KRB-CRED-EXT 4293 } 4295 KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { 4296 pvno [0] INTEGER (5), 4297 msg-type [1] INTEGER (22), 4298 tickets [2] SEQUENCE OF Ticket, 4299 enc-part [3] EncryptedData { 4300 EncKrbCredPart, 4301 { key-session | key-subsession }, { ku-EncKrbCredPart }} 4302 } 4304 KRB-CRED-EXT ::= [APPLICATION 24] Signed { 4305 [APPLICATION 24] SEQUENCE { 4306 pvno [0] INTEGER (5), 4307 msg-type [1] INTEGER (24), 4308 tickets [2] SEQUENCE OF Ticket, 4309 enc-part [3] EncryptedData { 4310 EncKrbCredPart, 4311 { key-session | key-subsession }, { ku-EncKrbCredPart }}, 4312 ... 4313 }, { key-session | key-subsession }, { ku-KrbCred-cksum } 4314 } 4316 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4317 ticket-info [0] SEQUENCE OF KrbCredInfo, 4318 nonce [1] Nonce OPTIONAL, 4319 timestamp [2] KerberosTime OPTIONAL, 4320 usec [3] Microseconds OPTIONAL, 4321 s-address [4] HostAddress OPTIONAL, 4322 r-address [5] HostAddress OPTIONAL 4323 } 4324 KrbCredInfo ::= SEQUENCE { 4325 key [0] EncryptionKey, 4326 prealm [1] Realm OPTIONAL, 4327 pname [2] PrincipalName OPTIONAL, 4328 flags [3] TicketFlags OPTIONAL, 4329 authtime [4] KerberosTime OPTIONAL, 4330 starttime [5] KerberosTime OPTIONAL, 4331 endtime [6] KerberosTime OPTIONAL, 4332 renew-till [7] KerberosTime OPTIONAL, 4333 srealm [8] Realm OPTIONAL, 4334 sname [9] PrincipalName OPTIONAL, 4335 caddr [10] HostAddresses OPTIONAL 4336 } 4338 TGT-REQ ::= [APPLICATION 16] SEQUENCE { 4339 pvno [0] INTEGER (5), 4340 msg-type [1] INTEGER (16), 4341 sname [2] PrincipalName OPTIONAL, 4342 srealm [3] Realm OPTIONAL, 4343 ... 4344 } 4346 -- 4347 -- *** Error messages 4348 -- 4350 ErrCode ::= Int32 4352 KRB-ERROR ::= CHOICE { 4353 rfc1510 KRB-ERROR-1510, 4354 ext KRB-ERROR-EXT 4355 } 4356 KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE { 4357 pvno [0] INTEGER (5), 4358 msg-type [1] INTEGER (30), 4359 ctime [2] KerberosTime OPTIONAL, 4360 cusec [3] Microseconds OPTIONAL, 4361 stime [4] KerberosTime, 4362 susec [5] Microseconds, 4363 error-code [6] ErrCode, 4364 crealm [7] RealmIA5 OPTIONAL, 4365 cname [8] PrincipalNameIA5 OPTIONAL, 4366 realm [9] RealmIA5 -- Correct realm --, 4367 sname [10] PrincipalNameIA5 -- Correct name --, 4368 e-text [11] KerberosString OPTIONAL, 4369 e-data [12] OCTET STRING OPTIONAL 4370 } 4372 KRB-ERROR-EXT ::= [APPLICATION 23] Signed { 4373 [APPLICATION 23] SEQUENCE{ 4374 pvno [0] INTEGER (5), 4375 msg-type [1] INTEGER (23), 4376 ctime [2] KerberosTime OPTIONAL, 4377 cusec [3] Microseconds OPTIONAL, 4378 stime [4] KerberosTime, 4379 susec [5] Microseconds, 4380 error-code [6] ErrCode, 4381 crealm [7] Realm OPTIONAL, 4382 cname [8] PrincipalName OPTIONAL, 4383 realm [9] Realm -- Correct realm --, 4384 sname [10] PrincipalName -- Correct name --, 4385 e-text [11] KerberosString OPTIONAL, 4386 e-data [12] OCTET STRING OPTIONAL, 4387 ..., 4388 typed-data [13] TYPED-DATA OPTIONAL, 4389 nonce [14] Nonce OPTIONAL, 4390 lang-tag [15] LangTag OPTIONAL, 4391 ... 4392 }, { }, { ku-KrbError-cksum } 4393 } 4395 METHOD-DATA ::= SEQUENCE OF PA-DATA 4397 TDType ::= TH-id 4399 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4400 data-type [0] TDType, 4401 data-value [1] OCTET STRING OPTIONAL 4402 } 4403 td-dh-parameters TDType ::= int32 : 109 4405 -- 4406 -- *** Error codes 4407 -- 4409 -- No error 4410 kdc-err-none ErrCode ::= 0 4411 -- Client's entry in database has expired 4412 kdc-err-name-exp ErrCode ::= 1 4413 -- Server's entry in database has expired 4414 kdc-err-service-exp ErrCode ::= 2 4415 -- Requested protocol version number not supported 4416 kdc-err-bad-pvno ErrCode ::= 3 4417 -- Client's key encrypted in old master key 4418 kdc-err-c-old-mast-kvno ErrCode ::= 4 4419 -- Server's key encrypted in old master key 4420 kdc-err-s-old-mast-kvno ErrCode ::= 5 4421 -- Client not found in Kerberos database 4422 kdc-err-c-principal-unknown ErrCode ::= 6 4423 -- Server not found in Kerberos database 4424 kdc-err-s-principal-unknown ErrCode ::= 7 4425 -- Multiple principal entries in database 4426 kdc-err-principal-not-unique ErrCode ::= 8 4427 -- The client or server has a null key 4428 kdc-err-null-key ErrCode ::= 9 4429 -- Ticket not eligible for postdating 4430 kdc-err-cannot-postdate ErrCode ::= 10 4431 -- Requested start time is later than end time 4432 kdc-err-never-valid ErrCode ::= 11 4433 -- KDC policy rejects request 4434 kdc-err-policy ErrCode ::= 12 4435 -- KDC cannot accommodate requested option 4436 kdc-err-badoption ErrCode ::= 13 4437 -- KDC has no support for encryption type 4438 kdc-err-etype-nosupp ErrCode ::= 14 4439 -- KDC has no support for checksum type 4440 kdc-err-sumtype-nosupp ErrCode ::= 15 4441 -- KDC has no support for padata type 4442 kdc-err-padata-type-nosupp ErrCode ::= 16 4443 -- KDC has no support for transited type 4444 kdc-err-trtype-nosupp ErrCode ::= 17 4445 -- Clients credentials have been revoked 4446 kdc-err-client-revoked ErrCode ::= 18 4447 -- Credentials for server have been revoked 4448 kdc-err-service-revoked ErrCode ::= 19 4449 -- TGT has been revoked 4450 kdc-err-tgt-revoked ErrCode ::= 20 4451 -- Client not yet valid - try again later 4452 kdc-err-client-notyet ErrCode ::= 21 4453 -- Server not yet valid - try again later 4454 kdc-err-service-notyet ErrCode ::= 22 4455 -- Password has expired - change password to reset 4456 kdc-err-key-expired ErrCode ::= 23 4457 -- Pre-authentication information was invalid 4458 kdc-err-preauth-failed ErrCode ::= 24 4459 -- Additional pre-authenticationrequired 4460 kdc-err-preauth-required ErrCode ::= 25 4461 -- Requested server and ticket don't match 4462 kdc-err-server-nomatch ErrCode ::= 26 4463 -- Server principal valid for user2user only 4464 kdc-err-must-use-user2user ErrCode ::= 27 4465 -- KDC Policy rejects transited path 4466 kdc-err-path-not-accpeted ErrCode ::= 28 4467 -- A service is not available 4468 kdc-err-svc-unavailable ErrCode ::= 29 4469 -- Integrity check on decrypted field failed 4470 krb-ap-err-bad-integrity ErrCode ::= 31 4471 -- Ticket expired 4472 krb-ap-err-tkt-expired ErrCode ::= 32 4473 -- Ticket not yet valid 4474 krb-ap-err-tkt-nyv ErrCode ::= 33 4475 -- Request is a replay 4476 krb-ap-err-repeat ErrCode ::= 34 4477 -- The ticket isn't for us 4478 krb-ap-err-not-us ErrCode ::= 35 4479 -- Ticket and authenticator don't match 4480 krb-ap-err-badmatch ErrCode ::= 36 4481 -- Clock skew too great 4482 krb-ap-err-skew ErrCode ::= 37 4483 -- Incorrect net address 4484 krb-ap-err-badaddr ErrCode ::= 38 4485 -- Protocol version mismatch 4486 krb-ap-err-badversion ErrCode ::= 39 4487 -- Invalid msg type 4488 krb-ap-err-msg-type ErrCode ::= 40 4489 -- Message stream modified 4490 krb-ap-err-modified ErrCode ::= 41 4491 -- Message out of order 4492 krb-ap-err-badorder ErrCode ::= 42 4493 -- Specified version of key is not available 4494 krb-ap-err-badkeyver ErrCode ::= 44 4495 -- Service key not available 4496 krb-ap-err-nokey ErrCode ::= 45 4497 -- Mutual authentication failed 4498 krb-ap-err-mut-fail ErrCode ::= 46 4499 -- Incorrect message direction 4500 krb-ap-err-baddirection ErrCode ::= 47 4501 -- Alternative authentication method required 4502 krb-ap-err-method ErrCode ::= 48 4503 -- Incorrect sequence number in message 4504 krb-ap-err-badseq ErrCode ::= 49 4505 -- Inappropriate type of checksum in message 4506 krb-ap-err-inapp-cksum ErrCode ::= 50 4507 -- Policy rejects transited path 4508 krb-ap-path-not-accepted ErrCode ::= 51 4509 -- Response too big for UDP, retry with TCP 4510 krb-err-response-too-big ErrCode ::= 52 4511 -- Generic error (description in e-text) 4512 krb-err-generic ErrCode ::= 60 4513 -- Field is too long for this implementation 4514 krb-err-field-toolong ErrCode ::= 61 4515 -- Reserved for PKINIT 4516 kdc-error-client-not-trusted ErrCode ::= 62 4517 -- Reserved for PKINIT 4518 kdc-error-kdc-not-trusted ErrCode ::= 63 4519 -- Reserved for PKINIT 4520 kdc-error-invalid-sig ErrCode ::= 64 4521 -- Reserved for PKINIT 4522 kdc-err-key-too-weak ErrCode ::= 65 4523 -- Reserved for PKINIT 4524 kdc-err-certificate-mismatch ErrCode ::= 66 4525 -- No TGT available to validate USER-TO-USER 4526 krb-ap-err-no-tgt ErrCode ::= 67 4527 -- USER-TO-USER TGT issued different KDC 4528 kdc-err-wrong-realm ErrCode ::= 68 4529 -- Ticket must be for USER-TO-USER 4530 krb-ap-err-user-to-user-required ErrCode ::= 69 4531 -- Reserved for PKINIT 4532 kdc-err-cant-verify-certificate ErrCode ::= 70 4533 -- Reserved for PKINIT 4534 kdc-err-invalid-certificate ErrCode ::= 71 4535 -- Reserved for PKINIT 4536 kdc-err-revoked-certificate ErrCode ::= 72 4537 -- Reserved for PKINIT 4538 kdc-err-revocation-status-unknown ErrCode ::= 73 4539 -- Reserved for PKINIT 4540 kdc-err-revocation-status-unavailable ErrCode ::= 74 4542 END 4544 B. Kerberos and Character Encodings (Informative) 4546 [adapted from KCLAR 5.2.1] 4548 The original specification of the Kerberos protocol in RFC 1510 uses 4549 GeneralString in numerous places for human-readable string data. 4550 Historical implementations of Kerberos cannot utilize the full power 4551 of GeneralString. This ASN.1 type requires the use of designation 4552 and invocation escape sequences as specified in ISO 2022 | ECMA-35 4553 [ISO2022] to switch character sets, and the default character set 4554 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] 4555 International Reference Version (IRV) (aka U.S. ASCII), which mostly 4556 works. 4558 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3) 4559 and two Control-function code elements (C0..C1). DER previously 4560 [X690-1997] prohibited the designation of character sets as any but 4561 the G0 and C0 sets. This had the side effect of prohibiting the use 4562 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any 4563 other character-sets that utilize a 96-character set, since it is 4564 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code 4565 element. Recent revisions to the ASN.1 standards resolve this 4566 contradiction. 4568 In practice, many implementations treat RFC 1510 GeneralStrings as if 4569 they were 8-bit strings of whichever character set the implementation 4570 defaults to, without regard for correct usage of character-set 4571 designation escape sequences. The default character set is often 4572 determined by the current user's operating system dependent locale. 4573 At least one major implementation places unescaped UTF-8 encoded 4574 Unicode characters in the GeneralString. This failure to conform to 4575 the GeneralString specifications results in interoperability issues 4576 when conflicting character encodings are utilized by the Kerberos 4577 clients, services, and KDC. 4579 This unfortunate situation is the result of improper documentation of 4580 the restrictions of the ASN.1 GeneralString type in prior Kerberos 4581 specifications. 4583 [the following should probably be rewritten and moved into the 4584 principal name section] 4586 For compatibility, implementations MAY choose to accept GeneralString 4587 values that contain characters other than those permitted by 4588 IA5String, but they should be aware that character set designation 4589 codes will likely be absent, and that the encoding should probably be 4590 treated as locale-specific in almost every way. Implementations MAY 4591 also choose to emit GeneralString values that are beyond those 4592 permitted by IA5String, but should be aware that doing so is 4593 extraordinarily risky from an interoperability perspective. 4595 Some existing implementations use GeneralString to encode unescaped 4596 locale-specific characters. This is a violation of the ASN.1 4597 standard. Most of these implementations encode US-ASCII in the left- 4598 hand half, so as long the implementation transmits only US-ASCII, the 4599 ASN.1 standard is not violated in this regard. As soon as such an 4600 implementation encodes unescaped locale-specific characters with the 4601 high bit set, it violates the ASN.1 standard. 4603 Other implementations have been known to use GeneralString to contain 4604 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 4605 is a different encoding, not a 94 or 96 character "G" set as defined 4606 by ISO 2022. It is believed that these implementations do not even 4607 use the ISO 2022 escape sequence to change the character encoding. 4608 Even if implementations were to announce the change of encoding by 4609 using that escape sequence, the ASN.1 standard prohibits the use of 4610 any escape sequences other than those used to designate/invoke "G" or 4611 "C" sets allowed by GeneralString. 4613 C. Kerberos History (Informative) 4615 [Adapted from KCLAR "BACKGROUND"] 4617 The Kerberos model is based in part on Needham and Schroeder's 4618 trusted third-party authentication protocol [NS78] and on 4619 modifications suggested by Denning and Sacco [DS81]. The original 4620 design and implementation of Kerberos Versions 1 through 4 was the 4621 work of two former Project Athena staff members, Steve Miller of 4622 Digital Equipment Corporation and Clifford Neuman (now at the 4623 Information Sciences Institute of the University of Southern 4624 California), along with Jerome Saltzer, Technical Director of Project 4625 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 4626 members of Project Athena have also contributed to the work on 4627 Kerberos. 4629 Version 5 of the Kerberos protocol (described in this document) has 4630 evolved from Version 4 based on new requirements and desires for 4631 features not available in Version 4. The design of Version 5 of the 4632 Kerberos protocol was led by Clifford Neuman and John Kohl with much 4633 input from the community. The development of the MIT reference 4634 implementation was led at MIT by John Kohl and Theodore Ts'o, with 4635 help and contributed code from many others. Since RFC1510 was 4636 issued, extensions and revisions to the protocol have been proposed 4637 by many individuals. Some of these proposals are reflected in this 4638 document. Where such changes involved significant effort, the 4639 document cites the contribution of the proposer. 4641 Reference implementations of both version 4 and version 5 of Kerberos 4642 are publicly available and commercial implementations have been 4643 developed and are widely used. Details on the differences between 4644 Kerberos Versions 4 and 5 can be found in [KNT94]. 4646 D. Notational Differences from [KCLAR] 4648 [ possible point for discussion ] 4650 [KCLAR] uses notational conventions slightly different from this 4651 document. As a derivative of RFC 1510, the text of [KCLAR] uses C- 4652 language style identifier names for defined values. In ASN.1 4653 notation, identifiers referencing defined values must begin with a 4654 lowercase letter and contain hyphen (-) characters rather than 4655 underscore (_) characters, while identifiers referencing types begin 4656 with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase 4657 identifiers with underscores to identify defined values. This has 4658 the potential to create confusion, but neither document defines 4659 values using actual ASN.1 value-assignment notation. 4661 It is debatable whether it is advantageous to write all identifier 4662 names (regardless of their ASN.1 token type) in all-uppercase letters 4663 for the purpose of emphasis in running text. The alternative is to 4664 use double-quote characters (") when ambiguity is possible. 4666 Normative References 4668 [ISO646] 4669 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. 4671 [ISO2022] 4672 "Information technology -- Character code structure and 4673 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. 4675 [KCRYPTO] 4676 K. Raeburn, "Encryption and Checksum Specifications for Kerberos 4677 5", draft-ietf-krb-wg-crypto-07.txt, work in progress. 4679 [RFC2119] 4680 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate 4681 Requirement Levels", March 1997. 4683 [RFC3660] 4684 H. Alvestrand, "Tags for the Identification of Languages", 4685 RFC 3660, January 2001. 4687 [SASLPREP] 4688 Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names 4689 and passwords", draft-ietf-sasl-saslprep-10.txt, work in 4690 progress. 4692 [X680] 4693 "Information technology -- Abstract Syntax Notation One (ASN.1): 4694 Specification of basic notation", ITU-T Recommendation X.680 4695 (2002) | ISO/IEC 8824-1:2002. 4697 [X682] 4698 "Information technology -- Abstract Syntax Notation One (ASN.1): 4699 Constraint specification", ITU-T Recommendation X.682 (2002) | 4700 ISO/IEC 8824-3:2002. 4702 [X683] 4703 "Information technology -- Abstract Syntax Notation One (ASN.1): 4704 Parameterization of ASN.1 specifications", ITU-T Recommendation 4705 X.683 (2002) | ISO/IEC 8824-4:2002. 4707 [X690] 4708 "Information technology -- ASN.1 encoding Rules: Specification 4709 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 4710 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 4711 X.690 (2002) | ISO/IEC 8825-1:2002. 4713 Informative References 4715 [DS81] 4716 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 4717 Distribution Protocols," Communications of the ACM, Vol. 24(8), 4718 pp. 533-536 (August 1981). 4720 [Dub00] 4721 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous 4722 Systems", Elsevier-Morgan Kaufmann, 2000. 4723 4725 [ISO8859-1] 4726 "Information technology -- 8-bit single-byte coded graphic 4727 character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 4728 8859-1:1998. 4730 [KCLAR] 4731 Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos 4732 Network Authentication Service (V5)", draft-ietf-krb-wg- 4733 kerberos-clarifications-07.txt, work in progress. 4735 [KNT94] 4736 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 4737 Evolution of the Kerberos Authentication System". In 4738 Distributed Open Systems, pages 78-94. IEEE Computer Society 4739 Press, 1994. 4741 [Lar96] 4742 John Larmouth, "Understanding OSI", International Thomson 4743 Computer Press, 1996. 4744 4746 [Lar99] 4747 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann, 4748 1999. 4750 [NS78] 4751 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 4752 Authentication in Large Networks of Computers", Communications 4753 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 4755 [RFC1510] 4756 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication 4757 Service (v5)", RFC1510, September 1993, Status: Proposed 4758 Standard. 4760 [RFC1964] 4761 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 4762 June 1996, Status: Proposed Standard. 4764 [X690-2002] 4765 "Information technology -- ASN.1 encoding rules: Specification 4766 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) 4767 and Distinguished Encoding Rules (DER)", ITU-T Recommendation 4768 X.690 (2002) | ISO/IEC 8825-1:2002. 4770 Author's Address 4772 Tom Yu 4773 77 Massachusetts Ave 4774 Cambridge, MA 02139 4775 USA 4776 tlyu@mit.edu 4778 Copyright Statement 4780 Copyright (C) The Internet Society (2005). This document is subject 4781 to the rights, licenses and restrictions contained in BCP 78, and 4782 except as set forth therein, the authors retain all their rights. 4784 This document and the information contained herein are provided on an 4785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4787 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4788 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4789 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4792 Intellectual Property Statement 4794 The IETF takes no position regarding the validity or scope of any 4795 Intellectual Property Rights or other rights that might be claimed to 4796 pertain to the implementation or use of the technology described in 4797 this document or the extent to which any license under such rights 4798 might or might not be available; nor does it represent that it has 4799 made any independent effort to identify any such rights. Information 4800 on the procedures with respect to rights in RFC documents can be 4801 found in BCP 78 and BCP 79. 4803 Copies of IPR disclosures made to the IETF Secretariat and any 4804 assurances of licenses to be made available, or the result of an 4805 attempt made to obtain a general license or permission for the use of 4806 such proprietary rights by implementers or users of this 4807 specification can be obtained from the IETF on-line IPR repository at 4808 http://www.ietf.org/ipr. 4810 The IETF invites any interested party to bring to its attention any 4811 copyrights, patents or patent applications, or other proprietary 4812 rights that may cover technology that may be required to implement 4813 this standard. Please address the information to the IETF at ietf- 4814 ipr@ietf.org.