idnits 2.17.1 draft-ietf-krb-wg-kerberos-clarifications-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 38) being 105 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 1783 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([DS81], [MNSS87], [NT94], [NS78], [SNS88]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 404: '...Implementations of Kerberos, GSSAPI, and SASL [RFC 2222] MUST NOT use DNS to...' RFC 2119 keyword, line 406: '...authors MAY wish to append a staticall...' RFC 2119 keyword, line 414: '...ty, applications SHOULD provide securi...' RFC 2119 keyword, line 477: '...authentication SHOULD fail. One of the...' RFC 2119 keyword, line 645: '...LID flag clients MUST ignore ticket fl...' (158 more instances...) -- The abstract seems to indicate that this document updates RFC1510, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 4061 has weird spacing: '...ticator non-P...' == Line 4063 has weird spacing: '...ketPart non-P...' == Line 4093 has weird spacing: '...RepPart non-...' == Line 4095 has weird spacing: '...RepPart non-P...' == Line 4097 has weird spacing: '...RepPart non-...' == (3 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The type of IPv6 addresses is twenty-four (24). [RFC2373]. The following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: -- 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 (November 1, 2002) is 7847 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 section? 'NT94' on line 5143 looks like a reference -- Missing reference section? 'SNS88' on line 5156 looks like a reference -- Missing reference section? 'MNSS87' on line 5130 looks like a reference -- Missing reference section? 'NS78' on line 5139 looks like a reference -- Missing reference section? 'DS81' on line 5083 looks like a reference -- Missing reference section? 'KNT92' on line 5111 looks like a reference -- Missing reference section? 'RFC 2222' on line 404 looks like a reference -- Missing reference section? 'Neu93' on line 5134 looks like a reference -- Missing reference section? 'KCRYPTO' on line 4503 looks like a reference -- Missing reference section? '18' on line 1686 looks like a reference -- Missing reference section? '19' on line 1698 looks like a reference -- Missing reference section? '20' on line 1782 looks like a reference -- Missing reference section? 'X680' on line 5163 looks like a reference -- Missing reference section? 'RFC1510' on line 2076 looks like a reference -- Missing reference section? 'RFC1964' on line 2076 looks like a reference -- Missing reference section? 'X690' on line 5167 looks like a reference -- Missing reference section? '0' on line 5551 looks like a reference -- Missing reference section? '1' on line 5552 looks like a reference -- Missing reference section? '2' on line 5546 looks like a reference -- Missing reference section? '3' on line 5547 looks like a reference -- Missing reference section? 'Pat92' on line 5147 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 5255 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 5263 looks like a reference -- Missing reference section? '4' on line 5500 looks like a reference -- Missing reference section? '5' on line 5501 looks like a reference -- Missing reference section? '6' on line 5502 looks like a reference -- Missing reference section? '7' on line 5503 looks like a reference -- Missing reference section? '8' on line 5504 looks like a reference -- Missing reference section? '9' on line 5505 looks like a reference -- Missing reference section? '10' on line 5506 looks like a reference -- Missing reference section? '24' on line 2970 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 5299 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 5301 looks like a reference -- Missing reference section? '11' on line 5507 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 5356 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 5358 looks like a reference -- Missing reference section? 'APPLICATION 25' on line 5373 looks like a reference -- Missing reference section? 'APPLICATION 26' on line 5375 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 5396 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 5410 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 5422 looks like a reference -- Missing reference section? 'APPLICATION 27' on line 5427 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 5434 looks like a reference -- Missing reference section? 'APPLICATION 21' on line 5450 looks like a reference -- Missing reference section? 'APPLICATION 28' on line 5457 looks like a reference -- Missing reference section? '32' on line 3862 looks like a reference -- Missing reference section? 'APPLICATION 22' on line 5466 looks like a reference -- Missing reference section? 'APPLICATION 29' on line 5473 looks like a reference -- Missing reference section? 'APPLICATION 30' on line 5495 looks like a reference -- Missing reference section? '12' on line 5508 looks like a reference -- Missing reference section? 'RFC 1779' on line 4197 looks like a reference -- Missing reference section? 'Westerlund' on line 4354 looks like a reference -- Missing reference section? 'RFC2373' on line 4283 looks like a reference -- Missing reference section? 'RFC1884' on line 4284 looks like a reference -- Missing reference section? 'Danielsson' on line 4354 looks like a reference -- Missing reference section? 'RFC 1035' on line 4411 looks like a reference -- Missing reference section? 'RFC 2052' on line 4426 looks like a reference -- Missing reference section? 'RFC 2253' on line 4659 looks like a reference -- Missing reference section? '40' on line 4691 looks like a reference -- Missing reference section? 'Blumenthal96' on line 5062 looks like a reference -- Missing reference section? 'Bellare98' on line 5065 looks like a reference -- Missing reference section? 'DES77' on line 5071 looks like a reference -- Missing reference section? 'DESM80' on line 5075 looks like a reference -- Missing reference section? 'Dolev91' on line 5079 looks like a reference -- Missing reference section? 'DS90' on line 5087 looks like a reference -- Missing reference section? 'Horowitz96' on line 5091 looks like a reference -- Missing reference section? 'HorowitzB96' on line 5094 looks like a reference -- Missing reference section? 'IS3309' on line 5097 looks like a reference -- Missing reference section? 'KBC96' on line 5107 looks like a reference -- Missing reference section? 'Krawczyk96' on line 5116 looks like a reference -- Missing reference section? 'LGDSR87' on line 5120 looks like a reference -- Missing reference section? 'MD4-92' on line 5124 looks like a reference -- Missing reference section? 'MD5-92' on line 5127 looks like a reference -- Missing reference section? 'RFC-2279' on line 5150 looks like a reference -- Missing reference section? 'SG92' on line 5152 looks like a reference -- Missing reference section? 'X509-88' on line 5160 looks like a reference -- Missing reference section? 'TM' on line 5707 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 80 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 John Kohl 3 Theodore Ts'o 4 Tom Yu 5 Sam Hartman 6 Ken Raeburn 7 Jeffrey Altman 8 November 1, 2002 9 Expires 1 May, 2003 11 The Kerberos Network Authentication Service (V5) 12 draft-ietf-krb-wg-kerberos-clarifications-02 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC 2026. Internet-Drafts are working documents 18 of the Internet Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months and 23 may be updated, replaced, or obsoleted by other documents at any time. It is 24 inappropriate to use Internet-Drafts as reference material or to cite them 25 other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 36 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 38 The distribution of this memo is unlimited. It is filed as 39 draft-ietf-krb-wg-kerberos-clarifications-02.txt, and expires 1 May 2003. 40 Please send comments to: ietf-krb-wg@anl.gov 42 ABSTRACT 44 This document provides an overview and specification of Version 5 of the 45 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 46 and its intended use that require more detailed or clearer explanation than 47 was provided in RFC1510. This document is intended to provide a detailed 48 description of the protocol, suitable for implementation, together with 49 descriptions of the appropriate use of protocol messages and fields within 50 those messages. 52 This document contains a subset of the changes considered and discussed in 53 the Kerberos working group and is intended as an interim description of 54 Kerberos. Additional changes to the Kerberos protocol have been proposed and 55 will appear in a subsequent extensions document. 57 This document is not intended to describe Kerberos to the end user, system 58 administrator, or application developer. Higher level papers describing 59 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 60 are available elsewhere. 62 OVERVIEW 64 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 65 network authentication system is based. It also specifies Version 5 of the 66 Kerberos protocol. 68 The motivations, goals, assumptions, and rationale behind most design 69 decisions are treated cursorily; they are more fully described in a paper 70 available in IEEE communications [NT94] and earlier in the Kerberos portion 71 of the Athena Technical Plan [MNSS87]. The protocols have been a proposed 72 standard and are being considered for advancement for draft standard through 73 the IETF standard process. Comments are encouraged on the presentation, but 74 only minor refinements to the protocol as implemented or extensions that fit 75 within current protocol framework will be considered at this time. 77 Requests for addition to an electronic mailing list for discussion of 78 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. 79 This mailing list is gatewayed onto the Usenet as the group 80 comp.protocols.kerberos. Requests for further information, including 81 documents and code availability, may be sent to info-kerberos@MIT.EDU. 83 BACKGROUND 85 The Kerberos model is based in part on Needham and Schroeder's trusted 86 third-party authentication protocol [NS78] and on modifications suggested by 87 Denning and Sacco [DS81]. The original design and implementation of Kerberos 88 Versions 1 through 4 was the work of two former Project Athena staff 89 members, Steve Miller of Digital Equipment Corporation and Clifford Neuman 90 (now at the Information Sciences Institute of the University of Southern 91 California), along with Jerome Saltzer, Technical Director of Project 92 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members 93 of Project Athena have also contributed to the work on Kerberos. 95 Version 5 of the Kerberos protocol (described in this document) has evolved 96 from Version 4 based on new requirements and desires for features not 97 available in Version 4. The design of Version 5 of the Kerberos protocol was 98 led by Clifford Neuman and John Kohl with much input from the community. The 99 development of the MIT reference implementation was led at MIT by John Kohl 100 and Theodore T'so, with help and contributed code from many others. Since 101 RFC1510 was issued, extensions and revisions to the protocol have been 102 proposed by many individuals. Some of these proposals are reflected in this 103 document. Where such changes involved significant effort, the document cites 104 the contribution of the proposer. 106 Reference implementations of both version 4 and version 5 of Kerberos are 107 publicly available and commercial implementations have been developed and 108 are widely used. Details on the differences between Kerberos Versions 4 and 109 5 can be found in [KNT92]. 111 Table of Contents 113 1. Introduction 114 1.1. Cross-realm operation 115 1.2. Choosing a principal with which to communicate 116 1.3. Authorization 117 1.5. Environmental assumptions 118 2. Ticket flag uses and requests 119 2.1. Initial, pre-authenticated, and hardware authenticated tickets 120 2.2. Invalid tickets 121 2.3. Renewable tickets 122 2.4. Postdated tickets 123 2.5. Proxiable and proxy tickets 124 2.6. Forwardable tickets 125 2.8. Other KDC options 126 3. Message Exchanges 127 3.1. The Authentication Service Exchange 128 3.1.1. Generation of KRB_AS_REQ message 129 3.1.2. Receipt of KRB_AS_REQ message 130 3.1.3. Generation of KRB_AS_REP message 131 3.1.4. Generation of KRB_ERROR message 132 3.1.5. Receipt of KRB_AS_REP message 133 3.1.6. Receipt of KRB_ERROR message 134 3.2. The Client/Server Authentication Exchange 135 3.2.1. The KRB_AP_REQ message 136 3.2.2. Generation of a KRB_AP_REQ message 137 3.2.3. Receipt of KRB_AP_REQ message 138 3.2.4. Generation of a KRB_AP_REP message 139 3.2.5. Receipt of KRB_AP_REP message 140 3.2.6. Using the encryption key 141 3.3. The Ticket-Granting Service (TGS) Exchange 142 3.3.1. Generation of KRB_TGS_REQ message 143 3.3.2. Receipt of KRB_TGS_REQ message 144 3.3.3. Generation of KRB_TGS_REP message 145 3.3.3.1. Checking for revoked tickets 146 3.3.3.2. Encoding the transited field 147 3.3.4. Receipt of KRB_TGS_REP message 148 3.4. The KRB_SAFE Exchange 149 3.4.1. Generation of a KRB_SAFE message 150 3.4.2. Receipt of KRB_SAFE message 151 3.5. The KRB_PRIV Exchange 152 3.5.1. Generation of a KRB_PRIV message 153 3.5.2. Receipt of KRB_PRIV message 154 3.6. The KRB_CRED Exchange 155 3.6.1. Generation of a KRB_CRED message 156 3.6.2. Receipt of KRB_CRED message 157 3.7. User to User Authentication Exchanges 158 4. Encryption and Checksum Specifications 159 5. Message Specifications 160 5.1. Specific Compatibility Notes on ASN.1 161 5.1.1. ASN.1 Distinguished Encoding Rules 162 5.1.2. Optional Integer Fields 163 5.1.3. Empty SEQUENCE OF Types 164 5.1.4. Unrecognized Tag Numbers 165 5.1.5. Tag Numbers Greater Than 30 166 5.2. Basic Kerberos Types 167 5.2.1. KerberosString 168 5.2.2. Realm and PrincipalName 169 5.2.3. KerberosTime 170 5.2.4. Constrained Integer types 171 5.2.5. HostAddress and HostAddresses 172 5.2.6. AuthorizationData 173 5.2.6.1. IF-RELEVANT 174 5.2.6.4. KDCIssued 175 5.2.6.5. AND-OR 176 5.2.6.8. MANDATORY-FOR-KDC 177 5.2.7. PA-DATA 178 5.2.7.1. PA-TGS-REQ 179 5.2.7.2. Encrypted Timestamp Pre-authentication 180 5.2.7.5. PA-ETYPE-INFO2 181 5.2.8. KerberosFlags 182 5.2.9. Cryptosystem-related Types 183 5.3. Tickets 184 5.4. Specifications for the AS and TGS exchanges 185 5.4.1. KRB_KDC_REQ definition 186 5.4.2. KRB_KDC_REP definition 187 5.5. Client/Server (CS) message specifications 188 5.5.1. KRB_AP_REQ definition 189 5.5.2. KRB_AP_REP definition 190 5.5.3. Error message reply 191 5.6. KRB_SAFE message specification 192 5.7. KRB_PRIV message specification 193 5.8. KRB_CRED message specification 194 5.9. Error message specification 195 5.10. Application Tag Numbers 196 6. Naming Constraints 197 6.1. Realm Names 198 6.2. Principal Names 199 6.2.1. Name of server principals 200 7. Constants and other defined values 201 7.1. Host address types 202 7.2. KDC messaging 203 7.2.1 IP Transports 204 7.2.1.1. UDP/IP transport 205 7.2.1.2. TCP/IP transport 206 7.2.1.3 KDC Discovery on IP Networks 207 7.2.1.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 208 7.2.1.3.2. Specifying KDC Location information with DNS SRV records 209 7.2.1.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 210 7.3. Name of the TGS 211 7.4. OID arc for KerberosV5 212 7.5. Protocol constants and associated values 213 7.5.1. Key usage numbers 214 7.5.2. PreAuthentication Data Types 215 7.5.3. Address Types 216 7.5.4. Authorization Data Types 217 7.5.5. Transited Encoding Types 218 7.5.6. Protocol Version Number 219 7.5.7. Kerberos Message Types 220 7.5.8. Name Types 221 7.5.9. Error Codes 222 8. Interoperability requirements 223 8.1. Specification 2 224 8.2. Recommended KDC values 225 9. IANA considerations 226 10. Security Considerations 227 11. Acknowledgement and References 228 A. ASN.1 module 229 B. Changes since RFC-1510 230 1. Introduction 232 Kerberos provides a means of verifying the identities of principals, (e.g. a 233 workstation user or a network server) on an open (unprotected) network. This 234 is accomplished without relying on assertions by the host operating system, 235 without basing trust on host addresses, without requiring physical security 236 of all the hosts on the network, and under the assumption that packets 237 traveling along the network can be read, modified, and inserted at 238 will[1.1]. Kerberos performs authentication under these conditions as a 239 trusted third-party authentication service by using conventional (shared 240 secret key [1.2]) cryptography. Kerberos extensions (outside the scope of 241 this document) can provide for the use of public key cryptography during 242 certain phases of the authentication protocol [@RFCE: if PKINIT advances 243 concurrently include reference to the RFC here]. Such extensions support 244 Kerberos authentication for users registered with public key certification 245 authorities and provide certain benefits of public key cryptography in 246 situations where they are needed. 248 The basic Kerberos authentication process proceeds as follows: A client 249 sends a request to the authentication server (AS) requesting "credentials" 250 for a given server. The AS responds with these credentials, encrypted in the 251 client's key. The credentials consist of a "ticket" for the server and a 252 temporary encryption key (often called a "session key"). The client 253 transmits the ticket (which contains the client's identity and a copy of the 254 session key, all encrypted in the server's key) to the server. The session 255 key (now shared by the client and server) is used to authenticate the 256 client, and may optionally be used to authenticate the server. It may also 257 be used to encrypt further communication between the two parties or to 258 exchange a separate sub-session key to be used to encrypt further 259 communication. 261 Implementation of the basic protocol consists of one or more authentication 262 servers running on physically secure hosts. The authentication servers 263 maintain a database of principals (i.e., users and servers) and their secret 264 keys. Code libraries provide encryption and implement the Kerberos protocol. 265 In order to add authentication to its transactions, a typical network 266 application adds one or two calls to the Kerberos library directly or 267 through the Generic Security Services Application Programming Interface, 268 GSSAPI, described in separate document [ref to GSSAPI RFC]. These calls 269 result in the transmission of the necessary messages to achieve 270 authentication. 272 The Kerberos protocol consists of several sub-protocols (or exchanges). 273 There are two basic methods by which a client can ask a Kerberos server for 274 credentials. In the first approach, the client sends a cleartext request for 275 a ticket for the desired server to the AS. The reply is sent encrypted in 276 the client's secret key. Usually this request is for a ticket-granting 277 ticket (TGT) which can later be used with the ticket-granting server (TGS). 278 In the second method, the client sends a request to the TGS. The client uses 279 the TGT to authenticate itself to the TGS in the same manner as if it were 280 contacting any other application server that requires Kerberos 281 authentication. The reply is encrypted in the session key from the TGT. 282 Though the protocol specification describes the AS and the TGS as separate 283 servers, they are implemented in practice as different protocol entry points 284 within a single Kerberos server. 286 Once obtained, credentials may be used to verify the identity of the 287 principals in a transaction, to ensure the integrity of messages exchanged 288 between them, or to preserve privacy of the messages. The application is 289 free to choose whatever protection may be necessary. 291 To verify the identities of the principals in a transaction, the client 292 transmits the ticket to the application server. Since the ticket is sent "in 293 the clear" (parts of it are encrypted, but this encryption doesn't thwart 294 replay) and might be intercepted and reused by an attacker, additional 295 information is sent to prove that the message originated with the principal 296 to whom the ticket was issued. This information (called the authenticator) 297 is encrypted in the session key, and includes a timestamp. The timestamp 298 proves that the message was recently generated and is not a replay. 299 Encrypting the authenticator in the session key proves that it was generated 300 by a party possessing the session key. Since no one except the requesting 301 principal and the server know the session key (it is never sent over the 302 network in the clear) this guarantees the identity of the client. 304 The integrity of the messages exchanged between principals can also be 305 guaranteed using the session key (passed in the ticket and contained in the 306 credentials). This approach provides detection of both replay attacks and 307 message stream modification attacks. It is accomplished by generating and 308 transmitting a collision-proof checksum (elsewhere called a hash or digest 309 function) of the client's message, keyed with the session key. Privacy and 310 integrity of the messages exchanged between principals can be secured by 311 encrypting the data to be passed using the session key contained in the 312 ticket or the sub-session key found in the authenticator. 314 The authentication exchanges mentioned above require read-only access to the 315 Kerberos database. Sometimes, however, the entries in the database must be 316 modified, such as when adding new principals or changing a principal's key. 317 This is done using a protocol between a client and a third Kerberos server, 318 the Kerberos Administration Server (KADM). There is also a protocol for 319 maintaining multiple copies of the Kerberos database. Neither of these 320 protocols are described in this document. 322 1.1. Cross-realm operation 324 The Kerberos protocol is designed to operate across organizational 325 boundaries. A client in one organization can be authenticated to a server in 326 another. Each organization wishing to run a Kerberos server establishes its 327 own "realm". The name of the realm in which a client is registered is part 328 of the client's name, and can be used by the end-service to decide whether 329 to honor a request. 331 By establishing "inter-realm" keys, the administrators of two realms can 332 allow a client authenticated in the local realm to prove its identity to 333 servers in other realms[1.3]. The exchange of inter-realm keys (a separate 334 key may be used for each direction) registers the ticket-granting service of 335 each realm as a principal in the other realm. A client is then able to 336 obtain a ticket-granting ticket for the remote realm's ticket-granting 337 service from its local realm. When that ticket-granting ticket is used, the 338 remote ticket-granting service uses the inter-realm key (which usually 339 differs from its own normal TGS key) to decrypt the ticket-granting ticket, 340 and is thus certain that it was issued by the client's own TGS. Tickets 341 issued by the remote ticket-granting service will indicate to the 342 end-service that the client was authenticated from another realm. 344 A realm is said to communicate with another realm if the two realms share an 345 inter-realm key, or if the local realm shares an inter-realm key with an 346 intermediate realm that communicates with the remote realm. An 347 authentication path is the sequence of intermediate realms that are 348 transited in communicating from one realm to another. 350 Realms may be organized hierarchically. Each realm shares a key with its 351 parent and a different key with each child. If an inter-realm key is not 352 directly shared by two realms, the hierarchical organization allows an 353 authentication path to be easily constructed. If a hierarchical organization 354 is not used, it may be necessary to consult a database in order to construct 355 an authentication path between realms. 357 Although realms are typically hierarchical, intermediate realms may be 358 bypassed to achieve cross-realm authentication through alternate 359 authentication paths (these might be established to make communication 360 between two realms more efficient). It is important for the end-service to 361 know which realms were transited when deciding how much faith to place in 362 the authentication process. To facilitate this decision, a field in each 363 ticket contains the names of the realms that were involved in authenticating 364 the client. 366 The application server is ultimately responsible for accepting or rejecting 367 authentication and should check the transited field. The application server 368 may choose to rely on the KDC for the application server's realm to check 369 the transited field. The application server's KDC will set the 370 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 371 realms may also check the transited field as they issue 372 ticket-granting-tickets for other realms, but they are encouraged not to do 373 so. A client may request that the KDC's not check the transited field by 374 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 375 required to honor this flag. 377 1.2. Choosing a principal with which to communicate 379 The Kerberos protocol provides the means for verifying (subject to the 380 assumptions in 1.5) that the entity with which one communicates is the same 381 entity that was registered with the KDC using the claimed identity 382 (principal name). It is still necessary to determine whether that identity 383 corresponds to the entity with which one intends to communicate. 385 When appropriate data has been exchanged in advance, this determination may 386 be performed syntactically by the application based on the application 387 protocol specification, information provided by the user, and configuration 388 files. For example, the server principal name (including realm) for a telnet 389 server might be derived from the user specified host name (from the telnet 390 command line), the "host/" prefix specified in the application protocol 391 specification, and a mapping to a Kerberos realm derived syntactically from 392 the domain part of the specified hostname and information from the local 393 Kerberos realms database. 395 One can also rely on trusted third parties to make this determination, but 396 only when the data obtained from the third party is suitably integrity 397 protected wile resident on the third party server and when transmitted. 398 Thus, for example, one should not rely on an unprotected domain name system 399 record to map a host alias to the primary name of a server, accepting the 400 primary name as the party one intends to contact, since an attacker can 401 modify the mapping and impersonate the party with which one intended to 402 communicate. 404 Implementations of Kerberos, GSSAPI, and SASL [RFC 2222] MUST NOT use DNS to 405 canonicalize the host components of service principal names. Application 406 authors MAY wish to append a statically configured domain name to 407 unqualified hosts before passing the name to security mechanisms. 409 Implementation note: Many current implementations do some degree of 410 canonicalization of the provided service name, often using DNS even though 411 it creates security problems. However there is no consistency among 412 implementations about whether the service name is case folded to lower case 413 or wether reverse resolution is used. To maximize interoperability and 414 security, applications SHOULD provide security mechanisms with names which 415 result from folding the user-entered name to lower case, without performing 416 any other modifications or canonicalization. 418 1.3. Authorization 420 As an authentication service, Kerberos provides a means of verifying the 421 identity of principals on a network. Authentication is usually useful 422 primarily as a first step in the process of authorization, determining 423 whether a client may use a service, which objects the client is allowed to 424 access, and the type of access allowed for each. Kerberos does not, by 425 itself, provide authorization. Possession of a client ticket for a service 426 provides only for authentication of the client to that service, and in the 427 absence of a separate authorization procedure, it should not be considered 428 by an application as authorizing the use of that service. 430 Such separate authorization methods may be implemented as application 431 specific access control functions and may utilize files on the application 432 server, or on separately issued authorization credentials such as those 433 based on proxies [Neu93], or on other authorization services. Separately 434 authenticated authorization credentials may be embedded in a tickets 435 authorization data when encapsulated by the kdc-issued authorization data 436 element. 438 Applications should not accept the mere issuance of a service ticket by the 439 Kerberos server (even by a modified Kerberos server) as granting authority 440 to use the service, since such applications may become vulnerable to the 441 bypass of this authorization check in an environment if they interoperate 442 with other KDCs or where other options for application authentication (e.g. 443 the PKTAPP proposal) are provided. 445 1.4. Extending Kerberos Without Breaking Interoperability 447 As the deployed base of Kerberos implementations grows, extending Kerberos 448 becomes more important. Unfortunately some extensions to the existing 449 Kerberos protocol create interoperability issues because of uncertainty 450 regarding the treatment of certain extensibility options by some 451 implementations. This section includes guidelines that will enable future 452 implementations to maintain interoperability. 454 Kerberos provides a general mechanism for protocol extensibility. Some 455 protocol messages contain typed holes -- sub-messages that contain an 456 octet-string along with an integer that defines how to interpret the 457 octet-string. The integer types are registered centrally, but can be used 458 both for vendor extensions and for extensions standardized through the IETF. 460 1.4.1. Compatibility with RFC 1510 462 It is important to note that existing Kerberos message formats can not be 463 readily extended by adding fields to the ASN.1 types. Sending additional 464 fields often results in the entire message being discarded without an error 465 indication. Future versions of this specification will provide guidelines to 466 ensure that ASN.1 fields can be added without creating an interoperability 467 problem. 469 In the meantime, all new or modified implementations of Kerberos that 470 receive an unknown message extension should preserve the encoding of the 471 extension but otherwise ignore the presence of the extension. Recipients 472 MUST NOT decline a request simply because an extension is present. 474 There is one exception to this rule. If an unknown authorization data 475 element type is received by a server other than the ticket granting service 476 either in an AP-REQ or in a ticket contained in an AP-REQ, then 477 authentication SHOULD fail. One of the primary uses of authorization data is 478 to restrict the use of the ticket. If the service cannot determine whether 479 the restriction applies to that service then a security weakness may result 480 if the ticket can be used for that service. Authorization elements that are 481 optional should be enclosed in the AD-IF-RELEVANT element. 483 The ticket granting service must ignore but propagate to derivative tickets 484 any unknown authorization data types, unless those data types are embedded 485 in a MANDATORY-FOR-KDC element, in which case the request will be rejected. 486 This behavior is appropriate because requiring that the ticket granting 487 service understand unknown authorization data types would require that KDC 488 software be upgraded to understand new application-level restrictions before 489 applications used these restrictions, decreasing the utility of 490 authorization data as a mechanism for restricting the use of tickets. No 491 security problem is created because services to which the tickets are issued 492 will verify the authorization data. 494 Implementation note: Many RFC 1510 implementations ignore unknown 495 authorization data elements. Depending on these implementations to honor 496 authorization data restrictions may create a security weakness. 498 1.4.2. Sending Extensible Messages 500 Care must be taken to ensure that old implementations can understand 501 messages sent to them even if they do not understand an extension that is 502 used. Unless the sender knows an extension is supported, the extension 503 cannot change the semantics of the core message or previously defined 504 extensions. 506 For example, an extension including key information necessary to decrypt the 507 encrypted part of a KDC-REP could only be used in situations where the 508 recipient was known to support the extension. Thus when designing such 509 extensions it is important to provide a way for the recipient to notify the 510 sender of support for the extension. For example in the case of an extension 511 that changes the KDC-REP reply key, the client could indicate support for 512 the extension by including a padata element in the AS-REQ sequence. The KDC 513 should only use the extension if this padata element is present in the 514 AS-REQ. Even if policy requires the use of the extension, it is better to 515 return an error indicating that the extension is required than to use the 516 extension when the recipient may not support it; debugging why 517 implementations do not interoperate is easier when errors are returned. 519 1.5. Environmental assumptions 521 Kerberos imposes a few assumptions on the environment in which it can 522 properly function: 524 * "Denial of service" attacks are not solved with Kerberos. There are 525 places in the protocols where an intruder can prevent an application 526 from participating in the proper authentication steps. Detection and 527 solution of such attacks (some of which can appear to be not-uncommon 528 "normal" failure modes for the system) is usually best left to the 529 human administrators and users. 530 * Principals must keep their secret keys secret. If an intruder somehow 531 steals a principal's key, it will be able to masquerade as that 532 principal or impersonate any server to the legitimate principal. 533 * "Password guessing" attacks are not solved by Kerberos. If a user 534 chooses a poor password, it is possible for an attacker to successfully 535 mount an offline dictionary attack by repeatedly attempting to decrypt, 536 with successive entries from a dictionary, messages obtained which are 537 encrypted under a key derived from the user's password. 538 * Each host on the network must have a clock which is "loosely 539 synchronized" to the time of the other hosts; this synchronization is 540 used to reduce the bookkeeping needs of application servers when they 541 do replay detection. The degree of "looseness" can be configured on a 542 per-server basis, but is typically on the order of 5 minutes. If the 543 clocks are synchronized over the network, the clock synchronization 544 protocol must itself be secured from network attackers. 545 * Principal identifiers are not recycled on a short-term basis. A typical 546 mode of access control will use access control lists (ACLs) to grant 547 permissions to particular principals. If a stale ACL entry remains for 548 a deleted principal and the principal identifier is reused, the new 549 principal will inherit rights specified in the stale ACL entry. By not 550 re-using principal identifiers, the danger of inadvertent access is 551 removed. 553 1.6. Glossary of terms 555 Below is a list of terms used throughout this document. 557 Authentication 558 Verifying the claimed identity of a principal. 559 Authentication header 560 A record containing a Ticket and an Authenticator to be presented to a 561 server as part of the authentication process. 562 Authentication path 563 A sequence of intermediate realms transited in the authentication 564 process when communicating from one realm to another. 565 Authenticator 566 A record containing information that can be shown to have been recently 567 generated using the session key known only by the client and server. 568 Authorization 569 The process of determining whether a client may use a service, which 570 objects the client is allowed to access, and the type of access allowed 571 for each. 572 Capability 573 A token that grants the bearer permission to access an object or 574 service. In Kerberos, this might be a ticket whose use is restricted by 575 the contents of the authorization data field, but which lists no 576 network addresses, together with the session key necessary to use the 577 ticket. 578 Ciphertext 579 The output of an encryption function. Encryption transforms plaintext 580 into ciphertext. 581 Client 582 A process that makes use of a network service on behalf of a user. Note 583 that in some cases a Server may itself be a client of some other server 584 (e.g. a print server may be a client of a file server). 585 Credentials 586 A ticket plus the secret session key necessary to successfully use that 587 ticket in an authentication exchange. 588 KDC 589 Key Distribution Center, a network service that supplies tickets and 590 temporary session keys; or an instance of that service or the host on 591 which it runs. The KDC services both initial ticket and ticket-granting 592 ticket requests. The initial ticket portion is sometimes referred to as 593 the Authentication Server (or service). The ticket-granting ticket 594 portion is sometimes referred to as the ticket-granting server (or 595 service). 596 Kerberos 597 Aside from the 3-headed dog guarding Hades, the name given to Project 598 Athena's authentication service, the protocol used by that service, or 599 the code used to implement the authentication service. 600 Plaintext 601 The input to an encryption function or the output of a decryption 602 function. Decryption transforms ciphertext into plaintext. 603 Principal 604 A named client or server entity that participates in a network 605 communication, with one name that is considered canonical. 606 Principal identifier 607 The canonical name used to uniquely identify each different principal. 609 Seal 610 To encipher a record containing several fields in such a way that the 611 fields cannot be individually replaced without either knowledge of the 612 encryption key or leaving evidence of tampering. 613 Secret key 614 An encryption key shared by a principal and the KDC, distributed 615 outside the bounds of the system, with a long lifetime. In the case of 616 a human user's principal, the secret key may be derived from a 617 password. 618 Server 619 A particular Principal which provides a resource to network clients. 620 The server is sometimes referred to as the Application Server. 621 Service 622 A resource provided to network clients; often provided by more than one 623 server (for example, remote file service). 624 Session key 625 A temporary encryption key used between two principals, with a lifetime 626 limited to the duration of a single login "session". 627 Sub-session key 628 A temporary encryption key used between two principals, selected and 629 exchanged by the principals using the session key, and with a lifetime 630 limited to the duration of a single association. 631 Ticket 632 A record that helps a client authenticate itself to a server; it 633 contains the client's identity, a session key, a timestamp, and other 634 information, all sealed using the server's secret key. It only serves 635 to authenticate a client when presented along with a fresh 636 Authenticator. 638 2. Ticket flag uses and requests 640 Each Kerberos ticket contains a set of flags which are used to indicate 641 attributes of that ticket. Most flags may be requested by a client when the 642 ticket is obtained; some are automatically turned on and off by a Kerberos 643 server as required. The following sections explain what the various flags 644 mean and give examples of reasons to use them. With the exception of the 645 INVALID flag clients MUST ignore ticket flags that are not recognized. KDCs 646 MUST ignore KDC options that are not recognized. Some implementations of RFC 647 1510 are known to reject unknown KDC options, so clients may need to resend 648 a request without KDC new options absent if the request was rejected when 649 sent with option added since RFC 1510. Since new KDCs will ignore unknown 650 options, clients MUST confirm that the ticket returned by the KDC meets 651 their needs. 653 Note that it is not in general possible to determine whether an option was 654 not honored because it was not understood or because it was rejected either 655 through configuration or policy. When adding a new option to the Kerberos 656 protocol, designers should consider whether the distinction is important for 657 their option. In cases where it is, a mechanism for the KDC to return an 658 indication that the option was understood but rejected needs to be provided 659 in the specification of the option. Often in such cases, the mechanism needs 660 to be broad enough to permit an error or reason to be returned. 662 2.1. Initial, pre-authenticated, and hardware authenticated tickets 664 The INITIAL flag indicates that a ticket was issued using the AS protocol 665 and not issued based on a ticket-granting ticket. Application servers that 666 want to require the demonstrated knowledge of a client's secret key (e.g. a 667 password-changing program) can insist that this flag be set in any tickets 668 they accept, and thus be assured that the client's key was recently 669 presented to the application client. 671 The PRE-AUTHENT and HW-AUTHENT flags provide additional information about 672 the initial authentication, regardless of whether the current ticket was 673 issued directly (in which case INITIAL will also be set) or issued on the 674 basis of a ticket-granting ticket (in which case the INITIAL flag is clear, 675 but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 676 ticket-granting ticket). 678 2.2. Invalid tickets 680 The INVALID flag indicates that a ticket is invalid. Application servers 681 must reject tickets which have this flag set. A postdated ticket will 682 usually be issued in this form. Invalid tickets must be validated by the KDC 683 before use, by presenting them to the KDC in a TGS request with the VALIDATE 684 option specified. The KDC will only validate tickets after their starttime 685 has passed. The validation is required so that postdated tickets which have 686 been stolen before their starttime can be rendered permanently invalid 687 (through a hot-list mechanism) (see section 3.3.3.1). 689 2.3. Renewable tickets 691 Applications may desire to hold tickets which can be valid for long periods 692 of time. However, this can expose their credentials to potential theft for 693 equally long periods, and those stolen credentials would be valid until the 694 expiration time of the ticket(s). Simply using short-lived tickets and 695 obtaining new ones periodically would require the client to have long-term 696 access to its secret key, an even greater risk. Renewable tickets can be 697 used to mitigate the consequences of theft. Renewable tickets have two 698 "expiration times": the first is when the current instance of the ticket 699 expires, and the second is the latest permissible value for an individual 700 expiration time. An application client must periodically (i.e. before it 701 expires) present a renewable ticket to the KDC, with the RENEW option set in 702 the KDC request. The KDC will issue a new ticket with a new session key and 703 a later expiration time. All other fields of the ticket are left unmodified 704 by the renewal process. When the latest permissible expiration time arrives, 705 the ticket expires permanently. At each renewal, the KDC may consult a 706 hot-list to determine if the ticket had been reported stolen since its last 707 renewal; it will refuse to renew such stolen tickets, and thus the usable 708 lifetime of stolen tickets is reduced. 710 The RENEWABLE flag in a ticket is normally only interpreted by the 711 ticket-granting service (discussed below in section 3.3). It can usually be 712 ignored by application servers. However, some particularly careful 713 application servers may wish to disallow renewable tickets. 715 If a renewable ticket is not renewed by its expiration time, the KDC will 716 not renew the ticket. The RENEWABLE flag is reset by default, but a client 717 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 718 message. If it is set, then the renew-till field in the ticket contains the 719 time after which the ticket may not be renewed. 721 2.4. Postdated tickets 723 Applications may occasionally need to obtain tickets for use much later, 724 e.g. a batch submission system would need tickets to be valid at the time 725 the batch job is serviced. However, it is dangerous to hold valid tickets in 726 a batch queue, since they will be on-line longer and more prone to theft. 727 Postdated tickets provide a way to obtain these tickets from the KDC at job 728 submission time, but to leave them "dormant" until they are activated and 729 validated by a further request of the KDC. If a ticket theft were reported 730 in the interim, the KDC would refuse to validate the ticket, and the thief 731 would be foiled. 733 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 734 ticket-granting service. It can be ignored by application servers. This flag 735 must be set in a ticket-granting ticket in order to issue a postdated ticket 736 based on the presented ticket. It is reset by default; it may be requested 737 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 738 This flag does not allow a client to obtain a postdated ticket-granting 739 ticket; postdated ticket-granting tickets can only by obtained by requesting 740 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 741 postdated ticket will be the remaining life of the ticket-granting ticket at 742 the time of the request, unless the RENEWABLE option is also set, in which 743 case it can be the full life (endtime-starttime) of the ticket-granting 744 ticket. The KDC may limit how far in the future a ticket may be postdated. 746 The POSTDATED flag indicates that a ticket has been postdated. The 747 application server can check the authtime field in the ticket to see when 748 the original authentication occurred. Some services may choose to reject 749 postdated tickets, or they may only accept them within a certain period 750 after the original authentication. When the KDC issues a POSTDATED ticket, 751 it will also be marked as INVALID, so that the application client must 752 present the ticket to the KDC to be validated before use. 754 2.5. Proxiable and proxy tickets 756 At times it may be necessary for a principal to allow a service to perform 757 an operation on its behalf. The service must be able to take on the identity 758 of the client, but only for a particular purpose. A principal can allow a 759 service to take on the principal's identity for a particular purpose by 760 granting it a proxy. 762 The process of granting a proxy using the proxy and proxiable flags is used 763 to provide credentials for use with specific services. Though conceptually 764 also a proxy, user's wishing to delegate their identity for ANY purpose must 765 use the ticket forwarding mechanism described in the next section to forward 766 a ticket granting ticket. 768 The PROXIABLE flag in a ticket is normally only interpreted by the 769 ticket-granting service. It can be ignored by application servers. When set, 770 this flag tells the ticket-granting server that it is OK to issue a new 771 ticket (but not a ticket-granting ticket) with a different network address 772 based on this ticket. This flag is set if requested by the client on initial 773 authentication. By default, the client will request that it be set when 774 requesting a ticket granting ticket, and reset when requesting any other 775 ticket. 777 This flag allows a client to pass a proxy to a server to perform a remote 778 request on its behalf, e.g. a print service client can give the print server 779 a proxy to access the client's files on a particular file server in order to 780 satisfy a print request. 782 In order to complicate the use of stolen credentials, Kerberos tickets are 783 usually valid from only those network addresses specifically included in the 784 ticket[2.1]. When granting a proxy, the client must specify the new network 785 address from which the proxy is to be used, or indicate that the proxy is to 786 be issued for use from any address. 788 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 789 Application servers may check this flag and at their option they may require 790 additional authentication from the agent presenting the proxy in order to 791 provide an audit trail. 793 2.6. Forwardable tickets 795 Authentication forwarding is an instance of a proxy where the service 796 granted is complete use of the client's identity. An example where it might 797 be used is when a user logs in to a remote system and wants authentication 798 to work from that system as if the login were local. 800 The FORWARDABLE flag in a ticket is normally only interpreted by the 801 ticket-granting service. It can be ignored by application servers. The 802 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 803 flag, except ticket-granting tickets may also be issued with different 804 network addresses. This flag is reset by default, but users may request that 805 it be set by setting the FORWARDABLE option in the AS request when they 806 request their initial ticket-granting ticket. 808 This flag allows for authentication forwarding without requiring the user to 809 enter a password again. If the flag is not set, then authentication 810 forwarding is not permitted, but the same result can still be achieved if 811 the user engages in the AS exchange specifying the requested network 812 addresses and supplies a password. 814 The FORWARDED flag is set by the TGS when a client presents a ticket with 815 the FORWARDABLE flag set and requests a forwarded ticket by specifying the 816 FORWARDED KDC option and supplying a set of addresses for the new ticket. It 817 is also set in all tickets issued based on tickets with the FORWARDED flag 818 set. Application servers may choose to process FORWARDED tickets differently 819 than non-FORWARDED tickets. 821 If addressless tickets are forwarded from one system to another, clients 822 SHOULD still use this option to obtain a new TGT in order to have different 823 session keys on the different systems. 825 2.7 Transited Policy Checking 827 In Kerberos, the application server is ultimately responsible for accepting 828 or rejecting authentication and should check that only suitably trusted KDCs 829 are relied upon to authenticate a principal. The transited field in the 830 ticket identifies which KDCs were involved in the authentication process and 831 an application server would normally check this field. If any of these are 832 untrusted to authenticate the indicated client principal (probably 833 determined by a realm-based policy), the authentication attempt must be 834 rejected. The presence of trusted KDCs in this list does not provide any 835 guarantee; an untrusted KDC may have fabricated the list. 837 While the end server ultimately decides whether authentication is valid, the 838 KDC for the end server's realm may apply a realm specific policy for 839 validating the transited field and accepting credentials for cross-realm 840 authentication. When the KDC applies such checks and accepts such 841 cross-realm authentication it will set the TRANSITED-POLICY-CHECKED flag in 842 the service tickets it issues based on the cross-realm TGT. A client may 843 request that the KDCs not check the transited field by setting the 844 DISABLE-TRANSITED-CHECK flag. KDCs are encouraged but not required to honor 845 this flag. 847 2.8. Other KDC options 849 There are three additional options which may be set in a client's request of 850 the KDC. 852 2.8.1 Renewable-OK 854 The RENEWABLE-OK option indicates that the client will accept a renewable 855 ticket if a ticket with the requested life cannot otherwise be provided. If 856 a ticket with the requested life cannot be provided, then the KDC may issue 857 a renewable ticket with a renew-till equal to the the requested endtime. The 858 value of the renew-till field may still be adjusted by site-determined 859 limits or limits imposed by the individual principal or server. 861 2.8.2 ENC-TKT-IN-SKEY 863 In its basic form the Kerberos protocol supports authentication in a client 864 server setting and is not well suited to authentication in a peer-to-peer 865 environment because the long term key of the user does not remain on the 866 workstation after initial login. Authentication of such peers may be 867 supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-SKEY 868 option supports user-to-user authentication by allowing the KDC to issue a 869 service ticket encrypted using the session key from another ticket granting 870 ticket issued to another user. The ENC-TKT-IN-SKEY option is honored only by 871 the ticket-granting service. It indicates that the ticket to be issued for 872 the end server is to be encrypted in the session key from the additional 873 second ticket-granting ticket provided with the request. See section 3.3.3 874 for specific details. 876 2.8.3 Passwordless Hardware Authentication 878 The OPT-HARDWARE-AUTH option indicates that the client wishes to use some 879 form of hardware authentication instead of or in addition to the client's 880 password or other long-lived encryption key. OPT-HARDWARE-AUTH is honored 881 only by the authentication service. If supported and allowed by policy, the 882 KDC will return an errorcode KDC_ERR_PREAUTH_REQUIRED and include the 883 required METHOD-DATA to perform such authentication. 885 3. Message Exchanges 887 The following sections describe the interactions between network clients and 888 servers and the messages involved in those exchanges. 890 3.1. The Authentication Service Exchange 892 Summary 893 Message direction Message type Section 894 1. Client to Kerberos KRB_AS_REQ 5.4.1 895 2. Kerberos to client KRB_AS_REP or 5.4.2 896 KRB_ERROR 5.9.1 898 The Authentication Service (AS) Exchange between the client and the Kerberos 899 Authentication Server is initiated by a client when it wishes to obtain 900 authentication credentials for a given server but currently holds no 901 credentials. In its basic form, the client's secret key is used for 902 encryption and decryption. This exchange is typically used at the initiation 903 of a login session to obtain credentials for a Ticket-Granting Server which 904 will subsequently be used to obtain credentials for other servers (see 905 section 3.3) without requiring further use of the client's secret key. This 906 exchange is also used to request credentials for services which must not be 907 mediated through the Ticket-Granting Service, but rather require a 908 principal's secret key, such as the password-changing service[3.1]. This 909 exchange does not by itself provide any assurance of the the identity of the 910 user[3.2]. 912 The exchange consists of two messages: KRB_AS_REQ from the client to 913 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 914 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 916 In the request, the client sends (in cleartext) its own identity and the 917 identity of the server for which it is requesting credentials, other 918 information about the credentials it is requesting, and a randomly generated 919 nonce which can be used to detect replays, and to associate replies with the 920 matching requests. This nonce must be generated randomly by the client and 921 remembered for checking against the nonce in the expected reply. The 922 response, KRB_AS_REP, contains a ticket for the client to present to the 923 server, and a session key that will be shared by the client and the server. 924 The session key and additional information are encrypted in the client's 925 secret key. The encrypted part of the KRB_AS_REP message also contains the 926 nonce which must be matched with the nonce from the KRB_AS_REQ message. 928 Without pre-authentication, the authentication server does not know whether 929 the client is actually the principal named in the request. It simply sends a 930 reply without knowing or caring whether they are the same. This is 931 acceptable because nobody but the principal whose identity was given in the 932 request will be able to use the reply. Its critical information is encrypted 933 in that principal's key. However, an attacker can send a KRB_AS_REQ message 934 to get known plaintext in order to attack the principal's key. Especially if 935 the key is based on a password, this may create a security exposure. So, the 936 initial request supports an optional field that can be used to pass 937 additional information that might be needed for the initial exchange. This 938 field should be used for pre-authentication as described in section 3.1.1. 940 Various errors can occur; these are indicated by an error response 941 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not 942 encrypted. The KRB_ERROR message contains information which can be used to 943 associate it with the message to which it replies. The contents of the 944 KRB_ERROR message are not integrity-protected. As such, the client cannot 945 detect replays, fabrications or modifications. A solution to this problem 946 will be included in a future version of the protocol. 948 3.1.1. Generation of KRB_AS_REQ message 950 The client may specify a number of options in the initial request. Among 951 these options are whether pre-authentication is to be performed; whether the 952 requested ticket is to be renewable, proxiable, or forwardable; whether it 953 should be postdated or allow postdating of derivative tickets; whether the 954 client requests an anonymous ticket; and whether a renewable ticket will be 955 accepted in lieu of a non-renewable ticket if the requested ticket 956 expiration date cannot be satisfied by a non-renewable ticket (due to 957 configuration constraints). 959 The client prepares the KRB_AS_REQ message and sends it to the KDC. 961 3.1.2. Receipt of KRB_AS_REQ message 963 If all goes well, processing the KRB_AS_REQ message will result in the 964 creation of a ticket for the client to present to the server. The format for 965 the ticket is described in section 5.3. The contents of the ticket are 966 determined as follows. 968 Because Kerberos can run over unreliable transports such as UDP, the KDC 969 MUST be prepared to retransmit responses in case they are lost. If a KDC 970 receives a request identical to one it has recently successfully processed, 971 the KDC MUST respond with a KRB_AS_REP message rather than a replay error. 972 In order to reduce ciphertext given to a potential attacker, KDCs MAY wish 973 to send the same response generated when the request was first handled. KDCs 974 MUST obey this replay behavior even if the actual transport in use is 975 reliable. 977 3.1.3. Generation of KRB_AS_REP message 979 The authentication server looks up the client and server principals named in 980 the KRB_AS_REQ in its database, extracting their respective keys. If the 981 requested client principal named in the request is not known because it 982 doesn't exist in the KDC's principal database, then an error message with a 983 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 985 If required, the server pre-authenticates the request, and if the 986 pre-authentication check fails, an error message with the code 987 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, but 988 was not present in the request, an error message with the code 989 KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO 990 pre-authentication field will be included in the KRB-ERROR message. If the 991 server cannot accommodate an encryption type requested by the client, an 992 error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC 993 generates a 'random' session key[3.3]. 995 When responding to an AS request, if there are multiple encryption keys 996 registered for a client in the Kerberos database , then the etype field from 997 the AS request is used by the KDC to select the encryption method to be used 998 to protect the encrypted part of the KRB_AS_REP message which is sent to the 999 client. If there is more than one supported strong encryption type in the 1000 etype list, the first valid strong etype for which an encryption key is 1001 available is used. 1003 When the user's key is generated from a password or pass phrase, the 1004 string-to-key function for the particular encryption key type is used, as 1005 specified in [KCRYPTO]. The salt value and additional parameters for the 1006 string-to-key function have default values (specified by section 6 and by 1007 the encryption mechanism specification, respectively) that may be overridden 1008 by preauthentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, 1009 PA-S2K-PARAMS, etc). Since the KDC is presumed to store a copy of the 1010 resulting key only, these values should not be changed for password-based 1011 keys except when changing the principal's key. 1013 It is not possible to reliably generate a user's key given a pass phrase 1014 without contacting the KDC, since it will not be known whether alternate 1015 salt or parameter values are required. 1017 When the etype field is present in a KDC request, whether an AS or TGS 1018 request, the KDC will attempt to assign the type of the random session key 1019 from the list of methods in the etype field. The KDC will select the 1020 appropriate type using the list of methods provided together with 1021 information from the Kerberos database indicating acceptable encryption 1022 methods for the application server. The KDC will not issue tickets with a 1023 weak session key encryption type. 1025 If the requested start time is absent, indicates a time in the past, or is 1026 within the window of acceptable clock skew for the KDC and the POSTDATE 1027 option has not been specified, then the start time of the ticket is set to 1028 the authentication server's current time. If it indicates a time in the 1029 future beyond the acceptable clock skew, but the POSTDATED option has not 1030 been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise 1031 the requested start time is checked against the policy of the local realm 1032 (the administrator might decide to prohibit certain types or ranges of 1033 postdated tickets), and if acceptable, the ticket's start time is set as 1034 requested and the INVALID flag is set in the new ticket. The postdated 1035 ticket must be validated before use by presenting it to the KDC after the 1036 start time has been reached. 1038 The expiration time of the ticket will be set to the earlier of the 1039 requested endtime and a time determined by local policy, possibly determined 1040 using realm or principal specific factors. For example, the expiration time 1041 may be set to the minimum of the following: 1043 * The expiration time (endtime) requested in the KRB_AS_REQ message. 1044 * The ticket's start time plus the maximum allowable lifetime associated 1045 with the client principal from the authentication server's database. 1046 * The ticket's start time plus the maximum allowable lifetime associated 1047 with the server principal. 1048 * The ticket's start time plus the maximum lifetime set by the policy of 1049 the local realm. 1051 If the requested expiration time minus the start time (as determined above) 1052 is less than a site-determined minimum lifetime, an error message with code 1053 KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the 1054 ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' 1055 option was requested, then the 'RENEWABLE' flag is set in the new ticket, 1056 and the renew-till value is set as if the 'RENEWABLE' option were requested 1057 (the field and option names are described fully in section 5.4.1). 1059 If the RENEWABLE option has been requested or if the RENEWABLE-OK option has 1060 been set and a renewable ticket is to be issued, then the renew-till field 1061 is set to the minimum of: 1063 * Its requested value. 1064 * The start time of the ticket plus the minimum of the two maximum 1065 renewable lifetimes associated with the principals' database entries. 1066 * The start time of the ticket plus the maximum renewable lifetime set by 1067 the policy of the local realm. 1069 The flags field of the new ticket will have the following options set if 1070 they have been requested and if the policy of the local realm allows: 1071 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS. If 1072 the new ticket is post-dated (the start time is in the future), its INVALID 1073 flag will also be set. 1075 If all of the above succeed, the server will encrypt ciphertext part of the 1076 ticket using the encryption key extracted from the server principal's record 1077 in the Kerberos database using the encryption type associated with the 1078 server principal's key (this choice is NOT affected by the etype field in 1079 the request). It then formats a KRB_AS_REP message (see section 5.4.2), 1080 copying the addresses in the request into the caddr of the response, placing 1081 any required pre-authentication data into the padata of the response, and 1082 encrypts the ciphertext part in the client's key using an acceptable 1083 encryption method requested in the etype field of the request, or in some 1084 key specified by pre-authentication mechanisms being used. 1086 3.1.4. Generation of KRB_ERROR message 1088 Several errors can occur, and the Authentication Server responds by 1089 returning an error message, KRB_ERROR, to the client, with the error-code 1090 and e-text fields set to appropriate values. The error message contents and 1091 details are described in Section 5.9.1. 1093 3.1.5. Receipt of KRB_AS_REP message 1095 If the reply message type is KRB_AS_REP, then the client verifies that the 1096 cname and crealm fields in the cleartext portion of the reply match what it 1097 requested. If any padata fields are present, they may be used to derive the 1098 proper secret key to decrypt the message. The client decrypts the encrypted 1099 part of the response using its secret key, verifies that the nonce in the 1100 encrypted part matches the nonce it supplied in its request (to detect 1101 replays). It also verifies that the sname and srealm in the response match 1102 those in the request (or are otherwise expected values), and that the host 1103 address field is also correct. It then stores the ticket, session key, start 1104 and expiration times, and other information for later use. The 1105 key-expiration field from the encrypted part of the response may be checked 1106 to notify the user of impending key expiration (the client program could 1107 then suggest remedial action, such as a password change). 1109 Upon validation of the KRB_AS_REP message (by checking the returned nonce 1110 against that sent in the KRB_AS_REQ message) the client knows that the 1111 current time on the KDC is that read from the authtime field of the 1112 encrypted part of the reply. The client can optionally use this value for 1113 clock synchronization in subsequent messages by recording with the ticket 1114 the difference (offset) between the authtime value and the local clock. This 1115 offset can then be used by the same user to adjust the time read from the 1116 system clock when generating messages [cite Davis and Geer]. 1118 This technique must be used when adjusting for clock skew instead of 1119 directly changing the system clock because the KDC reply is only 1120 authenticated to the user whose secret key was used, but not to the system 1121 or workstation. If the clock were adjusted, an attacker colluding with a 1122 user logging into a workstation could agree on a password, resulting in a 1123 KDC reply that would be correctly validated even though it did not originate 1124 from a KDC trusted by the workstation. 1126 Proper decryption of the KRB_AS_REP message is not sufficient for the host 1127 to verify the identity of the user; the user and an attacker could cooperate 1128 to generate a KRB_AS_REP format message which decrypts properly but is not 1129 from the proper KDC. If the host wishes to verify the identity of the user, 1130 it must require the user to present application credentials which can be 1131 verified using a securely-stored secret key for the host. If those 1132 credentials can be verified, then the identity of the user can be assured. 1134 3.1.6. Receipt of KRB_ERROR message 1136 If the reply message type is KRB_ERROR, then the client interprets it as an 1137 error and performs whatever application-specific tasks are necessary to 1138 recover. 1140 3.2. The Client/Server Authentication Exchange 1142 Summary 1143 Message direction Message type Section 1144 Client to Application server KRB_AP_REQ 5.5.1 1145 [optional] Application server to client KRB_AP_REP or 5.5.2 1146 KRB_ERROR 5.9.1 1148 The client/server authentication (CS) exchange is used by network 1149 applications to authenticate the client to the server and vice versa. The 1150 client must have already acquired credentials for the server using the AS or 1151 TGS exchange. 1153 3.2.1. The KRB_AP_REQ message 1155 The KRB_AP_REQ contains authentication information which should be part of 1156 the first message in an authenticated transaction. It contains a ticket, an 1157 authenticator, and some additional bookkeeping information (see section 1158 5.5.1 for the exact format). The ticket by itself is insufficient to 1159 authenticate a client, since tickets are passed across the network in 1160 cleartext[3.4], so the authenticator is used to prevent invalid replay of 1161 tickets by proving to the server that the client knows the session key of 1162 the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is 1163 referred to elsewhere as the 'authentication header.' 1164 3.2.2. Generation of a KRB_AP_REQ message 1166 When a client wishes to initiate authentication to a server, it obtains 1167 (either through a credentials cache, the AS exchange, or the TGS exchange) a 1168 ticket and session key for the desired service. The client may re-use any 1169 tickets it holds until they expire. To use a ticket the client constructs a 1170 new Authenticator from the the system time, its name, and optionally an 1171 application specific checksum, an initial sequence number to be used in 1172 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in 1173 negotiations for a session key unique to this particular session. 1174 Authenticators may not be re-used and will be rejected if replayed to a 1175 server[3.5]. If a sequence number is to be included, it should be randomly 1176 chosen so that even after many messages have been exchanged it is not likely 1177 to collide with other sequence numbers in use. 1179 The client may indicate a requirement of mutual authentication or the use of 1180 a session-key based ticket (for user to user authentciation - see section 1181 3.7) by setting the appropriate flag(s) in the ap-options field of the 1182 message. 1184 The Authenticator is encrypted in the session key and combined with the 1185 ticket to form the KRB_AP_REQ message which is then sent to the end server 1186 along with any additional application-specific information. 1188 3.2.3. Receipt of KRB_AP_REQ message 1190 Authentication is based on the server's current time of day (clocks must be 1191 loosely synchronized), the authenticator, and the ticket. Several errors are 1192 possible. If an error occurs, the server is expected to reply to the client 1193 with a KRB_ERROR message. This message may be encapsulated in the 1194 application protocol if its 'raw' form is not acceptable to the protocol. 1195 The format of error messages is described in section 5.9.1. 1197 The algorithm for verifying authentication information is as follows. If the 1198 message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE 1199 error. If the key version indicated by the Ticket in the KRB_AP_REQ is not 1200 one the server can use (e.g., it indicates an old key, and the server no 1201 longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is 1202 returned. If the USE-SESSION-KEY flag is set in the ap-options field, it 1203 indicates to the server that user-to-user authentication is in use, and that 1204 the ticket is encrypted in the session key from the server's ticket-granting 1205 ticket rather than in the server's secret key. See section 3.7 for a more 1206 complete description of the affect of user to user authentication on all 1207 messages in the Kerberos protocol. 1209 Since it is possible for the server to be registered in multiple realms, 1210 with different keys in each, the srealm field in the unencrypted portion of 1211 the ticket in the KRB_AP_REQ is used to specify which secret key the server 1212 should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is 1213 returned if the server doesn't have the proper key to decipher the ticket. 1215 The ticket is decrypted using the version of the server's key specified by 1216 the ticket. If the decryption routines detect a modification of the ticket 1217 (each encryption system must provide safeguards to detect modified 1218 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned 1219 (chances are good that different keys were used to encrypt and decrypt). 1221 The authenticator is decrypted using the session key extracted from the 1222 decrypted ticket. If decryption shows it to have been modified, the 1223 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client 1224 from the ticket are compared against the same fields in the authenticator. 1225 If they don't match, the KRB_AP_ERR_BADMATCH error is returned; this 1226 normally is caused by a client error or attempted attack. The addresses in 1227 the ticket (if any) are then searched for an address matching the 1228 operating-system reported address of the client. If no match is found or the 1229 server insists on ticket addresses but none are present in the ticket, the 1230 KRB_AP_ERR_BADADDR error is returned. If the local (server) time and the 1231 client time in the authenticator differ by more than the allowable clock 1232 skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned. 1234 Unless the application server provides its own suitable means to protect 1235 against replay (for example, a challenge-response sequence initiated by the 1236 server after authentication, or use of a server-generated encryption 1237 subkey), the server must utilize a replay cache to remember any 1238 authenticator presented within the allowable clock skew. Careful analysis of 1239 the application protocol and implementation is recommended before 1240 eliminating this cache. The replay cache will store the server name, along 1241 with the client name, time and microsecond fields from the recently-seen 1242 authenticators and if a matching tuple is found, the KRB_AP_ERR_REPEAT error 1243 is returned [3.7]. If a server loses track of authenticators presented 1244 within the allowable clock skew, it must reject all requests until the clock 1245 skew interval has passed, providing assurance that any lost or re-played 1246 authenticators will fall outside the allowable clock skew and can no longer 1247 be successfully replayed[3.8]. 1249 Implementation note: If a client generates multiple requests to the KDC with 1250 the same timestamp, including the microsecond field, all but the first of 1251 the requests received will be rejected as replays. This might happen, for 1252 example, if the resolution of the client's clock is too coarse. 1253 Implementations should ensure that the timestamps are not reused, possibly 1254 by incrementing the microseconds field in the time stamp when the clock 1255 returns the same time for multiple requests. 1257 If multiple servers (for example, different services on one machine, or a 1258 single service implemented on multiple machines) share a service principal 1259 (a practice we do not recommend in general, but acknowledge will be used in 1260 some cases), they should also share this replay cache, or the application 1261 protocol should be designed so as to eliminate the need for it. Note that 1262 this applies to all of the services, if any of the application protocols 1263 does not have replay protection built in; an authenticator used with such a 1264 service could later be replayed to a different service with the same service 1265 principal but no replay protection, if the former doesn't record the 1266 authenticator information in the common replay cache. 1268 If a sequence number is provided in the authenticator, the server saves it 1269 for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey 1270 is present, the server either saves it for later use or uses it to help 1271 generate its own choice for a subkey to be returned in a KRB_AP_REP message. 1273 The server computes the age of the ticket: local (server) time minus the 1274 start time inside the Ticket. If the start time is later than the current 1275 time by more than the allowable clock skew or if the INVALID flag is set in 1276 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the 1277 current time is later than end time by more than the allowable clock skew, 1278 the KRB_AP_ERR_TKT_EXPIRED error is returned. 1280 If all these checks succeed without an error, the server is assured that the 1281 client possesses the credentials of the principal named in the ticket and 1282 thus, the client has been authenticated to the server. 1284 Passing these checks provides only authentication of the named principal; it 1285 does not imply authorization to use the named service. Applications must 1286 make a separate authorization decisions based upon the authenticated name of 1287 the user, the requested operation, local access control information such as 1288 that contained in a .k5login or .k5users file, and possibly a separate 1289 distributed authorization service. 1291 3.2.4. Generation of a KRB_AP_REP message 1293 Typically, a client's request will include both the authentication 1294 information and its initial request in the same message, and the server need 1295 not explicitly reply to the KRB_AP_REQ. However, if mutual authentication 1296 (not only authenticating the client to the server, but also the server to 1297 the client) is being performed, the KRB_AP_REQ message will have 1298 MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is 1299 required in response. As with the error message, this message may be 1300 encapsulated in the application protocol if its "raw" form is not acceptable 1301 to the application's protocol. The timestamp and microsecond field used in 1302 the reply must be the client's timestamp and microsecond field (as provided 1303 in the authenticator)[3.9]. If a sequence number is to be included, it 1305 should be randomly chosen as described above for the authenticator. A subkey 1306 may be included if the server desires to negotiate a different subkey. The 1307 KRB_AP_REP message is encrypted in the session key extracted from the 1308 ticket. 1310 3.2.5. Receipt of KRB_AP_REP message 1312 If a KRB_AP_REP message is returned, the client uses the session key from 1313 the credentials obtained for the server[3.10] to decrypt the message, and 1314 verifies that the timestamp and microsecond fields match those in the 1315 Authenticator it sent to the server. If they match, then the client is 1316 assured that the server is genuine. The sequence number and subkey (if 1317 present) are retained for later use. 1319 3.2.6. Using the encryption key 1321 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server 1322 share an encryption key which can be used by the application. In some cases, 1323 the use of this session key will be implicit in the protocol; in others the 1324 method of use must be chosen from several alternatives. The 'true session 1325 key' to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses 1326 may be chosen by the application based on the session key from the ticket 1327 and subkeys in the KRB_AP_REP message and the authenticator[3.11]. To 1328 mitigate the effect of failures in random number generation on the client it 1329 is strongly encouraged that any key derived by an application for subsequent 1330 use include the full key entropy derived from the KDC generated session key 1331 carried in the ticket. We leave the protocol negotiations of how to use the 1332 key (e.g. selecting an encryption or checksum type) to the application 1333 programmer; the Kerberos protocol does not constrain the implementation 1334 options, but an example of how this might be done follows. 1336 One way that an application may choose to negotiate a key to be used for 1337 subsequent integrity and privacy protection is for the client to propose a 1338 key in the subkey field of the authenticator. The server can then choose a 1339 key using the proposed key from the client as input, returning the new 1340 subkey in the subkey field of the application reply. This key could then be 1341 used for subsequent communication. 1343 To make this example more concrete, if the communication patterns of an 1344 application dictates the use of encryption modes of operation incompatible 1345 with the encryption system used for the authenticator, then a key compatible 1346 with the required encryption system may be generated by either the client, 1347 the server, or collaboratively by both and exchanged using the subkey field. 1348 This generation might involve the use of a random number as a pre-key, 1349 initially generated by either party, which could then be encrypted using the 1350 session key from the ticket, and the result exchanged and used for 1351 subsequent encryption. By encrypting the pre-key with the session key from 1352 the ticket, randomness from the KDC generated key is assured of being 1353 present in the negotiated key. Application developers must be careful 1354 however, to use a means of introducing this entropy that does not allow an 1355 attacker to learn the session key from the ticket if it learns the key 1356 generated and used for subsequent communication. The reader should note that 1357 this is only an example, and that an analysis of the particular cryptosystem 1358 to be used, must be made before deciding how to generate values for the 1359 subkey fields, and the key to be used for subsequent communication. 1361 With both the one-way and mutual authentication exchanges, the peers should 1362 take care not to send sensitive information to each other without proper 1363 assurances. In particular, applications that require privacy or integrity 1364 should use the KRB_AP_REP response from the server to client to assure both 1365 client and server of their peer's identity. If an application protocol 1366 requires privacy of its messages, it can use the KRB_PRIV message (section 1367 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 1369 3.3. The Ticket-Granting Service (TGS) Exchange 1371 Summary 1372 Message direction Message type Section 1373 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1374 2. Kerberos to client KRB_TGS_REP or 5.4.2 1375 KRB_ERROR 5.9.1 1377 The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1378 initiated by a client when it wishes to obtain authentication credentials 1379 for a given server (which might be registered in a remote realm), when it 1380 wishes to renew or validate an existing ticket, or when it wishes to obtain 1381 a proxy ticket. In the first case, the client must already have acquired a 1382 ticket for the Ticket-Granting Service using the AS exchange (the 1383 ticket-granting ticket is usually obtained when a client initially 1384 authenticates to the system, such as when a user logs in). The message 1385 format for the TGS exchange is almost identical to that for the AS exchange. 1386 The primary difference is that encryption and decryption in the TGS exchange 1387 does not take place under the client's key. Instead, the session key from 1388 the ticket-granting ticket or renewable ticket, or sub-session key from an 1389 Authenticator is used. As is the case for all application servers, expired 1390 tickets are not accepted by the TGS, so once a renewable or ticket-granting 1391 ticket expires, the client must use a separate exchange to obtain valid 1392 tickets. 1394 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1395 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1396 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1397 client plus a request for credentials. The authentication information 1398 consists of the authentication header (KRB_AP_REQ) which includes the 1399 client's previously obtained ticket-granting, renewable, or invalid ticket. 1400 In the ticket-granting ticket and proxy cases, the request may include one 1401 or more of: a list of network addresses, a collection of typed authorization 1402 data to be sealed in the ticket for authorization use by the application 1403 server, or additional tickets (the use of which are described later). The 1404 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1405 session key from the ticket-granting ticket or renewable ticket, or if 1406 present, in the sub-session key from the Authenticator (part of the 1407 authentication header). The KRB_ERROR message contains an error code and 1408 text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1409 KRB_TGS_REP message contains information which can be used to detect 1410 replays, and to associate it with the message to which it replies. The 1411 KRB_ERROR message also contains information which can be used to associate 1412 it with the message to which it replies. The same comments about integrity 1413 protection of KRB_ERROR messages mentioned in section 3.1 apply to the TGS 1414 exchange. 1416 3.3.1. Generation of KRB_TGS_REQ message 1418 Before sending a request to the ticket-granting service, the client must 1419 determine in which realm the application server is believed to be 1420 registered[3.12]. If the client knows the service principal name and realm 1421 and it does not already possess a ticket-granting ticket for the appropriate 1422 realm, then one must be obtained. This is first attempted by requesting a 1423 ticket-granting ticket for the destination realm from a Kerberos server for 1424 which the client possesses a ticket-granting ticket (using the KRB_TGS_REQ 1425 message recursively). The Kerberos server may return a TGT for the desired 1426 realm in which case one can proceed. Alternatively, the Kerberos server may 1427 return a TGT for a realm which is 'closer' to the desired realm (further 1428 along the standard hierarchical path between the client's realm and the 1429 requested realm server's realm). It should be noted in this case that 1430 misconfiguration of the Kerberos servers may cause loops in the resulting 1431 authentication path, which the client should be careful to detect and avoid. 1433 If the Kerberos server returns a TGT for a 'closer' realm other than the 1434 desired realm, the client may wish to use local policy configuration to 1435 verify that the authentication path used is an acceptable one. 1436 Alternatively, a client may wish to choose its own authentication path, 1437 rather than relying on the Kerberos server to select one. In either case, 1438 any policy or configuration information used to choose or validate 1439 authentication paths, whether by the Kerberos server or client, must be 1440 obtained from a trusted source. 1442 When a client obtains a ticket-granting ticket that is 'closer' to the 1443 destination realm, the client may cache this ticket and reuse it in future 1444 KRB-TGS exchanges with services in the 'closer' realm. However, if the 1445 client were to obtain a ticket-granting ticket for the 'closer' realm by 1446 starting at the initial KDC rather than as part of obtaining another ticket, 1447 then a shorter path to the 'closer' realm might be used. This shorter path 1448 may be desirable because fewer intermediate KDCs would know the ssesion key 1449 of the ticket involved. For this reason, clients should evaluate whether 1450 they trust the realms transited in obtaining the 'closer' ticket when making 1451 a decision to use the ticket in future. 1453 Once the client obtains a ticket-granting ticket for the appropriate realm, 1454 it determines which Kerberos servers serve that realm, and contacts one. The 1455 list might be obtained through a configuration file or network service or it 1456 may be generated from the name of the realm; as long as the secret keys 1457 exchanged by realms are kept secret, only denial of service results from 1458 using a false Kerberos server. 1460 (This paragraph changed) As in the AS exchange, the client may specify a 1461 number of options in the KRB_TGS_REQ message. One of these options is the 1462 ENC-TKT-IN-SKEY option used for user to user authentication. An overview of 1463 user to user authentication can be found in section 3.7. When generating the 1464 KRB_TGS_REQ message, this option indicates that the client is including a 1465 ticket granting ticket obtained from the application server in the 1466 additional tickets field of the request and that the KDC should encrypt the 1467 ticket for the application server using the session key from this additional 1468 ticket, instead of using a server key from the principal database. 1470 The client prepares the KRB_TGS_REQ message, providing an authentication 1471 header as an element of the padata field, and including the same fields as 1472 used in the KRB_AS_REQ message along with several optional fields: the 1473 enc-authorizatfion-data field for application server use and additional 1474 tickets required by some options. 1476 In preparing the authentication header, the client can select a sub-session 1477 key under which the response from the Kerberos server will be 1478 encrypted[3.13]. If the sub-session key is not specified, the session key 1479 from the ticket-granting ticket will be used. If the enc-authorization-data 1480 is present, it must be encrypted in the sub-session key, if present, from 1481 the authenticator portion of the authentication header, or if not present, 1482 using the session key from the ticket-granting ticket. 1484 Once prepared, the message is sent to a Kerberos server for the destination 1485 realm. 1487 3.3.2. Receipt of KRB_TGS_REQ message 1489 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1490 message, but there are many additional checks to be performed. First, the 1491 Kerberos server must determine which server the accompanying ticket is for 1492 and it must select the appropriate key to decrypt it. For a normal 1493 KRB_TGS_REQ message, it will be for the ticket granting service, and the 1494 TGS's key will be used. If the TGT was issued by another realm, then the 1495 appropriate inter-realm key must be used. If the accompanying ticket is not 1496 a ticket granting ticket for the current realm, but is for an application 1497 server in the current realm, the RENEW, VALIDATE, or PROXY options are 1498 specified in the request, and the server for which a ticket is requested is 1499 the server named in the accompanying ticket, then the KDC will decrypt the 1500 ticket in the authentication header using the key of the server for which it 1501 was issued. If no ticket can be found in the padata field, the 1502 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1504 Once the accompanying ticket has been decrypted, the user-supplied checksum 1505 in the Authenticator must be verified against the contents of the request, 1506 and the message rejected if the checksums do not match (with an error code 1507 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1508 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1509 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1510 returned. If the authorization-data are present, they are decrypted using 1511 the sub-session key from the Authenticator. 1513 If any of the decryptions indicate failed integrity checks, the 1514 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1516 As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP message 1517 if it receives a KRB_TGS_REQ message identical to one it has recently 1518 processed. However, if the authenticator is a replay, but the rest of the 1519 request is not identical, then the KDC SHOULD return KRB_AP_ERR_REPEAT. 1521 3.3.3. Generation of KRB_TGS_REP message 1523 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1524 but with its type field set to KRB_TGS_REP. The detailed specification is in 1525 section 5.4.2. 1527 The response will include a ticket for the requested server or for a ticket 1528 granting server of an intermediate KDC to be contacted to obtain the 1529 requested ticket. The Kerberos database is queried to retrieve the record 1530 for the appropriate server (including the key with which the ticket will be 1531 encrypted). If the request is for a ticket granting ticket for a remote 1532 realm, and if no key is shared with the requested realm, then the Kerberos 1533 server will select the realm 'closest' to the requested realm with which it 1534 does share a key, and use that realm instead. If the requested server cannot 1535 be found in the TGS database, then a TGT for another trusted realm may be 1536 returned instead of a ticket for the service. This TGT is a referral 1537 mechanism to cause the client to retry the request to the realm of the TGT. 1538 These are the only cases where the response for the KDC will be for a 1539 different server than that requested by the client. 1541 By default, the address field, the client's name and realm, the list of 1542 transited realms, the time of initial authentication, the expiration time, 1543 and the authorization data of the newly-issued ticket will be copied from 1544 the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1545 needs to be updated, but the transited type is not supported, the 1546 KDC_ERR_TRTYPE_NOSUPP error is returned. 1548 If the request specifies an endtime, then the endtime of the new ticket is 1549 set to the minimum of (a) that request, (b) the endtime from the TGT, and 1550 (c) the starttime of the TGT plus the minimum of the maximum life for the 1551 application server and the maximum life for the local realm (the maximum 1552 life for the requesting principal was already applied when the TGT was 1553 issued). If the new ticket is to be a renewal, then the endtime above is 1554 replaced by the minimum of (a) the value of the renew_till field of the 1555 ticket and (b) the starttime for the new ticket plus the life 1556 (endtime-starttime) of the old ticket. 1558 If the FORWARDED option has been requested, then the resulting ticket will 1559 contain the addresses specified by the client. This option will only be 1560 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1561 similar; the resulting ticket will contain the addresses specified by the 1562 client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1563 PROXY option will not be honored on requests for additional ticket-granting 1564 tickets. 1566 If the requested start time is absent, indicates a time in the past, or is 1567 within the window of acceptable clock skew for the KDC and the POSTDATE 1568 option has not been specified, then the start time of the ticket is set to 1569 the authentication server's current time. If it indicates a time in the 1570 future beyond the acceptable clock skew, but the POSTDATED option has not 1571 been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1572 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1573 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1574 postdated and the requested starttime is checked against the policy of the 1575 local realm. If acceptable, the ticket's start time is set as requested, and 1577 the INVALID flag is set. The postdated ticket must be validated before use 1578 by presenting it to the KDC after the starttime has been reached. However, 1579 in no case may the starttime, endtime, or renew-till time of a newly-issued 1580 postdated ticket extend beyond the renew-till time of the ticket-granting 1581 ticket. 1583 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1584 has been included in the request, it indicates that the client is using user 1585 to user authentication to prove its identity to a server that does not have 1586 access to a persistent key. Section 3.7 describes the affect of this option 1587 on the entire Kerberos protocol. When generating the KRB_TGS_REP message, 1588 this option in the KRB_TGS_REQ message tells the KDC to decrypt the 1589 additional ticket using the key for the server to which the additional 1590 ticket was issued and verify that it is a ticket-granting ticket. If the 1591 name of the requested server is missing from the request, the name of the 1592 client in the additional ticket will be used. Otherwise the name of the 1593 requested server will be compared to the name of the client in the 1594 additional ticket and if different, the request will be rejected. If the 1595 request succeeds, the session key from the additional ticket will be used to 1596 encrypt the new ticket that is issued instead of using the key of the server 1597 for which the new ticket will be used. 1599 If the name of the server in the ticket that is presented to the KDC as part 1600 of the authentication header is not that of the ticket-granting server 1601 itself, the server is registered in the realm of the KDC, and the RENEW 1602 option is requested, then the KDC will verify that the RENEWABLE flag is set 1603 in the ticket, that the INVALID flag is not set in the ticket, and that the 1604 renew_till time is still in the future. If the VALIDATE option is requested, 1605 the KDC will check that the starttime has passed and the INVALID flag is 1606 set. If the PROXY option is requested, then the KDC will check that the 1607 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1608 passes the hotlist check described in the next section, the KDC will issue 1609 the appropriate new ticket. 1611 The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1612 in the sub-session key from the Authenticator, if present, or the session 1613 key key from the ticket-granting ticket. It is not encrypted using the 1614 client's secret key. Furthermore, the client's key's expiration date and the 1615 key version number fields are left out since these values are stored along 1616 with the client's database record, and that record is not needed to satisfy 1617 a request based on a ticket-granting ticket. 1619 3.3.3.1. Checking for revoked tickets 1621 Whenever a request is made to the ticket-granting server, the presented 1622 ticket(s) is(are) checked against a hot-list of tickets which have been 1623 canceled. This hot-list might be implemented by storing a range of issue 1624 timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1625 that range, it would be rejected. In this way, a stolen ticket-granting 1626 ticket or renewable ticket cannot be used to gain additional tickets 1627 (renewals or otherwise) once the theft has been reported to the KDC for the 1628 realm in which the server resides. Any normal ticket obtained before it was 1629 reported stolen will still be valid (because they require no interaction 1630 with the KDC), but only until their normal expiration time. If TGT's have 1631 been issued for cross-realm authentication, use of the cross-realm TGT will 1632 not be affected unless the hot-list is propagated to the KDC's for the 1633 realms for which such cross-realm tickets were issued. 1635 3.3.3.2. Encoding the transited field 1637 If the identity of the server in the TGT that is presented to the KDC as 1638 part of the authentication header is that of the ticket-granting service, 1639 but the TGT was issued from another realm, the KDC will look up the 1640 inter-realm key shared with that realm and use that key to decrypt the 1641 ticket. If the ticket is valid, then the KDC will honor the request, subject 1642 to the constraints outlined above in the section describing the AS exchange. 1643 The realm part of the client's identity will be taken from the 1644 ticket-granting ticket. The name of the realm that issued the 1645 ticket-granting ticket, if it is not the realm of the client principal, will 1646 be added to the transited field of the ticket to be issued. This is 1647 accomplished by reading the transited field from the ticket-granting ticket 1648 (which is treated as an unordered set of realm names), adding the new realm 1649 to the set, then constructing and writing out its encoded (shorthand) form 1650 (this may involve a rearrangement of the existing encoding). 1652 Note that the ticket-granting service does not add the name of its own 1653 realm. Instead, its responsibility is to add the name of the previous realm. 1654 This prevents a malicious Kerberos server from intentionally leaving out its 1655 own name (it could, however, omit other realms' names). 1657 The names of neither the local realm nor the principal's realm are to be 1658 included in the transited field. They appear elsewhere in the ticket and 1659 both are known to have taken part in authenticating the principal. Since the 1660 endpoints are not included, both local and single-hop inter-realm 1661 authentication result in a transited field that is empty. 1663 Because the name of each realm transited is added to this field, it might 1664 potentially be very long. To decrease the length of this field, its contents 1665 are encoded. The initially supported encoding is optimized for the normal 1666 case of inter-realm communication: a hierarchical arrangement of realms 1667 using either domain or X.500 style realm names. This encoding (called 1668 DOMAIN-X500-COMPRESS) is now described. 1670 Realm names in the transited field are separated by a ",". The ",", "\", 1671 trailing "."s, and leading spaces (" ") are special characters, and if they 1672 are part of a realm name, they must be quoted in the transited field by 1673 preceding them with a "\". 1675 A realm name ending with a "." is interpreted as being prepended to the 1676 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1677 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1679 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1681 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1682 would not be included in this field, and we would have: 1684 "EDU,MIT.,WASHINGTON.EDU" 1685 A realm name beginning with a "/" is interpreted as being appended to the 1686 previous realm[18]. If it is to stand by itself, then it should be preceded 1687 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1688 /COM/HP, /COM, and /COM/DEC as: 1690 "/COM,/HP,/APOLLO, /COM/DEC". 1692 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1693 they would not be included in this field, and we would have: 1695 "/COM,/HP" 1697 A null subfield preceding or following a "," indicates that all realms 1698 between the previous realm and the next realm have been traversed[19]. Thus, 1699 "," means that all realms along the path between the client and the server 1700 have been traversed. ",EDU, /COM," means that that all realms from the 1701 client's realm up to EDU (in a domain style hierarchy) have been traversed, 1702 and that everything from /COM down to the server's realm in an X.500 style 1703 has also been traversed. This could occur if the EDU realm in one hierarchy 1704 shares an inter-realm key directly with the /COM realm in another hierarchy. 1706 3.3.4. Receipt of KRB_TGS_REP message 1708 When the KRB_TGS_REP is received by the client, it is processed in the same 1709 manner as the KRB_AS_REP processing described above. The primary difference 1710 is that the ciphertext part of the response must be decrypted using the 1711 sub-session key from the Authenticator, if it was specified in the request, 1712 or the session key key from the ticket-granting ticket, rather than the 1713 client's secret key. The server name returned in the reply is the true 1714 principal name of the service. 1716 3.4. The KRB_SAFE Exchange 1718 The KRB_SAFE message may be used by clients requiring the ability to detect 1719 modifications of messages they exchange. It achieves this by including a 1720 keyed collision-proof checksum of the user data and some control 1721 information. The checksum is keyed with an encryption key (usually the last 1722 key negotiated via subkeys, or the session key if no negotiation has 1723 occurred). 1725 3.4.1. Generation of a KRB_SAFE message 1727 When an application wishes to send a KRB_SAFE message, it collects its data 1728 and the appropriate control information and computes a checksum over them. 1729 The checksum algorithm should be the keyed checksum mandated to be 1730 implemented along with the crypto system used for the sub-session or session 1731 key. The checksum is generated using the sub-session key if present, or the 1732 session key. Some implementations use a different checksum algorithm for 1733 KRB_SAFE messages but doing so in a interoperable manner is impossible. 1734 Implementations should accept any checksum algorithm they implement that 1735 both has adequate security and that has keys compatible with the sub-session 1736 or session key. Unkeyed or non-collision-proof checksums are not suitable 1737 for this use. 1739 The control information for the KRB_SAFE message includes both a timestamp 1740 and a sequence number. The designer of an application using the KRB_SAFE 1741 message must choose at least one of the two mechanisms. This choice should 1742 be based on the needs of the application protocol. 1744 Sequence numbers are useful when all messages sent will be received by one's 1745 peer. Connection state is presently required to maintain the session key, so 1746 maintaining the next sequence number should not present an additional 1747 problem. 1749 If the application protocol is expected to tolerate lost messages without 1750 them being resent, the use of the timestamp is the appropriate replay 1751 detection mechanism. Using timestamps is also the appropriate mechanism for 1752 multi-cast protocols where all of one's peers share a common sub-session 1753 key, but some messages will be sent to a subset of one's peers. 1755 After computing the checksum, the client then transmits the information and 1756 checksum to the recipient in the message format specified in section 5.6.1. 1758 3.4.2. Receipt of KRB_SAFE message 1760 When an application receives a KRB_SAFE message, it verifies it as follows. 1761 If any error occurs, an error code is reported for use by the application. 1763 The message is first checked by verifying that the protocol version and type 1764 fields match the current version and KRB_SAFE, respectively. A mismatch 1765 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1766 application verifies that the checksum used is a collision-proof keyed 1767 checksum that uses keys compatible with the sub-session or session key as 1768 appropriate, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. 1769 The sender's address MUST be included in the control information; the 1770 recipient verifies that the operating system's report of the sender's 1771 address matches the sender's address in the message, and (if a recipient 1772 address is specified or the recipient requires an address) that one of the 1773 recipient's addresses appears as the recipient's address in the message. To 1774 work with network address translation, senders MAY wish to use the 1775 directional address type specified in section 8.1 for the sender address and 1776 not include recipient addresses. A failed match for either case generates a 1777 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the sequence 1778 number fields are checked. If timestamp and usec are expected and not 1779 present, or they are present but not current, the KRB_AP_ERR_SKEW error is 1780 generated. If the server name, along with the client name, time and 1781 microsecond fields from the Authenticator match any recently-seen (sent or 1782 received[20] ) such tuples, the KRB_AP_ERR_REPEAT error is generated. If an 1783 incorrect sequence number is included, or a sequence number is expected but 1784 not present, the KRB_AP_ERR_BADORDER error is generated. If neither a 1785 time-stamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED 1786 error is generated. Finally, the checksum is computed over the data and 1787 control information, and if it doesn't match the received checksum, a 1788 KRB_AP_ERR_MODIFIED error is generated. 1790 If all the checks succeed, the application is assured that the message was 1791 generated by its peer and was not modified in transit. 1793 3.5. The KRB_PRIV Exchange 1795 The KRB_PRIV message may be used by clients requiring confidentiality and 1796 the ability to detect modifications of exchanged messages. It achieves this 1797 by encrypting the messages and adding control information. 1799 3.5.1. Generation of a KRB_PRIV message 1801 When an application wishes to send a KRB_PRIV message, it collects its data 1802 and the appropriate control information (specified in section 5.7.1) and 1803 encrypts them under an encryption key (usually the last key negotiated via 1804 subkeys, or the session key if no negotiation has occurred). As part of the 1805 control information, the client must choose to use either a timestamp or a 1806 sequence number (or both); see the discussion in section 3.4.1 for 1807 guidelines on which to use. After the user data and control information are 1808 encrypted, the client transmits the ciphertext and some 'envelope' 1809 information to the recipient. 1811 3.5.2. Receipt of KRB_PRIV message 1813 When an application receives a KRB_PRIV message, it verifies it as follows. 1814 If any error occurs, an error code is reported for use by the application. 1816 The message is first checked by verifying that the protocol version and type 1817 fields match the current version and KRB_PRIV, respectively. A mismatch 1818 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1819 application then decrypts the ciphertext and processes the resultant 1820 plaintext. If decryption shows the data to have been modified, a 1821 KRB_AP_ERR_BAD_INTEGRITY error is generated. The sender's address MUST be 1822 included in the control information; the recipient verifies that the 1823 operating system's report of the sender's address matches the sender's 1824 address in the message, and (if a recipient address is specified or the 1825 recipient requires an address) that one of the recipient's addresses appears 1826 as the recipient's address in the message. A failed match for either case 1827 generates a KRB_AP_ERR_BADADDR error. To work with network address 1828 translation, implementations MAY wish to use the directional address type 1829 defined in section 7.1 for the sender address and include no recipient 1830 address. Then the timestamp and usec and/or the sequence number fields are 1831 checked. If timestamp and usec are expected and not present, or they are 1832 present but not current, the KRB_AP_ERR_SKEW error is generated. If the 1833 server name, along with the client name, time and microsecond fields from 1834 the Authenticator match any recently-seen such tuples, the KRB_AP_ERR_REPEAT 1835 error is generated. If an incorrect sequence number is included, or a 1836 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error 1837 is generated. If neither a time-stamp and usec or a sequence number is 1838 present, a KRB_AP_ERR_MODIFIED error is generated. 1840 If all the checks succeed, the application can assume the message was 1841 generated by its peer, and was securely transmitted (without intruders able 1842 to see the unencrypted contents). 1844 3.6. The KRB_CRED Exchange 1846 The KRB_CRED message may be used by clients requiring the ability to send 1847 Kerberos credentials from one host to another. It achieves this by sending 1848 the tickets together with encrypted data containing the session keys and 1849 other information associated with the tickets. 1851 3.6.1. Generation of a KRB_CRED message 1853 When an application wishes to send a KRB_CRED message it first (using the 1854 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1855 constructs a KRB_CRED message using the ticket or tickets so obtained, 1856 placing the session key needed to use each ticket in the key field of the 1857 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1858 message. 1860 Other information associated with each ticket and obtained during the 1861 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1862 the encrypted part of the KRB_CRED message. The current time and, if 1863 specifically required by the application the nonce, s-address, and r-address 1864 fields, are placed in the encrypted part of the KRB_CRED message which is 1865 then encrypted under an encryption key previously exchanged in the KRB_AP 1866 exchange (usually the last key negotiated via subkeys, or the session key if 1867 no negotiation has occurred). 1869 Implementation note: When constructing a KRB_CRED message for inclusion in a 1870 GSSAPI initial context token, the MIT implementation of Kerberos will not 1871 encrypt the KRB_CRED message if the session key is a DES or tripple DES key. 1872 For interoperability with MIT, the Microsoft implementation will not encrypt 1873 the KRB_CRED in a GSSAPI token if it is using a DES session key. Starting at 1874 version 1.2.5, MIT Kerberos can receive and decode either encrypted or 1875 unencrypted KRB_CRED tokens in the GSSAPI exchange. The Heimdal 1876 implementation of Kerberos can also accept either encrypted or unencrypted 1877 KRB_CRED messages. Since the KRB_CRED message in a GSSAPI token is encrypted 1878 in the authenticator, the MIT behavior does not present a security problem, 1879 although it is a violation of the Kerberos specification. 1881 3.6.2. Receipt of KRB_CRED message 1883 When an application receives a KRB_CRED message, it verifies it. If any 1884 error occurs, an error code is reported for use by the application. The 1885 message is verified by checking that the protocol version and type fields 1886 match the current version and KRB_CRED, respectively. A mismatch generates a 1887 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1888 decrypts the ciphertext and processes the resultant plaintext. If decryption 1889 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1890 generated. v 1892 If present or required, the recipient MAY verify that the operating system's 1893 report of the sender's address matches the sender's address in the message, 1894 and that one of the recipient's addresses appears as the recipient's address 1895 in the message. The address check does not provide any added security, since 1896 the address if present has already been checked in the KRB_AP_REQ message 1897 and there is not any benefit to be gained by an attacker in reflecting a 1898 KRB_CRED message back to its originator. Thus, the recipient MAY wish to 1899 ignore the address even if present in order to work better in NAT 1900 environments. A failed match for either case generates a KRB_AP_ERR_BADADDR 1901 error. Recipients MAY wish to skip the address check as the KRB_CRED message 1902 cannot generally be reflected back toThe timestamp and usec fields (and the 1903 nonce field if required) are checked next. If the timestamp and usec are not 1904 present, or they are present but not current, the KRB_AP_ERR_SKEW error is 1905 generated. 1907 If all the checks succeed, the application stores each of the new tickets in 1908 its ticket cache together with the session key and other information in the 1909 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1910 message. 1912 3.7. User to User Authentication Exchanges 1914 (This entire subsection is new) User to User authentication provides a 1915 method to perform authentication when the verifier does not have a access to 1916 long term service key. This might be the case when running a server (for 1917 example a window server) as a user on a workstation. In such cases, the 1918 server may have access to the ticket granting ticket obtained when the user 1919 logged in to the workstation, but because the server is running as an 1920 unprivleged user it might not have access to system keys. Similar situations 1921 may arise when running peer-to-peer applications. 1923 Summary 1924 Message direction Message type Sections 1925 0. Message from application server Not Specified 1926 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 1927 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 1928 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 1930 To address this problem, the Kerberos protocol allows the client to request 1931 that the ticket issued by the KDC be encrypted using a session key a ticket 1932 granting ticket issued to the party that will verify the authentication. 1933 This ticket granting ticket must be obtained from the verifier by a means 1934 exchange external to the Kerberos protococl, usually as part of the 1935 application protocol. This message is shown in the summary above as message 1936 0. Note that because the ticket granting ticket is encrypted in the KDC's 1937 secret key, can not be used for authentication without posession of the 1938 corresponding secret key, and because the verifier does not give out the 1939 corresponding secret key, providing a copy of the verifiers ticket granting 1940 ticket does not allow impersonation of the verifier. 1942 Once the verifier's ticket granting ticket has been obtained by the client, 1943 by specifying the ENC-TKT-IN-SKEY option to the KDC, the client can include 1944 the ticket as an additional ticket in its KRB_TGS_REQ frequest to the KDC 1945 (message 1 in the table above). 1947 If validated according to the instructions in 3.3.3, the application ticket 1948 returned to the client (message 3 in the table above) will be encrypted 1949 using the session key from the additional ticket and the client will note 1950 this when it uses or stores the application ticket. 1952 When contacting the server using a ticket obtained for user to user 1953 authentication (message 3 in the table above), the client must specify the 1954 USE-SESSION-KEY flag in the ap-options field. This tells the application 1955 server to use the session key associated with its ticket granting ticket to 1956 decrypt the server ticket provided in the application request. 1958 4. Encryption and Checksum Specifications 1960 The Kerberos protocols described in this document are designed to encrypt 1961 messages of arbitrary sizes, using stream or block encryption ciphers. 1962 Encryption is used to prove the identities of the network entities 1963 participating in message exchanges. The Key Distribution Center for each 1964 realm is trusted by all principals registered in that realm to store a 1965 secret key in confidence. Proof of knowledge of this secret key is used to 1966 verify the authenticity of a principal. 1968 The KDC uses the principal's secret key (in the AS exchange) or a shared 1969 session key (in the TGS exchange) to encrypt responses to ticket requests; 1970 the ability to obtain the secret key or session key implies the knowledge of 1971 the appropriate keys and the identity of the KDC. The ability of a principal 1972 to decrypt the KDC response and present a Ticket and a properly formed 1973 Authenticator (generated with the session key from the KDC response) to a 1974 service verifies the identity of the principal; likewise the ability of the 1975 service to extract the session key from the Ticket and prove its knowledge 1976 thereof in a response verifies the identity of the service. 1978 [RFCEDITOR: Insert citation for KCRYPTO] defines a framework for defining 1979 encryption and checksum mechanisms for use with Kerberos. It also defines 1980 several such mechanisms, and more may be added in future updates to that 1981 document. 1983 The string-to-key operation provided by [KCRYPTO] is used to produce a 1984 long-term key for a principal (generally for a user). The default salt 1985 string, if none is provided via preauthentication data, is the concatenation 1986 of the principal's realm and name components, in order, with no separators. 1987 Unless otherwise indicated, the default string-to-key opaque parameter set 1988 as defined in [KCRYPTO] is used. 1990 Encrypted data, keys and checksums are transmitted using the EncryptedData, 1991 EncryptionKey and Checksum data objects defined in section 5.2.9. The 1992 encryption, decryption, and checksum operations described in this document 1993 use the corresponding encryption, decryption, and get_mic operations 1994 described in [KCRYPTO], with implicit "specific key" generation using the 1995 "key usage" values specified in the description of each EncryptedData or 1996 Checksum object to vary the key for each operation. Note that in some cases, 1997 the value to be used is dependent on the method of choosing the key or the 1998 context of the message. 2000 Key usages are unsigned 32 bit integers; zero is not permitted. The key 2001 usage values for encrypting or checksumming Kerberos messages are indicated 2002 in section 5 along with the message definitions. Key usage values 512-1023 2003 are reserved for uses internal to a Kerberos implementation. (For example, 2004 seeding a pseudo-random number generator with a value produced by encrypting 2005 something with a session key and a key usage value not used for any other 2006 purpose.) Key usage values between 1024 and 2047 (inclusive) are reserved 2007 for application use; applications should use even values for encryption and 2008 odd values for checksums within this range. Key usage values are also 2009 summarized in a table in section 8.4. 2011 There might exist other documents which define protocols in terms of the 2012 RFC1510 encryption types or checksum types. Such documents would not know 2013 about key usages. In order that these specifications continue to be 2014 meaningful until they are updated, key usages 1024 and 1025 must be used to 2015 derive keys for encryption and checksums, respectively. (Of course, this 2016 does not apply to protocols that do their own encryption independent of this 2017 framework, directly using the key resulting from the Kerberos authentication 2018 exchange.) New protocols defined in terms of the Kerberos encryption and 2019 checksum types should use their own key usage values. 2021 Unless otherwise indicated, no cipher state chaining is done from one 2022 encryption operation to another. 2024 Implementation note: While we don't recommend it, undoubtedly some 2025 application protocols will continue to use the key data directly, even if 2026 only in some of the currently existing protocol specifications. [4.1]. An 2027 implementation intended to support general Kerberos applications may 2028 therefore need to make the key data available, as well as the attributes and 2029 operations described in [KCRYPTO]. 2031 5. Message Specifications 2033 NOTE: The ASN.1 collected here should be identical to the contents of 2034 Appendix A. In case of conflict, the contents of Appendix A shall take 2035 precedence. 2037 The Kerberos protocol is defined here in terms of Abstract Syntax Notation 2038 One (ASN.1) [X680], which provides a syntax for specifying both the abstract 2039 layout of protocol messages as well as their encodings. Implementors not 2040 utilizing an existing ASN.1 compiler or support library are cautioned to 2041 thoroughly understand the actual ASN.1 specification to ensure correct 2042 implementation behavior, as there is more complexity in the notation than is 2043 immediately obvious, and some tutorials and guides to ASN.1 are misleading 2044 or erroneous. 2046 Note that in several places, there have been changes here from RFC 1510 that 2047 change the abstract types. This is in part to address widespread assumptions 2048 that various implementors have made, in some cases resulting in 2049 unintentional violations of the ASN.1 standard. These will be clearly 2050 flagged when they occur. The differences between the abstract types in RFC 2051 1510 and abstract types in this document can cause incompatible encodings to 2052 be emitted when certain encoding rules, e.g. the Packed Encoding Rules 2053 (PER), are used. This theoretical incompatibility should not be relevant for 2054 Kerberos, since Kerberos explicitly specifies the use of the Distinguished 2055 Encoding Rules (DER). It might be an issue for protocols wishing to use 2056 Kerberos types with other encoding rules. (This practice is not 2057 recommended.) With very few exceptions (most notably the usages of BIT 2058 STRING), the encodings resulting from using the DER remain identical between 2059 the types defined in RFC 1510 and the types defined in this document. 2061 The type definitions in this section assume an ASN.1 module definition of 2062 the following form: 2064 KerberosV5Spec2 { 2065 iso(1) identified-organization(3) dod(6) internet(1) 2066 security(5) kerberosV5(2) modules(4) krb5spec2(2) 2067 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2069 -- rest of definitions here 2071 END 2073 This specifies that the tagging context for the module will be explicit and 2074 non-automatic. 2076 Note that in some other publications [RFC1510] [RFC1964], the "dod" portion 2077 of the object identifier is erroneously specified as having the value "5". 2078 In the case of RFC 1964, use of the "correct" OID value would result in a 2079 change in the wire protocol; therefore, it remains unchanged for now. 2081 Note that elsewhere in this document, nomenclature for various message types 2082 is inconsistent, but seems to largely follow C language conventions, 2083 including use of underscore (_) characters and all-caps spelling of names 2084 intended to be numeric constants. Also, in some places, identifiers 2085 (especially ones refering to constants) are written in all-caps in order to 2086 distinguish them from surrounding explanatory text. 2088 The ASN.1 notation does not permit underscores in identifiers, so in actual 2089 ASN.1 definitions, underscores are replaced with hyphens (-). Additionally, 2090 structure member names and defined values in ASN.1 must begin with a 2091 lowercase letter, while type names must begin with an uppercase letter. 2093 5.1. Specific Compatibility Notes on ASN.1 2095 For compatibility purposes, implementors should heed the following specific 2096 notes regarding the use of ASN.1 in Kerberos. These notes do not describe 2097 deviations from standard usage of ASN.1. The purpose of these notes is to 2098 instead describe some historical quirks and non-compliance of various 2099 implementations, as well as historical ambiguities, which, while being valid 2100 ASN.1, can lead to confusion during implementation. 2102 5.1.1. ASN.1 Distinguished Encoding Rules 2104 The encoding of Kerberos protocol messages shall obey the Distinguished 2105 Encoding Rules (DER) of ASN.1 as described in [X690]. Some implementations 2106 (believed to be primarly ones derived from DCE 1.1 and earlier) are known to 2107 use the more general Basic Encoding Rules (BER); in particular, these 2108 implementations send indefinite encodings of lengths. Implementations may 2109 accept such encodings in the interests of backwards compatibility, though 2110 implementors are warned that decoding fully-general BER is fraught with 2111 peril. 2113 5.1.2. Optional Integer Fields 2115 Some implementations do not internally distinguish between an omitted 2116 optional integer value and a transmitted value of zero. The places in the 2117 protocol where this is relevant include various microseconds fields, nonces, 2118 and sequence numbers. Implementations should treat omitted optional integer 2119 values as having been transmitted with a value of zero, if the application 2120 is expecting this. 2122 5.1.3. Empty SEQUENCE OF Types 2124 There are places in the protocol where a message contains a SEQUENCE OF type 2125 as an optional member. This can result in an encoding that contains an empty 2126 SEQUENCE OF encoding. The Kerberos protocol does not semantically 2127 distinguish between an absent optional SEQUENCE OF type and a present 2128 optional but empty SEQUENCE OF type. Implementations should not send empty 2129 SEQUENCE OF encodings that are marked OPTIONAL, but should accept them as 2130 being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax describing 2131 Kerberos messages, instances of these problematic optional SEQUENCE OF types 2132 are indicated a comment. 2134 5.1.4. Unrecognized Tag Numbers 2136 Future revisions to this protocol may include new message types with 2137 different APPLICATION class tag numbers. Such revisions should protect older 2138 implementations by only sending the message types to parties that are known 2139 to understand them, e.g. by means of a flag bit set by the receiver in a 2140 preceding request. In the interest of robust error handling, implementations 2141 should gracefully handle receiving a message with an unrecognized tag 2142 anyway, and return an error message if appropriate. 2144 5.1.5. Tag Numbers Greater Than 30 2146 A naive implementation of a DER ASN.1 decoder may experience problems with 2147 ASN.1 tag numbers greater than 30, due to such tag numbers being encoded 2148 using more than one byte. Future revisions of this protocol may utilize tag 2149 numbers greater than 30, and implementations should be prepared to 2150 gracefully return an error, if appropriate, if they do not recognize the 2151 tag. 2153 5.2. Basic Kerberos Types 2155 This section defines a number of basic types that are potentially used in 2156 multiple Kerberos protocol messages. 2158 5.2.1. KerberosString 2160 The original specification of the Kerberos protocol in RFC 1510 uses 2161 GeneralString in numerous places for human-readable string data. Historical 2162 implementations of Kerberos cannot utilize the full power of GeneralString. 2163 This ASN.1 type requires the use of designation and invocation escape 2164 sequences as specified in ISO-2022/ECMA-35 to switch character sets, and the 2165 default character set that is designated as G0 is the ISO-646/ECMA-6 2166 International Reference Version (IRV) (aka U.S. ASCII), which mostly works. 2168 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) and two 2169 Control-function code elements (C0..C1). DER prohibits the designation of 2170 character sets as any but the G0 and C0 sets. Unfortunately, this seems to 2171 have the side effect of prohibiting the use of ISO-8859 (ISO Latin) 2172 character-sets or any other character-sets that utilize a 96-character set, 2173 since it is prohibited by ISO-2022/ECMA-35 to designate them as the G0 code 2174 element. This side effect is being investigated in the ASN.1 standards 2175 community. 2177 In practice, many implementations treat GeneralStrings as if they were 8-bit 2178 strings of whichever character set the implementation defaults to, without 2179 regard for correct usage of character-set designation escape sequences. The 2180 default character set is often determined by the current user's operating 2181 system dependent locale. At least one major implementation places unescaped 2182 UTF-8 encoded Unicode characters in the GeneralString. This failure to 2183 adhere to the GeneralString specifications results in interoperability 2184 issues when conflicting character encodings are utilized by the Kerberos 2185 clients, services, and KDC. 2187 This unfortunate situation is the result of improper documentation of the 2188 restrictions of the ASN.1 GeneralString type in prior Kerberos 2189 specifications. 2191 The new (post-RFC 1510) type KerberosString, defined below, is a 2192 GeneralString that is constrained to only contain characters in IA5String 2194 KerberosString ::= GeneralString (IA5String) 2196 US-ASCII control characters should in general not be used in KerberosString, 2197 except for cases such as newlines in lengthy error messages. Control 2198 characters should not be used in principal names or realm names. 2200 For compatibility, implementations may choose to accept GeneralString values 2201 that contain characters other than those permitted by IA5String, but they 2202 should be aware that character set designation codes will likely be absent, 2203 and that the encoding should probably be treated as locale-specific in 2204 almost every way. Implementations may also choose to emit GeneralString 2205 values that are beyond those permitted by IA5String, but should be aware 2206 that doing so is extraordinarily risky from an interoperability perspective. 2208 Some existing implementations use GeneralString to encode unescaped 2209 locale-specific characters. This is a violation of the ASN.1 standard. Most 2210 of these implementations encode US-ASCII in the left-hand half, so as long 2211 the implementation transmits only US-ASCII, the ASN.1 standard is not 2212 violated in this regard. As soon as such an implementation encodes unescaped 2213 locale-specific characters with the high bit set, it violates the ASN.1 2214 standard. 2216 Other implementations have been known to use GeneralString to contain a 2217 UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 is a 2218 different encoding, not a 94 or 96 character "G" set as defined by ISO 2022. 2219 It is believed that these implementations do not even use the ISO 2022 2220 escape sequence to change the character encoding. Even if implementations 2221 were to announce the change of encoding by using that escape sequence, the 2222 ASN.1 standard prohibits the use of any escape sequences other than those 2223 used to designate/invoke "G" or "C" sets allowed by GeneralString. 2225 Future revisions to this protocol will almost certainly allow for a more 2226 interoperable representation of principal names, probably including 2227 UTF8String. 2229 Note that applying a new constraint to a previously unconstrained type 2230 constitutes creation of a new ASN.1 type. In this particular case, the 2231 change does not result in a changed encoding under DER. 2233 5.2.2. Realm and PrincipalName 2235 Realm ::= KerberosString 2237 PrincipalName ::= SEQUENCE { 2238 name-type [0] Int32, 2239 name-string [1] SEQUENCE OF KerberosString 2240 } 2242 Kerberos realm names are encoded as KerberosStrings. Realms shall not 2243 contain a character with the code 0 (the ASCII NUL). Most realms will 2244 usually consist of several components separated by periods (.), in the style 2245 of Internet Domain Names, or separated by slashes (/) in the style of X.500 2246 names. Acceptable forms for realm names are specified in section 7. A 2247 PrincipalName is a typed sequence of components consisting of the following 2248 sub-fields: 2250 name-type 2251 This field specifies the type of name that follows. Pre-defined values 2252 for this field are specified in section 7.2. The name-type should be 2253 treated as a hint. Ignoring the name type, no two names can be the same 2254 (i.e. at least one of the components, or the realm, must be different). 2255 This constraint may be eliminated in the future. 2257 name-string 2258 This field encodes a sequence of components that form a name, each 2259 component encoded as a KerberosString. Taken together, a PrincipalName 2260 and a Realm form a principal identifier. Most PrincipalNames will have 2261 only a few components (typically one or two). 2263 5.2.3. KerberosTime 2265 KerberosTime ::= GeneralizedTime -- with no fractional seconds 2267 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 2268 KerberosTime value shall not include any fractional portions of the seconds. 2269 As required by the DER, it further shall not include any separators, and it 2270 shall specify the UTC time zone (Z). Example: The only valid format for UTC 2271 time 6 minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z. 2273 5.2.4. Constrained Integer types 2275 Some integer members of types should be constrained to values representable 2276 in 32 bits, for compatibility with reasonable implementation limits. 2278 Int32 ::= INTEGER (-2147483648..2147483647) 2279 -- signed values representable in 32 bits 2281 UInt32 ::= INTEGER (0..4294967295) 2282 -- unsigned 32 bit values 2284 Microseconds ::= INTEGER (0..999999) 2285 -- microseconds 2287 While this results in changes to the abstract types from the RFC 1510 2288 version, the encoding in DER should be unaltered. Historical implementations 2289 were typically limited to 32-bit integer values anyway, and assigned numbers 2290 should fall in the space of integer values representable in 32 bits in order 2291 to promote interoperability anyway. 2293 There are several integer fields in messages that are constrained to fixed 2294 values. 2296 pvno 2297 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always the 2298 constant integer 5. There is no easy way to make this field into a 2299 useful protocol version number, so its value is fixed. 2300 msg-type 2301 this integer field usually is identical to the application tag number 2302 of the containing message type. 2304 5.2.5. HostAddress and HostAddresses 2306 HostAddress ::= SEQUENCE { 2307 addr-type [0] Int32, 2308 address [1] OCTET STRING 2309 } 2311 -- NOTE: HostAddresses is always used as an OPTIONAL field and 2312 -- should not be empty. 2313 HostAddresses -- NOTE: subtly different from rfc1510, 2314 -- but has a value mapping and encodes the same 2315 ::= SEQUENCE OF HostAddress 2317 The host address encodings consists of two fields: 2319 addr-type 2320 This field specifies the type of address that follows. Pre-defined 2321 values for this field are specified in section 8.1. 2322 address 2323 This field encodes a single address of type addr-type. 2325 The two forms differ slightly. HostAddress contains exactly one address; 2326 HostAddresses contains a sequence of possibly many addresses. 2328 5.2.6. AuthorizationData 2330 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 2331 -- should not be empty. 2332 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2333 ad-type [0] Int32, 2334 ad-data [1] OCTET STRING 2335 } 2337 ad-data 2338 This field contains authorization data to be interpreted according to 2339 the value of the corresponding ad-type field. 2340 ad-type 2341 This field specifies the format for the ad-data subfield. All negative 2342 values are reserved for local use. Non-negative values are reserved for 2343 registered use. 2345 Each sequence of type and data is referred to as an authorization element. 2346 Elements may be application specific, however, there is a common set of 2347 recursive elements that should be understood by all implementations. These 2348 elements contain other elements embedded within them, and the interpretation 2349 of the encapsulating element determines which of the embedded elements must 2350 be interpreted, and which may be ignored. 2352 These common authorization data elements are recursivly defined, meaning the 2353 ad-data for these types will itself contain a sequence of authorization data 2354 whose interpretation is affected by the encapsulating element. Depending on 2355 the meaning of the encapsulating element, the encapsulated elements may be 2356 ignored, might be interpreted as issued directly by the KDC, or they might 2357 be stored in a separate plaintext part of the ticket. The types of the 2358 encapsulating elements are specified as part of the Kerberos specification 2359 because the behavior based on these values should be understood across 2360 implementations whereas other elements need only be understood by the 2361 applications which they affect. 2363 Authorization data elements are considered critical if present in a ticket 2364 or authenticator. Unless encapsulated in a known authorization data element 2365 amending the criticality of the elements it contains, if an unknown 2366 authorization data element type is received by a server either in an AP-REQ 2367 or in a ticket contained in an AP-REQ, then authentication SHOULD fail. 2368 Authorization data is intended to restrict the use of a ticket. If the 2369 service cannot determine whether the restriction applies to that service 2370 then a security weakness may result if the ticket can be used for that 2371 service. Authorization elements that are optional can be enclosed in 2372 AD-IF-RELEVANT element. 2374 In the definitions that follow, the value of the ad-type for the element 2375 will be specified as the least significant part of the subsection number, 2376 and the value of the ad-data will be as shown in the ASN.1 structure that 2377 follows the subsection heading. 2378 contents of ad-data ad-type 2380 DER encoding of AD-IF-RELEVANT 1 2382 DER encoding of AD-KDCIssued 4 2384 DER encoding of AD-OR 5 2386 DER encoding of AD-MANDATORY-FOR-KDC 8 2388 5.2.6.1. IF-RELEVANT 2390 AD-IF-RELEVANT ::= AuthorizationData 2392 AD elements encapsulated within the if-relevant element are intended for 2393 interpretation only by application servers that understand the particular 2394 ad-type of the embedded element. Application servers that do not understand 2395 the type of an element embedded within the if-relevant element may ignore 2396 the uninterpretable element. This element promotes interoperability across 2397 implementations which may have local extensions for authorization. 2399 5.2.6.4. KDCIssued 2401 AD-KDCIssued ::= SEQUENCE { 2402 ad-checksum [0] Checksum, 2403 i-realm [1] Realm OPTIONAL, 2404 i-sname [2] PrincipalName OPTIONAL, 2405 elements [3] AuthorizationData 2406 } 2408 ad-checksum 2409 A checksum over the elements field using a cryptographic checksum 2410 method that is identical to the checksum used to protect the ticket 2411 itself (i.e. using the same hash function and the same encryption 2412 algorithm used to encrypt the ticket) using the key used to protect the 2413 ticket, and a key usage value of 19. 2414 i-realm, i-sname 2415 The name of the issuing principal if different from the KDC itself. 2416 This field would be used when the KDC can verify the authenticity of 2417 elements signed by the issuing principal and it allows this KDC to 2418 notify the application server of the validity of those elements. 2419 elements 2420 A sequence of authorization data elements issued by the KDC. 2422 The KDC-issued ad-data field is intended to provide a means for Kerberos 2423 principal credentials to embed within themselves privilege attributes and 2424 other mechanisms for positive authorization, amplifying the priveleges of 2425 the principal beyond what can be done using a credentials without such an 2426 a-data element. 2428 This can not be provided without this element because the definition of the 2429 authorization-data field allows elements to be added at will by the bearer 2430 of a TGT at the time that they request service tickets and elements may also 2431 be added to a delegated ticket by inclusion in the authenticator. 2433 For KDC-issued elements this is prevented because the elements are signed by 2434 the KDC by including a checksum encrypted using the server's key (the same 2435 key used to encrypt the ticket - or a key derived from that key). Elements 2436 encapsulated with in the KDC-issued element will be ignored by the 2437 application server if this "signature" is not present. Further, elements 2438 encapsulated within this element from a ticket granting ticket may be 2439 interpreted by the KDC, and used as a basis according to policy for 2440 including new signed elements within derivative tickets, but they will not 2441 be copied to a derivative ticket directly. If they are copied directly to a 2442 derivative ticket by a KDC that is not aware of this element, the signature 2443 will not be correct for the application ticket elements, and the field will 2444 be ignored by the application server. 2446 This element and the elements it encapulates may be safely ignored by 2447 applications, application servers, and KDCs that do not implement this 2448 element. 2450 5.2.6.5. AND-OR 2452 AD-AND-OR ::= SEQUENCE { 2453 condition-count [0] INTEGER, 2454 elements [1] AuthorizationData 2455 } 2457 When restrictive AD elements are encapsulated within the and-or element are 2458 encountered, only the number specified in condition-count of the 2459 encapsulated conditions must be met in order to satisfy this element. This 2460 element may be used to implement an "or" operation by setting the 2461 condition-count field to 1, and it may specify an "and" operation by setting 2462 the condition count to the number of embedded elements. Application servers 2463 that do not implement this element must reject tickets that contain 2464 authorization data elements of this type. 2466 5.2.6.8. MANDATORY-FOR-KDC 2468 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2470 AD elements encapsulated within the mandatory-for-kdc element are to be 2471 interpreted by the KDC. KDCs that do not understand the type of an element 2472 embedded within the if-relevant element must reject the request. 2474 5.2.7. PA-DATA 2476 Historically, PA-DATA have been known as "pre-authentication data", meaning 2477 that they were used to augment the initial authentication with the KDC. 2478 Since that time, they have also been used as a typed hole with which to 2479 extend protocol exchanges with the KDC. 2481 PA-DATA ::= SEQUENCE { 2482 -- NOTE: first tag is [1], not [0] 2483 padata-type [1] Int32, 2484 padata-value [2] OCTET STRING -- might be encoded AP-REQ 2485 } 2487 padata-type 2488 indicates the way that the padata-value element is to be interpreted. 2489 Negative values of padata-type are reserved for unregistered use; 2490 non-negative values are used for a registered interpretation of the 2491 element type. 2492 padata-value 2493 Usually contains the DER encoding of another type; the padata-type 2494 field identifies which type is encoded here. 2496 padata-type name contents of padata-value 2498 1 pa-tgs-req DER encoding of AP-REQ 2500 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 2502 3 pa-pw-salt salt (not ASN.1 encoded) 2504 11 pa-etype-info DER encoding of PA-ETYPE-INFO 2506 19 pa-etype-info2 DER encoding of PA-ETYPE-INFO2 2508 This field may also contain information needed by certain extensions to the 2509 Kerberos protocol. For example, it might be used to initially verify the 2510 identity of a client before any response is returned. 2512 The padata field can also contain information needed to help the KDC or the 2513 client select the key needed for generating or decrypting the response. This 2514 form of the padata is useful for supporting the use of certain token cards 2515 with Kerberos. The details of such extensions are specified in separate 2516 documents. See [Pat92] for additional uses of this field. 2518 5.2.7.1. PA-TGS-REQ 2520 In the case of requests for additional tickets (KRB_TGS_REQ), padata-value 2521 will contain an encoded AP-REQ. The checksum in the authenticator (which 2522 must be collision-proof) is to be computed over the KDC-REQ-BODY encoding. 2524 5.2.7.2. Encrypted Timestamp Pre-authentication 2526 There are pre-authentication types that may be used to pre-authenticate a 2527 client by means of an encrypted timestamp. 2529 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 2531 PA-ENC-TS-ENC ::= SEQUENCE { 2532 patimestamp [0] KerberosTime -- client's time --, 2533 pausec [1] Microseconds OPTIONAL 2534 } 2536 Patimestamp contains the client's time, and pausec contains the 2537 microseconds, which may be omitted if a client will not generate more than 2538 one request per second. The ciphertext (padata-value) consists of the 2539 PA-ENC-TS-ENC encoding, encrypted using the client's secret key and a key 2540 usage value of 1. 2542 This preauthentication type was not present in RFC 1510, but many 2543 implementations support it. 2545 5.2.7.3. PA-PW-SALT 2547 The padata-value for this preauthentication type contains the salt for the 2548 string-to-key to be used by the client to obtain the key for decrypting the 2549 encrypted part of an AS-REP message. Unfortunately, for historical reasons, 2550 the character set to be used is unspecified and probably locale-specific. 2552 This preauthentication type was not present in RFC 1510, but many 2553 implementations support it. It is necessary in any case where the salt for 2554 the string-to-key algorithm is not the default. 2556 In the trivial example, a zero-length salt string is very commonplace for 2557 realms that have converted their principal databases from Kerberos 4. 2559 A KDC should not send PA-PW-SALT when issuing a KRB-ERROR message that 2560 requests additional preauthentication. Implementation note: some KDC 2561 implementations issue an erroneous PA-PW-SALT when issuing a KRB-ERROR 2562 message that requests additional preauthentication. Therefore, clients 2563 should ignore a PA-PW-SALT accompanying a KRB-ERROR message that requests 2564 additional preauthentication. 2566 5.2.7.4. PA-ETYPE-INFO 2568 The ETYPE-INFO preauthentication type is sent by the KDC in a KRB-ERROR 2569 indicating a requirement for additional preauthentication. It is usually 2570 used to notify a client of which key to use for the encryption of an 2571 encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP 2572 preauthentication value. It may also be sent in an AS-REP to provide 2573 information to the client about which key salt to use for the string-to-key 2574 to be used by the client to obtain the key for decrypting the encrypted part 2575 the AS-REP. 2577 ETYPE-INFO-ENTRY ::= SEQUENCE { 2578 etype [0] Int32, 2579 salt [1] OCTET STRING OPTIONAL 2580 } 2582 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 2584 The salt, like that of PA-PW-SALT, is also completely unspecified with 2585 respect to character set and is probably locale-specific. 2587 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one 2588 ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in the 2589 AS-REP. 2591 This preauthentication type was not present in RFC 1510, but many 2592 implementations that support encrypted timestamps for preauthentication need 2593 to support ETYPE-INFO as well. 2595 5.2.7.5. PA-ETYPE-INFO2 2597 The ETYPE-INFO2 preauthentication type is sent by the KDC in a KRB-ERROR 2598 indicating a requirement for additional preauthentication. It is usually 2599 used to notify a client of which key to use for the encryption of an 2600 encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP 2601 preauthentication value. It may also be sent in an AS-REP to provide 2602 information to the client about which key salt to use for the string-to-key 2603 to be used by the client to obtain the key for decrypting the encrypted part 2604 the AS-REP. 2606 ETYPE-INFO2-ENTRY ::= SEQUENCE { 2607 etype [0] Int32, 2608 salt [1] KerberosString OPTIONAL, 2609 s2kparams [2] OCTET STRING OPTIONAL 2610 } 2612 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY 2614 The type of the salt is KerberosString, but existing installations might 2615 have locale-specific characters stored in salt strings, and implementors may 2616 choose to handle them. 2618 The interpretation of s2kparams is specified in the cryptosystem description 2619 associated with the etype. Each cryptosystem has a default interpretation of 2620 s2kparams that will hold if that element is omitted from the encoding of 2621 ETYPE-INFO2-ENTRY. 2623 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one 2624 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in the 2625 AS-REP. 2627 The preferred ordering of preauthentication data that modify client key 2628 selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by PW-SALT. A 2629 KDC shall send all of these preauthentication data that it supports, in the 2630 preferred ordering, when issuing an AS-REP or when issuing a KRB-ERROR 2631 requesting additional preauthentication. 2633 The ETYPE-INFO2 preauthentication type was not present in RFC 1510. 2635 5.2.8. KerberosFlags 2637 For several message types, a specific constrained bit string type, 2638 KerberosFlags, is used. 2640 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 2641 -- shall be sent, but no fewer than 32 2643 Compatibility note: the following paragraphs describe a change from the 2644 RFC1510 description of bit strings that would result in incompatility in the 2645 case of an implementation that strictly conformed to ASN.1 DER and RFC1510. 2647 ASN.1 bit strings have multiple uses. The simplest use of a bit string is to 2648 contain a vector of bits, with no particular meaning attached to individual 2649 bits. This vector of bits is not necessarily a multiple of eight bits long. 2650 The use in Kerberos of a bit string as a compact boolean vector wherein each 2651 element has a distinct meaning poses some problems. The natural notation for 2652 a compact boolean vector is the ASN.1 "NamedBit" notation, and the DER 2653 require that encodings of a bit string using "NamedBit" notation exclude any 2654 trailing zero bits. This truncation is easy to neglect, especially given C 2655 language implementations that may naturally choose to store boolean vectors 2656 as 32 bit integers. 2658 For example, if the notation for KDCOptions were to include the "NamedBit" 2659 notation, as in RFC 1510, and a KDCOptions value to be encoded had only the 2660 "forwardable" (bit number one) bit set, the DER encoding must only include 2661 two bits: the first reserved bit ("reserved", bit number zero, value zero) 2662 and the one-valued bit (bit number one) for "forwardable". 2664 Most existing implementations of Kerberos unconditionally send 32 bits on 2665 the wire when encoding bit strings used as boolean vectors. This behavior 2666 violates the ASN.1 syntax used for flag values in RFC 1510, but occurs on 2667 such a widely installed base that the protocol description is being modified 2668 to accomodate it. 2670 Consequently, this document removes the "NamedBit" notations for individual 2671 bits, relegating them to comments. The size constraint on the KerberosFlags 2672 type requires that at least 32 bits be encoded at all times, though a 2673 lenient implementation may choose to accept fewer than 32 bits and to treat 2674 the missing bits as set to zero. 2676 Currently, no uses of KerberosFlags specify more than 32 bits worth of 2677 flags, although future revisions of this document may do so. When more than 2678 32 bits are to be transmitted in a KerberosFlags value, future revisions to 2679 this document will likely specify that the smallest number of bits needed to 2680 encode the highest-numbered one-valued bit should be sent. This is somewhat 2681 similar to the DER encoding of a bit string that is declared with the 2682 "NamedBit" notation. 2684 5.2.9. Cryptosystem-related Types 2686 Many Kerberos protocol messages contain an EncryptedData as a container for 2687 arbitrary encrypted data, which is often the encrypted encoding of another 2688 data type. Fields within EncryptedData assist the recipient in selecting a 2689 key with which to decrypt the enclosed data. 2691 EncryptedData ::= SEQUENCE { 2692 etype [0] Int32 -- EncryptionType --, 2693 kvno [1] UInt32 OPTIONAL, 2694 cipher [2] OCTET STRING -- ciphertext 2695 } 2697 etype 2698 This field identifies which encryption algorithm was used to encipher 2699 the cipher. 2700 kvno 2701 This field contains the version number of the key under which data is 2702 encrypted. It is only present in messages encrypted under long lasting 2703 keys, such as principals' secret keys. 2704 cipher 2705 This field contains the enciphered text, encoded as an OCTET STRING. 2706 (Note that the encryption mechanisms defined in [KCRYPTO] must 2707 incorporate integrity protection as well, so no additional checksum is 2708 required.) 2710 The EncryptionKey type is the means by which cryptographic keys used for 2711 encryption are transfered. 2713 EncryptionKey ::= SEQUENCE { 2714 keytype [0] Int32 -- actually encryption type --, 2715 keyvalue [1] OCTET STRING 2716 } 2718 keytype 2719 This field specifies the encryption type of the encryption key that 2720 follows in the keyvalue field. While its name is "keytype", it actually 2721 specifies an encryption type. Previously, multiple cryptosystems that 2722 performed encryption differently but were capable of using keys with 2723 the same characteristics were permitted to share an assigned number to 2724 designate the type of key; this usage is now deprecated. 2725 keyvalue 2726 This field contains the key itself, encoded as an octet string. 2728 Messages containing cleartext data to be authenticated will usually do so by 2729 using a member of type Checksum. Most instances of Checksum use a keyed 2730 hash, though exceptions will be noted. 2732 Checksum ::= SEQUENCE { 2733 cksumtype [0] Int32, 2734 checksum [1] OCTET STRING 2735 } 2737 cksumtype 2738 This field indicates the algorithm used to generate the accompanying 2739 checksum. 2740 checksum 2741 This field contains the checksum itself, encoded as an octet string. 2743 See section 4 for a brief description of the use of encryption and checksums 2744 in Kerberos. 2746 5.3. Tickets 2748 This section describes the format and encryption parameters for tickets and 2749 authenticators. When a ticket or authenticator is included in a protocol 2750 message it is treated as an opaque object. A ticket is a record that helps a 2751 client authenticate to a service. A Ticket contains the following 2752 information: 2754 Ticket ::= [APPLICATION 1] SEQUENCE { 2755 tkt-vno [0] INTEGER (5), 2756 realm [1] Realm, 2757 sname [2] PrincipalName, 2758 enc-part [3] EncryptedData -- EncTicketPart 2759 } 2761 -- Encrypted part of ticket 2762 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2763 flags [0] TicketFlags, 2764 key [1] EncryptionKey, 2765 crealm [2] Realm, 2766 cname [3] PrincipalName, 2767 transited [4] TransitedEncoding, 2768 authtime [5] KerberosTime, 2769 starttime [6] KerberosTime OPTIONAL, 2770 endtime [7] KerberosTime, 2771 renew-till [8] KerberosTime OPTIONAL, 2772 caddr [9] HostAddresses OPTIONAL, 2773 authorization-data [10] AuthorizationData OPTIONAL 2774 } 2776 -- encoded Transited field 2777 TransitedEncoding ::= SEQUENCE { 2778 tr-type [0] Int32 -- must be registered --, 2779 contents [1] OCTET STRING 2780 } 2781 TicketFlags ::= KerberosFlags 2782 -- reserved(0), 2783 -- forwardable(1), 2784 -- forwarded(2), 2785 -- proxiable(3), 2786 -- proxy(4), 2787 -- may-postdate(5), 2788 -- postdated(6), 2789 -- invalid(7), 2790 -- renewable(8), 2791 -- initial(9), 2792 -- pre-authent(10), 2793 -- hw-authent(11), 2794 -- the following are new since 1510 2795 -- transited-policy-checked(12), 2796 -- ok-as-delegate(13) 2798 tkt-vno 2799 This field specifies the version number for the ticket format. This 2800 document describes version number 5. 2801 realm 2802 This field specifies the realm that issued a ticket. It also serves to 2803 identify the realm part of the server's principal identifier. Since a 2804 Kerberos server can only issue tickets for servers within its realm, 2805 the two will always be identical. 2806 sname 2807 This field specifies all components of the name part of the server's 2808 identity, including those parts that identify a specific instance of a 2809 service. 2810 enc-part 2811 This field holds the encrypted encoding of the EncTicketPart sequence. 2812 It is encrypted in the key shared by Kerberos and the end server (the 2813 server's secret key), using a key usage value of 2. 2814 flags 2815 This field indicates which of various options were used or requested 2816 when the ticket was issued. The meanings of the flags are: 2817 Bit(s) Name Description 2819 0 reserved Reserved for future expansion of this 2820 field. 2822 The FORWARDABLE flag is normally only 2823 interpreted by the TGS, and can be 2824 ignored by end servers. When set, this 2825 1 forwardable flag tells the ticket-granting server 2826 that it is OK to issue a new 2827 ticket-granting ticket with a 2828 different network address based on the 2829 presented ticket. 2831 When set, this flag indicates that the 2832 ticket has either been forwarded or 2833 2 forwarded was issued based on authentication 2834 involving a forwarded ticket-granting 2835 ticket. 2837 The PROXIABLE flag is normally only 2838 interpreted by the TGS, and can be 2839 ignored by end servers. The PROXIABLE 2840 flag has an interpretation identical 2841 3 proxiable to that of the FORWARDABLE flag, 2842 except that the PROXIABLE flag tells 2843 the ticket-granting server that only 2844 non-ticket-granting tickets may be 2845 issued with different network 2846 addresses. 2848 4 proxy When set, this flag indicates that a 2849 ticket is a proxy. 2851 The MAY-POSTDATE flag is normally only 2852 interpreted by the TGS, and can be 2853 5 may-postdate ignored by end servers. This flag 2854 tells the ticket-granting server that 2855 a post-dated ticket may be issued 2856 based on this ticket-granting ticket. 2858 This flag indicates that this ticket 2859 has been postdated. The end-service 2860 6 postdated can check the authtime field to see 2861 when the original authentication 2862 occurred. 2864 This flag indicates that a ticket is 2865 invalid, and it must be validated by 2866 7 invalid the KDC before use. Application 2867 servers must reject tickets which have 2868 this flag set. 2870 The RENEWABLE flag is normally only 2871 interpreted by the TGS, and can 2872 usually be ignored by end servers 2873 8 renewable (some particularly careful servers may 2874 wish to disallow renewable tickets). A 2875 renewable ticket can be used to obtain 2876 a replacement ticket that expires at a 2877 later date. 2879 This flag indicates that this ticket 2880 9 initial was issued using the AS protocol, and 2881 not issued based on a ticket-granting 2882 ticket. 2884 This flag indicates that during 2885 initial authentication, the client was 2886 authenticated by the KDC before a 2887 10 pre-authent ticket was issued. The strength of the 2888 preauthentication method is not 2889 indicated, but is acceptable to the 2890 KDC. 2892 This flag indicates that the protocol 2893 employed for initial authentication 2894 required the use of hardware expected 2895 11 hw-authent to be possessed solely by the named 2896 client. The hardware authentication 2897 method is selected by the KDC and the 2898 strength of the method is not 2899 indicated. 2901 This flag indicates that the KDC for 2902 the realm has checked the transited 2903 field against a realm defined policy 2904 for trusted certifiers. If this flag 2905 is reset (0), then the application 2906 server must check the transited field 2907 itself, and if unable to do so it must 2908 reject the authentication. If the flag 2909 12 transited- is set (1) then the application server 2910 policy-checked 2911 may skip its own validation of the 2912 transited field, relying on the 2913 validation performed by the KDC. At 2914 its option the application server may 2915 still apply its own validation based 2916 on a separate policy for acceptance. 2918 This flag is new since RFC 1510. 2920 This flag indicates that the server 2921 (not the client) specified in the 2922 ticket has been determined by policy 2923 of the realm to be a suitable 2924 recipient of delegation. A client can 2925 use the presence of this flag to help 2926 it make a decision whether to delegate 2927 credentials (either grant a proxy or a 2928 forwarded ticket granting ticket) to 2929 13 ok-as-delegate this server. The client is free to 2930 ignore the value of this flag. When 2931 setting this flag, an administrator 2932 should consider the Security and 2933 placement of the server on which the 2934 service will run, as well as whether 2935 the service requires the use of 2936 delegated credentials. 2938 This flag is new since RFC 1510. 2940 14-31 reserved Reserved for future use. 2942 key 2943 This field exists in the ticket and the KDC response and is used to 2944 pass the session key from Kerberos to the application server and the 2945 client. 2946 crealm 2947 This field contains the name of the realm in which the client is 2948 registered and in which initial authentication took place. 2949 cname 2950 This field contains the name part of the client's principal identifier. 2951 transited 2952 This field lists the names of the Kerberos realms that took part in 2953 authenticating the user to whom this ticket was issued. It does not 2954 specify the order in which the realms were transited. See section 2955 3.3.3.2 for details on how this field encodes the traversed realms. 2956 When the names of CA's are to be embedded in the transited field (as 2957 specified for some extensions to the protocol), the X.500 names of the 2958 CA's should be mapped into items in the transited field using the 2959 mapping defined by RFC2253. 2960 authtime 2961 This field indicates the time of initial authentication for the named 2962 principal. It is the time of issue for the original ticket on which 2963 this ticket is based. It is included in the ticket to provide 2964 additional information to the end service, and to provide the necessary 2965 information for implementation of a `hot list' service at the KDC. An 2966 end service that is particularly paranoid could refuse to accept 2967 tickets for which the initial authentication occurred "too far" in the 2968 past. This field is also returned as part of the response from the KDC. 2969 When returned as part of the response to initial authentication 2970 (KRB_AS_REP), this is the current time on the Kerberos server[24]. 2971 starttime 2972 This field in the ticket specifies the time after which the ticket is 2973 valid. Together with endtime, this field specifies the life of the 2974 ticket. If it is absent from the ticket, its value should be treated as 2975 that of the authtime field. 2976 endtime 2977 This field contains the time after which the ticket will not be honored 2978 (its expiration time). Note that individual services may place their 2979 own limits on the life of a ticket and may reject tickets which have 2980 not yet expired. As such, this is really an upper bound on the 2981 expiration time for the ticket. 2982 renew-till 2983 This field is only present in tickets that have the RENEWABLE flag set 2984 in the flags field. It indicates the maximum endtime that may be 2985 included in a renewal. It can be thought of as the absolute expiration 2986 time for the ticket, including all renewals. 2988 caddr 2989 This field in a ticket contains zero (if omitted) or more (if present) 2990 host addresses. These are the addresses from which the ticket can be 2991 used. If there are no addresses, the ticket can be used from any 2992 location. The decision by the KDC to issue or by the end server to 2993 accept zero-address tickets is a policy decision and is left to the 2994 Kerberos and end-service administrators; they may refuse to issue or 2995 accept such tickets. The suggested and default policy, however, is that 2996 such tickets will only be issued or accepted when additional 2997 information that can be used to restrict the use of the ticket is 2998 included in the authorization_data field. Such a ticket is a 2999 capability. 3001 Network addresses are included in the ticket to make it harder for an 3002 attacker to use stolen credentials. Because the session key is not sent 3003 over the network in cleartext, credentials can't be stolen simply by 3004 listening to the network; an attacker has to gain access to the session 3005 key (perhaps through operating system security breaches or a careless 3006 user's unattended session) to make use of stolen tickets. 3008 It is important to note that the network address from which a 3009 connection is received cannot be reliably determined. Even if it could 3010 be, an attacker who has compromised the client's workstation could use 3011 the credentials from there. Including the network addresses only makes 3012 it more difficult, not impossible, for an attacker to walk off with 3013 stolen credentials and then use them from a "safe" location. 3014 authorization-data 3015 The authorization-data field is used to pass authorization data from 3016 the principal on whose behalf a ticket was issued to the application 3017 service. If no authorization data is included, this field will be left 3018 out. Experience has shown that the name of this field is confusing, and 3019 that a better name for this field would be restrictions. Unfortunately, 3020 it is not possible to change the name of this field at this time. 3022 This field contains restrictions on any authority obtained on the basis 3023 of authentication using the ticket. It is possible for any principal in 3024 posession of credentials to add entries to the authorization data field 3025 since these entries further restrict what can be done with the ticket. 3026 Such additions can be made by specifying the additional entries when a 3027 new ticket is obtained during the TGS exchange, or they may be added 3028 during chained delegation using the authorization data field of the 3029 authenticator. 3031 Because entries may be added to this field by the holder of 3032 credentials, except when an entry is separately authenticated by 3033 encapsulation in the kdc-issued element, it is not allowable for the 3034 presence of an entry in the authorization data field of a ticket to 3035 amplify the privileges one would obtain from using a ticket. 3037 The data in this field may be specific to the end service; the field 3038 will contain the names of service specific objects, and the rights to 3039 those objects. The format for this field is described in section 5.2. 3040 Although Kerberos is not concerned with the format of the contents of 3041 the sub-fields, it does carry type information (ad-type). 3043 By using the authorization_data field, a principal is able to issue a 3044 proxy that is valid for a specific purpose. For example, a client 3045 wishing to print a file can obtain a file server proxy to be passed to 3046 the print server. By specifying the name of the file in the 3047 authorization_data field, the file server knows that the print server 3048 can only use the client's rights when accessing the particular file to 3049 be printed. 3051 A separate service providing authorization or certifying group 3052 membership may be built using the authorization-data field. In this 3053 case, the entity granting authorization (not the authorized entity), 3054 may obtain a ticket in its own name (e.g. the ticket is issued in the 3055 name of a privilege server), and this entity adds restrictions on its 3056 own authority and delegates the restricted authority through a proxy to 3057 the client. The client would then present this authorization credential 3058 to the application server separately from the authentication exchange. 3059 Alternatively, such authorization credentials may be embedded in the 3060 ticket authenticating the authorized entity, when the authorization is 3061 separately authenticated using the kdc-issued authorization data 3062 element (see B.4). 3064 Similarly, if one specifies the authorization-data field of a proxy and 3065 leaves the host addresses blank, the resulting ticket and session key 3066 can be treated as a capability. See [Neu93] for some suggested uses of 3067 this field. 3069 The authorization-data field is optional and does not have to be 3070 included in a ticket. 3072 5.4. Specifications for the AS and TGS exchanges 3074 This section specifies the format of the messages used in the exchange 3075 between the client and the Kerberos server. The format of possible error 3076 messages appears in section 5.9.1. 3078 5.4.1. KRB_KDC_REQ definition 3080 The KRB_KDC_REQ message has no application tag number of its own. Instead, 3081 it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, which each have an 3082 application tag, depending on whether the request is for an initial ticket 3083 or an additional ticket. In either case, the message is sent from the client 3084 to the KDC to request credentials for a service. 3086 The message fields are: 3088 AS-REQ ::= [APPLICATION 10] KDC-REQ 3090 TGS-REQ ::= [APPLICATION 12] KDC-REQ 3092 KDC-REQ ::= SEQUENCE { 3093 -- NOTE: first tag is [1], not [0] 3094 pvno [1] INTEGER (5) , 3095 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 3096 padata [3] SEQUENCE OF PA-DATA OPTIONAL 3097 -- NOTE: not empty --, 3098 req-body [4] KDC-REQ-BODY 3099 } 3101 KDC-REQ-BODY ::= SEQUENCE { 3102 kdc-options [0] KDCOptions, 3103 cname [1] PrincipalName OPTIONAL 3104 -- Used only in AS-REQ --, 3105 realm [2] Realm 3106 -- Server's realm 3107 -- Also client's in AS-REQ --, 3108 sname [3] PrincipalName OPTIONAL, 3109 from [4] KerberosTime OPTIONAL, 3110 till [5] KerberosTime, 3111 rtime [6] KerberosTime OPTIONAL, 3112 nonce [7] UInt32, 3113 etype [8] SEQUENCE OF Int32 -- EncryptionType 3114 -- in preference order --, 3115 addresses [9] HostAddresses OPTIONAL, 3116 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 3117 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3118 -- NOTE: not empty 3119 } 3120 KDCOptions ::= KerberosFlags 3121 -- reserved(0), 3122 -- forwardable(1), 3123 -- forwarded(2), 3124 -- proxiable(3), 3125 -- proxy(4), 3126 -- allow-postdate(5), 3127 -- postdated(6), 3128 -- unused7(7), 3129 -- renewable(8), 3130 -- unused9(9), 3131 -- unused10(10), 3132 -- opt-hardware-auth(11), 3133 -- unused12(12), 3134 -- unused13(13), 3135 -- 15 is reserved for canonicalize 3136 -- unused15(15), 3137 -- 26 was unused in 1510 3138 -- disable-transited-check(26), 3139 -- 3140 -- renewable-ok(27), 3141 -- enc-tkt-in-skey(28), 3142 -- renew(30), 3143 -- validate(31) 3145 The fields in this message are: 3147 pvno 3148 This field is included in each message, and specifies the protocol 3149 version number. This document specifies protocol version 5. 3150 msg-type 3151 This field indicates the type of a protocol message. It will almost 3152 always be the same as the application identifier associated with a 3153 message. It is included to make the identifier more readily accessible 3154 to the application. For the KDC-REQ message, this type will be 3155 KRB_AS_REQ or KRB_TGS_REQ. 3156 padata 3157 Contains pre-authentication data. Requests for additional tickets 3158 (KRB_TGS_REQ) must contain a padata of PA-TGS-REQ. 3160 The padata (pre-authentication data) field contains a sequence of 3161 authentication information which may be needed before credentials can 3162 be issued or decrypted. In most requests for initial authentication 3163 (KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left 3164 out. 3165 req-body 3166 This field is a placeholder delimiting the extent of the remaining 3167 fields. If a checksum is to be calculated over the request, it is 3168 calculated over an encoding of the KDC-REQ-BODY sequence which is 3169 enclosed within the req-body field. 3171 kdc-options 3172 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 3173 KDC and indicates the flags that the client wants set on the tickets as 3174 well as other information that is to modify the behavior of the KDC. 3175 Where appropriate, the name of an option may be the same as the flag 3176 that is set by that option. Although in most case, the bit in the 3177 options field will be the same as that in the flags field, this is not 3178 guaranteed, so it is not acceptable to simply copy the options field to 3179 the flags field. There are various checks that must be made before 3180 honoring an option anyway. 3182 The kdc_options field is a bit-field, where the selected options are 3183 indicated by the bit being set (1), and the unselected options and 3184 reserved fields being reset (0). The encoding of the bits is specified 3185 in section 5.2. The options are described in more detail above in 3186 section 2. The meanings of the options are: 3187 Bits Name Description 3189 0 RESERVED Reserved for future expansion of 3190 this field. 3192 The FORWARDABLE option indicates 3193 that the ticket to be issued is to 3194 have its forwardable flag set. It 3195 1 FORWARDABLE may only be set on the initial 3196 request, or in a subsequent request 3197 if the ticket-granting ticket on 3198 which it is based is also 3199 forwardable. 3201 The FORWARDED option is only 3202 specified in a request to the 3203 ticket-granting server and will only 3204 be honored if the ticket-granting 3205 ticket in the request has its 3206 2 FORWARDED FORWARDABLE bit set. This option 3207 indicates that this is a request for 3208 forwarding. The address(es) of the 3209 host from which the resulting ticket 3210 is to be valid are included in the 3211 addresses field of the request. 3213 The PROXIABLE option indicates that 3214 the ticket to be issued is to have 3215 its proxiable flag set. It may only 3216 3 PROXIABLE be set on the initial request, or in 3217 a subsequent request if the 3218 ticket-granting ticket on which it 3219 is based is also proxiable. 3221 The PROXY option indicates that this 3222 is a request for a proxy. This 3223 option will only be honored if the 3224 ticket-granting ticket in the 3225 4 PROXY request has its PROXIABLE bit set. 3226 The address(es) of the host from 3227 which the resulting ticket is to be 3228 valid are included in the addresses 3229 field of the request. 3231 The ALLOW-POSTDATE option indicates 3232 that the ticket to be issued is to 3233 have its MAY-POSTDATE flag set. It 3234 5 ALLOW-POSTDATE may only be set on the initial 3235 request, or in a subsequent request 3236 if the ticket-granting ticket on 3237 which it is based also has its 3238 MAY-POSTDATE flag set. 3240 The POSTDATED option indicates that 3241 this is a request for a postdated 3242 ticket. This option will only be 3243 honored if the ticket-granting 3244 ticket on which it is based has its 3245 6 POSTDATED MAY-POSTDATE flag set. The resulting 3246 ticket will also have its INVALID 3247 flag set, and that flag may be reset 3248 by a subsequent request to the KDC 3249 after the starttime in the ticket 3250 has been reached. 3252 7 UNUSED This option is presently unused. 3254 The RENEWABLE option indicates that 3255 the ticket to be issued is to have 3256 its RENEWABLE flag set. It may only 3257 be set on the initial request, or 3258 when the ticket-granting ticket on 3259 8 RENEWABLE which the request is based is also 3260 renewable. If this option is 3261 requested, then the rtime field in 3262 the request contains the desired 3263 absolute expiration time for the 3264 ticket. 3266 9 RESERVED Reserved for PK-Cross 3268 These options are presently unused. 3269 10-13 UNUSED Option 11 is reserved for future is 3270 as opt-hardware-auth. 3272 14-25 RESERVED Reserved for future use. 3274 By default the KDC will check the 3275 transited field of a 3276 ticket-granting-ticket against the 3277 policy of the local realm before it 3278 will issue derivative tickets based 3279 on the ticket granting ticket. If 3280 this flag is set in the request, 3281 checking of the transited field is 3282 disabled. Tickets issued without the 3283 26 DISABLE-TRANSITED-CHECK performance of this check will be 3284 noted by the reset (0) value of the 3285 TRANSITED-POLICY-CHECKED flag, 3286 indicating to the application server 3287 that the tranisted field must be 3288 checked locally. KDC's are 3289 encouraged but not required to honor 3290 the DISABLE-TRANSITED-CHECK option. 3292 This flag is new since RFC 1510 3294 The RENEWABLE-OK option indicates 3295 that a renewable ticket will be 3296 acceptable if a ticket with the 3297 requested life cannot otherwise be 3298 provided. If a ticket with the 3299 requested life cannot be provided, 3300 27 RENEWABLE-OK then a renewable ticket may be 3301 issued with a renew-till equal to 3302 the the requested endtime. The value 3303 of the renew-till field may still be 3304 limited by local limits, or limits 3305 selected by the individual principal 3306 or server. 3308 This option is used only by the 3309 ticket-granting service. The 3310 ENC-TKT-IN-SKEY option indicates 3311 28 ENC-TKT-IN-SKEY that the ticket for the end server 3312 is to be encrypted in the session 3313 key from the additional 3314 ticket-granting ticket provided. 3316 29 RESERVED Reserved for future use. 3318 This option is used only by the 3319 ticket-granting service. The RENEW 3320 option indicates that the present 3321 request is for a renewal. The ticket 3322 provided is encrypted in the secret 3323 key for the server on which it is 3324 30 RENEW valid. This option will only be 3325 honored if the ticket to be renewed 3326 has its RENEWABLE flag set and if 3327 the time in its renew-till field has 3328 not passed. The ticket to be renewed 3329 is passed in the padata field as 3330 part of the authentication header. 3332 This option is used only by the 3333 ticket-granting service. The 3334 VALIDATE option indicates that the 3335 request is to validate a postdated 3336 ticket. It will only be honored if 3337 the ticket presented is postdated, 3338 presently has its INVALID flag set, 3339 31 VALIDATE and would be otherwise usable at 3340 this time. A ticket cannot be 3341 validated before its starttime. The 3342 ticket presented for validation is 3343 encrypted in the key of the server 3344 for which it is valid and is passed 3345 in the padata field as part of the 3346 authentication header. 3347 cname and sname 3348 These fields are the same as those described for the ticket in section 3349 5.3. sname may only be absent when the ENC-TKT-IN-SKEY option is 3350 specified. If absent, the name of the server is taken from the name of 3351 the client in the ticket passed as additional-tickets. 3352 enc-authorization-data 3353 The enc-authorization-data, if present (and it can only be present in 3354 the TGS_REQ form), is an encoding of the desired authorization-data 3355 encrypted under the sub-session key if present in the Authenticator, or 3356 alternatively from the session key in the ticket-granting ticket, both 3357 from the padata field in the KRB_AP_REQ. The key usage value used when 3358 encrypting is 5 if a sub-session key is used, or 4 if the session key 3359 is used. 3360 realm 3361 This field specifies the realm part of the server's principal 3362 identifier. In the AS exchange, this is also the realm part of the 3363 client's principal identifier. 3364 from 3365 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3366 requests when the requested ticket is to be postdated. It specifies the 3367 desired start time for the requested ticket. If this field is omitted 3368 then the KDC should use the current time instead. 3369 till 3370 This field contains the expiration date requested by the client in a 3371 ticket request. It is not optional, but if the requested endtime is 3372 "19700101000000Z", the requested ticket is to have the maximum endtime 3373 permitted according to KDC policy for. This special timestamp 3374 corresponds to a UNIX time_t value of zero on most systems. 3375 rtime 3376 This field is the requested renew-till time sent from a client to the 3377 KDC in a ticket request. It is optional. 3378 nonce 3379 This field is part of the KDC request and response. It it intended to 3380 hold a random number generated by the client. If the same number is 3381 included in the encrypted response from the KDC, it provides evidence 3382 that the response is fresh and has not been replayed by an attacker. 3383 Nonces must never be re-used. 3385 etype 3386 This field specifies the desired encryption algorithm to be used in the 3387 response. 3388 addresses 3389 This field is included in the initial request for tickets, and 3390 optionally included in requests for additional tickets from the 3391 ticket-granting server. It specifies the addresses from which the 3392 requested ticket is to be valid. Normally it includes the addresses for 3393 the client's host. If a proxy is requested, this field will contain 3394 other addresses. The contents of this field are usually copied by the 3395 KDC into the caddr field of the resulting ticket. 3396 additional-tickets 3397 Additional tickets may be optionally included in a request to the 3398 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 3399 specified, then the session key from the additional ticket will be used 3400 in place of the server's key to encrypt the new ticket. When the 3401 ENC-TKT-IN-SKEY option is used for user-to-user authentication, this 3402 addional ticket may be a TGT issued by the local realm or an 3403 inter-realm TGT issued for the current KDC's realm by a remote KDC. If 3404 more than one option which requires additional tickets has been 3405 specified, then the additional tickets are used in the order specified 3406 by the ordering of the options bits (see kdc-options, above). 3408 The application tag number will be either ten (10) or twelve (12) depending 3409 on whether the request is for an initial ticket (AS-REQ) or for an 3410 additional ticket (TGS-REQ). 3412 The optional fields (addresses, authorization-data and additional-tickets) 3413 are only included if necessary to perform the operation specified in the 3414 kdc-options field. 3416 It should be noted that in KRB_TGS_REQ, the protocol version number appears 3417 twice and two different message types appear: the KRB_TGS_REQ message 3418 contains these fields as does the authentication header (KRB_AP_REQ) that is 3419 passed in the padata field. 3421 5.4.2. KRB_KDC_REP definition 3423 The KRB_KDC_REP message format is used for the reply from the KDC for either 3424 an initial (AS) request or a subsequent (TGS) request. There is no message 3425 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 3426 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 3427 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 3428 the client's secret key, and the client's key version number is included in 3429 the key version number for the encrypted data. For KRB_TGS_REP, the 3430 ciphertext is encrypted in the sub-session key from the Authenticator, or if 3431 absent, the session key from the ticket-granting ticket used in the request. 3432 In that case, no version number will be present in the EncryptedData 3433 sequence. 3435 The KRB_KDC_REP message contains the following fields: 3437 AS-REP ::= [APPLICATION 11] KDC-REP 3439 TGS-REP ::= [APPLICATION 13] KDC-REP 3441 KDC-REP ::= SEQUENCE { 3442 pvno [0] INTEGER (5), 3443 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 3444 padata [2] SEQUENCE OF PA-DATA OPTIONAL 3445 -- NOTE: not empty --, 3446 crealm [3] Realm, 3447 cname [4] PrincipalName, 3448 ticket [5] Ticket, 3449 enc-part [6] EncryptedData 3450 -- EncASRepPart or EncTGSRepPart, 3451 -- as appropriate 3452 } 3454 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 3456 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 3458 EncKDCRepPart ::= SEQUENCE { 3459 key [0] EncryptionKey, 3460 last-req [1] LastReq, 3461 nonce [2] UInt32, 3462 key-expiration [3] KerberosTime OPTIONAL, 3463 flags [4] TicketFlags, 3464 authtime [5] KerberosTime, 3465 starttime [6] KerberosTime OPTIONAL, 3466 endtime [7] KerberosTime, 3467 renew-till [8] KerberosTime OPTIONAL, 3468 srealm [9] Realm, 3469 sname [10] PrincipalName, 3470 caddr [11] HostAddresses OPTIONAL 3471 } 3473 LastReq ::= SEQUENCE OF SEQUENCE { 3474 lr-type [0] Int32, 3475 lr-value [1] KerberosTime 3476 } 3478 pvno and msg-type 3479 These fields are described above in section 5.4.1. msg-type is either 3480 KRB_AS_REP or KRB_TGS_REP. 3481 padata 3482 This field is described in detail in section 5.4.1. One possible use 3483 for this field is to encode an alternate "salt" string to be used with 3484 a string-to-key algorithm. This ability is useful to ease transitions 3485 if a realm name needs to change (e.g. when a company is acquired); in 3486 such a case all existing password-derived entries in the KDC database 3487 would be flagged as needing a special salt string until the next 3488 password change. 3490 crealm, cname, srealm and sname 3491 These fields are the same as those described for the ticket in section 3492 5.3. 3493 ticket 3494 The newly-issued ticket, from section 5.3. 3495 enc-part 3496 This field is a place holder for the ciphertext and related information 3497 that forms the encrypted part of a message. The description of the 3498 encrypted part of the message follows each appearance of this field. 3500 The key usage value for encrypting this field is 3 in an AS-REP 3501 message, using the client's long-term key or another key selected via 3502 preauthentication mechanisms. In a TGS-REP message, the key usage value 3503 is 8 if the TGS session key is used, or 9 if a TGS authenticator subkey 3504 is used. 3506 Compatibility note: Some implementations unconditionally send an 3507 encrypted EncTGSRepPart (application tag number 26) in this field 3508 regardless of whether the reply is a AS-REP or a TGS-REP. In the 3509 interests of compatibility, implementors may wish to relax the check on 3510 the tag number of the decrypted ENC-PART. 3511 key 3512 This field is the same as described for the ticket in section 5.3. 3513 last-req 3514 This field is returned by the KDC and specifies the time(s) of the last 3515 request by a principal. Depending on what information is available, 3516 this might be the last time that a request for a ticket-granting ticket 3517 was made, or the last time that a request based on a ticket-granting 3518 ticket was successful. It also might cover all servers for a realm, or 3519 just the particular server. Some implementations may display this 3520 information to the user to aid in discovering unauthorized use of one's 3521 identity. It is similar in spirit to the last login time displayed when 3522 logging into timesharing systems. 3523 lr-type 3524 This field indicates how the following lr-value field is to be 3525 interpreted. Negative values indicate that the information 3526 pertains only to the responding server. Non-negative values 3527 pertain to all servers for the realm. 3529 If the lr-type field is zero (0), then no information is conveyed 3530 by the lr-value subfield. If the absolute value of the lr-type 3531 field is one (1), then the lr-value subfield is the time of last 3532 initial request for a TGT. If it is two (2), then the lr-value 3533 subfield is the time of last initial request. If it is three (3), 3534 then the lr-value subfield is the time of issue for the newest 3535 ticket-granting ticket used. If it is four (4), then the lr-value 3536 subfield is the time of the last renewal. If it is five (5), then 3537 the lr-value subfield is the time of last request (of any type). 3538 If it is (6), then the lr-value subfield is the time when the 3539 password will expire. 3540 lr-value 3541 This field contains the time of the last request. the time must be 3542 interpreted according to the contents of the accompanying lr-type 3543 subfield. 3545 nonce 3546 This field is described above in section 5.4.1. 3547 key-expiration 3548 The key-expiration field is part of the response from the KDC and 3549 specifies the time that the client's secret key is due to expire. The 3550 expiration might be the result of password aging or an account 3551 expiration. This field will usually be left out of the TGS reply since 3552 the response to the TGS request is encrypted in a session key and no 3553 client information need be retrieved from the KDC database. It is up to 3554 the application client (usually the login program) to take appropriate 3555 action (such as notifying the user) if the expiration time is imminent. 3556 flags, authtime, starttime, endtime, renew-till and caddr 3557 These fields are duplicates of those found in the encrypted portion of 3558 the attached ticket (see section 5.3), provided so the client may 3559 verify they match the intended request and to assist in proper ticket 3560 caching. If the message is of type KRB_TGS_REP, the caddr field will 3561 only be filled in if the request was for a proxy or forwarded ticket, 3562 or if the user is substituting a subset of the addresses from the 3563 ticket granting ticket. If the client-requested addresses are not 3564 present or not used, then the addresses contained in the ticket will be 3565 the same as those included in the ticket-granting ticket. 3567 5.5. Client/Server (CS) message specifications 3569 This section specifies the format of the messages used for the 3570 authentication of the client to the application server. 3572 5.5.1. KRB_AP_REQ definition 3574 The KRB_AP_REQ message contains the Kerberos protocol version number, the 3575 message type KRB_AP_REQ, an options field to indicate any options in use, 3576 and the ticket and authenticator themselves. The KRB_AP_REQ message is often 3577 referred to as the 'authentication header'. 3579 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3580 pvno [0] INTEGER (5), 3581 msg-type [1] INTEGER (14), 3582 ap-options [2] APOptions, 3583 ticket [3] Ticket, 3584 authenticator [4] EncryptedData -- Authenticator 3585 } 3587 APOptions ::= KerberosFlags 3588 -- reserved(0), 3589 -- use-session-key(1), 3590 -- mutual-required(2) 3592 pvno and msg-type 3593 These fields are described above in section 5.4.1. msg-type is 3594 KRB_AP_REQ. 3596 ap-options 3597 This field appears in the application request (KRB_AP_REQ) and affects 3598 the way the request is processed. It is a bit-field, where the selected 3599 options are indicated by the bit being set (1), and the unselected 3600 options and reserved fields being reset (0). The encoding of the bits 3601 is specified in section 5.2. The meanings of the options are: 3602 Bit(s) Name Description 3604 0 reserved Reserved for future expansion of this field. 3606 The USE-SESSION-KEY option indicates that the 3607 ticket the client is presenting to a server 3608 1 use-session-key is encrypted in the session key from the 3609 server's ticket-granting ticket. When this 3610 option is not specified, the ticket is 3611 encrypted in the server's secret key. 3613 The MUTUAL-REQUIRED option tells the server 3614 2 mutual-required that the client requires mutual 3615 authentication, and that it must respond with 3616 a KRB_AP_REP message. 3618 3-31 reserved Reserved for future use. 3619 ticket 3620 This field is a ticket authenticating the client to the server. 3621 authenticator 3622 This contains the encrypted authenticator, which includes the client's 3623 choice of a subkey. 3625 The encrypted authenticator is included in the AP-REQ; it certifies to a 3626 server that the sender has recent knowledge of the encryption key in the 3627 accompanying ticket, to help the server detect replays. It also assists in 3628 the selection of a "true session key" to use with the particular session. 3629 The DER encoding of the following is encrypted in the ticket's session key, 3630 with a key usage value of 11 in normal application exchanges, or 7 when used 3631 as the PA-TGS-REQ PA-DATA field of a TGS-REQ exchange (see section 5.4.1): 3633 -- Unencrypted authenticator 3634 Authenticator ::= [APPLICATION 2] SEQUENCE { 3635 authenticator-vno [0] INTEGER (5), 3636 crealm [1] Realm, 3637 cname [2] PrincipalName, 3638 cksum [3] Checksum OPTIONAL, 3639 cusec [4] Microseconds, 3640 ctime [5] KerberosTime, 3641 subkey [6] EncryptionKey OPTIONAL, 3642 seq-number [7] UInt32 OPTIONAL, 3643 authorization-data [8] AuthorizationData OPTIONAL 3644 } 3646 authenticator-vno 3647 This field specifies the version number for the format of the 3648 authenticator. This document specifies version 5. 3650 crealm and cname 3651 These fields are the same as those described for the ticket in section 3652 5.3. 3653 cksum 3654 This field contains a checksum of the the application data that 3655 accompanies the KRB_AP_REQ, computed using a key usage value of 10 in 3656 normal application exchanges, or 6 when used in the TGS-REQ PA-TGS-REQ 3657 AP-DATA field. 3658 cusec 3659 This field contains the microsecond part of the client's timestamp. Its 3660 value (before encryption) ranges from 0 to 999999. It often appears 3661 along with ctime. The two fields are used together to specify a 3662 reasonably accurate timestamp. 3663 ctime 3664 This field contains the current time on the client's host. 3665 subkey 3666 This field contains the client's choice for an encryption key which is 3667 to be used to protect this specific application session. Unless an 3668 application specifies otherwise, if this field is left out the session 3669 key from the ticket will be used. 3670 seq-number 3671 This optional field includes the initial sequence number to be used by 3672 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 3673 detect replays (It may also be used by application specific messages). 3674 When included in the authenticator this field specifies the initial 3675 sequence number for messages from the client to the server. When 3676 included in the AP-REP message, the initial sequence number is that for 3677 messages from the server to the client. When used in KRB_PRIV or 3678 KRB_SAFE messages, it is incremented by one after each message is sent. 3679 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to 3680 zero following the value 2^32 - 1. 3682 For sequence numbers to adequately support the detection of replays 3683 they should be non-repeating, even across connection boundaries. The 3684 initial sequence number should be random and uniformly distributed 3685 across the full space of possible sequence numbers, so that it cannot 3686 be guessed by an attacker and so that it and the successive sequence 3687 numbers do not repeat other sequences. 3689 Implmentation note: historically, some implementations transmit signed 3690 twos-complement numbers for sequence numbers. In the interests of 3691 compatibility, implementations may accept the equivalent negative 3692 number where a positive number greater than 2^31 - 1 is expected. 3694 Implementation note: as noted before, some implementations omit the 3695 optional sequence number when its value would be zero. Implementations 3696 may accept an omitted sequence number when expecting a value of zero, 3697 and should not transmit an Authenticator with a sequence number of 3698 zero. 3699 authorization-data 3700 This field is the same as described for the ticket in section 5.3. It 3701 is optional and will only appear when additional restrictions are to be 3702 placed on the use of a ticket, beyond those carried in the ticket 3703 itself. 3705 5.5.2. KRB_AP_REP definition 3707 The KRB_AP_REP message contains the Kerberos protocol version number, the 3708 message type, and an encrypted time- stamp. The message is sent in response 3709 to an application request (KRB_AP_REQ) where the mutual authentication 3710 option has been selected in the ap-options field. 3712 AP-REP ::= [APPLICATION 15] SEQUENCE { 3713 pvno [0] INTEGER (5), 3714 msg-type [1] INTEGER (15), 3715 enc-part [2] EncryptedData -- EncAPRepPart 3716 } 3718 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 3719 ctime [0] KerberosTime, 3720 cusec [1] Microseconds, 3721 subkey [2] EncryptionKey OPTIONAL, 3722 seq-number [3] UInt32 OPTIONAL 3723 } 3725 The encoded EncAPRepPart is encrypted in the shared session key of the 3726 ticket. The optional subkey field can be used in an application-arranged 3727 negotiation to choose a per association session key. 3729 pvno and msg-type 3730 These fields are described above in section 5.4.1. msg-type is 3731 KRB_AP_REP. 3732 enc-part 3733 This field is described above in section 5.4.2. It is computed with a 3734 key usage value of 12. 3735 ctime 3736 This field contains the current time on the client's host. 3737 cusec 3738 This field contains the microsecond part of the client's timestamp. 3739 subkey 3740 This field contains an encryption key which is to be used to protect 3741 this specific application session. See section 3.2.6 for specifics on 3742 how this field is used to negotiate a key. Unless an application 3743 specifies otherwise, if this field is left out, the sub-session key 3744 from the authenticator, or if also left out, the session key from the 3745 ticket will be used. 3746 seq-number 3747 This field is described above in section 5.3.2. 3749 5.5.3. Error message reply 3751 If an error occurs while processing the application request, the KRB_ERROR 3752 message will be sent in response. See section 5.9.1 for the format of the 3753 error message. The cname and crealm fields may be left out if the server 3754 cannot determine their appropriate values from the corresponding KRB_AP_REQ 3755 message. If the authenticator was decipherable, the ctime and cusec fields 3756 will contain the values from it. 3758 5.6. KRB_SAFE message specification 3760 This section specifies the format of a message that can be used by either 3761 side (client or server) of an application to send a tamper-proof message to 3762 its peer. It presumes that a session key has previously been exchanged (for 3763 example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3765 5.6.1. KRB_SAFE definition 3767 The KRB_SAFE message contains user data along with a collision-proof 3768 checksum keyed with the last encryption key negotiated via subkeys, or the 3769 session key if no negotiation has occurred. The message fields are: 3771 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3772 pvno [0] INTEGER (5), 3773 msg-type [1] INTEGER (20), 3774 safe-body [2] KRB-SAFE-BODY, 3775 cksum [3] Checksum 3776 } 3778 KRB-SAFE-BODY ::= SEQUENCE { 3779 user-data [0] OCTET STRING, 3780 timestamp [1] KerberosTime OPTIONAL, 3781 usec [2] Microseconds OPTIONAL, 3782 seq-number [3] UInt32 OPTIONAL, 3783 s-address [4] HostAddress, 3784 r-address [5] HostAddress OPTIONAL 3785 } 3787 pvno and msg-type 3788 These fields are described above in section 5.4.1. msg-type is 3789 KRB_SAFE. 3790 safe-body 3791 This field is a placeholder for the body of the KRB-SAFE message. 3792 cksum 3793 This field contains the checksum of the application data, computed with 3794 a key usage value of 15. 3796 The checksum is computed over the encoding of the KRB-SAFE sequence. 3797 First, the cksum is set to a type zero, zero-length value and the 3798 checksum is computed over the encoding of the KRB-SAFE sequence, then 3799 the checksum is set to the result of that computation, and finally the 3800 KRB-SAFE sequence is encoded again. This method, while different than 3801 the one specified in RFC 1510, corresponds to existing practice. 3802 user-data 3803 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 3804 the application specific data that is being passed from the sender to 3805 the recipient. 3806 timestamp 3807 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 3808 are the current time as known by the sender of the message. By checking 3809 the timestamp, the recipient of the message is able to make sure that 3810 it was recently generated, and is not a replay. 3812 usec 3813 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 3814 the microsecond part of the timestamp. 3815 seq-number 3816 This field is described above in section 5.3.2. 3817 s-address 3818 Sender's address. 3820 This field specifies the address in use by the sender of the message. 3821 It may be omitted if not required by the application protocol. 3822 r-address 3823 This field specifies the address in use by the recipient of the 3824 message. It may be omitted for some uses (such as broadcast protocols), 3825 but the recipient may arbitrarily reject such messages. This field, 3826 along with s-address, can be used to help detect messages which have 3827 been incorrectly or maliciously delivered to the wrong recipient. 3829 5.7. KRB_PRIV message specification 3831 This section specifies the format of a message that can be used by either 3832 side (client or server) of an application to securely and privately send a 3833 message to its peer. It presumes that a session key has previously been 3834 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3836 5.7.1. KRB_PRIV definition 3838 The KRB_PRIV message contains user data encrypted in the Session Key. The 3839 message fields are: 3841 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3842 pvno [0] INTEGER (5), 3843 msg-type [1] INTEGER (21), 3844 -- NOTE: there is no [2] tag 3845 enc-part [3] EncryptedData -- EncKrbPrivPart 3846 } 3848 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 3849 user-data [0] OCTET STRING, 3850 timestamp [1] KerberosTime OPTIONAL, 3851 usec [2] Microseconds OPTIONAL, 3852 seq-number [3] UInt32 OPTIONAL, 3853 s-address [4] HostAddress -- sender's addr --, 3854 r-address [5] HostAddress OPTIONAL -- recip's addr 3855 } 3857 pvno and msg-type 3858 These fields are described above in section 5.4.1. msg-type is 3859 KRB_PRIV. 3860 enc-part 3861 This field holds an encoding of the EncKrbPrivPart sequence encrypted 3862 under the session key[32], with a key usage value of 13. This encrypted 3863 encoding is used for the enc-part field of the KRB-PRIV message. 3864 user-data, timestamp, usec, s-address and r-address 3865 These fields are described above in section 5.6.1. 3866 seq-number 3867 This field is described above in section 5.3.2. 3869 5.8. KRB_CRED message specification 3871 This section specifies the format of a message that can be used to send 3872 Kerberos credentials from one principal to another. It is presented here to 3873 encourage a common mechanism to be used by applications when forwarding 3874 tickets or providing proxies to subordinate servers. It presumes that a 3875 session key has already been exchanged perhaps by using the 3876 KRB_AP_REQ/KRB_AP_REP messages. 3878 5.8.1. KRB_CRED definition 3880 The KRB_CRED message contains a sequence of tickets to be sent and 3881 information needed to use the tickets, including the session key from each. 3882 The information needed to use the tickets is encrypted under an encryption 3883 key previously exchanged or transferred alongside the KRB_CRED message. The 3884 message fields are: 3886 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3887 pvno [0] INTEGER (5), 3888 msg-type [1] INTEGER (22), 3889 tickets [2] SEQUENCE OF Ticket, 3890 enc-part [3] EncryptedData -- EncKrbCredPart 3891 } 3893 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3894 ticket-info [0] SEQUENCE OF KrbCredInfo, 3895 nonce [1] UInt32 OPTIONAL, 3896 timestamp [2] KerberosTime OPTIONAL, 3897 usec [3] Microseconds OPTIONAL, 3898 s-address [4] HostAddress OPTIONAL, 3899 r-address [5] HostAddress OPTIONAL 3900 } 3902 KrbCredInfo ::= SEQUENCE { 3903 key [0] EncryptionKey, 3904 prealm [1] Realm OPTIONAL, 3905 pname [2] PrincipalName OPTIONAL, 3906 flags [3] TicketFlags OPTIONAL, 3907 authtime [4] KerberosTime OPTIONAL, 3908 starttime [5] KerberosTime OPTIONAL, 3909 endtime [6] KerberosTime OPTIONAL, 3910 renew-till [7] KerberosTime OPTIONAL, 3911 srealm [8] Realm OPTIONAL, 3912 sname [9] PrincipalName OPTIONAL, 3913 caddr [10] HostAddresses OPTIONAL 3914 } 3916 pvno and msg-type 3917 These fields are described above in section 5.4.1. msg-type is 3918 KRB_CRED. 3919 tickets 3920 These are the tickets obtained from the KDC specifically for use by the 3921 intended recipient. Successive tickets are paired with the 3922 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3923 message. 3925 enc-part 3926 This field holds an encoding of the EncKrbCredPart sequence encrypted 3927 under the session key shared between the sender and the intended 3928 recipient, with a key usage value of 14. This encrypted encoding is 3929 used for the enc-part field of the KRB-CRED message. 3931 Implementation note: implementations of certain applications, most 3932 notably of the Kerberos GSS-API mechanism, do not encrypt the KRB-CRED 3933 message when sending it. In the case of the GSS-API mechanism, this is 3934 not a security vulnerability, as the KRB-CRED message itself is itself 3935 encrypted inside an Authenticator. 3936 nonce 3937 If practical, an application may require the inclusion of a nonce 3938 generated by the recipient of the message. If the same value is 3939 included as the nonce in the message, it provides evidence that the 3940 message is fresh and has not been replayed by an attacker. A nonce must 3941 never be re-used; it should be generated randomly by the recipient of 3942 the message and provided to the sender of the message in an application 3943 specific manner. 3944 timestamp and usec 3945 These fields specify the time that the KRB-CRED message was generated. 3946 The time is used to provide assurance that the message is fresh. 3947 s-address and r-address 3948 These fields are described above in section 5.6.1. They are used 3949 optionally to provide additional assurance of the integrity of the 3950 KRB-CRED message. 3951 key 3952 This field exists in the corresponding ticket passed by the KRB-CRED 3953 message and is used to pass the session key from the sender to the 3954 intended recipient. The field's encoding is described in section 5.2.9. 3956 The following fields are optional. If present, they can be associated with 3957 the credentials in the remote ticket file. If left out, then it is assumed 3958 that the recipient of the credentials already knows their value. 3960 prealm and pname 3961 The name and realm of the delegated principal identity. 3962 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3963 These fields contain the values of the corresponding fields from the 3964 ticket found in the ticket field. Descriptions of the fields are 3965 identical to the descriptions in the KDC-REP message. 3967 5.9. Error message specification 3969 This section specifies the format for the KRB_ERROR message. The fields 3970 included in the message are intended to return as much information as 3971 possible about an error. It is not expected that all the information 3972 required by the fields will be available for all types of errors. If the 3973 appropriate information is not available when the message is composed, the 3974 corresponding field will be left out of the message. 3976 Note that since the KRB_ERROR message is not integrity protected, it is 3977 quite possible for an intruder to synthesize or modify such a message. In 3978 particular, this means that the client should not use any fields in this 3979 message for security-critical purposes, such as setting a system clock or 3980 generating a fresh authenticator. The message can be useful, however, for 3981 advising a user on the reason for some failure. 3983 5.9.1. KRB_ERROR definition 3985 The KRB_ERROR message consists of the following fields: 3987 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3988 pvno [0] INTEGER (5), 3989 msg-type [1] INTEGER (30), 3990 ctime [2] KerberosTime OPTIONAL, 3991 cusec [3] Microseconds OPTIONAL, 3992 stime [4] KerberosTime, 3993 susec [5] Microseconds, 3994 error-code [6] Int32, 3995 crealm [7] Realm OPTIONAL, 3996 cname [8] PrincipalName OPTIONAL, 3997 realm [9] Realm -- service realm --, 3998 sname [10] PrincipalName -- service name --, 3999 e-text [11] KerberosString OPTIONAL, 4000 e-data [12] OCTET STRING OPTIONAL 4001 } 4003 pvno and msg-type 4004 These fields are described above in section 5.4.1. msg-type is 4005 KRB_ERROR. 4006 ctime 4007 This field is described above in section 5.4.1. 4008 cusec 4009 This field is described above in section 5.5.2. 4010 stime 4011 This field contains the current time on the server. It is of type 4012 KerberosTime. 4013 susec 4014 This field contains the microsecond part of the server's timestamp. Its 4015 value ranges from 0 to 999999. It appears along with stime. The two 4016 fields are used in conjunction to specify a reasonably accurate 4017 timestamp. 4018 error-code 4019 This field contains the error code returned by Kerberos or the server 4020 when a request fails. To interpret the value of this field see the list 4021 of error codes in section 8. Implementations are encouraged to provide 4022 for national language support in the display of error messages. 4023 crealm, cname, srealm and sname 4024 These fields are described above in section 5.3. 4025 e-text 4026 This field contains additional text to help explain the error code 4027 associated with the failed request (for example, it might include a 4028 principal name which was unknown). 4030 e-data 4031 This field contains additional data about the error for use by the 4032 application to help it recover from or handle the error. If the 4033 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 4034 contain an encoding of a sequence of padata fields, each corresponding 4035 to an acceptable pre-authentication method and optionally containing 4036 data for the method: 4038 METHOD-DATA ::= SEQUENCE OF PA-DATA 4040 For error codes defined in this document other than 4041 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field 4042 are implementation-defined. Similarly, for future error codes, the 4043 format and contents of the e-data field are implementation-defined 4044 unless specified. Whether defined by the implementation or in a future 4045 document, the e-data field MAY take the form of TYPED-DATA: 4047 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4048 data-type [0] INTEGER, 4049 data-value [1] OCTET STRING OPTIONAL 4050 } 4051 5.10. Application Tag Numbers 4053 The following table lists the application class tag numbers used by various 4054 data types defined in this section. 4055 Tag Number(s) Type Name Comments 4057 0 unused 4059 1 Ticket PDU 4061 2 Authenticator non-PDU 4063 3 EncTicketPart non-PDU 4065 4-10 unused 4067 10 AS-REQ PDU 4069 11 AS-REP PDU 4071 12 TGS-REQ PDU 4073 13 TGS-REP PDU 4075 14 AP-REQ PDU 4077 15 AP-REP PDU 4079 16 RESERVED16 TGT-REQ 4081 17 RESERVED17 TGT-REP 4083 18-19 unused 4085 20 KRB-SAFE PDU 4087 21 KRB-PRIV PDU 4089 22 KRB-CRED PDU 4091 23-24 unused 4093 25 EncASRepPart non-PDU 4095 26 EncTGSRepPart non-PDU 4097 27 EncApRepPart non-PDU 4099 28 EncKrbPrivPart non-PDU 4101 29 EncKrbCredPart non-PDU 4103 30 KRB-ERROR PDU 4104 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are the 4105 only ASN.1 types intended as top-level types of the Kerberos protcol, and 4106 are the only types that may be used as elements in another protocol that 4107 makes use of Kerberos. 4109 6. Naming Constraints 4111 6.1. Realm Names 4113 Although realm names are encoded as GeneralStrings and although a realm can 4114 technically select any name it chooses, interoperability across realm 4115 boundaries requires agreement on how realm names are to be assigned, and 4116 what information they imply. 4118 To enforce these conventions, each realm must conform to the conventions 4119 itself, and it must require that any realms with which inter-realm keys are 4120 shared also conform to the conventions and require the same from its 4121 neighbors. 4123 Kerberos realm names are case sensitive. Realm names that differ only in the 4124 case of the characters are not equivalent. There are presently four styles 4125 of realm names: domain, X500, other, and reserved. Examples of each style 4126 follow: 4128 domain: ATHENA.MIT.EDU (example) 4129 X500: C=US/O=OSF (example) 4130 other: NAMETYPE:rest/of.name=without-restrictions (example) 4131 reserved: reserved, but will not conflict with above 4133 Domain syle realm names must look like domain names: they consist of 4134 components separated by periods (.) and they contain neither colons (:) nor 4135 slashes (/). Though domain names themselves are case insensitive, in order 4136 for realms to match, the case must match as well. When establishing a new 4137 realm name based on an internet domain name it is recommended by convention 4138 that the characters be converted to upper case. 4140 X.500 names contain an equal (=) and cannot contain a colon (:) before the 4141 equal. The realm names for X.500 names will be string representations of the 4142 names with components separated by slashes. Leading and trailing slashes 4143 will not be included. Note that the slash separator is consistent with 4144 Kerberos implementations based on RFC1510, but it is different from the 4145 separator recommended in RFC2253. 4147 Names that fall into the other category must begin with a prefix that 4148 contains no equal (=) or period (.) and the prefix must be followed by a 4149 colon (:) and the rest of the name. All prefixes must be assigned before 4150 they may be used. Presently none are assigned. 4152 The reserved category includes strings which do not fall into the first 4153 three categories. All names in this category are reserved. It is unlikely 4154 that names will be assigned to this category unless there is a very strong 4155 argument for not using the 'other' category. 4157 These rules guarantee that there will be no conflicts between the various 4158 name styles. The following additional constraints apply to the assignment of 4159 realm names in the domain and X.500 categories: the name of a realm for the 4160 domain or X.500 formats must either be used by the organization owning (to 4161 whom it was assigned) an Internet domain name or X.500 name, or in the case 4162 that no such names are registered, authority to use a realm name may be 4163 derived from the authority of the parent realm. For example, if there is no 4164 domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4165 authorize the creation of a realm with that name. 4167 This is acceptable because the organization to which the parent is assigned 4168 is presumably the organization authorized to assign names to its children in 4169 the X.500 and domain name systems as well. If the parent assigns a realm 4170 name without also registering it in the domain name or X.500 hierarchy, it 4171 is the parent's responsibility to make sure that there will not in the 4172 future exist a name identical to the realm name of the child unless it is 4173 assigned to the same entity as the realm name. 4175 6.2. Principal Names 4177 As was the case for realm names, conventions are needed to ensure that all 4178 agree on what information is implied by a principal name. The name-type 4179 field that is part of the principal name indicates the kind of information 4180 implied by the name. The name-type should be treated only as a hint to 4181 interpreting the meaning of a name. It is not significant when checking for 4182 equivalence. Principal names that differ only in the name-type identify the 4183 same principal. The name type does not partition the name space. Ignoring 4184 the name type, no two names can be the same (i.e. at least one of the 4185 components, or the realm, must be different). The following name types are 4186 defined: 4188 name-type value meaning 4190 NT-UNKNOWN 0 Name type not known 4191 NT-PRINCIPAL 1 General principal name (e.g. username, 4192 or DCE principal) 4193 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4194 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4195 NT-SRV-XHST 4 Service with slash-separated host name components 4196 NT-UID 5 Unique ID 4197 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4198 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4199 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 4201 When a name implies no information other than its uniqueness at a particular 4202 time the name type PRINCIPAL should be used. The principal name type should 4203 be used for users, and it might also be used for a unique server. If the 4204 name is a unique machine generated ID that is guaranteed never to be 4205 reassigned then the name type of UID should be used (note that it is 4206 generally a bad idea to reassign names of any type since stale entries might 4207 remain in access control lists). 4209 If the first component of a name identifies a service and the remaining 4210 components identify an instance of the service in a server specified manner, 4211 then the name type of SRV-INST should be used. An example of this name type 4212 is the Kerberos ticket-granting service whose name has a first component of 4213 krbtgt and a second component identifying the realm for which the ticket is 4214 valid. 4216 If instance is a single component following the service name and the 4217 instance identifies the host on which the server is running, then the name 4218 type SRV-HST should be used. This type is typically used for Internet 4219 services such as telnet and the Berkeley R commands. If the separate 4220 components of the host name appear as successive components following the 4221 name of the service, then the name type SRV-XHST should be used. This type 4222 might be used to identify servers on hosts with X.500 names where the slash 4223 (/) might otherwise be ambiguous. 4225 A name type of NT-X500-PRINCIPAL should be used when a name from an X.509 4226 certificate is translated into a Kerberos name. The encoding of the X.509 4227 name as a Kerberos principal shall conform to the encoding rules specified 4228 in RFC 2253. 4230 A name type of SMTP allows a name to be of a form that resembles a SMTP 4231 email name. This name, including an "@" and a domain name, is used as the 4232 one component of the principal name. 4234 A name type of UNKNOWN should be used when the form of the name is not 4235 known. When comparing names, a name of type UNKNOWN will match principals 4236 authenticated with names of any type. A principal authenticated with a name 4237 of type UNKNOWN, however, will only match other names of type UNKNOWN. 4239 Names of any type with an initial component of 'krbtgt' are reserved for the 4240 Kerberos ticket granting service. See section 8.2.4 for the form of such 4241 names. 4243 6.2.1. Name of server principals 4245 The principal identifier for a server on a host will generally be composed 4246 of two parts: (1) the realm of the KDC with which the server is registered, 4247 and (2) a two-component name of type NT-SRV-HST if the host name is an 4248 Internet domain name or a multi-component name of type NT-SRV-XHST if the 4249 name of the host is of a form such as X.500 that allows slash (/) 4250 separators. The first component of the two- or multi-component name will 4251 identify the service and the latter components will identify the host. Where 4252 the name of the host is not case sensitive (for example, with Internet 4253 domain names) the name of the host must be lower case. If specified by the 4254 application protocol for services such as telnet and the Berkeley R commands 4255 which run with system privileges, the first component may be the string 4256 'host' instead of a service specific identifier. When a host has an official 4257 name and one or more aliases and the official name can be reliably 4258 determined, the official name of the host should be used when constructing 4259 the name of the server principal. 4261 7. Constants and other defined values 4263 7.1. Host address types 4265 All negative values for the host address type are reserved for local use. 4266 All non-negative values are reserved for officially assigned type fields and 4267 interpretations. 4269 The values of the types for the following addresses are chosen to match the 4270 defined address family constants in the Berkeley Standard Distributions of 4271 Unix. They can be found in with symbolic names AF_xxx (where xxx is an 4272 abbreviation of the address family name). 4274 Internet (IPv4) Addresses 4276 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB 4277 order. The IPv4 loopback address should not appear in a Kerberos packet. The 4278 type of IPv4 addresses is two (2). 4280 Internet (IPv6) Addresses [Westerlund] 4282 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The 4283 type of IPv6 addresses is twenty-four (24). [RFC2373]. The following 4284 addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 4286 * the Unspecified Address 4287 * the Loopback Address 4288 * Link-Local addresses 4290 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 4292 DECnet Phase IV addresses 4294 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The 4295 type of DECnet Phase IV addresses is twelve (12). 4297 Netbios addresses 4299 Netbios addresses are 16-octet addresses typically composed of 1 to 15 4300 characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0. 4301 The type of Netbios addresses is 20 (0x14). 4303 Directional Addresses 4305 In many environments, including the sender address in KRB_SAFE and KRB_PRIV 4306 messages is undesirable because the addresses may be changed in transport by 4307 network address translators. However, if these addresses are removed, the 4308 messages may be subject to a reflection attack in which a message is 4309 reflected back to its originator. The directional address type provides a 4310 way to avoid transport addresses and reflection attacks. Directional 4311 addresses are encoded as four byte unsigned integers in network byte order. 4312 If the message is originated by the party sending the original KRB_AP_REQ 4313 message, then an address of 0 should be used. If the message is originated 4314 by the party to whom that KRB_AP_REQ was sent, then the address 1 should be 4315 used. Applications involving multiple parties can specify the use of other 4316 addresses. 4318 Directional addresses MUST only be used for the sender address field in the 4319 KRB_SAFE or KRB_PRIV messages. They MUST NOT be used as a ticket address or 4320 in a KRB_AP_REQ message. This address type SHOULD only be used in situations 4321 where the sending party knows that the receiving party supports the address 4322 type. This generally means that directional addresses may only be used when 4323 the application protocol requires their support. Directional addresses are 4324 type XX (0xXX). 4326 7.2. KDC messaging 4328 7.2.1 IP Transports 4330 Kerberos defines two IP transport mechanisms for communication between 4331 clients and servers: UDP/IP and TCP/IP. 4333 7.2.1.1. UDP/IP transport 4335 Kerberos servers (KDCs) supporting IP transports MUST accept UDP requests 4336 and SHOULD listen for such requests on port 88 (decimal) unless specifically 4337 configured to listen on an alternative UDP port. Alternate ports MAY be used 4338 when running multiple KDCs for multiple realms on the same host. 4340 Kerberos clients supporting IP transports SHOULD support the sending of UDP 4341 requests. Clients SHOULD use KDC discovery [7.2.1.3] to identify the IP 4342 address and port to which they will send their request. 4344 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP transport, the 4345 client shall send a UDP datagram containing only an encoding of the request 4346 to the KDC. The KDC will respond with a reply datagram containing only an 4347 encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to the 4348 sending port at the sender's IP address. The response to a request made 4349 through UDP/IP transport must also use UDP/IP transport. If the response can 4350 not be handled using UDP (for example because it is too large), the KDC must 4351 return an error forcing the client to retry the request using the TCP 4352 transport. 4354 7.2.1.2. TCP/IP transport [Westerlund,Danielsson] 4356 Kerberos servers (KDCs) supporting IP transports MUST accept TCP requests 4357 and SHOULD listen for such requests on port 88 (decimal) unless specifically 4358 configured to listen on an alternate TCP port. Alternate ports MAY be used 4359 when running multiple KDCs for multiple realms on the same host. 4361 Clients must support the sending of TCP requests, but may choose to intially 4362 try a request using the UDP transport. Clients SHOULD use KDC discovery 4363 [7.2.1.3] to identify the IP address and port to which they will send their 4364 request. 4366 Implementation note: Some extensions to the Kerberos protocol will not 4367 succeed if any client or KDC not supporting the TCP transport is involved. 4368 Implementations of RFC 1510 were not required to support TCP/IP transports. 4370 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, the 4371 response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to the client 4372 on the same TCP stream that was established for the request. The KDC may 4373 close the TCP stream after sending a response, but may leave the stream open 4374 for a reasonable period of time if it expects a followup. Care must be taken 4375 in managing TCP/IP connections on the KDC to prevent denial of service 4376 attacks based on the number of open TCP/IP connections. 4378 The client MUST be prepared to have the stream closed by the KDC at anytime 4379 after the receipt of a response. A stream closure should not be treated as a 4380 fatal error. Instead, if multiple exchanges are required (e.g., certain 4381 forms of preauthentication) the client may need to establish a new 4382 connection when it is ready to send subsequent messages. A client may close 4383 the stream after receiving a response, and should close the stream if it 4384 does not expect to send followup messages. 4386 A client MAY send multiple requests before receiving responses, though it 4387 must be prepared to handle the connection being closed after the first 4388 response. 4390 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over 4391 the TCP stream is preceded by the length of the request as 4 octets in 4392 network byte order. The high bit of the length is reserved for future 4393 expansion and must currently be set to zero. 4395 If multiple requests are sent over a single TCP connection, and the KDC 4396 sends multiple responses, the KDC is not required to send the responses in 4397 the order of the corresponding requests. This may permit some 4398 implementations to send each response as soon as it is ready even if earlier 4399 requests are still being processed (for example, waiting for a response from 4400 an external device or database). 4402 7.2.1.3 KDC Discovery on IP Networks 4404 Kerberos client implementations must provide a means for the client to 4405 determine the location of the Kerberos Key Distribution Centers (KDCs). 4406 Traditionally, Kerberos implementations have stored such configuration 4407 information in a file on each client machine. Experience has shown this 4408 method of storing configuration information presents problems with 4409 out-of-date information and scaling problems, especially when using 4410 cross-realm authentication. This section describes a method for using the 4411 Domain Name System [RFC 1035] for storing KDC location information. 4413 7.2.1.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 4415 In Kerberos, realm names are case sensitive. While it is strongly encouraged 4416 that all realm names be all upper case this recommendation has not been 4417 adopted by all sites. Some sites use all lower case names and other use 4418 mixed case. DNS on the other hand is case insensitive for queries. Since 4419 "MYREALM", "myrealm", and "MyRealm" are all different it is necessary that 4420 only one of the possible combinations of upper and lower case characters be 4421 used. This restriction may be lifted in the future as the DNS naming scheme 4422 is expanded to support non-ASCII names. 4424 7.2.1.3.2. Specifying KDC Location information with DNS SRV records 4426 KDC location information is to be stored using the DNS SRV RR [RFC 2052]. 4427 The format of this RR is as follows: 4429 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 4431 The Service name for Kerberos is always "_kerberos". 4433 The Proto can be one of "_udp", "_tcp". If these SRV records are to be used, 4434 both "_udp" and "_tcp" records MUST be specified for all KDC deployments. 4436 The Realm is the Kerberos realm that this record corresponds to. 4438 TTL, Class, SRV, Priority, Weight, and Target have the standard meaning as 4439 defined in RFC 2052. 4441 As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV records 4442 SHOULD be the value assigned to "kerberos" by the Internet Assigned Number 4443 Authority: 88 (decimal) unless the KDC is configured to listen on an 4444 alternate TCP port. 4446 Implementation note: Many existing client implementations do not support KDC 4447 Discovery and are configured to send requests to the IANA assigned port (88 4448 decimal), so it is strongly recommended that KDCs be configured to listen on 4449 that port. 4451 7.2.1.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 4453 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two Kerberos 4454 servers, kdc1.example.com and kdc2.example.com. Queries should be directed 4455 to kdc1.example.com first as per the specified priority. Weights are not 4456 used in these sample records. 4458 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 4459 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 4460 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 4461 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 4463 7.3. Name of the TGS 4465 The principal identifier of the ticket-granting service shall be composed of 4466 three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part 4467 name of type NT-SRV-INST, with the first part "krbtgt" and the second part 4468 the name of the realm which will accept the ticket-granting ticket. For 4469 example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 4470 used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier 4471 of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 4472 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get 4473 tickets from the MIT.EDU realm has a principal identifier of 4474 "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name). 4476 7.4. OID arc for KerberosV5 4478 This OID may be used to identify Kerberos protocol messages encapsulated in 4479 other protocols. It also designates the OID arc for KerberosV5-related OIDs 4480 assigned by future IETF action. Implementation note:: RFC 1510 had an 4481 incorrect value (5) for "dod" in its OID. 4483 id-krb5 OBJECT IDENTIFIER ::= { 4484 iso(1) identified-organization(3) dod(6) internet(1) 4485 security(5) kerberosV5(2) 4486 } 4488 Assignment of OIDs beneath the id-krb5 arc must be obtained by contacting 4489 krb5-oid-registrar@mit.edu. 4491 7.5. Protocol constants and associated values 4493 The following tables list constants used in the protocol and define their 4494 meanings. Ranges are specified in the "specification" section that limit the 4495 values of constants for which values are defined here. This allows 4496 implementations to make assumptions about the maximum values that will be 4497 received for these constants. Implementation receiving values outside the 4498 range specified in the "specification" section may reject the request, but 4499 they must recover cleanly. 4501 7.5.1. Key usage numbers 4503 The encryption and checksum specifications in [KCRYPTO] require as input a 4504 "key usage number", to alter the encryption key used in any specific 4505 message, to make certain types of cryptographic attack more difficult. These 4506 are the key usage values assigned in this document: 4508 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted 4509 with the client key (section 5.2.7.2) 4510 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session 4511 key or application session key), encrypted with the 4512 service key (section 5.3) 4513 3. AS-REP encrypted part (includes TGS session key or 4514 application session key), encrypted with the client key 4515 (section 5.4.2) 4516 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 4517 the TGS session key (section 5.4.1) 4518 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 4519 the TGS authenticator subkey (section 5.4.1) 4520 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 4521 keyed with the TGS session key (sections 5.5.1) 4522 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator 4523 (includes TGS authenticator subkey), encrypted with the 4524 TGS session key (section 5.5.1) 4525 8. TGS-REP encrypted part (includes application session 4526 key), encrypted with the TGS session key (section 4527 5.4.2) 4528 9. TGS-REP encrypted part (includes application session 4529 key), encrypted with the TGS authenticator subkey 4530 (section 5.4.2) 4531 10. AP-REQ Authenticator cksum, keyed with the application 4532 session key (section 5.5.1) 4533 11. AP-REQ Authenticator (includes application 4534 authenticator subkey), encrypted with the application 4535 session key (section 5.5.1) 4536 12. AP-REP encrypted part (includes application session 4537 subkey), encrypted with the application session key 4538 (section 5.5.2) 4539 13. KRB-PRIV encrypted part, encrypted with a key chosen by 4540 the application (section 5.7.1) 4541 14. KRB-CRED encrypted part, encrypted with a key chosen by 4542 the application (section 5.8.1) 4543 15. KRB-SAFE cksum, keyed with a key chosen by the 4544 application (section 5.8.1) 4545 19. AD-KDCIssued checksum (ad-checksum in appendix B.4) 4546 22-24. Reserved for use in GSSAPI mechanisms derived from RFC 4547 1964. (raeburn/MIT) 4548 18, 20-21, 25-511. Reserved for future use in Kerberos and related 4549 protocols. 4550 512-1023. Reserved for uses internal to a Kerberos 4551 implementation. 4553 7.5.2. PreAuthentication Data Types 4555 padata and data types padata-type value comment 4557 PA-TGS-REQ 1 4558 PA-ENC-TIMESTAMP 2 4559 PA-PW-SALT 3 4560 [reserved] 4 4561 PA-ENC-UNIX-TIME 5 (depricated) 4562 PA-SANDIA-SECUREID 6 4563 PA-SESAME 7 4564 PA-OSF-DCE 8 4565 PA-CYBERSAFE-SECUREID 9 4566 PA-AFS3-SALT 10 4567 PA-ETYPE-INFO 11 4568 PA-SAM-CHALLENGE 12 (sam/otp) 4569 PA-SAM-RESPONSE 13 (sam/otp) 4570 PA-PK-AS-REQ 14 (pkinit) 4571 PA-PK-AS-REP 15 (pkinit) 4572 PA-ETYPE-INFO2 19 (replaces pa-etype-info) 4573 PA-USE-SPECIFIED-KVNO 20 4574 PA-SAM-REDIRECT 21 (sam/otp) 4575 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 4576 TD-PADATA 22 (embeds padata) 4577 PA-SAM-ETYPE-INFO 23 (sam/otp) 4578 PA-ALT-PRINC 24 (crawdad@fnal.gov) 4579 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 4580 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 4581 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 4582 TD-KRB-PRINCIPAL 102 PrincipalName 4583 TD-KRB-REALM 103 Realm 4584 TD-TRUSTED-CERTIFIERS 104 from PKINIT 4585 TD-CERTIFICATE-INDEX 105 from PKINIT 4586 TD-APP-DEFINED-ERROR 106 application specific 4587 TD-REQ-NONCE 107 INTEGER 4588 TD-REQ-SEQ 108 INTEGER 4589 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 4591 7.5.3. Address Types 4593 Address type value 4595 IPV4 2 4596 ChaosNet 5 4597 XNS 6 4598 ISO 7 4599 DECNET Phase IV 12 4600 AppleTalk DDP 16 4601 NetBios 20 4602 IPV6 24 4603 7.5.4. Authorization Data Types 4605 authorization data type ad-type value 4606 AD-IF-RELEVANT 1 4607 AD-INTENDED-FOR-SERVER 2 4608 AD-INTENDED-FOR-APPLICATION-CLASS 3 4609 AD-KDC-ISSUED 4 4610 AD-OR 5 4611 AD-MANDATORY-TICKET-EXTENSIONS 6 4612 AD-IN-TICKET-EXTENSIONS 7 4613 AD-MANDATORY-FOR-KDC 8 4614 reserved values 9-63 4615 OSF-DCE 64 4616 SESAME 65 4617 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 4618 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 4620 7.5.5. Transited Encoding Types 4622 transited encoding type tr-type value 4623 DOMAIN-X500-COMPRESS 1 4624 reserved values all others 4626 7.5.6. Protocol Version Number 4628 Label Value Meaning or MIT code 4630 pvno 5 current Kerberos protocol version number 4632 7.5.7. Kerberos Message Types 4634 message types 4636 KRB_AS_REQ 10 Request for initial authentication 4637 KRB_AS_REP 11 Response to KRB_AS_REQ request 4638 KRB_TGS_REQ 12 Request for authentication based on TGT 4639 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4640 KRB_AP_REQ 14 application request to server 4641 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4642 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request 4643 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply 4644 KRB_SAFE 20 Safe (checksummed) application message 4645 KRB_PRIV 21 Private (encrypted) application message 4646 KRB_CRED 22 Private (encrypted) message to forward credentials 4647 KRB_ERROR 30 Error response 4649 7.5.8. Name Types 4651 name types 4653 KRB_NT_UNKNOWN 0 Name type not known 4654 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4655 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4656 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 4657 KRB_NT_SRV_XHST 4 Service with host as remaining components 4658 KRB_NT_UID 5 Unique ID 4659 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4660 7.5.9. Error Codes 4662 error codes 4664 KDC_ERR_NONE 0 No error 4665 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4666 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4667 KDC_ERR_BAD_PVNO 3 Requested protocol version number 4668 not supported 4669 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 4670 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 4671 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4672 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4673 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 4674 KDC_ERR_NULL_KEY 9 The client or server has a null key 4675 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4676 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 4677 KDC_ERR_POLICY 12 KDC policy rejects request 4678 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4679 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4680 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4681 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4682 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4683 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4684 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4685 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4686 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4687 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4688 KDC_ERR_KEY_EXPIRED 23 Password has expired 4689 - change password to reset 4690 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 4691 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 4692 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 4693 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 4694 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 4695 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 4696 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 4697 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4698 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4699 KRB_AP_ERR_REPEAT 34 Request is a replay 4700 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4701 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4702 KRB_AP_ERR_SKEW 37 Clock skew too great 4703 KRB_AP_ERR_BADADDR 38 Incorrect net address 4704 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4705 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4706 KRB_AP_ERR_MODIFIED 41 Message stream modified 4707 KRB_AP_ERR_BADORDER 42 Message out of order 4708 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 4709 KRB_AP_ERR_NOKEY 45 Service key not available 4710 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4711 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4712 KRB_AP_ERR_METHOD 48 Alternative authentication method required 4713 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4714 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 4715 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 4716 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 4717 KRB_ERR_GENERIC 60 Generic error (description in e-text) 4718 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 4719 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 4720 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 4721 KDC_ERROR_INVALID_SIG 64 (pkinit) 4722 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 4723 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 4724 KRB_AP_ERR_NO_TGT 67 (user-to-user) 4725 KDC_ERR_WRONG_REALM 68 (user-to-user) 4726 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 4727 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 4728 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 4729 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 4730 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 4731 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 4732 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 4733 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 4734 8. Interoperability requirements 4736 Version 5 of the Kerberos protocol supports a myriad of options. Among these 4737 are multiple encryption and checksum types, alternative encoding schemes for 4738 the transited field, optional mechanisms for pre-authentication, the 4739 handling of tickets with no addresses, options for mutual authentication, 4740 user to user authentication, support for proxies, forwarding, postdating, 4741 and renewing tickets, the format of realm names, and the handling of 4742 authorization data. 4744 In order to ensure the interoperability of realms, it is necessary to define 4745 a minimal configuration which must be supported by all implementations. This 4746 minimal configuration is subject to change as technology does. For example, 4747 if at some later date it is discovered that one of the required encryption 4748 or checksum algorithms is not secure, it will be replaced. 4750 8.1. Specification 2 4752 This section defines the second specification of these options. 4753 Implementations which are configured in this way can be said to support 4754 Kerberos Version 5 Specification 2 (5.2). Specification 1 (deprecated) may 4755 be found in RFC1510. 4757 Transport 4759 TCP/IP and UDP/IP transport must be supported by clients and KDCs claiming 4760 conformance to specification 2. 4762 Encryption and checksum methods 4764 The following encryption and checksum mechanisms must be supported. 4766 Encyrption: AES256-CTS-HMAC-SHA1-96 4767 Checksums: HMAC-SHA1-96-AES256 4769 Implementations should support other mechanisms as well, but the additional 4770 mechanisms may only be used when communicating with principals known to also 4771 support them. The mechanisms that should be supported are: 4773 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD 4774 Checksums: DES-MD5, HMAC-SHA1-DES3-KD 4776 Implementations may support other mechanisms as well, but the additional 4777 mechanisms may only be used when communicating with principals known to also 4778 support them. 4780 Implementation note: earlier implementations of Kerberos generate messages 4781 using the CRC-32, RSA-MD5 checksum methods. For interoperability with these 4782 earlier releases implementors may consider supporting these checksum methods 4783 but should carefully analyze the security impplications to limit the 4784 situations within which these methods are accepted. 4786 Realm Names 4788 All implementations must understand hierarchical realms in both the Internet 4789 Domain and the X.500 style. When a ticket granting ticket for an unknown 4790 realm is requested, the KDC must be able to determine the names of the 4791 intermediate realms between the KDCs realm and the requested realm. 4793 Transited field encoding 4795 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 4796 Alternative encodings may be supported, but they may be used only when that 4797 encoding is supported by ALL intermediate realms. 4799 Pre-authentication methods 4801 The TGS-REQ method must be supported. The TGS-REQ method is not used on the 4802 initial request. The PA-ENC-TIMESTAMP method must be supported by clients 4803 but whether it is enabled by default may be determined on a realm by realm 4804 basis. If not used in the initial request and the error 4805 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 4806 acceptable method, the client should retry the initial request using the 4807 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 4808 PA-ENC-TIMESTAMP method, but if not supported the server should ignore the 4809 presence of PA-ENC-TIMESTAMP pre-authentication in a request. 4811 The ETYPE-INFO2 method must be supported; this method is used to communicate 4812 the set of supported encryption types, and corresponding salt and string to 4813 key paramters. The ETYPE-INFO method should be supported for 4814 interoperability with older implementation. 4816 Mutual authentication 4818 Mutual authentication (via the KRB_AP_REP message) must be supported. 4820 Ticket addresses and flags 4822 All KDC's must pass through tickets that carry no addresses (i.e. if a TGT 4823 contains no addresses, the KDC will return derivative tickets). 4824 Implementations SHOULD default to requesting addressless tickets as this 4825 significantly increases interoperability with network address translation. 4826 In some cases realms or application servers MAY require that tickets have an 4827 address. 4829 Proxies and forwarded tickets must be supported. Individual realms and 4830 application servers can set their own policy on when such tickets will be 4831 accepted. 4833 All implementations must recognize renewable and postdated tickets, but need 4834 not actually implement them. If these options are not supported, the 4835 starttime and endtime in the ticket shall specify a ticket's entire useful 4836 life. When a postdated ticket is decoded by a server, all implementations 4837 shall make the presence of the postdated flag visible to the calling server. 4839 User-to-user authentication 4841 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option) 4842 must be provided by implementations, but individual realms may decide as a 4843 matter of policy to reject such requests on a per-principal or realm-wide 4844 basis. 4846 Authorization data 4848 Implementations must pass all authorization data subfields from 4849 ticket-granting tickets to any derivative tickets unless directed to 4850 suppress a subfield as part of the definition of that registered subfield 4851 type (it is never incorrect to pass on a subfield, and no registered 4852 subfield types presently specify suppression at the KDC). 4854 Implementations must make the contents of any authorization data subfields 4855 available to the server when a ticket is used. Implementations are not 4856 required to allow clients to specify the contents of the authorization data 4857 fields. 4859 Constant ranges 4861 All protocol constants are constrained to 32 bit (signed) values unless 4862 further constrained by the protocol definition. This limit is provided to 4863 allow implementations to make assumptions about the maximum values that will 4864 be received for these constants. Implementation receiving values outside 4865 this range may reject the request, but they must recover cleanly. 4867 8.2. Recommended KDC values 4869 Following is a list of recommended values for a KDC configuration. 4871 minimum lifetime 5 minutes 4872 maximum renewable lifetime 1 week 4873 maximum ticket lifetime 1 day 4874 empty addresses only when suitable restrictions appear 4875 in authorization data 4876 proxiable, etc. Allowed. 4878 9. IANA considerations 4880 Section 7 of this document specifies protocol constants and other defined 4881 values required for the interoperability of multiple implementations. Until 4882 otherwise specified in a subsequent RFC, allocations of additional protocol 4883 constants and other defined values required for extensions to the Kerberos 4884 protocol will be administered by the Kerberos Working Group. 4886 10. Security Considerations 4888 As an authentication service, Kerberos provides a means of verifying the 4889 identity of principals on a network. Kerberos does not, by itself, provide 4890 authorization. Applications should not accept the issuance of a service 4891 ticket by the Kerberos server as granting authority to use the service, 4892 since such applications may become vulnerable to the bypass of this 4893 authorization check in an environment if they inter-operate with other KDCs 4894 or where other options for application authentication are provided. 4896 Denial of service attacks are not solved with Kerberos. There are places in 4897 the protocols where an intruder can prevent an application from 4898 participating in the proper authentication steps. Because authentication is 4899 a required step for the use of many services, successful denial of service 4900 attacks on a Kerberos server might result in the denial of other network 4901 services that rely on Kerberos for authentication. Kerberos is vulnerable to 4902 many kinds of denial of service attacks: denial of service attacks on the 4903 network which would prevent clients from contacting the KDC; denial of 4904 service attacks on the domain name system which could prevent a client from 4905 finding the IP address of the Kerberos server; and denial of service attack 4906 by overloading the Kerberos KDC itself with repeated requests. 4908 Interoperability conflicts caused by incompatible character-set usage (see 4909 5.2.1) can result in denial of service for clients that utilize 4910 character-sets in Kerberos strings other than those stored in the KDC 4911 database. 4913 Authentication servers maintain a database of principals (i.e., users and 4914 servers) and their secret keys. The security of the authentication server 4915 machines is critical. The breach of security of an authentication server 4916 will compromise the security of all servers that rely upon the compromised 4917 KDC, and will compromise the authentication of any principals registered in 4918 the realm of the compromised KDC. 4920 Principals must keep their secret keys secret. If an intruder somehow steals 4921 a principal's key, it will be able to masquerade as that principal or 4922 impersonate any server to the legitimate principal. 4924 Password guessing attacks are not solved by Kerberos. If a user chooses a 4925 poor password, it is possible for an attacker to successfully mount an 4926 off-line dictionary attack by repeatedly attempting to decrypt, with 4927 successive entries from a dictionary, messages obtained which are encrypted 4928 under a key derived from the user's password. 4930 Unless pre-authentication options are required by the policy of a realm, the 4931 KDC will not know whether a request for authentication succeeds. An attacker 4932 can request a reply with credentials for any principal. These credentials 4933 will likely not be of much use to the attacker unless it knows the client's 4934 secret key, but the availability of the response encrypted in the client's 4935 secret key provides the attacker with ciphertext that may be used to mount 4936 brute force or dictionary attacks to decrypt the credentials, by guessing 4937 the user's password. For this reason it is strongly encouraged that Kerberos 4938 realms require the use of pre-authentication. Even with preauthentication, 4939 attackers may try brute force or dictionary attacks against credentials that 4940 are observed by eavesdropping on the network. 4942 Each host on the network must have a clock which is loosely synchronized to 4943 the time of the other hosts; this synchronization is used to reduce the 4944 bookkeeping needs of application servers when they do replay detection. The 4945 degree of "looseness" can be configured on a per-server basis, but is 4946 typically on the order of 5 minutes. If the clocks are synchronized over the 4947 network, the clock synchronization protocol must itself be secured from 4948 network attackers. 4950 Principal identifiers must not recycled on a short-term basis. A typical 4951 mode of access control will use access control lists (ACLs) to grant 4952 permissions to particular principals. If a stale ACL entry remains for a 4953 deleted principal and the principal identifier is reused, the new principal 4954 will inherit rights specified in the stale ACL entry. By not re-using 4955 principal identifiers, the danger of inadvertent access is removed. 4957 Proper decryption of an KRB_AS_REP message from the KDC is not sufficient 4958 for the host to verify the identity of the user; the user and an attacker 4959 could cooperate to generate a KRB_AS_REP format message which decrypts 4960 properly but is not from the proper KDC. To authenticate a user logging on 4961 to a local system, the credentials obtained in the AS exchange may first be 4962 used in a TGS exchange to obtain credentials for a local server. Those 4963 credentials must then be verified by a local server through successful 4964 completion of the Client/Server exchange. 4966 Kerberos credentials contain clear-text information identifying the 4967 principals to which they apply. If privacy of this information is needed, 4968 this exchange should itself be encapsulated in a protocol providing for 4969 confidentiality on the exchange of these credentials. 4971 Applications must take care to protect communications subsequent to 4972 authentication either by using the KRB_PRIV or KRB_SAFE messages as 4973 appropriate, or by applying their own confidentiality or integrity 4974 mechanisms on such communications. Completion of the KRB_AP_REQ and 4975 KRB_AP_REP exchange without subsequent use of confidentiality and integrity 4976 mechanisms provides only for authentication of the parties to the 4977 communication and not confidentiality and integrity of the subsequent 4978 communication. Application applying confidentiality and protections 4979 mechanisms other than KRB_PRIV and KRB_SAFE must make sure that the 4980 authentication step is appropriately linked with the protected communication 4981 channel that is established by the application. 4983 Unless the application server provides its own suitable means to protect 4984 against replay (for example, a challenge-response sequence initiated by the 4985 server after authentication, or use of a server-generated encryption 4986 subkey), the server must utilize a replay cache to remember any 4987 authenticator presented within the allowable clock skew. All services 4988 sharing a key need to use the same replay cache. If separate replay caches 4989 are used, then and authenticator used with one such service could later be 4990 replayed to a different service with the same service principal. 4992 If a server loses track of authenticators presented within the allowable 4993 clock skew, it must reject all requests until the clock skew interval has 4994 passed, providing assurance that any lost or replayed authenticators will 4995 fall outside the allowable clock skew and can no longer be successfully 4996 replayed. 4998 Implementations of Kerberos should not use untrusted directory servers to 4999 determine the realm of a host. To allow such would allow the compromise of 5000 the directory server to enable an attacker to direct the client to accept 5001 authentication with the wrong principal, i.e. one with a similar name, but 5002 in a realm with which the legitimate host was not registered. 5004 Implementations of Kerberos must not use DNS to canonicalize the host 5005 components of service principal names. To allow such canonicalization would 5006 allow a compromise of the DNS to result in a client obtaining credentials 5007 and correctly authenticating to the wrong principal. Though the client will 5008 know who it is communicating with, it will not be the principal with which 5009 it intended to communicate. 5011 If the Kerberos server returns a TGT for a 'closer' realm other than the 5012 desired realm, the client may wish to use local policy configuration to 5013 verify that the authentication path used is an acceptable one. 5014 Alternatively, a client may wish to choose its own authentication path, 5015 rather than relying on the Kerberos server to select one. In either case, 5016 any policy or configuration information used to choose or validate 5017 authentication paths, whether by the Kerberos server or client, must be 5018 obtained from a trusted source. 5020 The Kerberos protocol in its basic form does not provide perfect forward 5021 secrecy for communications. If traffic has been recorded by an eavesdropper, 5022 then messages encrypted using the KRB_PRIV message, or messages encrypted 5023 using application specific encryption under keys exchanged using Kerberos 5024 can be decrypted if the any of the user's, application server's, or KDC's 5025 key is subsequently discovered. This is because the session key use to 5026 encrypt such messages is transmitted over the network encrypted in the key 5027 of the application server, and also encrypted under the session key from the 5028 user's ticket granting ticket when returned to the user in the KRB_TGS_REP 5029 message. The session key from the ticket granting ticket was sent to the 5030 user in the KRB_AS_REP message encrypted in the user's secret key, and 5031 embedded in the ticket granting ticket, which was encrypted in the key of 5032 the KDC. Application requiring perfect forward secrecy must exchange keys 5033 through mechanisms that provide such assurance, but may use Kerberos for 5034 authentication of the encrypted channel established through such other 5035 means. 5037 11. Acknowledgement and References 5039 11.1 ACKNOWLEDGEMENTS 5041 The specification of the Kerberos protocol described in this document is the 5042 result of many years of effort. Over this period many individuals have 5043 contributed to the definition of the protocol and to the writing of the 5044 specification. Unfortunately it is not possible to list all contributors as 5045 authors of this document, though there are many not listed who are authors 5046 in spirit, because they contributed text for parts of some sections, because 5047 they contributed to the design of parts of the protocol, or because they 5048 contributed significantly to the discussion of the protocol in the IETF 5049 common authentication technology (CAT) and Kerberos working groups. 5051 Among those contributing to the development and specification of Kerberos 5052 were John Brezac, Marc Colan, Don Davis, Doug Engert, Dan Geer, Paul Hill, 5053 Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, Ari 5054 Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome Saltzer, 5055 Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, Brian Tung, and 5056 Assar Westerlund. Many other members of MIT Project Athena, the MIT 5057 networking group, and the Kerberos and CAT working groups of the IETF 5058 contributed but are not listed. 5060 11.1. REFERENCES 5062 [Blumenthal96] 5063 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers", 5064 Proceedings of PRAGOCRYPT '96, 1996. 5065 [Bellare98] 5066 Bellare, M., Desai, A., Pointcheval, D., Rogaway, P., "Relations Among 5067 Notions of Security for Public-Key Encryption Schemes". Extended 5068 abstract published in Advances in Cryptology- Crypto 98 Proceedings, 5069 Lecture Notes in Computer Science Vol. 1462, H. Krawcyzk ed., 5070 Springer-Verlag, 1998. 5071 [DES77] 5072 National Bureau of Standards, U.S. Department of Commerce, "Data 5073 Encryption Standard," Federal Information Processing Standards 5074 Publication 46, Washington, DC (1977). 5075 [DESM80] 5076 National Bureau of Standards, U.S. Department of Com- merce, "DES Modes 5077 of Operation," Federal Information Processing Standards Publication 81, 5078 Springfield, VA (December 1980). 5079 [Dolev91] 5080 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 5081 Proceedings of the 23rd Annual Symposium on Theory of Computing, ACM, 5082 1991. 5083 [DS81] 5084 Dorothy E. Denning and Giovanni Maria Sacco, "Time- stamps in Key 5085 Distribution Protocols," Communications of the ACM, Vol. 24(8), pp. 5086 533-536 (August 1981). 5087 [DS90] 5088 Don Davis and Ralph Swick, "Workstation Services and Kerberos 5089 Authentication at Project Athena," Technical Memorandum TM-424, MIT 5090 Laboratory for Computer Science (February 1990). 5091 [Horowitz96] 5092 Horowitz, M., "Key Derivation for Authentication, Integrity, and 5093 Privacy", draft-horowitz-key-derivation-02.txt, August 1998. 5094 [HorowitzB96] 5095 Horowitz, M., "Key Derivation for Kerberos V5", draft- 5096 horowitz-kerb-key-derivation-01.txt, September 1998. 5097 [IS3309] 5098 International Organization for Standardization, "ISO Information 5099 Processing Systems - Data Communication - High-Level Data Link Control 5100 Procedure - Frame Struc- ture," IS 3309 (October 1984). 3rd Edition. 5101 [ISO-646/ECMA-6] 5102 7-bit Coded Character Set 5103 [ISO-1022/ECMA-35] 5104 Character Code Structure and Extension Techniques 5105 [ISO-4873/ECMA-43] 5106 8-bit Coded Character Set Structure and Rules 5107 [KBC96] 5108 H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- Hashing for 5109 Message Authentication," Working Draft 5110 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 5111 [KNT92] 5112 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The Evolution 5113 of the Kerberos Authentication Service," in an IEEE Computer Society 5114 Text soon to be published (June 1992). 5116 [Krawczyk96] 5117 Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: Keyed-Hashing for 5118 Message Authentication", draft-ietf-ipsec-hmac- md5-01.txt, August, 5119 1996. 5120 [LGDSR87] 5121 P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- merfeld, and K. 5122 Raeburn, Section E.1: Service Manage- ment System, M.I.T. Project 5123 Athena, Cambridge, Mas- sachusetts (1987). 5124 [MD4-92] 5125 R. Rivest, "The MD4 Message Digest Algorithm," RFC 1320, MIT Laboratory 5126 for Computer Science (April 1992). 5127 [MD5-92] 5128 R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, MIT Laboratory 5129 for Computer Science (April 1992). 5130 [MNSS87] 5131 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section 5132 E.2.1: Kerberos Authentication and Authorization System, M.I.T. Project 5133 Athena, Cambridge, Massachusetts (December 21, 1987). 5134 [Neu93] 5135 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 5136 Distributed Systems," in Proceedings of the 13th International 5137 Conference on Distributed Com- puting Systems, Pittsburgh, PA (May, 5138 1993). 5139 [NS78] 5140 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5141 Authentication in Large Networks of Com- puters," Communications of the 5142 ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5143 [NT94] 5144 B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- cation Service 5145 for Computer Networks," IEEE Communica- tions Magazine, Vol. 32(9), pp. 5146 33-38 (September 1994). 5147 [Pat92]. 5148 J. Pato, Using Pre-Authentication to Avoid Password Guessing Attacks, 5149 Open Software Foundation DCE Request for Comments 26 (December 1992). 5150 [RFC-2279] 5151 UTF-8, a transformation format of ISO-10646 5152 [SG92] 5153 Stuart G. Stubblebine and Virgil D. Gligor, "On Message Integrity in 5154 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 5155 Research in Security and Privacy, Oakland, California (May 1992). 5156 [SNS88] 5157 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- beros: An 5158 Authentication Service for Open Network Sys- tems," pp. 191-202 in 5159 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 5160 [X509-88] 5161 CCITT, Recommendation X.509: The Directory Authentica- tion Framework, 5162 December 1988. 5163 [X680] 5164 Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, 5165 ITU-T Recommendation X.680 (1997) | ISO/IEC International Standard 5166 8824-1:1998. 5167 [X690] 5168 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 5169 Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 5170 ITU-T Recommendation X.690 (1997)| ISO/IEC International Standard 5171 8825-1:1998. 5173 A. ASN.1 module 5175 KerberosV5Spec2 { 5176 iso(1) identified-organization(3) dod(6) internet(1) 5177 security(5) kerberosV5(2) modules(4) krb5spec2(2) 5178 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 5180 -- OID arc for KerberosV5 5181 -- 5182 -- This OID may be used to identify Kerberos protocol messages 5183 -- encapsulated in other protocols. 5184 -- 5185 -- This OID also designates the OID arc for KerberosV5-related OIDs. 5186 -- 5187 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. 5188 id-krb5 OBJECT IDENTIFIER ::= { 5189 iso(1) identified-organization(3) dod(6) internet(1) 5190 security(5) kerberosV5(2) 5191 } 5193 Int32 ::= INTEGER (-2147483648..2147483647) 5194 -- signed values representable in 32 bits 5196 UInt32 ::= INTEGER (0..4294967295) 5197 -- unsigned 32 bit values 5199 Microseconds ::= INTEGER (0..999999) 5200 -- microseconds 5202 KerberosString ::= GeneralString (IA5String) 5204 Realm ::= KerberosString 5206 PrincipalName ::= SEQUENCE { 5207 name-type [0] Int32, 5208 name-string [1] SEQUENCE OF KerberosString 5209 } 5211 KerberosTime ::= GeneralizedTime -- with no fractional seconds 5213 HostAddress ::= SEQUENCE { 5214 addr-type [0] Int32, 5215 address [1] OCTET STRING 5216 } 5218 -- NOTE: HostAddresses is always used as an OPTIONAL field and 5219 -- should not be empty. 5220 HostAddresses -- NOTE: subtly different from rfc1510, 5221 -- but has a value mapping and encodes the same 5222 ::= SEQUENCE OF HostAddress 5224 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 5225 -- should not be empty. 5226 AuthorizationData ::= SEQUENCE OF SEQUENCE { 5227 ad-type [0] Int32, 5228 ad-data [1] OCTET STRING 5229 } 5230 PA-DATA ::= SEQUENCE { 5231 -- NOTE: first tag is [1], not [0] 5232 padata-type [1] Int32, 5233 padata-value [2] OCTET STRING -- might be encoded AP-REQ 5234 } 5236 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 5237 -- shall be sent, but no fewer than 32 5239 EncryptedData ::= SEQUENCE { 5240 etype [0] Int32 -- EncryptionType --, 5241 kvno [1] UInt32 OPTIONAL, 5242 cipher [2] OCTET STRING -- ciphertext 5243 } 5245 EncryptionKey ::= SEQUENCE { 5246 keytype [0] Int32 -- actually encryption type --, 5247 keyvalue [1] OCTET STRING 5248 } 5250 Checksum ::= SEQUENCE { 5251 cksumtype [0] Int32, 5252 checksum [1] OCTET STRING 5253 } 5255 Ticket ::= [APPLICATION 1] SEQUENCE { 5256 tkt-vno [0] INTEGER (5), 5257 realm [1] Realm, 5258 sname [2] PrincipalName, 5259 enc-part [3] EncryptedData -- EncTicketPart 5260 } 5262 -- Encrypted part of ticket 5263 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 5264 flags [0] TicketFlags, 5265 key [1] EncryptionKey, 5266 crealm [2] Realm, 5267 cname [3] PrincipalName, 5268 transited [4] TransitedEncoding, 5269 authtime [5] KerberosTime, 5270 starttime [6] KerberosTime OPTIONAL, 5271 endtime [7] KerberosTime, 5272 renew-till [8] KerberosTime OPTIONAL, 5273 caddr [9] HostAddresses OPTIONAL, 5274 authorization-data [10] AuthorizationData OPTIONAL 5275 } 5277 -- encoded Transited field 5278 TransitedEncoding ::= SEQUENCE { 5279 tr-type [0] Int32 -- must be registered --, 5280 contents [1] OCTET STRING 5281 } 5282 TicketFlags ::= KerberosFlags 5283 -- reserved(0), 5284 -- forwardable(1), 5285 -- forwarded(2), 5286 -- proxiable(3), 5287 -- proxy(4), 5288 -- may-postdate(5), 5289 -- postdated(6), 5290 -- invalid(7), 5291 -- renewable(8), 5292 -- initial(9), 5293 -- pre-authent(10), 5294 -- hw-authent(11), 5295 -- the following are new since 1510 5296 -- transited-policy-checked(12), 5297 -- ok-as-delegate(13) 5299 AS-REQ ::= [APPLICATION 10] KDC-REQ 5301 TGS-REQ ::= [APPLICATION 12] KDC-REQ 5303 KDC-REQ ::= SEQUENCE { 5304 -- NOTE: first tag is [1], not [0] 5305 pvno [1] INTEGER (5) , 5306 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 5307 padata [3] SEQUENCE OF PA-DATA OPTIONAL 5308 -- NOTE: not empty --, 5309 req-body [4] KDC-REQ-BODY 5310 } 5312 KDC-REQ-BODY ::= SEQUENCE { 5313 kdc-options [0] KDCOptions, 5314 cname [1] PrincipalName OPTIONAL 5315 -- Used only in AS-REQ --, 5316 realm [2] Realm 5317 -- Server's realm 5318 -- Also client's in AS-REQ --, 5319 sname [3] PrincipalName OPTIONAL, 5320 from [4] KerberosTime OPTIONAL, 5321 till [5] KerberosTime, 5322 rtime [6] KerberosTime OPTIONAL, 5323 nonce [7] UInt32, 5324 etype [8] SEQUENCE OF Int32 -- EncryptionType 5325 -- in preference order --, 5326 addresses [9] HostAddresses OPTIONAL, 5327 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 5328 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 5329 -- NOTE: not empty 5330 } 5331 KDCOptions ::= KerberosFlags 5332 -- reserved(0), 5333 -- forwardable(1), 5334 -- forwarded(2), 5335 -- proxiable(3), 5336 -- proxy(4), 5337 -- allow-postdate(5), 5338 -- postdated(6), 5339 -- unused7(7), 5340 -- renewable(8), 5341 -- unused9(9), 5342 -- unused10(10), 5343 -- opt-hardware-auth(11), 5344 -- unused12(12), 5345 -- unused13(13), 5346 -- 15 is reserved for canonicalize 5347 -- unused15(15), 5348 -- 26 was unused in 1510 5349 -- disable-transited-check(26), 5350 -- 5351 -- renewable-ok(27), 5352 -- enc-tkt-in-skey(28), 5353 -- renew(30), 5354 -- validate(31) 5356 AS-REP ::= [APPLICATION 11] KDC-REP 5358 TGS-REP ::= [APPLICATION 13] KDC-REP 5360 KDC-REP ::= SEQUENCE { 5361 pvno [0] INTEGER (5), 5362 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 5363 padata [2] SEQUENCE OF PA-DATA OPTIONAL 5364 -- NOTE: not empty --, 5365 crealm [3] Realm, 5366 cname [4] PrincipalName, 5367 ticket [5] Ticket, 5368 enc-part [6] EncryptedData 5369 -- EncASRepPart or EncTGSRepPart, 5370 -- as appropriate 5371 } 5373 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 5375 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 5376 EncKDCRepPart ::= SEQUENCE { 5377 key [0] EncryptionKey, 5378 last-req [1] LastReq, 5379 nonce [2] UInt32, 5380 key-expiration [3] KerberosTime OPTIONAL, 5381 flags [4] TicketFlags, 5382 authtime [5] KerberosTime, 5383 starttime [6] KerberosTime OPTIONAL, 5384 endtime [7] KerberosTime, 5385 renew-till [8] KerberosTime OPTIONAL, 5386 srealm [9] Realm, 5387 sname [10] PrincipalName, 5388 caddr [11] HostAddresses OPTIONAL 5389 } 5391 LastReq ::= SEQUENCE OF SEQUENCE { 5392 lr-type [0] Int32, 5393 lr-value [1] KerberosTime 5394 } 5396 AP-REQ ::= [APPLICATION 14] SEQUENCE { 5397 pvno [0] INTEGER (5), 5398 msg-type [1] INTEGER (14), 5399 ap-options [2] APOptions, 5400 ticket [3] Ticket, 5401 authenticator [4] EncryptedData -- Authenticator 5402 } 5404 APOptions ::= KerberosFlags 5405 -- reserved(0), 5406 -- use-session-key(1), 5407 -- mutual-required(2) 5409 -- Unencrypted authenticator 5410 Authenticator ::= [APPLICATION 2] SEQUENCE { 5411 authenticator-vno [0] INTEGER (5), 5412 crealm [1] Realm, 5413 cname [2] PrincipalName, 5414 cksum [3] Checksum OPTIONAL, 5415 cusec [4] Microseconds, 5416 ctime [5] KerberosTime, 5417 subkey [6] EncryptionKey OPTIONAL, 5418 seq-number [7] UInt32 OPTIONAL, 5419 authorization-data [8] AuthorizationData OPTIONAL 5420 } 5422 AP-REP ::= [APPLICATION 15] SEQUENCE { 5423 pvno [0] INTEGER (5), 5424 msg-type [1] INTEGER (15), 5425 enc-part [2] EncryptedData -- EncAPRepPart 5426 } 5427 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 5428 ctime [0] KerberosTime, 5429 cusec [1] Microseconds, 5430 subkey [2] EncryptionKey OPTIONAL, 5431 seq-number [3] UInt32 OPTIONAL 5432 } 5434 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 5435 pvno [0] INTEGER (5), 5436 msg-type [1] INTEGER (20), 5437 safe-body [2] KRB-SAFE-BODY, 5438 cksum [3] Checksum 5439 } 5441 KRB-SAFE-BODY ::= SEQUENCE { 5442 user-data [0] OCTET STRING, 5443 timestamp [1] KerberosTime OPTIONAL, 5444 usec [2] Microseconds OPTIONAL, 5445 seq-number [3] UInt32 OPTIONAL, 5446 s-address [4] HostAddress, 5447 r-address [5] HostAddress OPTIONAL 5448 } 5450 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 5451 pvno [0] INTEGER (5), 5452 msg-type [1] INTEGER (21), 5453 -- NOTE: there is no [2] tag 5454 enc-part [3] EncryptedData -- EncKrbPrivPart 5455 } 5457 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 5458 user-data [0] OCTET STRING, 5459 timestamp [1] KerberosTime OPTIONAL, 5460 usec [2] Microseconds OPTIONAL, 5461 seq-number [3] UInt32 OPTIONAL, 5462 s-address [4] HostAddress -- sender's addr --, 5463 r-address [5] HostAddress OPTIONAL -- recip's addr 5464 } 5466 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 5467 pvno [0] INTEGER (5), 5468 msg-type [1] INTEGER (22), 5469 tickets [2] SEQUENCE OF Ticket, 5470 enc-part [3] EncryptedData -- EncKrbCredPart 5471 } 5473 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 5474 ticket-info [0] SEQUENCE OF KrbCredInfo, 5475 nonce [1] UInt32 OPTIONAL, 5476 timestamp [2] KerberosTime OPTIONAL, 5477 usec [3] Microseconds OPTIONAL, 5478 s-address [4] HostAddress OPTIONAL, 5479 r-address [5] HostAddress OPTIONAL 5480 } 5481 KrbCredInfo ::= SEQUENCE { 5482 key [0] EncryptionKey, 5483 prealm [1] Realm OPTIONAL, 5484 pname [2] PrincipalName OPTIONAL, 5485 flags [3] TicketFlags OPTIONAL, 5486 authtime [4] KerberosTime OPTIONAL, 5487 starttime [5] KerberosTime OPTIONAL, 5488 endtime [6] KerberosTime OPTIONAL, 5489 renew-till [7] KerberosTime OPTIONAL, 5490 srealm [8] Realm OPTIONAL, 5491 sname [9] PrincipalName OPTIONAL, 5492 caddr [10] HostAddresses OPTIONAL 5493 } 5495 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 5496 pvno [0] INTEGER (5), 5497 msg-type [1] INTEGER (30), 5498 ctime [2] KerberosTime OPTIONAL, 5499 cusec [3] Microseconds OPTIONAL, 5500 stime [4] KerberosTime, 5501 susec [5] Microseconds, 5502 error-code [6] Int32, 5503 crealm [7] Realm OPTIONAL, 5504 cname [8] PrincipalName OPTIONAL, 5505 realm [9] Realm -- service realm --, 5506 sname [10] PrincipalName -- service name --, 5507 e-text [11] KerberosString OPTIONAL, 5508 e-data [12] OCTET STRING OPTIONAL 5509 } 5511 METHOD-DATA ::= SEQUENCE OF PA-DATA 5513 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 5514 data-type [0] INTEGER, 5515 data-value [1] OCTET STRING OPTIONAL 5516 } 5518 -- preauth stuff follows 5520 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 5522 PA-ENC-TS-ENC ::= SEQUENCE { 5523 patimestamp [0] KerberosTime -- client's time --, 5524 pausec [1] Microseconds OPTIONAL 5525 } 5527 ETYPE-INFO-ENTRY ::= SEQUENCE { 5528 etype [0] Int32, 5529 salt [1] OCTET STRING OPTIONAL 5530 } 5532 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 5533 ETYPE-INFO2-ENTRY ::= SEQUENCE { 5534 etype [0] Int32, 5535 salt [1] KerberosString OPTIONAL, 5536 s2kparams [2] OCTET STRING OPTIONAL 5537 } 5539 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY 5541 AD-IF-RELEVANT ::= AuthorizationData 5543 AD-KDCIssued ::= SEQUENCE { 5544 ad-checksum [0] Checksum, 5545 i-realm [1] Realm OPTIONAL, 5546 i-sname [2] PrincipalName OPTIONAL, 5547 elements [3] AuthorizationData 5548 } 5550 AD-AND-OR ::= SEQUENCE { 5551 condition-count [0] INTEGER, 5552 elements [1] AuthorizationData 5553 } 5555 AD-MANDATORY-FOR-KDC ::= AuthorizationData 5557 END 5558 B. Changes since RFC-1510 5560 This document replaces RFC-1510 and clarifies specification of items that 5561 were not completely specified. Where changes to recommended implementation 5562 choices were made, or where new options were added, those changes are 5563 described within the document and listed in this section. More 5564 significantly, "Specification 2" in section 8 changes the required 5565 encryption and checksum methods to bring them in line with the best current 5566 practices and to deprecate methods that are no longer considered 5567 sufficiently strong. 5569 B.1 Changes to Section 1 5571 Discussion was added to section on regarding the ability to rely on the KDC 5572 to check the transited field, and on the inclusion of a flag in a ticket 5573 indicating that this check has occurred. This is a new capability not 5574 present in RFC1510. Pre-existing implementations may ignore or not set this 5575 flag without negative security implications. 5577 The definition of the secret key says that in the case of a user the key may 5578 be derived from a password. In 1510, it said that the key was derived from 5579 the password. This change was made to accommodate situations where the user 5580 key might be stored on a smart-card, or otherwise obtained independent of a 5581 password. 5583 The introduction also mentions the use of public key for initial 5584 authentication in Kerberos by reference. RFC1510 did not include such a 5585 reference. 5587 Section 1.2 was added to explain that while Kerberos provides authentication 5588 of a named principal, it is still the responsibility of the application to 5589 ensure that the authenticated name is the entity with which the application 5590 wishes to communicate. 5592 Discussion of extensibility has been added to the introduction. 5594 B.1 Changes to Section 2 5596 Discussion of how extensibility affects ticket flags and KDC options was 5597 added to the introduction. No changes were made to existing options and 5598 flags specified in RFC1510, though some of the sections in the specification 5599 were renumbered, and text was revised to make the description and intent of 5600 existing options clearer, especially with respect to the ENC-TKT-IN-SKEY 5601 option (now section 2.8.2) which is used for user-to-user authentication. 5602 The new option and ticket flag transited policy checking (section 2.7) was 5603 added. 5605 B.2 Changes to Section 3 5607 A warning regarding generation of session keys for application use was 5608 added, urging the inclusion of key entropy from the KDC generated session 5609 key in the ticket. An example regarding use of the sub-session key was added 5610 to section 3.2.6. Descriptions of the pa-etype-info, and pa-pw-salt 5611 preauthentication data items were added. The recommendation for use of 5612 preauthentication was changed from "may" to "should" and a note was added 5613 regarding known plaintext attacks. 5615 B.3 Changes to Section 4 5617 In RFC 1510, section 4 described the database in the KDC. This discussion 5618 was not necessary for interoperability and unnecessarily constrained 5619 implementation. The old section 4 was removed. 5621 The current section 4 was formerly section 6 on encryption and checksum 5622 specifications. The major part of this section was brought up to date to 5623 support new encryption methods, and move to a separate document. Those few 5624 remaining aspects of the encryption and checksum specification specific to 5625 Kerberos are now specified in section 4. 5627 B.5 Changes to Section 5 5629 Significant changes were made to the layout of section 5 to clarify the 5630 correct behavior for optional fields. Many of these changes were made 5631 necessary because of improper ASN.1 description in the original Kerberos 5632 specification which left the correct behavior underspecified. Additionally, 5633 the wording in this section was tightened wherever possible to ensure that 5634 implementations conforming to this specification will be extensible with the 5635 addition of new fields in future specifications. 5637 Text was added describing time_t=0 issues in the ASN.1. Text was also added, 5638 clarifying issues with implementations treating omitted optional integers as 5639 zero. Text was added clarifying behavior for optional SEQUENCE or SEQUENCE 5640 OF that may be empty. Discussion was added regarding sequence numbers and 5641 behavior of some implementations, including "zero" behavior and negative 5642 numbers. A compatibility note was added regarding the unconditional sending 5643 of EncTGSRepPart regardless of the enclosing reply type. Minor changes were 5644 made to the description of the HostAddresses type. Integer types were 5645 constrained. KerberosString was defined as a (significantly) constrained 5646 GeneralString. KerberosFlags was defined to reflect existing implementation 5647 behavior that departs from the definition in RFC 1510. The 5648 transited-policy-checked(12) and the ok-as-delegate(13) ticket flags were 5649 added. The disable-transited-check(26) KDC option was added. 5651 Descriptions of commonly implemented PA-DATA were added to section 5. The 5652 description of KRB-SAFE has been updated to note the existing implementation 5653 behavior of of double-encoding. 5655 There were two definitions of METHOD-DATA in RFC 1510. The second one, 5656 intended for use with KRB_AP_ERR_METHOD was removed leaving the SEQUENCE OF 5657 PA-DATA definition. 5659 B.6 Changes to Section 6 5661 The old section 6 on encryption and checksums was moved to section 4, and 5662 changes were already described. The new section 6, naming constraints was 5663 formerly section 7. 5665 Words were added describing the convention that domain based realm names for 5666 newly created realms should be specified as upper case. This recommendation 5667 does not make lower case realm names illegal. Words were added highlighting 5668 that the slash separated components in the X500 style of realm names is 5669 consistent with existing RFC1510 based implementations, but that it 5670 conflicts with the general recommendation of X.500 name representation 5671 specified in RFC2253. 5673 B.7 Changes to Section 7 5675 The current section 7 was formerly section 8, on network transport, 5676 constants and defined values. Since RFC1510, the definition of the TCP 5677 transport for Kerberos messages was added, and the encryption and checksum 5678 number assignments have been moved into a separate document. 5680 B.8 Changes to Section 8 5682 "Specification 2" in section 8 changes the required encryption and checksum 5683 methods to bring them in line with the best current practices and to 5684 deprecate methods that are no longer considered sufficiently strong. 5686 B.9 New section 9 and 10 added 5688 Two new section, on IANA considerations and security considerations were 5689 added. 5691 B.11 Change to Appendices 5693 The pseudo-code has been removed from the appendix. The pseudo-code was 5694 sometimes misinterpreted to limit implementation choices and in RFC 1510, it 5695 was not always consistent with the words in the specification. Effort was 5696 made to clear up any ambiguities in the specification, rather than to rely 5697 on the pseudo-code. 5699 An appendix was added containing the complete ASN.1 module drawn from the 5700 discussion in section 5. 5702 An appendix was added defining those authorization data elements that must 5703 be understood by all Kerberos implementations. 5705 FOOTNOTES 5707 [TM] Project Athena, Athena, and Kerberos are trademarks of the 5708 Massachusetts Institute of Technology (MIT). No commercial use of these 5709 trademarks may be made without prior written permission of MIT. 5711 [1.1] Note, however, that many applications use Kerberos' functions only 5712 upon the initiation of a stream-based network connection. Unless an 5713 application subsequently provides integrity protection for the data stream, 5714 the identity verification applies only to the initiation of the connection, 5715 and does not guarantee that subsequent messages on the connection originate 5716 from the same principal. 5718 [1.2] Secret and private are often used interchangeably in the literature. 5719 In our usage, it takes two (or more) to share a secret, thus a shared DES 5720 key is a secret key. Something is only private when no one but its owner 5721 knows it. Thus, in public key cryptosystems, one has a public and a private 5722 key. 5724 [1.3] Of course, with appropriate permission the client could arrange 5725 registration of a separately-named principal in a remote realm, and engage 5726 in normal exchanges with that realm's services. However, for even small 5727 numbers of clients this becomes cumbersome, and more automatic methods as 5728 described here are necessary. 5730 [2.1] Though it is permissible to request or issue tickets with no network 5731 addresses specified. 5733 [3.1] The password-changing request must not be honored unless the requester 5734 can provide the old password (the user's current secret key). Otherwise, it 5735 would be possible for someone to walk up to an unattended session and change 5736 another user's password. 5738 [3.2] To authenticate a user logging on to a local system, the credentials 5739 obtained in the AS exchange may first be used in a TGS exchange to obtain 5740 credentials for a local server. Those credentials must then be verified by a 5741 local server through successful completion of the Client/Server exchange. 5743 [3.3] "Random" means that, among other things, it should be impossible to 5744 guess the next session key based on knowledge of past session keys. This can 5745 only be achieved in a pseudo-random number generator if it is based on 5746 cryptographic principles. It is more desirable to use a truly random number 5747 generator, such as one based on measurements of random physical phenomena. 5749 [3.4] Tickets contain both an encrypted and unencrypted portion, so 5750 cleartext here refers to the entire unit, which can be copied from one 5751 message and replayed in another without any cryptographic skill. 5753 [3.5] Note that this can make applications based on unreliable transports 5754 difficult to code correctly. If the transport might deliver duplicated 5755 messages, either a new authenticator must be generated for each retry, or 5756 the application server must match requests and replies and replay the first 5757 reply in response to a detected duplicate. 5759 ------------------------------------------------------------------------ 5760 ------------------------------------------------------------------------ 5761 [3.7]Note also that the rejection here is restricted to authenticators from 5762 the same principal to the same server. Other client principals communicating 5763 with the same server principal should not be have their authenticators 5764 rejected if the time and microsecond fields happen to match some other 5765 client's authenticator. 5767 [3.8] If this is not done, an attacker could subvert the authentication by 5768 recording the ticket and authenticator sent over the network to a server and 5769 replaying them following an event that caused the server to lose track of 5770 recently seen authenticators. 5772 [3.9] In the Kerberos version 4 protocol, the timestamp in the reply was the 5773 client's timestamp plus one. This is not necessary in version 5 because 5774 version 5 messages are formatted in such a way that it is not possible to 5775 create the reply by judicious message surgery (even in encrypted form) 5776 without knowledge of the appropriate encryption keys. 5778 [3.10] Note that for encrypting the KRB_AP_REP message, the sub-session key 5779 is not used, even if present in the Authenticator. 5781 [3.11] Implementations of the protocol may wish to provide routines to 5782 choose subkeys based on session keys and random numbers and to generate a 5783 negotiated key to be returned in the KRB_AP_REP message. 5785 [3.12]This can be accomplished in several ways. It might be known beforehand 5786 (since the realm is part of the principal identifier), it might be stored in 5787 a nameserver, or it might be obtained from a configuration file. If the 5788 realm to be used is obtained from a nameserver, there is a danger of being 5789 spoofed if the nameservice providing the realm name is not authenticated. 5790 This might result in the use of a realm which has been compromised, and 5791 would result in an attacker's ability to compromise the authentication of 5792 the application server to the client. 5794 [3.13] If the client selects a sub-session key, care must be taken to ensure 5795 the randomness of the selected sub-session key. One approach would be to 5796 generate a random number and XOR it with the session key from the 5797 ticket-granting ticket. 5799 [4.1] Perhaps one of the more common reasons for directly performing 5800 encryption is direct control over the negotiation and to select a 5801 "sufficiently strong" encryption algorithm (whatever that means in the 5802 context of a given application). While Kerberos directly provides no 5803 facility for negotiating encryption types between the application client and 5804 server, there are other means for accomplishing similar goals. For example, 5805 requesting only "sufficiently strong" session key types from the KDC, and 5806 assuming that any type returned by the KDC will be understood and supported 5807 by the application server.