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