idnits 2.17.1 draft-ietf-krb-wg-kerberos-clarifications-01.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 75 longer pages, the longest (page 9) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10. IANA considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 78 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** There are 539 instances of lines with control characters in the document. ** The abstract seems to contain references ([DS81], [MNSS87], [NT94], [KNT92], [NS78], [SNS88], [KCRYPTO], [Neu93]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 357: '...authentication SHOULD fail. One of the...' RFC 2119 keyword, line 529: '...VALID flags clients MUST ignore ticket...' RFC 2119 keyword, line 530: '...recognized. KDCs MUST ignore KDC optio...' RFC 2119 keyword, line 536: '...own options, clients MUST confirm that...' RFC 2119 keyword, line 884: '...ocessed, the KDC MUST respond with an ...' (146 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 3817 has weird spacing: '... value mean...' == Line 4140 has weird spacing: '...e value comme...' == Line 4434 has weird spacing: '...uitable restr...' == 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 (September 9, 2002) is 7893 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 4508 looks like a reference -- Missing reference section? 'SNS88' on line 4517 looks like a reference -- Missing reference section? 'MNSS87' on line 4497 looks like a reference -- Missing reference section? 'NS78' on line 4505 looks like a reference -- Missing reference section? 'DS81' on line 4467 looks like a reference -- Missing reference section? 'KNT92' on line 4484 looks like a reference -- Missing reference section? 'Neu93' on line 4501 looks like a reference -- Missing reference section? 'KCRYPTO' on line 3735 looks like a reference -- Missing reference section? '18' on line 1574 looks like a reference -- Missing reference section? '19' on line 1586 looks like a reference -- Missing reference section? '20' on line 1674 looks like a reference -- Missing reference section? 'RFC1510' on line 1857 looks like a reference -- Missing reference section? 'RFC1964' on line 1857 looks like a reference -- Missing reference section? '0' on line 4999 looks like a reference -- Missing reference section? '1' on line 5000 looks like a reference -- Missing reference section? '2' on line 4950 looks like a reference -- Missing reference section? 'Pat92' on line 4511 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 4619 looks like a reference -- Missing reference section? '3' on line 4951 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 4627 looks like a reference -- Missing reference section? '4' on line 4872 looks like a reference -- Missing reference section? '5' on line 4873 looks like a reference -- Missing reference section? '6' on line 4874 looks like a reference -- Missing reference section? '7' on line 4875 looks like a reference -- Missing reference section? '8' on line 5179 looks like a reference -- Missing reference section? '9' on line 4877 looks like a reference -- Missing reference section? '10' on line 4878 looks like a reference -- Missing reference section? '24' on line 2570 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 2692 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 2694 looks like a reference -- Missing reference section? '11' on line 4879 looks like a reference -- Missing reference section? '25' on line 2927 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 2980 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2982 looks like a reference -- Missing reference section? 'APPLICATION 25' on line 4739 looks like a reference -- Missing reference section? 'APPLICATION 26' on line 4740 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 4761 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 4777 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 4792 looks like a reference -- Missing reference section? 'APPLICATION 27' on line 4799 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 4806 looks like a reference -- Missing reference section? 'APPLICATION 21' on line 4821 looks like a reference -- Missing reference section? 'APPLICATION 28' on line 4828 looks like a reference -- Missing reference section? '32' on line 3409 looks like a reference -- Missing reference section? 'APPLICATION 22' on line 4837 looks like a reference -- Missing reference section? 'APPLICATION 29' on line 4845 looks like a reference -- Missing reference section? 'APPLICATION 30' on line 4867 looks like a reference -- Missing reference section? '12' on line 4880 looks like a reference -- Missing reference section? 'RFC 1779' on line 3825 looks like a reference -- Missing reference section? 'Westerlund' on line 3986 looks like a reference -- Missing reference section? 'RFC2373' on line 3913 looks like a reference -- Missing reference section? 'RFC1884' on line 3914 looks like a reference -- Missing reference section? 'Danielsson' on line 3986 looks like a reference -- Missing reference section? 'RFC 1035' on line 4043 looks like a reference -- Missing reference section? 'RFC 2253' on line 4237 looks like a reference -- Missing reference section? '40' on line 4266 looks like a reference -- Missing reference section? 'Blumenthal96' on line 4451 looks like a reference -- Missing reference section? 'Bellare98' on line 4453 looks like a reference -- Missing reference section? 'DES77' on line 4458 looks like a reference -- Missing reference section? 'DESM80' on line 4461 looks like a reference -- Missing reference section? 'Dolev91' on line 4464 looks like a reference -- Missing reference section? 'DS90' on line 4470 looks like a reference -- Missing reference section? 'Horowitz96' on line 4473 looks like a reference -- Missing reference section? 'HorowitzB96' on line 4475 looks like a reference -- Missing reference section? 'IS3309' on line 4477 looks like a reference -- Missing reference section? 'KBC96' on line 4481 looks like a reference -- Missing reference section? 'Krawczyk96' on line 4487 looks like a reference -- Missing reference section? 'LGDSR87' on line 4490 looks like a reference -- Missing reference section? 'MD4-92' on line 4493 looks like a reference -- Missing reference section? 'MD5-92' on line 4495 looks like a reference -- Missing reference section? 'SG92' on line 4514 looks like a reference -- Missing reference section? 'X509-88' on line 4520 looks like a reference -- Missing reference section? 'TM' on line 5121 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 76 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 September 9, 2002 9 Expires 9 March, 2003 11 The Kerberos Network Authentication Service (V5) 12 draft-ietf-krb-wg-kerberos-clarifications-01.txt 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 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them 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-01.txt, and expires 9 March 40 2003. Please send comments to: ietf-krb-wg@anl.gov 41 43 ABSTRACT 45 This document provides an overview and specification of Version 5 of the 46 Kerberos protocol, and updates RFC1510 to clarify aspects of the 47 protocol and its intended use that require more detailed or clearer 48 explanation than was provided in RFC1510. This document is intended to 49 provide a detailed description of the protocol, suitable for 50 implementation, together with descriptions of the appropriate use of 51 protocol messages and fields within those messages. 53 This document contains a subset of the changes considered and discussed 54 in the Kerberos working group and is intended as an interim description 55 of Kerberos. Additional changes to the Kerberos protocol have been 56 proposed and will appear in a subsequent extensions document. 58 This document is not intended to describe Kerberos to the end user, 59 system administrator, or application developer. Higher level papers 60 describing Version 5 of the Kerberos system [NT94] and documenting 61 version 4 [SNS88], are available elsewhere. 63 OVERVIEW 65 This INTERNET-DRAFT describes the concepts and model upon which the 66 Kerberos network authentication system is based. It also specifies 67 Version 5 of the Kerberos protocol. 69 The motivations, goals, assumptions, and rationale behind most design 70 decisions are treated cursorily; they are more fully described in a 71 paper available in IEEE communications [NT94] and earlier in the 72 Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols 73 have been a proposed standard and are being considered for advancement 74 for draft standard through the IETF standard process. Comments are 75 encouraged on the presentation, but only minor refinements to the 76 protocol as implemented or extensions that fit within current protocol 77 framework will be considered at this time. 79 Requests for addition to an electronic mailing list for discussion of 80 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU 81 . This mailing list is gatewayed onto 82 the Usenet as the group comp.protocols.kerberos. Requests for further 83 information, including documents and code availability, may be sent to 84 info-kerberos@MIT.EDU . 86 BACKGROUND 88 The Kerberos model is based in part on Needham and Schroeder's trusted 89 third-party authentication protocol [NS78] and on modifications 90 suggested by Denning and Sacco [DS81]. The original design and 91 implementation of Kerberos Versions 1 through 4 was the work of two 92 former Project Athena staff members, Steve Miller of Digital Equipment 93 Corporation and Clifford Neuman (now at the Information Sciences 94 Institute of the University of Southern California), along with Jerome 95 Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, MIT 96 Campus Network Manager. Many other members of Project Athena have also 97 contributed to the work on Kerberos. 99 Version 5 of the Kerberos protocol (described in this document) has 100 evolved from Version 4 based on new requirements and desires for 101 features not available in Version 4. The design of Version 5 of the 102 Kerberos protocol was led by Clifford Neuman and John Kohl with much 103 input from the community. The development of the MIT reference 104 implementation was led at MIT by John Kohl and Theodore T'so, with help 105 and contributed code from many others. Since RFC1510 was issued, 106 extensions and revisions to the protocol have been proposed by many 107 individuals. Some of these proposals are reflected in this document. 108 Where such changes involved significant effort, the document cites the 109 contribution of the proposer. 111 Reference implementations of both version 4 and version 5 of Kerberos 112 are publicly available and commercial implementations have been 113 developed and are widely used. Details on the differences between 114 Kerberos Versions 4 and 5 can be found in [KNT92]. 116 1. Introduction 118 Kerberos provides a means of verifying the identities of principals, 119 (e.g. a workstation user or a network server) on an open (unprotected) 120 network. This is accomplished without relying on assertions by the host 121 operating system, without basing trust on host addresses, without 122 requiring physical security of all the hosts on the network, and under 123 the assumption that packets traveling along the network can be read, 124 modified, and inserted at will[1.1] <#fn1.1>. Kerberos performs 125 authentication under these conditions as a trusted third-party 126 authentication service by using conventional (shared secret key [1.2] 127 <#fn1.2>) cryptography. Kerberos extensions (outside the scope of this 128 document) can provide for the use of public key cryptography during 129 certain phases of the authentication protocol [@RFCE: if PKINIT advances 130 concurrently include reference to the RFC here]. Such extensions support 131 Kerberos authentication for users registered with public key 132 certification authorities and provide certain benefits of public key 133 cryptography in situations where they are needed. 135 The basic Kerberos authentication process proceeds as follows: A client 136 sends a request to the authentication server (AS) requesting 137 "credentials" for a given server. The AS responds with these 138 credentials, encrypted in the client's key. The credentials consist of a 139 "ticket" for the server and a temporary encryption key (often called a 140 "session key"). The client transmits the ticket (which contains the 141 client's identity and a copy of the session key, all encrypted in the 142 server's key) to the server. The session key (now shared by the client 143 and server) is used to authenticate the client, and may optionally be 144 used to authenticate the server. It may also be used to encrypt further 145 communication between the two parties or to exchange a separate 146 sub-session key to be used to encrypt further communication. 148 Implementation of the basic protocol consists of one or more 149 authentication servers running on physically secure hosts. The 150 authentication servers maintain a database of principals (i.e., users 151 and servers) and their secret keys. Code libraries provide encryption 152 and implement the Kerberos protocol. In order to add authentication to 153 its transactions, a typical network application adds one or two calls to 154 the Kerberos library directly or through the Generic Security Services 155 Application Programming Interface, GSSAPI, described in separate 156 document [ref to GSSAPI RFC]. These calls result in the transmission of 157 the necessary messages to achieve authentication. 159 The Kerberos protocol consists of several sub-protocols (or exchanges). 160 There are two basic methods by which a client can ask a Kerberos server 161 for credentials. In the first approach, the client sends a cleartext 162 request for a ticket for the desired server to the AS. The reply is sent 163 encrypted in the client's secret key. Usually this request is for a 164 ticket-granting ticket (TGT) which can later be used with the 165 ticket-granting server (TGS). In the second method, the client sends a 166 request to the TGS. The client uses the TGT to authenticate itself to 167 the TGS in the same manner as if it were contacting any other 168 application server that requires Kerberos authentication. The reply is 169 encrypted in the session key from the TGT. Though the protocol 170 specification describes the AS and the TGS as separate servers, they are 171 implemented in practice as different protocol entry points within a 172 single Kerberos server. 174 Once obtained, credentials may be used to verify the identity of the 175 principals in a transaction, to ensure the integrity of messages 176 exchanged between them, or to preserve privacy of the messages. The 177 application is free to choose whatever protection may be necessary. 179 To verify the identities of the principals in a transaction, the client 180 transmits the ticket to the application server. Since the ticket is sent 181 "in the clear" (parts of it are encrypted, but this encryption doesn't 182 thwart replay) and might be intercepted and reused by an attacker, 183 additional information is sent to prove that the message originated with 184 the principal to whom the ticket was issued. This information (called 185 the authenticator) is encrypted in the session key, and includes a 186 timestamp. The timestamp proves that the message was recently generated 187 and is not a replay. Encrypting the authenticator in the session key 188 proves that it was generated by a party possessing the session key. 189 Since no one except the requesting principal and the server know the 190 session key (it is never sent over the network in the clear) this 191 guarantees the identity of the client. 193 The integrity of the messages exchanged between principals can also be 194 guaranteed using the session key (passed in the ticket and contained in 195 the credentials). This approach provides detection of both replay 196 attacks and message stream modification attacks. It is accomplished by 197 generating and transmitting a collision-proof checksum (elsewhere called 198 a hash or digest function) of the client's message, keyed with the 199 session key. Privacy and integrity of the messages exchanged between 200 principals can be secured by encrypting the data to be passed using the 201 session key contained in the ticket or the sub-session key found in the 202 authenticator. 204 The authentication exchanges mentioned above require read-only access to 205 the Kerberos database. Sometimes, however, the entries in the database 206 must be modified, such as when adding new principals or changing a 207 principal's key. This is done using a protocol between a client and a 208 third Kerberos server, the Kerberos Administration Server (KADM). There 209 is also a protocol for maintaining multiple copies of the Kerberos 210 database. Neither of these protocols are described in this document. 212 1.1. Cross-realm operation 214 The Kerberos protocol is designed to operate across organizational 215 boundaries. A client in one organization can be authenticated to a 216 server in another. Each organization wishing to run a Kerberos server 217 establishes its own "realm". The name of the realm in which a client is 218 registered is part of the client's name, and can be used by the 219 end-service to decide whether to honor a request. 221 By establishing "inter-realm" keys, the administrators of two realms can 222 allow a client authenticated in the local realm to prove its identity to 223 servers in other realms[1.3] <#fn1.3>. The exchange of inter-realm keys 224 (a separate key may be used for each direction) registers the 225 ticket-granting service of each realm as a principal in the other realm. 226 A client is then able to obtain a ticket-granting ticket for the remote 227 realm's ticket-granting service from its local realm. When that 228 ticket-granting ticket is used, the remote ticket-granting service uses 229 the inter-realm key (which usually differs from its own normal TGS key) 230 to decrypt the ticket-granting ticket, and is thus certain that it was 231 issued by the client's own TGS. Tickets issued by the remote 232 ticket-granting service will indicate to the end-service that the client 233 was authenticated from another realm. 235 A realm is said to communicate with another realm if the two realms 236 share an inter-realm key, or if the local realm shares an inter-realm 237 key with an intermediate realm that communicates with the remote realm. 238 An authentication path is the sequence of intermediate realms that are 239 transited in communicating from one realm to another. 241 Realms are typically organized hierarchically. Each realm shares a key 242 with its parent and a different key with each child. If an inter-realm 243 key is not directly shared by two realms, the hierarchical organization 244 allows an authentication path to be easily constructed. If a 245 hierarchical organization is not used, it may be necessary to consult a 246 database in order to construct an authentication path between realms. 248 Although realms are typically hierarchical, intermediate realms may be 249 bypassed to achieve cross-realm authentication through alternate 250 authentication paths (these might be established to make communication 251 between two realms more efficient). It is important for the end-service 252 to know which realms were transited when deciding how much faith to 253 place in the authentication process. To facilitate this decision, a 254 field in each ticket contains the names of the realms that were involved 255 in authenticating the client. 257 The application server is ultimately responsible for accepting or 258 rejecting authentication and should check the transited field. The 259 application server may choose to rely on the KDC for the application 260 server's realm to check the transited field. The application server's 261 KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDC's 262 for intermediate realms may also check the transited field as they issue 263 ticket-granting-tickets for other realms, but they are encouraged not to 264 do so. A client may request that the KDC's not check the transited field 265 by setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but 266 not required to honor this flag. 268 1.2. Choosing a principal with which to communicate 270 The Kerberos protocol provides the means for verifying (subject to the 271 assumptions in 1.4) that the entity with which one communicates is the 272 same entity that was registered with the KDC using the claimed identity 273 (principal name). It is still necessary to determine whether that 274 identity corresponds to the entity with which one intends to communicate. 276 When appropriate data has been exchanged in advance, this determination 277 may be performed syntactically by the application based on the 278 application protocol specification, information provided by the user, 279 and configuration files. For example, the server principal name 280 (including realm) for a telnet server might be derived from the user 281 specified host name (from the telnet command line), the "host/" prefix 282 specified in the application protocol specification, and a mapping to a 283 Kerberos realm derived syntactically from the domain part of the 284 specified hostname and information from the local Kerberos realms database. 286 One can also rely on trusted third parties to make this determination, 287 but only when the data obtained from the third party is suitably 288 integrity protected wile resident on the third party server and when 289 transmitted. Thus, for example, one should not rely on an unprotected 290 domain name system record to map a host alias to the primary name of a 291 server, accepting the primary name as the party one intends to contact, 292 since an attacker can modify the mapping and impersonate the party with 293 which one intended to communicate. 295 1.3. Authorization 297 As an authentication service, Kerberos provides a means of verifying the 298 identity of principals on a network. Authentication is usually useful 299 primarily as a first step in the process of authorization, determining 300 whether a client may use a service, which objects the client is allowed 301 to access, and the type of access allowed for each. Kerberos does not, 302 by itself, provide authorization. Possession of a client ticket for a 303 service provides only for authentication of the client to that service, 304 and in the absence of a separate authorization procedure, it should not 305 be considered by an application as authorizing the use of that service. 307 Such separate authorization methods may be implemented as application 308 specific access control functions and may utilize files on the 309 application server, or on separately issued authorization credentials 310 such as those based on proxies [Neu93], or on other authorization 311 services. Separately authenticated authorization credentials may be 312 embedded in a tickets authorization data when encapsulated by the 313 kdc-issued authorization data element. 315 Applications should not accept the mere issuance of a service ticket by 316 the Kerberos server (even by a modified Kerberos server) as granting 317 authority to use the service, since such applications may become 318 vulnerable to the bypass of this authorization check in an environment 319 if they interoperate with other KDCs or where other options for 320 application authentication (e.g. the PKTAPP proposal) are provided. 322 [Section 1.4 is replaced in the extensions document ] 324 1.4. Extending Kerberos Without Breaking Interoperability 326 As the deployed base of Kerberos implementations grows, extending 327 Kerberos becomes more important. Unfortunately some extensions to the 328 existing Kerberos protocol create interoperability issues because of 329 uncertainty regarding the treatment of certain extensibility options by 330 some implementations. This section includes guidelines that will enable 331 future implementations to maintain interoperability. 333 Kerberos provides a general mechanism for protocol extensibility. Some 334 protocol messages contain typed holes -- sub-messages that contain an 335 octet-string along with an integer that defines how to interpret the 336 octet-string. The integer types are registered centrally, but can be 337 used both for vendor extensions and for extensions standardized through 338 the IETF. 340 1.4.1. Compatibility with RFC 1510 342 It is important to note that existing Kerberos message formats can not 343 be readily extended by adding fields to the ASN.1 types. Sending 344 additional fields often results in the entire message being discarded 345 without an error indication. Future versions of this specification will 346 provide guidelines to ensure that ASN.1 fields can be added without 347 creating an interoperability problem. 349 In the meantime, all new or modified implementations of Kerberos that 350 receive an unknown message extension should preserve the encoding of the 351 extension but otherwise ignore the presence of the extension. Recipients 352 MUST NOT decline a request simply because an extension is present. 354 There is one exception to this rule. If an unknown authorization data 355 element type is received by a server other than the ticket granting 356 service either in an AP-REQ or in a ticket contained in an AP-REQ, then 357 authentication SHOULD fail. One of the primary uses of authorization 358 data is to restrict the use of the ticket. If the service cannot 359 determine whether the restriction applies to that service then a 360 security weakness may result if the ticket can be used for that service. 361 Authorization elements that are optional should be enclosed in the 362 AD-IF-RELEVANT element. 364 The ticket granting service must ignore but propagate to derivative 365 tickets any unknown authorization data types, unless those data types 366 are embedded in a MANDATORY-FOR-KDC element, in which case the request 367 will be rejected. This behavior is appropriate because requiring that 368 the ticket granting service understand unknown authorization data types 369 would require that KDC software be upgraded to understand new 370 application-level restrictions before applications used these 371 restrictions, decreasing the utility of authorization data as a 372 mechanism for restricting the use of tickets. No security problem is 373 created because services to which the tickets are issued will verify the 374 authorization data. 376 Implementation note: Many RFC 1510 implementations ignore unknown 377 authorization data elements. Depending on these implementations to honor 378 authorization data restrictions may create a security weakness. 380 1.4.2. Sending Extensible Messages 382 Care must be taken to ensure that old implementations can understand 383 messages sent to them even if they do not understand an extension that 384 is used. Unless the sender knows an extension is supported, the 385 extension cannot change the semantics of the core message or previously 386 defined extensions. 388 For example, an extension including key information necessary to decrypt 389 the encrypted part of a KDC-REP could only be used in situations where 390 the recipient was known to support the extension. Thus when designing 391 such extensions it is important to provide a way for the recipient to 392 notify the sender of support for the extension. For example in the case 393 of an extension that changes the KDC-REP reply key, the client could 394 indicate support for the extension by including a padata element in the 395 AS-REQ sequence. The KDC should only use the extension if this padata 396 element is present in the AS-REQ. Even if policy requires the use of the 397 extension, it is better to return an error indicating that the extension 398 is required than to use the extension when the recipient may not support 399 it; debugging why implementations do not interoperate is easier when 400 errors are returned. 402 1.6. Environmental assumptions 404 Kerberos imposes a few assumptions on the environment in which it can 405 properly function: 407 * "Denial of service" attacks are not solved with Kerberos. There 408 are places in the protocols where an intruder can prevent an 409 application from participating in the proper authentication steps. 410 Detection and solution of such attacks (some of which can appear 411 to be not-uncommon "normal" failure modes for the system) is 412 usually best left to the human administrators and users. 413 * Principals must keep their secret keys secret. If an intruder 414 somehow steals a principal's key, it will be able to masquerade as 415 that principal or impersonate any server to the legitimate principal. 416 * "Password guessing" attacks are not solved by Kerberos. If a user 417 chooses a poor password, it is possible for an attacker to 418 successfully mount an offline dictionary attack by repeatedly 419 attempting to decrypt, with successive entries from a dictionary, 420 messages obtained which are encrypted under a key derived from the 421 user's password. 422 * Each host on the network must have a clock which is "loosely 423 synchronized" to the time of the other hosts; this synchronization 424 is used to reduce the bookkeeping needs of application servers 425 when they do replay detection. The degree of "looseness" can be 426 configured on a per-server basis, but is typically on the order of 427 5 minutes. If the clocks are synchronized over the network, the 428 clock synchronization protocol must itself be secured from network 429 attackers. 430 * Principal identifiers are not recycled on a short-term basis. A 431 typical mode of access control will use access control lists 432 (ACLs) to grant permissions to particular principals. If a stale 433 ACL entry remains for a deleted principal and the principal 434 identifier is reused, the new principal will inherit rights 435 specified in the stale ACL entry. By not re-using principal 436 identifiers, the danger of inadvertent access is removed. 438 1.7. Glossary of terms 440 Below is a list of terms used throughout this document. 442 Authentication 443 Verifying the claimed identity of a principal. Authentication header 444 A record containing a Ticket and an Authenticator to be presented to 445 a server as part of the authentication process. 446 Authentication path 447 A sequence of intermediate realms transited in the authentication 448 process when communicating from one realm to another. 449 Authenticator 450 A record containing information that can be shown to have been 451 recently generated using the session key known only by the client 452 and server. 453 Authorization 454 The process of determining whether a client may use a service, which 455 objects the client is allowed to access, and the type of access 456 allowed for each. 458 Capability 459 A token that grants the bearer permission to access an object or 460 service. In Kerberos, this might be a ticket whose use is restricted 461 by the contents of the authorization data field, but which lists no 462 network addresses, together with the session key necessary to use 463 the ticket. 464 Ciphertext 465 The output of an encryption function. Encryption transforms 466 plaintext into ciphertext. 467 Client 468 A process that makes use of a network service on behalf of a user. 469 Note that in some cases a Server may itself be a client of some 470 other server (e.g. a print server may be a client of a file server). 471 Credentials 472 A ticket plus the secret session key necessary to successfully use 473 that ticket in an authentication exchange. 474 KDC 475 Key Distribution Center, a network service that supplies tickets and 476 temporary session keys; or an instance of that service or the host 477 on which it runs. The KDC services both initial ticket and 478 ticket-granting ticket requests. The initial ticket portion is 479 sometimes referred to as the Authentication Server (or service). The 480 ticket-granting ticket portion is sometimes referred to as the 481 ticket-granting server (or service). 482 Kerberos 483 Aside from the 3-headed dog guarding Hades, the name given to 484 Project Athena's authentication service, the protocol used by that 485 service, or the code used to implement the authentication service. 486 Plaintext 487 The input to an encryption function or the output of a decryption 488 function. Decryption transforms ciphertext into plaintext. 489 Principal 490 A named client or server entity that participates in a network 491 communication, with one name that is considered canonical. 492 Principal identifier 493 The canonical name used to uniquely identify each different principal. Seal 494 To encipher a record containing several fields in such a way that 495 the fields cannot be individually replaced without either knowledge 496 of the encryption key or leaving evidence of tampering. 497 Secret key 498 An encryption key shared by a principal and the KDC, distributed 499 outside the bounds of the system, with a long lifetime. In the case 500 of a human user's principal, the secret key may be derived from a 501 password. 502 Server 503 A particular Principal which provides a resource to network clients. 504 The server is sometimes referred to as the Application Server. 505 Service 506 A resource provided to network clients; often provided by more than 507 one server (for example, remote file service). 508 Session key 509 A temporary encryption key used between two principals, with a 510 lifetime limited to the duration of a single login "session". 511 Sub-session key 512 A temporary encryption key used between two principals, selected and 513 exchanged by the principals using the session key, and with a 514 lifetime limited to the duration of a single association. 515 Ticket 516 A record that helps a client authenticate itself to a server; it 517 contains the client's identity, a session key, a timestamp, and 518 other information, all sealed using the server's secret key. It only 519 serves to authenticate a client when presented along with a fresh 520 Authenticator. 522 2. Ticket flag uses and requests 524 Each Kerberos ticket contains a set of flags which are used to indicate 525 attributes of that ticket. Most flags may be requested by a client when 526 the ticket is obtained; some are automatically turned on and off by a 527 Kerberos server as required. The following sections explain what the 528 various flags mean and give examples of reasons to use them. With the 529 exception of the ANONYMOUS and INVALID flags clients MUST ignore ticket 530 flags that are not recognized. KDCs MUST ignore KDC options that are not 531 recognized. Some implementations of RFC 1510 are known to reject unknown 532 KDC options, so clients may need to resend a request without KDC new 533 options absent if the request was rejected when sent with option added 534 since RFC 1510. 536 Since new KDCs will ignore unknown options, clients MUST confirm that 537 the ticket returned by the KDC meets their needs. For example, as 538 discussed in section 2.8, a client requiring anonymous communication 539 needs to make sure that the ticket is actually anonymous. A KDC that 540 prohibits issuing of anonymous tickets or that does not understand the 541 anonymous option would not return an anonymous ticket. 543 Note that it is not in general possible to determine whether an option 544 was not honored because it was not understood or because it was rejected 545 either through configuration or policy. When adding a new option to the 546 Kerberos protocol, designers should consider whether the distinction is 547 important for their option. In cases where it is, a mechanism for the 548 KDC to return an indication that the option was understood but rejected 549 needs to be provided in the specification of the option. Often in such 550 cases, the mechanism needs to be broad enough to permit an error or 551 reason to be returned. 553 2.1. Initial, pre-authenticated, and hardware authenticated tickets 555 The INITIAL flag indicates that a ticket was issued using the AS 556 protocol and not issued based on a ticket-granting ticket. Application 557 servers that want to require the demonstrated knowledge of a client's 558 secret key (e.g. a password-changing program) can insist that this flag 559 be set in any tickets they accept, and thus be assured that the client's 560 key was recently presented to the application client. 562 The PRE-AUTHENT and HW-AUTHENT flags provide additional information 563 about the initial authentication, regardless of whether the current 564 ticket was issued directly (in which case INITIAL will also be set) or 565 issued on the basis of a ticket-granting ticket (in which case the 566 INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are 567 carried forward from the ticket-granting ticket). 569 2.2. Invalid tickets 571 The INVALID flag indicates that a ticket is invalid. Application servers 572 must reject tickets which have this flag set. A postdated ticket will 573 usually be issued in this form. Invalid tickets must be validated by the 574 KDC before use, by presenting them to the KDC in a TGS request with the 575 VALIDATE option specified. The KDC will only validate tickets after 576 their starttime has passed. The validation is required so that postdated 577 tickets which have been stolen before their starttime can be rendered 578 permanently invalid (through a hot-list mechanism) (see section 3.3.3.1). 580 2.3. Renewable tickets 582 Applications may desire to hold tickets which can be valid for long 583 periods of time. However, this can expose their credentials to potential 584 theft for equally long periods, and those stolen credentials would be 585 valid until the expiration time of the ticket(s). Simply using 586 short-lived tickets and obtaining new ones periodically would require 587 the client to have long-term access to its secret key, an even greater 588 risk. Renewable tickets can be used to mitigate the consequences of 589 theft. Renewable tickets have two "expiration times": the first is when 590 the current instance of the ticket expires, and the second is the latest 591 permissible value for an individual expiration time. An application 592 client must periodically (i.e. before it expires) present a renewable 593 ticket to the KDC, with the RENEW option set in the KDC request. The KDC 594 will issue a new ticket with a new session key and a later expiration 595 time. All other fields of the ticket are left unmodified by the renewal 596 process. When the latest permissible expiration time arrives, the ticket 597 expires permanently. At each renewal, the KDC may consult a hot-list to 598 determine if the ticket had been reported stolen since its last renewal; 599 it will refuse to renew such stolen tickets, and thus the usable 600 lifetime of stolen tickets is reduced. 602 The RENEWABLE flag in a ticket is normally only interpreted by the 603 ticket-granting service (discussed below in section 3.3). It can usually 604 be ignored by application servers. However, some particularly careful 605 application servers may wish to disallow renewable tickets. 607 If a renewable ticket is not renewed by its expiration time, the KDC 608 will not renew the ticket. The RENEWABLE flag is reset by default, but a 609 client may request it be set by setting the RENEWABLE option in the 610 KRB_AS_REQ message. If it is set, then the renew-till field in the 611 ticket contains the time after which the ticket may not be renewed. 613 2.4. Postdated tickets 615 Applications may occasionally need to obtain tickets for use much later, 616 e.g. a batch submission system would need tickets to be valid at the 617 time the batch job is serviced. However, it is dangerous to hold valid 618 tickets in a batch queue, since they will be on-line longer and more 619 prone to theft. Postdated tickets provide a way to obtain these tickets 620 from the KDC at job submission time, but to leave them "dormant" until 621 they are activated and validated by a further request of the KDC. If a 622 ticket theft were reported in the interim, the KDC would refuse to 623 validate the ticket, and the thief would be foiled. 625 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 626 ticket-granting service. It can be ignored by application servers. This 627 flag must be set in a ticket-granting ticket in order to issue a 628 postdated ticket based on the presented ticket. It is reset by default; 629 it may be requested by a client by setting the ALLOW-POSTDATE option in 630 the KRB_AS_REQ message. This flag does not allow a client to obtain a 631 postdated ticket-granting ticket; postdated ticket-granting tickets can 632 only by obtained by requesting the postdating in the KRB_AS_REQ message. 633 The life (endtime-starttime) of a postdated ticket will be the remaining 634 life of the ticket-granting ticket at the time of the request, unless 635 the RENEWABLE option is also set, in which case it can be the full life 636 (endtime-starttime) of the ticket-granting ticket. The KDC may limit how 637 far in the future a ticket may be postdated. 639 The POSTDATED flag indicates that a ticket has been postdated. The 640 application server can check the authtime field in the ticket to see 641 when the original authentication occurred. Some services may choose to 642 reject postdated tickets, or they may only accept them within a certain 643 period after the original authentication. When the KDC issues a 644 POSTDATED ticket, it will also be marked as INVALID, so that the 645 application client must present the ticket to the KDC to be validated 646 before use. 648 2.5. Proxiable and proxy tickets 650 At times it may be necessary for a principal to allow a service to 651 perform an operation on its behalf. The service must be able to take on 652 the identity of the client, but only for a particular purpose. A 653 principal can allow a service to take on the principal's identity for a 654 particular purpose by granting it a proxy. 656 The process of granting a proxy using the proxy and proxiable flags is 657 used to provide credentials for use with specific services. Though 658 conceptually also a proxy, user's wishing to delegate their identity for 659 ANY purpose must use the ticket forwarding mechanism described in the 660 next section to forward a ticket granting ticket. 662 The PROXIABLE flag in a ticket is normally only interpreted by the 663 ticket-granting service. It can be ignored by application servers. When 664 set, this flag tells the ticket-granting server that it is OK to issue a 665 new ticket (but not a ticket-granting ticket) with a different network 666 address based on this ticket. This flag is set if requested by the 667 client on initial authentication. By default, the client will request 668 that it be set when requesting a ticket granting ticket, and reset when 669 requesting any other ticket. 671 This flag allows a client to pass a proxy to a server to perform a 672 remote request on its behalf, e.g. a print service client can give the 673 print server a proxy to access the client's files on a particular file 674 server in order to satisfy a print request. 676 In order to complicate the use of stolen credentials, Kerberos tickets 677 are usually valid from only those network addresses specifically 678 included in the ticket[2.1] <#fn2.1>. When granting a proxy, the client 679 must specify the new network address from which the proxy is to be used, 680 or indicate that the proxy is to be issued for use from any address. 682 The PROXY flag is set in a ticket by the TGS when it issues a proxy 683 ticket. Application servers may check this flag and at their option they 684 may require additional authentication from the agent presenting the 685 proxy in order to provide an audit trail. 687 2.6. Forwardable tickets 689 Authentication forwarding is an instance of a proxy where the service 690 granted is complete use of the client's identity. An example where it 691 might be used is when a user logs in to a remote system and wants 692 authentication to work from that system as if the login were local. 694 The FORWARDABLE flag in a ticket is normally only interpreted by the 695 ticket-granting service. It can be ignored by application servers. The 696 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 697 flag, except ticket-granting tickets may also be issued with different 698 network addresses. This flag is reset by default, but users may request 699 that it be set by setting the FORWARDABLE option in the AS request when 700 they request their initial ticket-granting ticket. 702 This flag allows for authentication forwarding without requiring the 703 user to enter a password again. If the flag is not set, then 704 authentication forwarding is not permitted, but the same result can 705 still be achieved if the user engages in the AS exchange specifying the 706 requested network addresses and supplies a password. 708 The FORWARDED flag is set by the TGS when a client presents a ticket 709 with the FORWARDABLE flag set and requests a forwarded ticket by 710 specifying the FORWARDED KDC option and supplying a set of addresses for 711 the new ticket. It is also set in all tickets issued based on tickets 712 with the FORWARDED flag set. Application servers may choose to process 713 FORWARDED tickets differently than non-FORWARDED tickets. 715 2.7 Transited Policy Checking 717 In Kerberos, the application server is ultimately responsible for 718 accepting or rejecting authentication and should check that only 719 suitably trusted KDCs are relied upon to authenticate a principal. The 720 transited field in the ticket identifies which KDCs were involved in the 721 authentication process and an application server would normally check 722 this field. If any of these are untrusted to authenticate the indicated 723 client principal (probably determined by a realm-based policy), the 724 authentication attempt must be rejected. The presence of trusted KDCs in 725 this list does not provide any guarantee; an untrusted KDC may have 726 fabricated the list. 728 While the end server ultimately decides whether authentication is valid, 729 the KDC for the end server's realm may apply a realm specific policy for 730 validating the transited field and accepting credentials for cross-realm 731 authentication. When the KDC applies such checks and accepts such 732 cross-realm authentication it will set the TRANSITED-POLICY-CHECKED flag 733 in the service tickets it issues based on the cross-realm TGT. A client 734 may request that the KDCs not check the transited field by setting the 735 DISABLE-TRANSITED-CHECK flag. KDCs are encouraged but not required to 736 honor this flag. 738 2.8 Anonymous Tickets 740 When policy allows, a KDC may issue anonymous tickets for the purpose of 741 enabling encrypted communication between a client and server without 742 identifying the client to the server. Such anonymous tickets are issued 743 with a generic principal name configured on the KDC (e.g. "anonymous@") 744 and will have the ANONYMOUS flag set. A server accepting such a ticket 745 may assume that subsequent requests using the same ticket and session 746 key originate from the same user. Requests with the same username but 747 different tickets are likely to originate from different users. Users 748 request anonymous ticket by setting the REQUEST-ANONYMOUS option in an 749 AS or TGS request. 751 If a client requires anonymous communication then the client should 752 check to make sure that the resulting ticket is actually anonymous. A 753 KDC that does not understand the anonymous-requested flag will not 754 return an error, but will instead return a normal ticket. 756 2.9. Other KDC options 758 There are three additional options which may be set in a client's 759 request of the KDC. 761 2.9.1 Renewable-OK 763 The RENEWABLE-OK option indicates that the client will accept a 764 renewable ticket if a ticket with the requested life cannot otherwise be 765 provided. If a ticket with the requested life cannot be provided, then 766 the KDC may issue a renewable ticket with a renew-till equal to the the 767 requested endtime. The value of the renew-till field may still be 768 adjusted by site-determined limits or limits imposed by the individual 769 principal or server. 771 2.9.2 ENC-TKT-IN-SKEY 773 In its basic form the Kerberos protocol supports authentication in a 774 client server setting and is not well suited to authentication in a 775 peer-to-peer environment because the long term key of the user does not 776 remain on the workstation after initial login. Authentication of such 777 peers may be supported by Kerberos in its user-to-user variant. The 778 ENC-TKT-IN-SKEY option supports user-to-user authentication by allowing 779 the KDC to issue a service ticket encrypted using the session key from 780 another ticket granting ticket issued to another user. The 781 ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. 782 It indicates that the ticket to be issued for the end server is to be 783 encrypted in the session key from the additional second ticket-granting 784 ticket provided with the request. See section 3.3.3 for specific details. 786 2.9.4 Passwordless Hardware Authentication 788 The OPT-HARDWARE-AUTH option indicates that the client wishes to use 789 some form of hardware authentication instead of or in addition to the 790 client's password or other long-lived encryption key. OPT-HARDWARE-AUTH 791 is honored only by the authentication service. If supported and allowed 792 by policy, the KDC will return an errorcode KDC_ERR_PREAUTH_REQUIRED and 793 include the required METHOD-DATA to perform such authentication. 795 3. Message Exchanges 797 The following sections describe the interactions between network clients 798 and servers and the messages involved in those exchanges. 800 [Insert paragraph for extensions ] 802 3.1. The Authentication Service Exchange 804 Summary 805 Message direction Message type Section 806 1. Client to Kerberos KRB_AS_REQ 5.4.1 807 2. Kerberos to client KRB_AS_REP or 5.4.2 808 KRB_ERROR 5.9.1 810 The Authentication Service (AS) Exchange between the client and the 811 Kerberos Authentication Server is initiated by a client when it wishes 812 to obtain authentication credentials for a given server but currently 813 holds no credentials. In its basic form, the client's secret key is used 814 for encryption and decryption. This exchange is typically used at the 815 initiation of a login session to obtain credentials for a 816 Ticket-Granting Server which will subsequently be used to obtain 817 credentials for other servers (see section 3.3) without requiring 818 further use of the client's secret key. This exchange is also used to 819 request credentials for services which must not be mediated through the 820 Ticket-Granting Service, but rather require a principal's secret key, 821 such as the password-changing service[3.1] <#fn3.1>. This exchange does 822 not by itself provide any assurance of the the identity of the user[3.2] 823 <#fn3.2>. 825 The exchange consists of two messages: KRB_AS_REQ from the client to 826 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 827 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 829 In the request, the client sends (in cleartext) its own identity and the 830 identity of the server for which it is requesting credentials. The 831 response, KRB_AS_REP, contains a ticket for the client to present to the 832 server, and a session key that will be shared by the client and the 833 server. The session key and additional information are encrypted in the 834 client's secret key. The KRB_AS_REP message contains information which 835 can be used to detect replays, and to associate it with the message to 836 which it replies. [Insert sentence for extensions ] 838 Without pre-authentication, the authentication server does not know 839 whether the client is actually the principal named in the request. It 840 simply sends a reply without knowing or caring whether they are the 841 same. This is acceptable because nobody but the principal whose identity 842 was given in the request will be able to use the reply. Its critical 843 information is encrypted in that principal's key. However, an attacker 844 can send a KRB_AS_REQ message to get known plaintext in order to attack 845 the principal's key. Especially if the key is based on a password, this 846 may create a security exposure. So, the initial request supports an 847 optional field that can be used to pass additional information that 848 might be needed for the initial exchange. This field should be used for 849 pre-authentication as described in section 3.1.1. 851 Various errors can occur; these are indicated by an error response 852 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not 853 encrypted. The KRB_ERROR message contains information which can be used 854 to associate it with the message to which it replies. [This rest of this 855 paragraph is replaced in revisions ] The contents of 856 the KRB_ERROR message are not integrity-protected. As such, the client 857 cannot detect replays, fabrications or modifications. A solution to this 858 problem will be included in a future version of the protocol. 860 3.1.1. Generation of KRB_AS_REQ message 862 The client may specify a number of options in the initial request. Among 863 these options are whether pre-authentication is to be performed; whether 864 the requested ticket is to be renewable, proxiable, or forwardable; 865 whether it should be postdated or allow postdating of derivative 866 tickets; whether the client requests an anonymous ticket; and whether a 867 renewable ticket will be accepted in lieu of a non-renewable ticket if 868 the requested ticket expiration date cannot be satisfied by a 869 non-renewable ticket (due to configuration constraints). 871 The client prepares the KRB_AS_REQ message and sends it to the KDC. 872 [Insert the linked text in extensions ] 874 3.1.2. Receipt of KRB_AS_REQ message 876 If all goes well, processing the KRB_AS_REQ message will result in the 877 creation of a ticket for the client to present to the server. The format 878 for the ticket is described in section 5.3.1. The contents of the ticket 879 are determined as follows. 881 Because Kerberos can run over unreliable transports such as UDP, the KDC 882 MUST be prepared to retransmit responses in case they are lost. If a KDC 883 receives a request identical to one it has recently successfully 884 processed, the KDC MUST respond with an KRB_AS_REP message rather than a 885 replay error. In order to reduce ciphertext given to a potential 886 attacker, KDCs MAY wish to send an the same response generated when the 887 request was first handled. KDCs MUST obey this replay behavior even if 888 the actual transport in use is reliable. 890 3.1.3. Generation of KRB_AS_REP message 892 The authentication server looks up the client and server principals 893 named in the KRB_AS_REQ in its database, extracting their respective 894 keys. If the requested client principal named in the request is not 895 known because it doesn't exist in the KDC's principal database, then an 896 error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 898 If required, the server pre-authenticates the request, and if the 899 pre-authentication check fails, an error message with the code 900 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, 901 but was not present in the request, an error message with the code 902 KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO 903 pre-authentication field will be included in the KRB-ERROR message. If 904 the server cannot accommodate an encryption type requested by the 905 client, an error message with code KDC_ERR_ETYPE_NOSUPP is returned. 906 Otherwise the KDC generates a 'random' session key[3.3] <#fn3.3>. 908 When responding to an AS request, if there are multiple encryption keys 909 registered for a client in the Kerberos database , then the etype field 910 from the AS request is used by the KDC to select the encryption method 911 to be used to protect the encrypted part of the KRB_AS_REP message which 912 is sent to the client. If there is more than one supported strong 913 encryption type in the etype list, the first valid etype for which an 914 encryption key is available is used. The encryption method used to 915 protect the encrypted part of the KRB_TGS_REP message is the keytype of 916 the session key found in the ticket granting ticket presented in the 917 KRB_TGS_REQ. 919 When the user's key is generated from a password or pass phrase, the 920 string-to-key function for the particular encryption key type is used, 921 as specified in [KCRYPTO]. The salt value and additional parameters for 922 the string-to-key function have default values (specified by section 6 923 and by the encryption mechanism specification, respectively) that may be 924 overridden by preauthentication data (PA-PW-SALT, PA-AFS3-SALT, 925 PA-ETYPE-INFO, PA-S2K-PARAMS, etc). Since the KDC is presumed to store a 926 copy of the resulting key only, these values should not be changed for 927 password-based keys except when changing the principal's key. 929 It is not possible to reliably generate a user's key given a pass phrase 930 without contacting the KDC, since it will not be known whether alternate 931 salt or parameter values are required. 933 When the etype field is present in a KDC request, whether an AS or TGS 934 request, the KDC will attempt to assign the type of the random session 935 key from the list of methods in the etype field. The KDC will select the 936 appropriate type using the list of methods provided together with 937 information from the Kerberos database indicating acceptable encryption 938 methods for the application server. The KDC will not issue tickets with 939 a weak session key encryption type. 941 If the requested start time is absent, indicates a time in the past, or 942 is within the window of acceptable clock skew for the KDC and the 943 POSTDATE option has not been specified, then the start time of the 944 ticket is set to the authentication server's current time. If it 945 indicates a time in the future beyond the acceptable clock skew, but the 946 POSTDATED option has not been specified then the error 947 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start time 948 is checked against the policy of the local realm (the administrator 949 might decide to prohibit certain types or ranges of postdated tickets), 950 and if acceptable, the ticket's start time is set as requested and the 951 INVALID flag is set in the new ticket. The postdated ticket must be 952 validated before use by presenting it to the KDC after the start time 953 has been reached. 955 The expiration time of the ticket will be set to the earlier of the 956 requested endtime and a time determined by local policy, possibly 957 determined using realm or principal specific factors. For example, the 958 expiration time may be set to the minimum of the following: 960 * The expiration time (endtime) requested in the KRB_AS_REQ message. 961 * The ticket's start time plus the maximum allowable lifetime 962 associated with the client principal from the authentication 963 server's database. 964 * The ticket's start time plus the maximum allowable lifetime 965 associated with the server principal. 966 * The ticket's start time plus the maximum lifetime set by the 967 policy of the local realm. 969 If the requested expiration time minus the start time (as determined 970 above) is less than a site-determined minimum lifetime, an error message 971 with code KDC_ERR_NEVER_VALID is returned. If the requested expiration 972 time for the ticket exceeds what was determined as above, and if the 973 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' flag is set in 974 the new ticket, and the renew-till value is set as if the 'RENEWABLE' 975 option were requested (the field and option names are described fully in 976 section 5.4.1). 978 If the RENEWABLE option has been requested or if the RENEWABLE-OK option 979 has been set and a renewable ticket is to be issued, then the renew-till 980 field is set to the minimum of: 982 * Its requested value. 983 * The start time of the ticket plus the minimum of the two maximum 984 renewable lifetimes associated with the principals' database entries. 985 * The start time of the ticket plus the maximum renewable lifetime 986 set by the policy of the local realm. 988 The flags field of the new ticket will have the following options set if 989 they have been requested and if the policy of the local realm allows: 990 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS. 991 If the new ticket is post-dated (the start time is in the future), its 992 INVALID flag will also be set. 994 If all of the above succeed, the server will encrypt ciphertext part of 995 the ticket using the encryption key extracted from the server 996 principal's record in the Kerberos database using the encryption type 997 associated with the server principal's key (this choice is NOT affected 998 by the etype field in the request). It then formats a KRB_AS_REP message 999 (see section 5.4.2), copying the addresses in the request into the caddr 1000 of the response, placing any required pre-authentication data into the 1001 padata of the response, and encrypts the ciphertext part in the client's 1002 key using an acceptable encryption method requested in the etype field 1003 of the request, or in some key specified by pre-authentication 1004 mechanisms being used. 1006 3.1.4. Generation of KRB_ERROR message 1008 Several errors can occur, and the Authentication Server responds by 1009 returning an error message, KRB_ERROR, to the client, with the 1010 error-code, e-text, and optional e-cksum fields set to appropriate 1011 values. The error message contents and details are described in Section 1012 5.9.1. 1014 3.1.5. Receipt of KRB_AS_REP message 1016 If the reply message type is KRB_AS_REP, then the client verifies that 1017 the cname and crealm fields in the cleartext portion of the reply match 1018 what it requested. If any padata fields are present, they may be used to 1019 derive the proper secret key to decrypt the message. The client decrypts 1020 the encrypted part of the response using its secret key, verifies that 1021 the nonce in the encrypted part matches the nonce it supplied in its 1022 request (to detect replays). It also verifies that the sname and srealm 1023 in the response match those in the request (or are otherwise expected 1024 values), and that the host address field is also correct. It then stores 1025 the ticket, session key, start and expiration times, and other 1026 information for later use. The key-expiration field from the encrypted 1027 part of the response may be checked to notify the user of impending key 1028 expiration (the client program could then suggest remedial action, such 1029 as a password change). 1031 Proper decryption of the KRB_AS_REP message is not sufficient for the 1032 host to verify the identity of the user; the user and an attacker could 1033 cooperate to generate a KRB_AS_REP format message which decrypts 1034 properly but is not from the proper KDC. If the host wishes to verify 1035 the identity of the user, it must require the user to present 1036 application credentials which can be verified using a securely-stored 1037 secret key for the host. If those credentials can be verified, then the 1038 identity of the user can be assured. 1040 3.1.6. Receipt of KRB_ERROR message 1042 If the reply message type is KRB_ERROR, then the client interprets it as 1043 an error and performs whatever application-specific tasks are necessary 1044 to recover. 1046 3.2. The Client/Server Authentication Exchange 1048 Summary 1049 Message direction Message type Section 1050 Client to Application server KRB_AP_REQ 5.5.1 1051 [optional] Application server to client KRB_AP_REP or 5.5.2 1052 KRB_ERROR 5.9.1 1054 The client/server authentication (CS) exchange is used by network 1055 applications to authenticate the client to the server and vice versa. 1056 The client must have already acquired credentials for the server using 1057 the AS or TGS exchange. 1059 3.2.1. The KRB_AP_REQ message 1061 The KRB_AP_REQ contains authentication information which should be part 1062 of the first message in an authenticated transaction. It contains a 1063 ticket, an authenticator, and some additional bookkeeping information 1064 (see section 5.5.1 for the exact format). The ticket by itself is 1065 insufficient to authenticate a client, since tickets are passed across 1066 the network in cleartext[3.4] <#fn3.4>, so the authenticator is used to 1067 prevent invalid replay of tickets by proving to the server that the 1068 client knows the session key of the ticket and thus is entitled to use 1069 the ticket. The KRB_AP_REQ message is referred to elsewhere as the 1070 'authentication header.' 1072 3.2.2. Generation of a KRB_AP_REQ message 1074 When a client wishes to initiate authentication to a server, it obtains 1075 (either through a credentials cache, the AS exchange, or the TGS 1076 exchange) a ticket and session key for the desired service. The client 1077 may re-use any tickets it holds until they expire. To use a ticket the 1078 client constructs a new Authenticator from the the system time, its 1079 name, and optionally an application specific checksum, an initial 1080 sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a 1081 session subkey to be used in negotiations for a session key unique to 1082 this particular session. Authenticators may not be re-used and will be 1083 rejected if replayed to a server[3.5] <#fn3.5>. If a sequence number is 1084 to be included, it should be randomly chosen so that even after many 1085 messages have been exchanged it is not likely to collide with other 1086 sequence numbers in use. 1088 The client may indicate a requirement of mutual authentication or the 1089 use of a session-key based ticket by setting the appropriate flag(s) in 1090 the ap-options field of the message. 1092 The Authenticator is encrypted in the session key and combined with the 1093 ticket to form the KRB_AP_REQ message which is then sent to the end 1094 server along with any additional application-specific information. 1096 [Insert paragraph for extensions ] 1098 3.2.3. Receipt of KRB_AP_REQ message 1100 Authentication is based on the server's current time of day (clocks must 1101 be loosely synchronized), the authenticator, and the ticket. Several 1102 errors are possible. If an error occurs, the server is expected to reply 1103 to the client with a KRB_ERROR message. This message may be encapsulated 1104 in the application protocol if its 'raw' form is not acceptable to the 1105 protocol. The format of error messages is described in section 5.9.1. 1107 The algorithm for verifying authentication information is as follows. If 1108 the message type is not KRB_AP_REQ, the server returns the 1109 KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in 1110 the KRB_AP_REQ is not one the server can use (e.g., it indicates an old 1111 key, and the server no longer possesses a copy of the old key), the 1112 KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is 1113 set in the ap-options field, it indicates to the server that the ticket 1114 is encrypted in the session key from the server's ticket-granting ticket 1115 rather than its secret key [3.6] <#fn3.6>. 1117 Since it is possible for the server to be registered in multiple realms, 1118 with different keys in each, the srealm field in the unencrypted portion 1119 of the ticket in the KRB_AP_REQ is used to specify which secret key the 1120 server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error 1121 code is returned if the server doesn't have the proper key to decipher 1122 the ticket. 1124 The ticket is decrypted using the version of the server's key specified 1125 by the ticket. If the decryption routines detect a modification of the 1126 ticket (each encryption system must provide safeguards to detect 1127 modified ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error 1128 is returned (chances are good that different keys were used to encrypt 1129 and decrypt). 1131 The authenticator is decrypted using the session key extracted from the 1132 decrypted ticket. If decryption shows it to have been modified, the 1133 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the 1134 client from the ticket are compared against the same fields in the 1135 authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is 1136 returned; this normally is caused by a client error or attempted attack. 1137 The addresses in the ticket (if any) are then searched for an address 1138 matching the operating-system reported address of the client. If no 1139 match is found or the server insists on ticket addresses but none are 1140 present in the ticket, the KRB_AP_ERR_BADADDR error is returned. If the 1141 local (server) time and the client time in the authenticator differ by 1142 more than the allowable clock skew (e.g., 5 minutes), the 1143 KRB_AP_ERR_SKEW error is returned. 1145 Unless the application server provides its own suitable means to protect 1146 against replay (for example, a challenge-response sequence initiated by 1147 the server after authentication, or use of a server-generated encryption 1148 subkey), the server must utilize a replay cache to remember any 1149 authenticator presented within the allowable clock skew. Careful 1150 analysis of the application protocol and implementation is recommended 1151 before eliminating this cache. The replay cache will store the server 1152 name, along with the client name, time and microsecond fields from the 1153 recently-seen authenticators and if a matching tuple is found, the 1154 KRB_AP_ERR_REPEAT error is returned [3.7] <#fn3.7>. If a server loses 1155 track of authenticators presented within the allowable clock skew, it 1156 must reject all requests until the clock skew interval has passed, 1157 providing assurance that any lost or re-played authenticators will fall 1158 outside the allowable clock skew and can no longer be successfully 1159 replayed[3.8] <#fn3.8>. 1161 If a sequence number is provided in the authenticator, the server saves 1162 it for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a 1163 subkey is present, the server either saves it for later use or uses it 1164 to help generate its own choice for a subkey to be returned in a 1165 KRB_AP_REP message. 1167 If multiple servers (for example, different services on one machine, or 1168 a single service implemented on multiple machines) share a service 1169 principal (a practice we do not recommend in general, but acknowledge 1170 will be used in some cases), they should also share this replay cache, 1171 or the application protocol should be designed so as to eliminate the 1172 need for it. Note that this applies to all of the services, if any of 1173 the application protocols does not have replay protection built in; an 1174 authenticator used with such a service could later be replayed to a 1175 different service with the same service principal but no replay 1176 protection, if the former doesn't record the authenticator information 1177 in the common replay cache. 1179 The server computes the age of the ticket: local (server) time minus the 1180 start time inside the Ticket. If the start time is later than the 1181 current time by more than the allowable clock skew or if the INVALID 1182 flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. 1183 Otherwise, if the current time is later than end time by more than the 1184 allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is returned. 1186 If all these checks succeed without an error, the server is assured that 1187 the client possesses the credentials of the principal named in the 1188 ticket and thus, the client has been authenticated to the server. 1190 Passing these checks provides only authentication of the named 1191 principal; it does not imply authorization to use the named service. 1192 Applications must make a separate authorization decisions based upon the 1193 authenticated name of the user, the requested operation, local access 1194 control information such as that contained in a .k5login or .k5users 1195 file, and possibly a separate distributed authorization service. 1197 3.2.4. Generation of a KRB_AP_REP message 1199 Typically, a client's request will include both the authentication 1200 information and its initial request in the same message, and the server 1201 need not explicitly reply to the KRB_AP_REQ. However, if mutual 1202 authentication (not only authenticating the client to the server, but 1203 also the server to the client) is being performed, the KRB_AP_REQ 1204 message will have MUTUAL-REQUIRED set in its ap-options field, and a 1205 KRB_AP_REP message is required in response. As with the error message, 1206 this message may be encapsulated in the application protocol if its 1207 "raw" form is not acceptable to the application's protocol. The 1208 timestamp and microsecond field used in the reply must be the client's 1209 timestamp and microsecond field (as provided in the authenticator)[3.9] 1210 <#fn3.9>. If a sequence number is to be included, it should be randomly 1211 chosen as described above for the authenticator. A subkey may be 1212 included if the server desires to negotiate a different subkey. The 1213 KRB_AP_REP message is encrypted in the session key extracted from the 1214 ticket. 1216 [Insert paragraph for extensions ] 1218 3.2.5. Receipt of KRB_AP_REP message 1220 If a KRB_AP_REP message is returned, the client uses the session key 1221 from the credentials obtained for the server[3.10] <#fn3.10> to decrypt 1222 the message, and verifies that the timestamp and microsecond fields 1223 match those in the Authenticator it sent to the server. If they match, 1224 then the client is assured that the server is genuine. The sequence 1225 number and subkey (if present) are retained for later use. 1227 3.2.6. Using the encryption key 1229 [This seems inconsistent with crypto-architecture; we should look at 1230 before publication.] 1231 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and 1232 server share an encryption key which can be used by the application. In 1233 some cases, the use of this session key will be implicit in the 1234 protocol; in others the method of use must be chosen from several 1235 alternatives. The 'true session key' to be used for KRB_PRIV, KRB_SAFE, 1236 or other application-specific uses may be chosen by the application 1237 based on the session key from the ticket and subkeys in the KRB_AP_REP 1238 message and the authenticator[3.11] <#fn3.11>. To mitigate the effect of 1239 failures in random number generation on the client it is strongly 1240 encouraged that any key derived by an application for subsequent use 1241 include the full key entropy derived from the KDC generated session key 1242 carried in the ticket. We leave the protocol negotiations of how to use 1243 the key (e.g. selecting an encryption or checksum type) to the 1244 application programmer; the Kerberos protocol does not constrain the 1245 implementation options, but an example of how this might be done follows. 1247 One way that an application may choose to negotiate a key to be used for 1248 subsequent integrity and privacy protection is for the client to propose 1249 a key in the subkey field of the authenticator. The server can then 1250 choose a key using the proposed key from the client as input, returning 1251 the new subkey in the subkey field of the application reply. This key 1252 could then be used for subsequent communication. 1254 To make this example more concrete, if the communication patterns of an 1255 application dictates the use of encryption modes of operation 1256 incompatible with the encryption system used for the authenticator, then 1257 a key compatible with the required encryption system may be generated by 1258 either the client, the server, or collaboratively by both and exchanged 1259 using the subkey field. This generation might involve the use of a 1260 random number as a pre-key, initially generated by either party, which 1261 could then be encrypted using the session key from the ticket, and the 1262 result exchanged and used for subsequent encryption. By encrypting the 1263 pre-key with the session key from the ticket, randomness from the KDC 1264 generated key is assured of being present in the negotiated key. 1265 Application developers must be careful however, to use a means of 1266 introducing this entropy that does not allow an attacker to learn the 1267 session key from the ticket if it learns the key generated and used for 1268 subsequent communication. The reader should note that this is only an 1269 example, and that an analysis of the particular cryptosystem to be used, 1270 must be made before deciding how to generate values for the subkey 1271 fields, and the key to be used for subsequent communication. 1273 With both the one-way and mutual authentication exchanges, the peers 1274 should take care not to send sensitive information to each other without 1275 proper assurances. In particular, applications that require privacy or 1276 integrity should use the KRB_AP_REP response from the server to client 1277 to assure both client and server of their peer's identity. If an 1278 application protocol requires privacy of its messages, it can use the 1279 KRB_PRIV message (section 3.5). The KRB_SAFE message (section 3.4) can 1280 be used to assure integrity. 1282 3.3. The Ticket-Granting Service (TGS) Exchange 1284 Summary 1285 Message direction Message type Section 1286 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1287 2. Kerberos to client KRB_TGS_REP or 5.4.2 1288 KRB_ERROR 5.9.1 1290 The TGS exchange between a client and the Kerberos Ticket-Granting 1291 Server is initiated by a client when it wishes to obtain authentication 1292 credentials for a given server (which might be registered in a remote 1293 realm), when it wishes to renew or validate an existing ticket, or when 1294 it wishes to obtain a proxy ticket. In the first case, the client must 1295 already have acquired a ticket for the Ticket-Granting Service using the 1296 AS exchange (the ticket-granting ticket is usually obtained when a 1297 client initially authenticates to the system, such as when a user logs 1298 in). The message format for the TGS exchange is almost identical to that 1299 for the AS exchange. The primary difference is that encryption and 1300 decryption in the TGS exchange does not take place under the client's 1301 key. Instead, the session key from the ticket-granting ticket or 1302 renewable ticket, or sub-session key from an Authenticator is used. As 1303 is the case for all application servers, expired tickets are not 1304 accepted by the TGS, so once a renewable or ticket-granting ticket 1305 expires, the client must use a separate exchange to obtain valid tickets. 1307 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from 1308 the client to the Kerberos Ticket-Granting Server, and a reply 1309 (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes information 1310 authenticating the client plus a request for credentials. The 1311 authentication information consists of the authentication header 1312 (KRB_AP_REQ) which includes the client's previously obtained 1313 ticket-granting, renewable, or invalid ticket. In the ticket-granting 1314 ticket and proxy cases, the request may include one or more of: a list 1315 of network addresses, a collection of typed authorization data to be 1316 sealed in the ticket for authorization use by the application server, or 1317 additional tickets (the use of which are described later). The TGS reply 1318 (KRB_TGS_REP) contains the requested credentials, encrypted in the 1319 session key from the ticket-granting ticket or renewable ticket, or if 1320 present, in the sub-session key from the Authenticator (part of the 1321 authentication header). The KRB_ERROR message contains an error code and 1322 text explaining what went wrong. The KRB_ERROR message is not encrypted. 1323 The KRB_TGS_REP message contains information which can be used to detect 1324 replays, and to associate it with the message to which it replies. The 1325 KRB_ERROR message also contains information which can be used to 1326 associate it with the message to which it replies. The same comments 1327 about integrity protection of KRB_ERROR messages mentioned in section 1328 3.1 apply to the TGS exchange. 1330 3.3.1. Generation of KRB_TGS_REQ message 1332 Before sending a request to the ticket-granting service, the client must 1333 determine in which realm the application server is believed to be 1334 registered[3.12] <#fn3.12>. If the client knows the service principal 1335 name and realm and it does not already possess a ticket-granting ticket 1336 for the appropriate realm, then one must be obtained. This is first 1337 attempted by requesting a ticket-granting ticket for the destination 1338 realm from a Kerberos server for which the client possesses a 1339 ticket-granting ticket (using the KRB_TGS_REQ message recursively). The 1340 Kerberos server may return a TGT for the desired realm in which case one 1341 can proceed. Alternatively, the Kerberos server may return a TGT for a 1342 realm which is 'closer' to the desired realm (further along the standard 1343 hierarchical path between the client's realm and the requested realm 1344 server's realm). 1346 Once the client obtains a ticket-granting ticket for the appropriate 1347 realm, it determines which Kerberos servers serve that realm, and 1348 contacts one. The list might be obtained through a configuration file or 1349 network service or it may be generated from the name of the realm; as 1350 long as the secret keys exchanged by realms are kept secret, only denial 1351 of service results from using a false Kerberos server. 1353 As in the AS exchange, the client may specify a number of options in the 1354 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, 1355 providing an authentication header as an element of the padata field, 1356 and including the same fields as used in the KRB_AS_REQ message along 1357 with several optional fields: the enc-authorization-data field for 1358 application server use and additional tickets required by some options. 1360 In preparing the authentication header, the client can select a 1361 sub-session key under which the response from the Kerberos server will 1362 be encrypted[3.13] <#fn3.13>. If the sub-session key is not specified, 1363 the session key from the ticket-granting ticket will be used. If the 1364 enc-authorization-data is present, it must be encrypted in the 1365 sub-session key, if present, from the authenticator portion of the 1366 authentication header, or if not present, using the session key from the 1367 ticket-granting ticket. 1369 Once prepared, the message is sent to a Kerberos server for the 1370 destination realm. 1372 3.3.2. Receipt of KRB_TGS_REQ message 1374 The KRB_TGS_REQ message is processed in a manner similar to the 1375 KRB_AS_REQ message, but there are many additional checks to be 1376 performed. First, the Kerberos server must determine which server the 1377 accompanying ticket is for and it must select the appropriate key to 1378 decrypt it. For a normal KRB_TGS_REQ message, it will be for the ticket 1379 granting service, and the TGS's key will be used. If the TGT was issued 1380 by another realm, then the appropriate inter-realm key must be used. If 1381 the accompanying ticket is not a ticket granting ticket for the current 1382 realm, but is for an application server in the current realm, the RENEW, 1383 VALIDATE, or PROXY options are specified in the request, and the server 1384 for which a ticket is requested is the server named in the accompanying 1385 ticket, then the KDC will decrypt the ticket in the authentication 1386 header using the key of the server for which it was issued. If no ticket 1387 can be found in the padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error 1388 is returned. 1390 Once the accompanying ticket has been decrypted, the user-supplied 1391 checksum in the Authenticator must be verified against the contents of 1392 the request, and the message rejected if the checksums do not match 1393 (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum is not 1394 keyed or not collision-proof (with an error code of 1395 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the 1396 KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data are 1397 present, they are decrypted using the sub-session key from the 1398 Authenticator. 1400 If any of the decryptions indicate failed integrity checks, the 1401 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1403 As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP 1404 message if it receives a KRB_TGS_REQ message identical to one it has 1405 recently processed. However, if the authenticator is a replay, but the 1406 rest of the request is not identical, then the KDC SHOULD return 1407 KRB_AP_ERR_REPEAT. 1409 3.3.3. Generation of KRB_TGS_REP message 1411 The KRB_TGS_REP message shares its format with the KRB_AS_REP 1412 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed 1413 specification is in section 5.4.2. 1415 The response will include a ticket for the requested server or for a 1416 ticket granting server of an intermediate KDC to be contacted to obtain 1417 the requested ticket. The Kerberos database is queried to retrieve the 1418 record for the appropriate server (including the key with which the 1419 ticket will be encrypted). If the request is for a ticket granting 1420 ticket for a remote realm, and if no key is shared with the requested 1421 realm, then the Kerberos server will select the realm 'closest' to the 1422 requested realm with which it does share a key, and use that realm 1423 instead. If the requested server cannot be found in the TGS database, 1424 then a TGT for another trusted realm may be returned instead of a ticket 1425 for the service. This TGT is a referral mechanism to cause the client to 1426 retry the request to the realm of the TGT. These are the only cases 1427 where the response for the KDC will be for a different server than that 1428 requested by the client. 1430 By default, the address field, the client's name and realm, the list of 1431 transited realms, the time of initial authentication, the expiration 1432 time, and the authorization data of the newly-issued ticket will be 1433 copied from the ticket-granting ticket (TGT) or renewable ticket. If the 1434 transited field needs to be updated, but the transited type is not 1435 supported, the KDC_ERR_TRTYPE_NOSUPP error is returned. 1437 If the request specifies an endtime, then the endtime of the new ticket 1438 is set to the minimum of (a) that request, (b) the endtime from the TGT, 1439 and (c) the starttime of the TGT plus the minimum of the maximum life 1440 for the application server and the maximum life for the local realm (the 1441 maximum life for the requesting principal was already applied when the 1442 TGT was issued). If the new ticket is to be a renewal, then the endtime 1443 above is replaced by the minimum of (a) the value of the renew_till 1444 field of the ticket and (b) the starttime for the new ticket plus the 1445 life (endtime-starttime) of the old ticket. 1447 If the FORWARDED option has been requested, then the resulting ticket 1448 will contain the addresses specified by the client. This option will 1449 only be honored if the FORWARDABLE flag is set in the TGT. The PROXY 1450 option is similar; the resulting ticket will contain the addresses 1451 specified by the client. It will be honored only if the PROXIABLE flag 1452 in the TGT is set. The PROXY option will not be honored on requests for 1453 additional ticket-granting tickets. 1455 If the requested start time is absent, indicates a time in the past, or 1456 is within the window of acceptable clock skew for the KDC and the 1457 POSTDATE option has not been specified, then the start time of the 1458 ticket is set to the authentication server's current time. If it 1459 indicates a time in the future beyond the acceptable clock skew, but the 1460 POSTDATED option has not been specified or the MAY-POSTDATE flag is not 1461 set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is returned. 1462 Otherwise, if the ticket-granting ticket has the MAY-POSTDATE flag set, 1463 then the resulting ticket will be postdated and the requested starttime 1464 is checked against the policy of the local realm. If acceptable, the 1465 ticket's start time is set as requested, and the INVALID flag is set. 1466 The postdated ticket must be validated before use by presenting it to 1467 the KDC after the starttime has been reached. However, in no case may 1468 the starttime, endtime, or renew-till time of a newly-issued postdated 1469 ticket extend beyond the renew-till time of the ticket-granting ticket. 1471 If the ENC-TKT-IN-SKEY option has been specified and an additional 1472 ticket has been included in the request, the KDC will decrypt the 1473 additional ticket using the key for the server to which the additional 1474 ticket was issued and verify that it is a ticket-granting ticket. If the 1475 name of the requested server is missing from the request, the name of 1476 the client in the additional ticket will be used. Otherwise the name of 1477 the requested server will be compared to the name of the client in the 1478 additional ticket and if different, the request will be rejected. If the 1479 request succeeds, the session key from the additional ticket will be 1480 used to encrypt the new ticket that is issued instead of using the key 1481 of the server for which the new ticket will be used. 1483 If the name of the server in the ticket that is presented to the KDC as 1484 part of the authentication header is not that of the ticket-granting 1485 server itself, the server is registered in the realm of the KDC, and the 1486 RENEW option is requested, then the KDC will verify that the RENEWABLE 1487 flag is set in the ticket, that the INVALID flag is not set in the 1488 ticket, and that the renew_till time is still in the future. If the 1489 VALIDATE option is requested, the KDC will check that the starttime has 1490 passed and the INVALID flag is set. If the PROXY option is requested, 1491 then the KDC will check that the PROXIABLE flag is set in the ticket. If 1492 the tests succeed, and the ticket passes the hotlist check described in 1493 the next section, the KDC will issue the appropriate new ticket. 1495 The ciphertext part of the response in the KRB_TGS_REP message is 1496 encrypted in the sub-session key from the Authenticator, if present, or 1497 the session key key from the ticket-granting ticket. It is not encrypted 1498 using the client's secret key. Furthermore, the client's key's 1499 expiration date and the key version number fields are left out since 1500 these values are stored along with the client's database record, and 1501 that record is not needed to satisfy a request based on a 1502 ticket-granting ticket. 1504 3.3.3.1. Checking for revoked tickets 1506 Whenever a request is made to the ticket-granting server, the presented 1507 ticket(s) is(are) checked against a hot-list of tickets which have been 1508 canceled. This hot-list might be implemented by storing a range of issue 1509 timestamps for 'suspect tickets'; if a presented ticket had an authtime 1510 in that range, it would be rejected. In this way, a stolen 1511 ticket-granting ticket or renewable ticket cannot be used to gain 1512 additional tickets (renewals or otherwise) once the theft has been 1513 reported to the KDC for the realm in which the server resides. Any 1514 normal ticket obtained before it was reported stolen will still be valid 1515 (because they require no interaction with the KDC), but only until their 1516 normal expiration time. If TGT's have been issued for cross-realm 1517 authentication, use of the cross-realm TGT will not be affected unless 1518 the hot-list is propagated to the KDC's for the realms for which such 1519 cross-realm tickets were issued. 1521 3.3.3.2. Encoding the transited field 1523 If the identity of the server in the TGT that is presented to the KDC as 1524 part of the authentication header is that of the ticket-granting 1525 service, but the TGT was issued from another realm, the KDC will look up 1526 the inter-realm key shared with that realm and use that key to decrypt 1527 the ticket. If the ticket is valid, then the KDC will honor the request, 1528 subject to the constraints outlined above in the section describing the 1529 AS exchange. The realm part of the client's identity will be taken from 1530 the ticket-granting ticket. The name of the realm that issued the 1531 ticket-granting ticket, if it is not the realm of the client principal, 1532 will be added to the transited field of the ticket to be issued. This is 1533 accomplished by reading the transited field from the ticket-granting 1534 ticket (which is treated as an unordered set of realm names), adding the 1535 new realm to the set, then constructing and writing out its encoded 1536 (shorthand) form (this may involve a rearrangement of the existing 1537 encoding). 1539 Note that the ticket-granting service does not add the name of its own 1540 realm. Instead, its responsibility is to add the name of the previous 1541 realm. This prevents a malicious Kerberos server from intentionally 1542 leaving out its own name (it could, however, omit other realms' names). 1544 The names of neither the local realm nor the principal's realm are to be 1545 included in the transited field. They appear elsewhere in the ticket and 1546 both are known to have taken part in authenticating the principal. Since 1547 the endpoints are not included, both local and single-hop inter-realm 1548 authentication result in a transited field that is empty. 1550 Because the name of each realm transited is added to this field, it 1551 might potentially be very long. To decrease the length of this field, 1552 its contents are encoded. The initially supported encoding is optimized 1553 for the normal case of inter-realm communication: a hierarchical 1554 arrangement of realms using either domain or X.500 style realm names. 1555 This encoding (called DOMAIN-X500-COMPRESS) is now described. 1557 Realm names in the transited field are separated by a ",". The ",", "\", 1558 trailing "."s, and leading spaces (" ") are special characters, and if 1559 they are part of a realm name, they must be quoted in the transited 1560 field by preceding them with a "\". 1562 A realm name ending with a "." is interpreted as being prepended to the 1563 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1564 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1566 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1568 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that 1569 they would not be included in this field, and we would have: 1571 "EDU,MIT.,WASHINGTON.EDU" 1573 A realm name beginning with a "/" is interpreted as being appended to 1574 the previous realm[18]. If it is to stand by itself, then it should be 1575 preceded by a space (" "). For example, we can encode traversal of 1576 /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: 1578 "/COM,/HP,/APOLLO, /COM/DEC". 1580 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, 1581 they they would not be included in this field, and we would have: 1583 "/COM,/HP" 1585 A null subfield preceding or following a "," indicates that all realms 1586 between the previous realm and the next realm have been traversed[19]. 1587 Thus, "," means that all realms along the path between the client and 1588 the server have been traversed. ",EDU, /COM," means that that all realms 1589 from the client's realm up to EDU (in a domain style hierarchy) have 1590 been traversed, and that everything from /COM down to the server's realm 1591 in an X.500 style has also been traversed. This could occur if the EDU 1592 realm in one hierarchy shares an inter-realm key directly with the /COM 1593 realm in another hierarchy. 1595 3.3.4. Receipt of KRB_TGS_REP message 1597 When the KRB_TGS_REP is received by the client, it is processed in the 1598 same manner as the KRB_AS_REP processing described above. The primary 1599 difference is that the ciphertext part of the response must be decrypted 1600 using the session key from the ticket-granting ticket rather than the 1601 client's secret key. The server name returned in the reply is the true 1602 principal name of the service. 1604 3.4. The KRB_SAFE Exchange 1606 The KRB_SAFE message may be used by clients requiring the ability to 1607 detect modifications of messages they exchange. It achieves this by 1608 including a keyed collision-proof checksum of the user data and some 1609 control information. The checksum is keyed with an encryption key 1610 (usually the last key negotiated via subkeys, or the session key if no 1611 negotiation has occurred). 1613 3.4.1. Generation of a KRB_SAFE message 1615 When an application wishes to send a KRB_SAFE message, it collects its 1616 data and the appropriate control information and computes a checksum 1617 over them. The checksum algorithm should be the keyed checksum mandated 1618 to be implemented along with the crypto system used for the sub-session 1619 or session key. The checksum is generated using the sub-session key if 1620 present, or the session key. Some implementations use a different 1621 checksum algorithm for KRB_SAFE messages but doing so in a interoperable 1622 manner is impossible. Implementations should accept any checksum 1623 algorithm they implement that both has adequate security and that has 1624 keys compatible with the sub-session or session key. Unkeyed or 1625 non-collision-proof checksums are not suitable for this use. 1627 The control information for the KRB_SAFE message includes both a 1628 timestamp and a sequence number. The designer of an application using 1629 the KRB_SAFE message must choose at least one of the two mechanisms. 1630 This choice should be based on the needs of the application protocol. 1632 Sequence numbers are useful when all messages sent will be received by 1633 one's peer. Connection state is presently required to maintain the 1634 session key, so maintaining the next sequence number should not present 1635 an additional problem. 1637 If the application protocol is expected to tolerate lost messages 1638 without them being resent, the use of the timestamp is the appropriate 1639 replay detection mechanism. Using timestamps is also the appropriate 1640 mechanism for multi-cast protocols where all of one's peers share a 1641 common sub-session key, but some messages will be sent to a subset of 1642 one's peers. 1644 After computing the checksum, the client then transmits the information 1645 and checksum to the recipient in the message format specified in section 1646 5.6.1. 1648 3.4.2. Receipt of KRB_SAFE message 1650 When an application receives a KRB_SAFE message, it verifies it as 1651 follows. If any error occurs, an error code is reported for use by the 1652 application. 1654 The message is first checked by verifying that the protocol version and 1655 type fields match the current version and KRB_SAFE, respectively. A 1656 mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. 1657 The application verifies that the checksum used is a collision-proof 1658 keyed checksum that uses keys compatible with the sub-session or session 1659 key as appropriate, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is 1660 generated. The sender's address MUST be included in the control 1661 information; the recipient verifies that the operating system's report 1662 of the sender's address matches the sender's address in the message, and 1663 (if a recipient address is specified or the recipient requires an 1664 address) that one of the recipient's addresses appears as the 1665 recipient's address in the message. To work with network address 1666 translation, senders MAY wish to use the directional address type 1667 specified in section 8.1 for the sender address and not include 1668 recipient addresses. A failed match for either case generates a 1669 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1670 sequence number fields are checked. If timestamp and usec are expected 1671 and not present, or they are present but not current, the 1672 KRB_AP_ERR_SKEW error is generated. If the server name, along with the 1673 client name, time and microsecond fields from the Authenticator match 1674 any recently-seen (sent or received[20] ) such tuples, the 1675 KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is 1676 included, or a sequence number is expected but not present, the 1677 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec 1678 or a sequence number is present, a KRB_AP_ERR_MODIFIED error is 1679 generated. Finally, the checksum is computed over the data and control 1680 information, and if it doesn't match the received checksum, a 1681 KRB_AP_ERR_MODIFIED error is generated. 1683 If all the checks succeed, the application is assured that the message 1684 was generated by its peer and was not modified in transit. 1686 3.5. The KRB_PRIV Exchange 1688 The KRB_PRIV message may be used by clients requiring confidentiality 1689 and the ability to detect modifications of exchanged messages. It 1690 achieves this by encrypting the messages and adding control information. 1692 3.5.1. Generation of a KRB_PRIV message 1694 When an application wishes to send a KRB_PRIV message, it collects its 1695 data and the appropriate control information (specified in section 1696 5.7.1) and encrypts them under an encryption key (usually the last key 1697 negotiated via subkeys, or the session key if no negotiation has 1698 occurred). As part of the control information, the client must choose to 1699 use either a timestamp or a sequence number (or both); see the 1700 discussion in section 3.4.1 for guidelines on which to use. After the 1701 user data and control information are encrypted, the client transmits 1702 the ciphertext and some 'envelope' information to the recipient. 1704 3.5.2. Receipt of KRB_PRIV message 1706 When an application receives a KRB_PRIV message, it verifies it as 1707 follows. If any error occurs, an error code is reported for use by the 1708 application. 1710 The message is first checked by verifying that the protocol version and 1711 type fields match the current version and KRB_PRIV, respectively. A 1712 mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. 1713 The application then decrypts the ciphertext and processes the resultant 1714 plaintext. If decryption shows the data to have been modified, a 1715 KRB_AP_ERR_BAD_INTEGRITY error is generated. The sender's address MUST 1716 be included in the control information; the recipient verifies that the 1717 operating system's report of the sender's address matches the sender's 1718 address in the message, and (if a recipient address is specified or the 1719 recipient requires an address) that one of the recipient's addresses 1720 appears as the recipient's address in the message. A failed match for 1721 either case generates a KRB_AP_ERR_BADADDR error. To work with network 1722 address translation, implementations MAY wish to use the directional 1723 address type defined in section 8.1 for the sender address and include 1724 no recipient address. Then the timestamp and usec and/or the sequence 1725 number fields are checked. If timestamp and usec are expected and not 1726 present, or they are present but not current, the KRB_AP_ERR_SKEW error 1727 is generated. If the server name, along with the client name, time and 1728 microsecond fields from the Authenticator match any recently-seen such 1729 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect 1730 sequence number is included, or a sequence number is expected but not 1731 present, the KRB_AP_ERR_BADORDER error is generated. If neither a 1732 time-stamp and usec or a sequence number is present, a 1733 KRB_AP_ERR_MODIFIED error is generated. 1735 If all the checks succeed, the application can assume the message was 1736 generated by its peer, and was securely transmitted (without intruders 1737 able to see the unencrypted contents). 1739 3.6. The KRB_CRED Exchange 1741 The KRB_CRED message may be used by clients requiring the ability to 1742 send Kerberos credentials from one host to another. It achieves this by 1743 sending the tickets together with encrypted data containing the session 1744 keys and other information associated with the tickets. 1746 3.6.1. Generation of a KRB_CRED message 1748 When an application wishes to send a KRB_CRED message it first (using 1749 the KRB_TGS exchange) obtains credentials to be sent to the remote host. 1750 It then constructs a KRB_CRED message using the ticket or tickets so 1751 obtained, placing the session key needed to use each ticket in the key 1752 field of the corresponding KrbCredInfo sequence of the encrypted part of 1753 the the KRB_CRED message. 1755 Other information associated with each ticket and obtained during the 1756 KRB_TGS exchange is also placed in the corresponding KrbCredInfo 1757 sequence in the encrypted part of the KRB_CRED message. The current time 1758 and, if specifically required by the application the nonce, s-address, 1759 and r-address fields, are placed in the encrypted part of the KRB_CRED 1760 message which is then encrypted under an encryption key previously 1761 exchanged in the KRB_AP exchange (usually the last key negotiated via 1762 subkeys, or the session key if no negotiation has occurred). 1764 Implementation note: When constructing a KRB_CRED message for inclusion 1765 in a GSSAPI initial context token, the MIT implementation of Kerberos 1766 will not encrypt the KRB_CRED message if the session key is a DES or 1767 tripple DES key. For interoperability with MIT, the Microsoft 1768 implementation will not encrypt the KRB_CRED in a GSSAPI token if it is 1769 using a DES session key. Starting at version 1.2.5, MIT Kerberos can 1770 receive and decode either encrypted or unencrypted KRB_CRED tokens in 1771 the GSSAPI exchange. The Heimdal implementation of Kerberos can also 1772 accept either encrypted or unencrypted KRB_CRED messages. Since the 1773 KRB_CRED message in a GSSAPI token is encrypted in the authenticator, 1774 the MIT behavior does not present a security problem, although it is a 1775 violation of the Kerberos specification. 1777 3.6.2. Receipt of KRB_CRED message 1779 When an application receives a KRB_CRED message, it verifies it. If any 1780 error occurs, an error code is reported for use by the application. The 1781 message is verified by checking that the protocol version and type 1782 fields match the current version and KRB_CRED, respectively. A mismatch 1783 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1784 application then decrypts the ciphertext and processes the resultant 1785 plaintext. If decryption shows the data to have been modified, a 1786 KRB_AP_ERR_BAD_INTEGRITY error is generated. 1788 If present or required, the recipient MAY verify that the operating 1789 system's report of the sender's address matches the sender's address in 1790 the message, and that one of the recipient's addresses appears as the 1791 recipient's address in the message. The address check does not provide 1792 any added security, since the address if present has already been 1793 checked in the KRB_AP_REQ message and there is not any benefit to be 1794 gained by an attacker in reflecting a KRB_CRED message back to its 1795 originator. Thus, the recipient MAY wish to ignore the address even if 1796 present in order to work better in NAT environments. A failed match for 1797 either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY wish to 1798 skip the address check as the KRB_CRED message cannot generally be 1799 reflected back toThe timestamp and usec fields (and the nonce field if 1800 required) are checked next. If the timestamp and usec are not present, 1801 or they are present but not current, the KRB_AP_ERR_SKEW error is 1802 generated. 1804 If all the checks succeed, the application stores each of the new 1805 tickets in its ticket cache together with the session key and other 1806 information in the corresponding KrbCredInfo sequence from the encrypted 1807 part of the KRB_CRED message. 1809 4. SECTION HAS BEEN DELETED 1810 5. Message Specifications 1812 NOTE: The ASN.1 collected here should be identical to the contents of 1813 Appendix A. 1815 NOTE: The semantics described here should also not conflict with those 1816 in section 3, though that still needs checking. 1818 The Kerberos protocol is defined here in terms of Abstract Syntax 1819 Notation One (ASN.1), which provides a syntax for specifying both the 1820 abstract layout of protocol messages as well as their encodings. 1821 Implementors not utilizing an existing ASN.1 compiler or support library 1822 are cautioned to thoroughly understand the actual ASN.1 specification to 1823 ensure correct implementation behavior, as there is more complexity in 1824 the notation than is immediately obvious, and some tutorials and guides 1825 to ASN.1 are misleading or erroneous. 1827 Note that in several places, there have been changes here from RFC 1510 1828 that change the abstract types. This is in part to address widespread 1829 assumptions that various implementations have made, in some cases 1830 resulting in unintentional violations of the ASN.1 standard. These will 1831 be clearly flagged when they occur. The differences between the abstract 1832 types in RFC 1510 and abstract types in this document can cause 1833 incompatible encodings to be emitted when certain encoding rules, e.g. 1834 the Packed Encoding Rules (PER), are used. This theoretical 1835 incompatibility should not be relevant for Kerberos, since Kerberos 1836 explicitly specifies the use of the Distinguished Encoding Rules (DER). 1837 It might be an issue for protocols wishing to use Kerberos types with 1838 other encoding rules. (This practice is not recommended.) With very few 1839 exceptions (most notably the usages of BIT STRING), the encodings 1840 emitted by the DER remain identical between the types defined in RFC 1841 1510 and the types defined in this document. 1843 The type definitions in this section assume an ASN.1 module definition 1844 of the following form: 1846 Kerberos5 { 1847 iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 1848 } DEFINITIONS ::= BEGIN 1850 -- rest of definitions here 1852 END 1854 This specifies that the tagging context for the module will be explicit 1855 and non-automatic. 1857 Note that in some other publications [RFC1510] [RFC1964], the "dod" 1858 portion of the object identifier is erroneously specified as having the 1859 value "5". In the case of RFC 1964, use of the "correct" OID value would 1860 result in a change in the wire protocol; therefore, it remains unchanged 1861 for now. 1863 Note that elsewhere in this document, nomenclature for various message 1864 types is inconsistent, but seems to largely follow C language 1865 conventions, including use of underscore (_) characters and all-caps 1866 spelling of names intended to be numeric constants. Also, in some 1867 places, identifiers (especially ones refering to constants) are written 1868 in all-caps in order to distinguish them from surrounding explanatory text. 1870 The ASN.1 notation does not permit underscores in identifiers, so in 1871 actual ASN.1 definitions, underscores are replaced with hyphens (-). 1872 Additionally, structure member names and defined values in ASN.1 must 1873 begin with a lowercase letter, while type names must begin with an 1874 uppercase letter. 1876 5.1. Specific Compatibility Notes on ASN.1 1878 For compatibility purposes, implementors should heed the following 1879 specific notes regarding the use of ASN.1 in Kerberos. These notes do 1880 not describe deviations from standard usage of ASN.1. The purpose of 1881 these notes is to instead describe some historical quirks and 1882 non-compliance of various implementations, as well as historical 1883 ambiguities, which, while being valid ASN.1, can lead to confusion 1884 during implementation. 1886 5.1.1. ASN.1 Distinguished Encoding Rules 1888 The encoding of Kerberos protocol messages shall obey the Distinguished 1889 Encoding Rules (DER) of ASN.1 as described in X.690 (1997). Some 1890 implementations (believed to be primarly ones derived from DCE 1.1 and 1891 earlier) are known to use the more general Basic Encoding Rules (BER); 1892 in particular, these implementations send indefinite encodings of 1893 lengths. Implementations may accept such encodings in the interests of 1894 backwards compatibility, though implementors are warned that decoding 1895 fully-general BER is fraught with peril. 1897 5.1.2. Optional Integer Fields 1899 Some implementations do not internally distinguish between an omitted 1900 optional integer value and a transmitted value of zero. The places in 1901 the protocol where this is relevant include various microseconds fields, 1902 nonces, and sequence numbers. Implementations should treat omitted 1903 optional integer values as having been transmitted with a value of zero, 1904 if the application is expecting this. 1906 5.1.3. Zero-length SEQUENCE Types 1908 There are places in the protocol where a message contains a SEQUENCE OF 1909 type as an optional member, or a SEQUENCE type where all members are 1910 optional. This can result in an encoding that contains a zero-length 1911 SEQUENCE or SEQUENCE OF encoding. Implementations should not send 1912 zero-length SEQUENCE OF or SEQUENCE encodings that are marked OPTIONAL, 1913 but should accept them as being equivalent to an omitted OPTIONAL type. 1915 5.1.4. Unrecognized Tag Numbers 1917 Future revisions to this protocol may include new message types with 1918 different APPLICATION class tag numbers. Such revisions should protect 1919 older implementations by only sending the message types to parties that 1920 are known to understand them, e.g. by means of a flag bit set by the 1921 receiver in a preceding request. In the interest of robust error 1922 handling, implementations should gracefully handle receiving a message 1923 with an unrecognized tag anyway, and return an error message if 1924 appropriate. 1926 5.1.5. Tag Numbers Greater Than 30 1928 A naive implementation of a DER ASN.1 decoder may experience problems 1929 with ASN.1 tag numbers greater than 30, due to such tag numbers being 1930 encoded using more than one byte. Future revisions of this protocol may 1931 utilize tag numbers greater than 30, and implementations should be 1932 prepared to gracefully return an error, if appropriate, if they do not 1933 recognize the tag. 1935 5.2. Basic Kerberos Types 1937 This section defines a number of basic types that are potentially used 1938 in multiple Kerberos protocol messages. 1940 5.2.1. KerberosString 1942 [XXX The following paragraphs may need some editing, or maybe they want 1943 to live in a footnote] 1945 [XXX Note that this duplicates much of the contents of jaltman's draft] 1947 The original specification of the Kerberos protocol in RFC 1510 uses 1948 GeneralString in numerous places for human-readable string data. 1949 Historical implementations of Kerberos cannot utilize the full power of 1950 GeneralString. This ASN.1 type requires the use of designation and 1951 invocation escape sequences as specified in ISO 2022 to switch character 1952 sets, and the default character set that is designated for G0 is 1953 basically US ASCII, which mostly works. In practice, many 1954 implementations end up treating GeneralStrings as if they were strings 1955 of whatever character set the implementation defaults to, without regard 1956 for correct usage of character set designation escape sequences. 1958 Also, DER prohibits the invocation of character sets into any but the G0 1959 and C0 sets, which seems to outright prohibit the encoding of characters 1960 with the high bit set. Unfortunately, this seems to have the side effect 1961 of prohibiting the transmission of Latin-1 characters or any other 1962 characters that belong to a 96-character set, since it is prohibited to 1963 invoke them into G0. Some inconclusive discussion has taken place within 1964 the ASN.1 community on this subject. For now, we must assume that the 1965 ASN.1 specification of GeneralString as currently published is 1966 fundamentally flawed in several ways. 1968 One method of resolving these myriad difficulties is to constrain the 1969 use of GeneralString to only include IA5String, which is essentially the 1970 US-ASCII. US-ASCII control characters should in general not be used in 1971 KerberosString, except for cases such as newlines in lengthy error 1972 messages. 1974 The new (since RFC 1510) type KerberosString, defined below, is a 1975 GeneralString that is constrained to only contain characters in 1976 IA5String (which are US-ASCII). Note that the ASN.1 standard does not 1977 permit the use of escape sequences to change the character sets while 1978 encoding an IA5String. 1980 KerberosString ::= GeneralString (IA5String) 1982 Implementations may choose to accept GeneralString values that contain 1983 characters other than those permitted by IA5String, but they should be 1984 aware that character set designation codes will likely be absent, and 1985 that the encoding should probably be treated as locale-specific in 1986 almost every way. Implementations may also choose to emit GeneralString 1987 values that are beyond those permitted by IA5String, but should be aware 1988 that doing so is extraordinarily risky from an interoperability 1989 perspective. 1991 Some existing implementations use GeneralString to encode unescaped 1992 locale-specific characters. This is in violation of the ASN.1 standard. 1993 Most of these implementations encode US-ASCII in the left-hand half, so 1994 as long the implementation transmits only US-ASCII, the ASN.1 standard 1995 is not violated in this regard. As soon as such an implementation 1996 encodes unescaped locale-specific characters with the high bit set, it 1997 violates the ASN.1 standard. 1999 Other implementations have been known to use GeneralString to contain a 2000 UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 is a 2001 different encoding, not a 94 or 96 character "G" set as defined by ISO 2002 2022. It is believed that these implementations do not even use the ISO 2003 2022 escape sequence to change the character encoding. Even if 2004 implementations were to announce the change of encoding by using that 2005 escape sequence, the ASN.1 standard prohibits the use of any escape 2006 sequences other than those used to designate/invoke "G" or "C" sets 2007 allowed by GeneralString. 2009 Future revisions to this protocol will almost certainly allow for a more 2010 interoperable representation of principal names, probably including 2011 UTF8String. 2013 Note that applying a new constraint to a previously unconstrained type 2014 constitutes creation of a new ASN.1 type. In this particular case, the 2015 change does not result in a changed encoding under DER. 2017 5.2.2. Realm and PrincipalName 2019 Realm ::= KerberosString 2021 PrincipalName ::= SEQUENCE { 2022 name-type [0] Int32, 2023 name-string [1] SEQUENCE OF KerberosString 2024 } 2025 Kerberos realm names are encoded as KerberosStrings. Realms shall not 2026 contain a character with the code 0 (the ASCII NUL). Most realms will 2027 usually consist of several components separated by periods (.), in the 2028 style of Internet Domain Names, or separated by slashes (/) in the style 2029 of X.500 names. Acceptable forms for realm names are specified in 2030 section 7. A PrincipalName is a typed sequence of components consisting 2031 of the following sub-fields: 2033 name-type 2034 This field specifies the type of name that follows. Pre-defined 2035 values for this field are specified in section 7.2. The name-type 2036 should be treated as a hint. Ignoring the name type, no two names 2037 can be the same (i.e. at least one of the components, or the realm, 2038 must be different). This constraint may be eliminated in the future. 2039 name-string 2040 This field encodes a sequence of components that form a name, each 2041 component encoded as a KerberosString. Taken together, a 2042 PrincipalName and a Realm form a principal identifier. Most 2043 PrincipalNames will have only a few components (typically one or two). 2045 5.2.3. KerberosTime 2047 KerberosTime ::= GeneralizedTime -- with no fractional seconds 2049 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 2050 KerberosTime value shall not include any fractional portions of the 2051 seconds. As required by the DER, it further shall not include any 2052 separators, and it shall specify the UTC time zone (Z). Example: The 2053 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 2054 November 1985 is 19851106210627Z. 2056 5.2.4. Constrained Integer types 2058 Some integer members of types should be constrained to values 2059 representable in 32 bits, for compatibility with reasonable 2060 implementation limits. 2062 Int32 ::= INTEGER (-2147483648..2147483647) 2063 -- signed values representable in 32 bits 2065 UInt32 ::= INTEGER (0..4294967295) 2066 -- unsigned 32 bit values 2068 Microseconds ::= INTEGER (0..999999) 2069 -- microseconds 2071 While this results in changes to the abstract types from the RFC 1510 2072 version, the encoding in DER should be unaltered. Historical 2073 implementations were typically limited to 32-bit integer values anyway, 2074 and assigned numbers should fall in the space of integer values 2075 representable in 32 bits in order to promote interoperability anyway. 2077 There are some members of messages types that are still defined as 2078 unconstrained INTEGER types, but many of these have a (non-ASN.1) 2079 constraint applied in the descriptive text. There are specific cases 2080 where more discussion needs to occur regarding possible constraints, 2081 such as for the nonce fields in various messages. 2083 There are several integer fields in messages that are constrained to 2084 fixed values. 2086 pvno 2087 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always 2088 the constant integer 5. There is no easy way to make this field into 2089 a useful protocol version number, so its value is fixed. 2090 msg-type 2091 this integer field usually is identical to the application tag 2092 number of the containing message type. 2094 5.2.5. HostAddress and HostAddresses 2096 HostAddress ::= SEQUENCE { 2097 addr-type [0] Int32, 2098 address [1] OCTET STRING 2099 } 2101 -- XXX HostAddresses is always used as an OPTIONAL field and can be 2102 -- zero-length. 2103 HostAddresses -- XXX subtly different from rfc1510, 2104 -- but has a value mapping and encodes the same 2105 ::= SEQUENCE OF HostAddress 2107 The host address encodings consists of two fields: 2109 addr-type 2110 This field specifies the type of address that follows. Pre-defined 2111 values for this field are specified in section 8.1. 2112 address 2113 This field encodes a single address of type addr-type. 2115 The two forms differ slightly. HostAddress contains exactly one address; 2116 HostAddresses contains a sequence of possibly many addresses. 2118 5.2.6. AuthorizationData 2120 -- XXX AuthorizationData is always used as an OPTIONAL field and can 2121 -- be zero-length. 2122 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2123 ad-type [0] Int32, 2124 ad-data [1] OCTET STRING 2125 } 2127 ad-data 2128 This field contains authorization data to be interpreted according 2129 to the value of the corresponding ad-type field. 2130 ad-type 2131 This field specifies the format for the ad-data subfield. All 2132 negative values are reserved for local use. Non-negative values are 2133 reserved for registered use. 2135 Each sequence of type and data is referred to as an authorization 2136 element. Elements may be application specific, however, there is a 2137 common set of recursive elements that should be understood by all 2138 implementations. These elements contain other elements embedded within 2139 them, and the interpretation of the encapsulating element determines 2140 which of the embedded elements must be interpreted, and which may be 2141 ignored. Definitions for these common elements may be found in Appendix 2142 B <#ap_adata>. 2144 5.2.7. PA-DATA 2146 Historically, PA-DATA have been known as "pre-authentication data", 2147 meaning that they were used to augment the initial authentication with 2148 the KDC. Since that time, they have also been used as a typed hole with 2149 which to extend protocol exchanges with the KDC. 2151 PA-DATA ::= SEQUENCE { 2152 padata-type [1] Int32 -- first tag is [1], not [0] --, 2153 padata-value [2] OCTET STRING -- might be encoded AP-REQ 2154 } 2156 padata-type 2157 indicates the way that the padata-value element is to be 2158 interpreted. Negative values of padata-type are reserved for 2159 unregistered use; non-negative values are used for a registered 2160 interpretation of the element type. 2161 padata-value 2162 Usually contains the DER encoding of another type; the padata-type 2163 field identifies which type is encoded here. 2165 padata-type name contents of padata-value 2166 1 pa-tgs-req DER encoding of AP-REQ 2167 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 2168 3 pa-pw-salt salt (not ASN.1 encoded) 2169 10 pa-etype-info DER encoding of PA-ETYPE-INFO 2171 [XXX -- the following paragraph needs discussion, as does the general 2172 concept of authenticating the cleartext pieces of the protocol] 2174 This field may also contain information needed by certain extensions to 2175 the Kerberos protocol. For example, it might be used to initially verify 2176 the identity of a client before any response is returned. 2178 [XXX -- The following paragraph is subject to change pending the outcome 2179 of discussions concerning authenticated cleartext] 2181 When this field is used to authenticate or pre-authenticate a request, 2182 it should contain a keyed checksum over the KDC-REQ-BODY to bind the 2183 pre-authentication data to rest of the request. The KDC, as a matter of 2184 policy, may decide whether to honor a KDC-REQ which includes any 2185 pre-authentication data that does not contain the checksum field. 2187 It may also be used by the client to specify the version of a key that 2188 is being used for accompanying preauthentication, and/or which should be 2189 used to encrypt the reply from the KDC. [XXX the following paragraph 2190 should apply perhaps to PA-DATA in general] 2192 The padata field can also contain information needed to help the KDC or 2193 the client select the key needed for generating or decrypting the 2194 response. This form of the padata is useful for supporting the use of 2195 certain token cards with Kerberos. The details of such extensions are 2196 specified in separate documents. See [Pat92] for additional uses of this 2197 field. 2199 5.2.7.1. PA-TGS-REQ 2201 In the case of requests for additional tickets (KRB_TGS_REQ), 2202 padata-value will contain an encoded AP-REQ. The checksum in the 2203 authenticator (which must be collision-proof) is to be computed over the 2204 KDC-REQ-BODY encoding. 2206 5.2.7.2. Encrypted Timestamp Pre-authentication 2208 There are pre-authentication types that may be used to pre-authenticate 2209 a client by means of an encrypted timestamp. 2211 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 2213 PA-ENC-TS-ENC ::= SEQUENCE { 2214 patimestamp [0] KerberosTime -- client's time --, 2215 pausec [1] Microseconds OPTIONAL 2216 } 2218 Patimestamp contains the client's time, and pausec contains the 2219 microseconds, which may be omitted if a client will not generate more 2220 than one request per second. The ciphertext (padata-value) consists of 2221 the PA-ENC-TS-ENC encoding, encrypted using the client's secret key. 2223 This preauthentication type was not present in RFC 1510, but many 2224 implementations support it. 2226 5.2.7.3. PA-PW-SALT 2228 The padata-value for this preauthentication type contains the salt for 2229 the string-to-key to be used by the client to obtain the key for 2230 decrypting the encrypted part of an AS-REP message. Unfortunately, for 2231 historical reasons, the character set to be used is unspecified and 2232 probably locale-specific. 2234 This preauthentication type was not present in RFC 1510, but many 2235 implementations support it. It is necessary in any case where the salt 2236 for the string-to-key algorithm is not the default. 2238 In the trivial example, a zero-length salt string is very commonplace 2239 for realms that have converted their principal databases from Kerberos 4. 2241 5.2.7.4. PA-ETYPE-INFO 2243 The ETYPE-INFO preauthentication type is sent by the KDC in a KRB-ERROR 2244 indicating a requirement for additional preauthentication. It is usually 2245 used to notify a client of which key to use for the encryption of an 2246 encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP 2247 preauthentication value. 2249 ETYPE-INFO-ENTRY ::= SEQUENCE { 2250 etype [0] Int32, 2251 salt [1] OCTET STRING OPTIONAL 2252 } 2254 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 2255 The salt, like that of PA-PW-SALT, is also completely unspecified with 2256 respect to character set and is probably locale-specific. 2258 [XXX -- not clear whether ETYPE-INFO or PW-SALT should take precedence 2259 if they conflict] 2261 This preauthentication type was not present in RFC 1510, but many 2262 implementations that support encrypted timestamps for preauthentication 2263 need to support ETYPE-INFO as well. 2265 5.2.8. KerberosFlags 2267 For several message types, a specific constrained bit string type, 2268 KerberosFlags, is used. 2270 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 2271 -- shall be sent, but no fewer than 32 2273 Compatibility note: the following paragraphs describe a change from the 2274 RFC1510 description of bit strings that would result in incompatility in 2275 the case of an implementation that strictly conformed to ASN.1 DER and 2276 RFC1510. 2278 ASN.1 bit strings have multiple uses. The simplest use of a bit string 2279 is to contain a vector of bits, with no particular meaning attached to 2280 individual bits. This vector of bits is not necessarily a multiple of 2281 eight bits long. The use in Kerberos of a bit string as a compact 2282 boolean vector wherein each element has a distinct meaning poses some 2283 problems. The natural notation for a compact boolean vector is the ASN.1 2284 "NamedBit" notation, and the DER require that encodings of a bit string 2285 using "NamedBit" notation exclude any trailing zero bits. This 2286 truncation is easy to neglect, especially given C language 2287 implementations that may naturally choose to store boolean vectors as 32 2288 bit integers. 2290 For example, if the notation for KDCOptions were to include the 2291 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be 2292 encoded had only the "forwardable" (bit number one) bit set, the DER 2293 encoding must only include two bits: the first reserved bit ("reserved", 2294 bit number zero, value zero) and the one-valued bit (bit number one) for 2295 "forwardable". 2297 Most existing implementations of Kerberos unconditionally send 32 bits 2298 on the wire when encoding bit strings used as boolean vectors. This 2299 behavior violates the ASN.1 syntax used for flag values in RFC 1510, but 2300 occurs on such a widely installed base that the protocol description is 2301 being modified to accomodate it. 2303 Consequently, this document removes the "NamedBit" notations for 2304 individual bits, relegating them to comments. The size constraint on the 2305 KerberosFlags type requires that at least 32 bits be encoded at all 2306 times, though a lenient implementation may choose to accept fewer than 2307 32 bits and to treat the missing bits as set to zero. 2309 Currently, no uses of KerberosFlags specify more than 32 bits worth of 2310 flags, although future revisions of this document may do so. When more 2311 than 32 bits are to be transmitted in a KerberosFlags value, future 2312 revisions to this document will likely specify that the smallest number 2313 of bits needed to encode the highest-numbered one-valued bit should be 2314 sent. This is somewhat similar to the DER encoding of a bit string that 2315 is declared with the "NamedBit" notation. 2317 5.2.9. Cryptosystem-related Types 2319 Many Kerberos protocol messages contain an EncryptedData as a container 2320 for arbitrary encrypted data, which is often the encrypted encoding of 2321 another data type. Fields within EncryptedData assist the recipient in 2322 selecting a key with which to decrypt the enclosed data. 2324 EncryptedData ::= SEQUENCE { 2325 etype [0] Int32 -- EncryptionType --, 2326 kvno [1] UInt32 OPTIONAL, 2327 cipher [2] OCTET STRING -- ciphertext 2328 } 2330 etype 2331 This field identifies which encryption algorithm was used to 2332 encipher the cipher. Detailed specifications for selected encryption 2333 types appear in section 6. kvno 2334 This field contains the version number of the key under which data 2335 is encrypted. It is only present in messages encrypted under long 2336 lasting keys, such as principals' secret keys. cipher 2337 This field contains the enciphered text, encoded as an OCTET STRING. 2339 The EncryptionKey type is the means by which cryptographic keys used for 2340 encryption are transfered. 2342 EncryptionKey ::= SEQUENCE { 2343 keytype [0] Int32 -- actually encryption type --, 2344 keyvalue [1] OCTET STRING 2345 } 2347 keytype 2348 This field specifies the encryption type of the encryption key that 2349 follows in the keyvalue field. While its name is "keytype", it 2350 actually specifies an encryption type. Previously, multiple 2351 cryptosystems that performed encryption differently but were capable 2352 of using keys with the same characteristics were permitted to share 2353 an assigned number to designate the type of key; this usage is now 2354 deprecated. keyvalue 2355 This field contains the key itself, encoded as an octet string. 2357 All negative values for the encryption key type are reserved for 2358 local use. All non-negative values are reserved for officially 2359 assigned type fields and interpretations. 2361 Messages containing cleartext data to be authenticated will usually do 2362 so by using a member of type Checksum. Most instances of Checksum use a 2363 keyed hash, though exceptions will be noted. 2365 Checksum ::= SEQUENCE { 2366 cksumtype [0] Int32, 2367 checksum [1] OCTET STRING 2368 } 2370 cksumtype 2371 This field indicates the algorithm used to generate the accompanying 2372 checksum. checksum 2373 This field contains the checksum itself, encoded as an octet string. 2375 Detailed specification of selected checksum types appear in section 2376 6. Negative values for the checksum type are reserved for local use. 2377 All non-negative values are reserved for officially assigned type 2378 fields and interpretations. 2380 5.3. Tickets 2382 This section describes the format and encryption parameters for tickets 2383 and authenticators. When a ticket or authenticator is included in a 2384 protocol message it is treated as an opaque object. A ticket is a record 2385 that helps a client authenticate to a service. A Ticket contains the 2386 following information: 2388 Ticket ::= [APPLICATION 1] SEQUENCE { 2389 tkt-vno [0] INTEGER (5), 2390 realm [1] Realm, 2391 sname [2] PrincipalName, 2392 enc-part [3] EncryptedData -- EncTicketPart 2393 } 2395 -- Encrypted part of ticket 2396 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2397 flags [0] TicketFlags, 2398 key [1] EncryptionKey, 2399 crealm [2] Realm, 2400 cname [3] PrincipalName, 2401 transited [4] TransitedEncoding, 2402 authtime [5] KerberosTime, 2403 starttime [6] KerberosTime OPTIONAL, 2404 endtime [7] KerberosTime, 2405 renew-till [8] KerberosTime OPTIONAL, 2406 caddr [9] HostAddresses OPTIONAL, 2407 authorization-data [10] AuthorizationData OPTIONAL 2408 } 2410 -- encoded Transited field 2411 TransitedEncoding ::= SEQUENCE { 2412 tr-type [0] Int32 -- must be registered --, 2413 contents [1] OCTET STRING 2414 } 2416 TicketFlags ::= KerberosFlags 2417 -- reserved(0), 2418 -- forwardable(1), 2419 -- forwarded(2), 2420 -- proxiable(3), 2421 -- proxy(4), 2422 -- may-postdate(5), 2423 -- postdated(6), 2424 -- invalid(7), 2425 -- renewable(8), 2426 -- initial(9), 2427 -- pre-authent(10), 2428 -- hw-authent(11), 2429 -- the following are new since 1510; maybe remove from krb-clarifications? 2430 -- transited-policy-checked(12), 2431 -- ok-as-delegate(13) 2432 The encoding of EncTicketPart is encrypted in the key shared by Kerberos 2433 and the end server (the server's secret key). See section 6 for the 2434 format of the ciphertext. 2436 tkt-vno 2437 This field specifies the version number for the ticket format. This 2438 document describes version number 5. 2439 realm 2440 This field specifies the realm that issued a ticket. It also serves 2441 to identify the realm part of the server's principal identifier. 2442 Since a Kerberos server can only issue tickets for servers within 2443 its realm, the two will always be identical. 2444 sname 2445 This field specifies all components of the name part of the server's 2446 identity, including those parts that identify a specific instance of 2447 a service. 2448 enc-part 2449 This field holds the encrypted encoding of the EncTicketPart sequence. 2450 flags 2451 This field indicates which of various options were used or requested 2452 when the ticket was issued. It is a bit-field, where the selected 2453 options are indicated by the bit being set (1), and the unselected 2454 options and reserved fields being reset (0). [XXX X.690 ref and 2455 notes on pitfalls?] The meanings of the flags are: 2457 Bit(s) Name Description 2459 0 reserved Reserved for future expansion of this field. 2461 1 forwardable The FORWARDABLE flag is normally only interpreted by 2462 the TGS, and can be ignored by end servers. When set, this flag 2463 tells the ticket-granting server that it is OK to issue a new 2464 ticket-granting ticket with a different network address based on the 2465 presented ticket. 2467 2 forwarded When set, this flag indicates that the ticket has either 2468 been forwarded or was issued based on authentication involving a 2469 forwarded ticket-granting ticket. 2471 3 proxiable The PROXIABLE flag is normally only interpreted by the 2472 TGS, and can be ignored by end servers. The PROXIABLE flag has an 2473 interpretation identical to that of the FORWARDABLE flag, except 2474 that the PROXIABLE flag tells the ticket-granting server that only 2475 non-ticket-granting tickets may be issued with different network 2476 addresses. 2478 4 proxy When set, this flag indicates that a ticket is a proxy. 2480 5 may-postdate The MAY-POSTDATE flag is normally only interpreted by 2481 the TGS, and can be ignored by end servers. This flag tells the 2482 ticket-granting server that a post-dated ticket may be issued based 2483 on this ticket-granting ticket. 2485 6 postdated This flag indicates that this ticket has been postdated. 2486 The end-service can check the authtime field to see when the 2487 original authentication occurred. 2489 7 invalid This flag indicates that a ticket is invalid, and it must 2490 be validated by the KDC before use. Application servers must reject 2491 tickets which have this flag set. 2493 8 renewable The RENEWABLE flag is normally only interpreted by the 2494 TGS, and can usually be ignored by end servers (some particularly 2495 careful servers may wish to disallow renewable tickets). A renewable 2496 ticket can be used to obtain a replacement ticket that expires at a 2497 later date. 2499 9 initial This flag indicates that this ticket was issued using the 2500 AS protocol, and not issued based on a ticket-granting ticket. 2502 10 pre-authent This flag indicates that during initial 2503 authentication, the client was authenticated by the KDC before a 2504 ticket was issued. The strength of the preauthentication method is 2505 not indicated, but is acceptable to the KDC. 2507 11 hw-authent This flag indicates that the protocol employed for 2508 initial authentication required the use of hardware expected to be 2509 possessed solely by the named client. The hardware authentication 2510 method is selected by the KDC and the strength of the method is not 2511 indicated. 2513 12 transited- policy-checked This flag indicates that the KDC for 2514 the realm has checked the transited field against a realm defined 2515 policy for trusted certifiers. If this flag is reset (0), then the 2516 application server must check the transited field itself, and if 2517 unable to do so it must reject the authentication. If the flag is 2518 set (1) then the application server may skip its own validation of 2519 the transited field, relying on the validation performed by the KDC. 2520 At its option the application server may still apply its own 2521 validation based on a separate policy for acceptance. 2523 This flag is new since RFC 1510. 2525 13 ok-as-delegate This flag indicates that the server (not the 2526 client) specified in the ticket has been determined by policy of the 2527 realm to be a suitable recipient of delegation. A client can use the 2528 presence of this flag to help it make a decision whether to delegate 2529 credentials (either grant a proxy or a forwarded ticket granting 2530 ticket) to this server. The client is free to ignore the value of 2531 this flag. When setting this flag, an administrator should consider 2532 the Security and placement of the server on which the service will 2533 run, as well as whether the service requires the use of delegated 2534 credentials. 2536 This flag is new since RFC 1510. 2538 14-31 reserved Reserved for future use. 2540 key 2541 This field exists in the ticket and the KDC response and is used to 2542 pass the session key from Kerberos to the application server and the 2543 client. The field's encoding is described in section 6.2. 2544 crealm 2545 This field contains the name of the realm in which the client is 2546 registered and in which initial authentication took place. 2547 cname 2548 This field contains the name part of the client's principal identifier. 2550 transited 2551 This field lists the names of the Kerberos realms that took part in 2552 authenticating the user to whom this ticket was issued. It does not 2553 specify the order in which the realms were transited. See section 2554 3.3.3.2 for details on how this field encodes the traversed realms. 2555 When the names of CA's are to be embedded in the transited field (as 2556 specified for some extensions to the protocol), the X.500 names of 2557 the CA's should be mapped into items in the transited field using 2558 the mapping defined by RFC2253. 2559 authtime 2560 This field indicates the time of initial authentication for the 2561 named principal. It is the time of issue for the original ticket on 2562 which this ticket is based. It is included in the ticket to provide 2563 additional information to the end service, and to provide the 2564 necessary information for implementation of a `hot list' service at 2565 the KDC. An end service that is particularly paranoid could refuse 2566 to accept tickets for which the initial authentication occurred "too 2567 far" in the past. This field is also returned as part of the 2568 response from the KDC. When returned as part of the response to 2569 initial authentication (KRB_AS_REP), this is the current time on the 2570 Kerberos server[24]. 2571 starttime 2572 This field in the ticket specifies the time after which the ticket 2573 is valid. Together with endtime, this field specifies the life of 2574 the ticket. If it is absent from the ticket, its value should be 2575 treated as that of the authtime field. 2576 endtime 2577 This field contains the time after which the ticket will not be 2578 honored (its expiration time). Note that individual services may 2579 place their own limits on the life of a ticket and may reject 2580 tickets which have not yet expired. As such, this is really an upper 2581 bound on the expiration time for the ticket. 2582 renew-till 2583 This field is only present in tickets that have the RENEWABLE flag 2584 set in the flags field. It indicates the maximum endtime that may be 2585 included in a renewal. It can be thought of as the absolute 2586 expiration time for the ticket, including all renewals. 2587 caddr 2588 This field in a ticket contains zero (if omitted) or more (if 2589 present) host addresses. These are the addresses from which the 2590 ticket can be used. If there are no addresses, the ticket can be 2591 used from any location. The decision by the KDC to issue or by the 2592 end server to accept zero-address tickets is a policy decision and 2593 is left to the Kerberos and end-service administrators; they may 2594 refuse to issue or accept such tickets. The suggested and default 2595 policy, however, is that such tickets will only be issued or 2596 accepted when additional information that can be used to restrict 2597 the use of the ticket is included in the authorization_data field. 2598 Such a ticket is a capability. 2600 Network addresses are included in the ticket to make it harder for 2601 an attacker to use stolen credentials. Because the session key is 2602 not sent over the network in cleartext, credentials can't be stolen 2603 simply by listening to the network; an attacker has to gain access 2604 to the session key (perhaps through operating system security 2605 breaches or a careless user's unattended session) to make use of 2606 stolen tickets. 2608 It is important to note that the network address from which a 2609 connection is received cannot be reliably determined. Even if it 2610 could be, an attacker who has compromised the client's workstation 2611 could use the credentials from there. Including the network 2612 addresses only makes it more difficult, not impossible, for an 2613 attacker to walk off with stolen credentials and then use them from 2614 a "safe" location. 2616 authorization-data 2617 The authorization-data field is used to pass authorization data from 2618 the principal on whose behalf a ticket was issued to the application 2619 service. If no authorization data is included, this field will be 2620 left out. Experience has shown that the name of this field is 2621 confusing, and that a better name for this field would be 2622 restrictions. Unfortunately, it is not possible to change the name 2623 of this field at this time. 2625 This field contains restrictions on any authority obtained on the 2626 basis of authentication using the ticket. It is possible for any 2627 principal in posession of credentials to add entries to the 2628 authorization data field since these entries further restrict what 2629 can be done with the ticket. Such additions can be made by 2630 specifying the additional entries when a new ticket is obtained 2631 during the TGS exchange, or they may be added during chained 2632 delegation using the authorization data field of the authenticator. 2634 Because entries may be added to this field by the holder of 2635 credentials, except when an entry is separately authenticated by 2636 encapsulation in the kdc-issued element, it is not allowable for the 2637 presence of an entry in the authorization data field of a ticket to 2638 amplify the privileges one would obtain from using a ticket. 2640 The data in this field may be specific to the end service; the field 2641 will contain the names of service specific objects, and the rights 2642 to those objects. The format for this field is described in section 2643 5.2. Although Kerberos is not concerned with the format of the 2644 contents of the sub-fields, it does carry type information (ad-type). 2646 By using the authorization_data field, a principal is able to issue 2647 a proxy that is valid for a specific purpose. For example, a client 2648 wishing to print a file can obtain a file server proxy to be passed 2649 to the print server. By specifying the name of the file in the 2650 authorization_data field, the file server knows that the print 2651 server can only use the client's rights when accessing the 2652 particular file to be printed. 2654 A separate service providing authorization or certifying group 2655 membership may be built using the authorization-data field. In this 2656 case, the entity granting authorization (not the authorized entity), 2657 may obtain a ticket in its own name (e.g. the ticket is issued in 2658 the name of a privilege server), and this entity adds restrictions 2659 on its own authority and delegates the restricted authority through 2660 a proxy to the client. The client would then present this 2661 authorization credential to the application server separately from 2662 the authentication exchange. Alternatively, such authorization 2663 credentials may be embedded in the ticket authenticating the 2664 authorized entity, when the authorization is separately 2665 authenticated using the kdc-issued authorization data element (see 2666 B.4). 2668 Similarly, if one specifies the authorization-data field of a proxy 2669 and leaves the host addresses blank, the resulting ticket and 2670 session key can be treated as a capability. See [Neu93] for some 2671 suggested uses of this field. 2673 The authorization-data field is optional and does not have to be 2674 included in a ticket. 2676 5.4. Specifications for the AS and TGS exchanges 2678 This section specifies the format of the messages used in the exchange 2679 between the client and the Kerberos server. The format of possible error 2680 messages appears in section 5.9.1. 2682 5.4.1. KRB_KDC_REQ definition 2684 The KRB_KDC_REQ message has no application tag number of its own. 2685 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, which 2686 each have an application tag, depending on whether the request is for an 2687 initial ticket or an additional ticket. In either case, the message is 2688 sent from the client to the KDC to request credentials for a service. 2690 The message fields are: 2692 AS-REQ ::= [APPLICATION 10] KDC-REQ 2694 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2696 KDC-REQ ::= SEQUENCE { 2697 pvno [1] INTEGER (5) -- first tag is [1], not [0] --, 2698 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 2699 padata [3] SEQUENCE OF PA-DATA OPTIONAL 2700 -- XXX may be zero-length --, 2701 req-body [4] KDC-REQ-BODY 2702 } 2704 KDC-REQ-BODY ::= SEQUENCE { 2705 kdc-options [0] KDCOptions, 2706 cname [1] PrincipalName OPTIONAL 2707 -- Used only in AS-REQ --, 2708 realm [2] Realm 2709 -- Server's realm 2710 -- Also client's in AS-REQ --, 2711 sname [3] PrincipalName OPTIONAL, 2712 from [4] KerberosTime OPTIONAL, 2713 till [5] KerberosTime, 2714 rtime [6] KerberosTime OPTIONAL, 2715 nonce [7] UInt32, 2716 etype [8] SEQUENCE OF Int32 -- EncryptionType 2717 -- in preference order --, 2718 addresses [9] HostAddresses OPTIONAL, 2719 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 2720 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 2721 -- XXX may be zero-length 2722 } 2723 KDCOptions ::= KerberosFlags 2724 -- reserved(0), 2725 -- forwardable(1), 2726 -- forwarded(2), 2727 -- proxiable(3), 2728 -- proxy(4), 2729 -- allow-postdate(5), 2730 -- postdated(6), 2731 -- unused7(7), 2732 -- renewable(8), 2733 -- unused9(9), 2734 -- unused10(10), 2735 -- unused11(11), 2736 -- unused12(12), 2737 -- unused13(13), 2738 -- 26 was unused in 1510 2739 -- disable-transited-check(26), 2740 -- 2741 -- renewable-ok(27), 2742 -- enc-tkt-in-skey(28), 2743 -- renew(30), 2744 -- validate(31) 2746 The fields in this message are: 2748 pvno 2749 This field is included in each message, and specifies the protocol 2750 version number. This document specifies protocol version 5. 2751 msg-type 2752 This field indicates the type of a protocol message. It will almost 2753 always be the same as the application identifier associated with a 2754 message. It is included to make the identifier more readily 2755 accessible to the application. For the KDC-REQ message, this type 2756 will be KRB_AS_REQ or KRB_TGS_REQ. 2757 padata 2758 Contains pre-authentication data. Requests for additional tickets 2759 (KRB_TGS_REQ) must contain a padata of PA-TGS-REQ. 2761 The padata (pre-authentication data) field contains a sequence of 2762 authentication information which may be needed before credentials 2763 can be issued or decrypted. In most requests for initial 2764 authentication (KRB_AS_REQ) and most replies (KDC-REP), the padata 2765 field will be left out. 2767 req-body 2768 This field is a placeholder delimiting the extent of the remaining 2769 fields. If a checksum is to be calculated over the request, it is 2770 calculated over an encoding of the KDC-REQ-BODY sequence which is 2771 enclosed within the req-body field. 2772 kdc-options 2773 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2774 KDC and indicates the flags that the client wants set on the tickets 2775 as well as other information that is to modify the behavior of the 2776 KDC. Where appropriate, the name of an option may be the same as the 2777 flag that is set by that option. Although in most case, the bit in 2778 the options field will be the same as that in the flags field, this 2779 is not guaranteed, so it is not acceptable to simply copy the 2780 options field to the flags field. There are various checks that must 2781 be made before honoring an option anyway. 2783 The kdc_options field is a bit-field, where the selected options are 2784 indicated by the bit being set (1), and the unselected options and 2785 reserved fields being reset (0). The encoding of the bits is 2786 specified in section 5.2. The options are described in more detail 2787 above in section 2. The meanings of the options are: 2789 Bits Name Description 2791 0 RESERVED Reserved for future expansion of this field. 2793 1 FORWARDABLE The FORWARDABLE option indicates that the ticket to be 2794 issued is to have its forwardable flag set. It may only be set on 2795 the initial request, or in a subsequent request if the 2796 ticket-granting ticket on which it is based is also forwardable. 2798 2 FORWARDED The FORWARDED option is only specified in a request to 2799 the ticket-granting server and will only be honored if the 2800 ticket-granting ticket in the request has its FORWARDABLE bit set. 2801 This option indicates that this is a request for forwarding. The 2802 address(es) of the host from which the resulting ticket is to be 2803 valid are included in the addresses field of the request. 2805 3 PROXIABLE The PROXIABLE option indicates that the ticket to be 2806 issued is to have its proxiable flag set. It may only be set on the 2807 initial request, or in a subsequent request if the ticket-granting 2808 ticket on which it is based is also proxiable. 2810 4 PROXY The PROXY option indicates that this is a request for a 2811 proxy. This option will only be honored if the ticket-granting 2812 ticket in the request has its PROXIABLE bit set. The address(es) of 2813 the host from which the resulting ticket is to be valid are included 2814 in the addresses field of the request. 2816 5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates that the ticket 2817 to be issued is to have its MAY-POSTDATE flag set. It may only be 2818 set on the initial request, or in a subsequent request if the 2819 ticket-granting ticket on which it is based also has its 2820 MAY-POSTDATE flag set. 2822 6 POSTDATED The POSTDATED option indicates that this is a request 2823 for a postdated ticket. This option will only be honored if the 2824 ticket-granting ticket on which it is based has its MAY-POSTDATE 2825 flag set. The resulting ticket will also have its INVALID flag set, 2826 and that flag may be reset by a subsequent request to the KDC after 2827 the starttime in the ticket has been reached. 2829 7 UNUSED This option is presently unused. 2831 8 RENEWABLE The RENEWABLE option indicates that the ticket to be 2832 issued is to have its RENEWABLE flag set. It may only be set on the 2833 initial request, or when the ticket-granting ticket on which the 2834 request is based is also renewable. If this option is requested, 2835 then the rtime field in the request contains the desired absolute 2836 expiration time for the ticket. 2838 9 RESERVED Reserved for PK-Cross 2840 10-13 UNUSED These options are presently unused. 2842 14-25 RESERVED Reserved for future use. 2844 26 DISABLE-TRANSITED-CHECK By default the KDC will check the 2845 transited field of a ticket-granting-ticket against the policy of 2846 the local realm before it will issue derivative tickets based on the 2847 ticket granting ticket. If this flag is set in the request, checking 2848 of the transited field is disabled. Tickets issued without the 2849 performance of this check will be noted by the reset (0) value of 2850 the TRANSITED-POLICY-CHECKED flag, indicating to the application 2851 server that the tranisted field must be checked locally. KDC's are 2852 encouraged but not required to honor the DISABLE-TRANSITED-CHECK 2853 option. 2855 This flag is new since RFC 1510 2857 27 RENEWABLE-OK The RENEWABLE-OK option indicates that a renewable 2858 ticket will be acceptable if a ticket with the requested life cannot 2859 otherwise be provided. If a ticket with the requested life cannot be 2860 provided, then a renewable ticket may be issued with a renew-till 2861 equal to the the requested endtime. The value of the renew-till 2862 field may still be limited by local limits, or limits selected by 2863 the individual principal or server. 2865 28 ENC-TKT-IN-SKEY This option is used only by the ticket-granting 2866 service. The ENC-TKT-IN-SKEY option indicates that the ticket for 2867 the end server is to be encrypted in the session key from the 2868 additional ticket-granting ticket provided. 2870 29 RESERVED Reserved for future use. 2872 30 RENEW This option is used only by the ticket-granting service. 2873 The RENEW option indicates that the present request is for a 2874 renewal. The ticket provided is encrypted in the secret key for the 2875 server on which it is valid. This option will only be honored if the 2876 ticket to be renewed has its RENEWABLE flag set and if the time in 2877 its renew-till field has not passed. The ticket to be renewed is 2878 passed in the padata field as part of the authentication header. 2880 31 VALIDATE This option is used only by the ticket-granting service. 2881 The VALIDATE option indicates that the request is to validate a 2882 postdated ticket. It will only be honored if the ticket presented is 2883 postdated, presently has its INVALID flag set, and would be 2884 otherwise usable at this time. A ticket cannot be validated before 2885 its starttime. The ticket presented for validation is encrypted in 2886 the key of the server for which it is valid and is passed in the 2887 padata field as part of the authentication header. 2889 cname and sname 2890 These fields are the same as those described for the ticket in 2891 section 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY 2892 option is specified. If absent, the name of the server is taken from 2893 the name of the client in the ticket passed as additional-tickets. 2894 enc-authorization-data 2895 The enc-authorization-data, if present (and it can only be present 2896 in the TGS_REQ form), is an encoding of the desired 2897 authorization-data encrypted under the sub-session key if present in 2898 the Authenticator, or alternatively from the session key in the 2899 ticket-granting ticket, both from the padata field in the KRB_AP_REQ. 2901 realm 2902 This field specifies the realm part of the server's principal 2903 identifier. In the AS exchange, this is also the realm part of the 2904 client's principal identifier. If the CANONICALIZE option is set, 2905 the realm is used as a hint to the KDC for its database lookup. 2906 from 2907 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 2908 requests when the requested ticket is to be postdated. It specifies 2909 the desired start time for the requested ticket. If this field is 2910 omitted then the KDC should use the current time instead. 2911 till 2912 This field contains the expiration date requested by the client in a 2913 ticket request. It is not optional, but if the requested endtime is 2914 "19700101000000Z", the requested ticket is to have the maximum 2915 endtime permitted according to KDC policy for. This special 2916 timestamp corresponds to a UNIX time_t value of zero on most systems. 2917 rtime 2918 This field is the requested renew-till time sent from a client to 2919 the KDC in a ticket request. It is optional. 2920 nonce 2921 This field is part of the KDC request and response. It it intended 2922 to hold a random number generated by the client. If the same number 2923 is included in the encrypted response from the KDC, it provides 2924 evidence that the response is fresh and has not been replayed by an 2925 attacker. Nonces must never be re-used. Ideally, it should be 2926 generated randomly, but if the correct time is known, it may 2927 suffice[25]. 2928 etype 2929 This field specifies the desired encryption algorithm to be used in 2930 the response. 2931 addresses 2932 This field is included in the initial request for tickets, and 2933 optionally included in requests for additional tickets from the 2934 ticket-granting server. It specifies the addresses from which the 2935 requested ticket is to be valid. Normally it includes the addresses 2936 for the client's host. If a proxy is requested, this field will 2937 contain other addresses. The contents of this field are usually 2938 copied by the KDC into the caddr field of the resulting ticket. 2939 additional-tickets 2940 Additional tickets may be optionally included in a request to the 2941 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 2942 specified, then the session key from the additional ticket will be 2943 used in place of the server's key to encrypt the new ticket. When 2944 the ENC-TKT-IN-SKEY option is used for user-to-user authentication, 2945 this addional ticket may be a TGT issued by the local realm or an 2946 inter-realm TGT issued for the current KDC's realm by a remote KDC. 2947 If more than one option which requires additional tickets has been 2948 specified, then the additional tickets are used in the order 2949 specified by the ordering of the options bits (see kdc-options, above). 2951 The application tag number will be either ten (10) or twelve (12) 2952 depending on whether the request is for an initial ticket (AS-REQ) or 2953 for an additional ticket (TGS-REQ). 2955 The optional fields (addresses, authorization-data and 2956 additional-tickets) are only included if necessary to perform the 2957 operation specified in the kdc-options field. 2959 It should be noted that in KRB_TGS_REQ, the protocol version number 2960 appears twice and two different message types appear: the KRB_TGS_REQ 2961 message contains these fields as does the authentication header 2962 (KRB_AP_REQ) that is passed in the padata field. 2964 5.4.2. KRB_KDC_REP definition 2966 The KRB_KDC_REP message format is used for the reply from the KDC for 2967 either an initial (AS) request or a subsequent (TGS) request. There is 2968 no message type for KRB_KDC_REP. Instead, the type will be either 2969 KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext part 2970 of the reply depends on the message type. For KRB_AS_REP, the ciphertext 2971 is encrypted in the client's secret key, and the client's key version 2972 number is included in the key version number for the encrypted data. For 2973 KRB_TGS_REP, the ciphertext is encrypted in the sub-session key from the 2974 Authenticator, or if absent, the session key from the ticket-granting 2975 ticket used in the request. In that case, no version number will be 2976 present in the EncryptedData sequence. 2978 The KRB_KDC_REP message contains the following fields: 2980 AS-REP ::= [APPLICATION 11] KDC-REP 2982 TGS-REP ::= [APPLICATION 13] KDC-REP 2984 KDC-REP ::= SEQUENCE { 2985 pvno [0] INTEGER (5), 2986 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 2987 padata [2] SEQUENCE OF PA-DATA OPTIONAL 2988 -- XXX may be zero length --, 2989 crealm [3] Realm, 2990 cname [4] PrincipalName, 2991 ticket [5] Ticket, 2992 enc-part [6] EncryptedData 2993 -- EncASRepPart or EncTGSRepPart, 2994 -- as appropriate 2995 } 2997 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 2999 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 3001 EncKDCRepPart ::= SEQUENCE { 3002 key [0] EncryptionKey, 3003 last-req [1] LastReq, 3004 nonce [2] UInt32, 3005 key-expiration [3] KerberosTime OPTIONAL, 3006 flags [4] TicketFlags, 3007 authtime [5] KerberosTime, 3008 starttime [6] KerberosTime OPTIONAL, 3009 endtime [7] KerberosTime, 3010 renew-till [8] KerberosTime OPTIONAL, 3011 srealm [9] Realm, 3012 sname [10] PrincipalName, 3013 caddr [11] HostAddresses OPTIONAL 3014 } 3016 LastReq ::= SEQUENCE OF SEQUENCE { 3017 lr-type [0] Int32, 3018 lr-value [1] KerberosTime 3019 } 3020 pvno and msg-type 3021 These fields are described above in section 5.4.1. msg-type is 3022 either KRB_AS_REP or KRB_TGS_REP. 3023 padata 3024 This field is described in detail in section 5.4.1. One possible use 3025 for this field is to encode an alternate "mix-in" string to be used 3026 with a string-to-key algorithm (such as is described in section 3027 6.3.2). This ability is useful to ease transitions if a realm name 3028 needs to change (e.g. when a company is acquired); in such a case 3029 all existing password-derived entries in the KDC database would be 3030 flagged as needing a special mix-in string until the next password 3031 change. 3032 crealm, cname, srealm and sname 3033 These fields are the same as those described for the ticket in 3034 section 5.3.1. 3035 ticket 3036 The newly-issued ticket, from section 5.3.1. enc-part 3037 This field is a place holder for the ciphertext and related 3038 information that forms the encrypted part of a message. The 3039 description of the encrypted part of the message follows each 3040 appearance of this field. The encrypted part is encoded as described 3041 in section 6.1. 3043 Compatibility note: Some implementations unconditionally send an 3044 encrypted EncTGSRepPart (application tag number 26) in this field 3045 regardless of whether the reply is a AS-REP or a TGS-REP. In the 3046 interests of compatibility, implementors may wish to relax the check 3047 on the tag number of the decrypted ENC-PART. 3049 key 3050 This field is the same as described for the ticket in section 5.3.1. 3051 last-req 3052 This field is returned by the KDC and specifies the time(s) of the 3053 last request by a principal. Depending on what information is 3054 available, this might be the last time that a request for a 3055 ticket-granting ticket was made, or the last time that a request 3056 based on a ticket-granting ticket was successful. It also might 3057 cover all servers for a realm, or just the particular server. Some 3058 implementations may display this information to the user to aid in 3059 discovering unauthorized use of one's identity. It is similar in 3060 spirit to the last login time displayed when logging into 3061 timesharing systems. 3063 lr-type 3064 This field indicates how the following lr-value field is to be 3065 interpreted. Negative values indicate that the information pertains 3066 only to the responding server. Non-negative values pertain to all 3067 servers for the realm. 3069 If the lr-type field is zero (0), then no information is conveyed by 3070 the lr-value subfield. If the absolute value of the lr-type field is 3071 one (1), then the lr-value subfield is the time of last initial 3072 request for a TGT. If it is two (2), then the lr-value subfield is 3073 the time of last initial request. If it is three (3), then the 3074 lr-value subfield is the time of issue for the newest 3075 ticket-granting ticket used. If it is four (4), then the lr-value 3076 subfield is the time of the last renewal. If it is five (5), then 3077 the lr-value subfield is the time of last request (of any type). If 3078 it is (6), then the lr-value subfield is the time when the password 3079 will expire. 3081 lr-value 3082 This field contains the time of the last request. the time must be 3083 interpreted according to the contents of the accompanying lr-type 3084 subfield. 3086 nonce 3087 This field is described above in section 5.4.1. 3088 key-expiration 3089 The key-expiration field is part of the response from the KDC and 3090 specifies the time that the client's secret key is due to expire. 3091 The expiration might be the result of password aging or an account 3092 expiration. This field will usually be left out of the TGS reply 3093 since the response to the TGS request is encrypted in a session key 3094 and no client information need be retrieved from the KDC database. 3095 It is up to the application client (usually the login program) to 3096 take appropriate action (such as notifying the user) if the 3097 expiration time is imminent. 3098 flags, authtime, starttime, endtime, renew-till and caddr 3099 These fields are duplicates of those found in the encrypted portion 3100 of the attached ticket (see section 5.3.1), provided so the client 3101 may verify they match the intended request and to assist in proper 3102 ticket caching. If the message is of type KRB_TGS_REP, the caddr 3103 field will only be filled in if the request was for a proxy or 3104 forwarded ticket, or if the user is substituting a subset of the 3105 addresses from the ticket granting ticket. If the client-requested 3106 addresses are not present or not used, then the addresses contained 3107 in the ticket will be the same as those included in the 3108 ticket-granting ticket. 3110 5.5. Client/Server (CS) message specifications 3112 This section specifies the format of the messages used for the 3113 authentication of the client to the application server. 3115 5.5.1. KRB_AP_REQ definition 3117 The KRB_AP_REQ message contains the Kerberos protocol version number, 3118 the message type KRB_AP_REQ, an options field to indicate any options in 3119 use, and the ticket and authenticator themselves. The KRB_AP_REQ message 3120 is often referred to as the 'authentication header'. 3122 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3123 pvno [0] INTEGER (5), 3124 msg-type [1] INTEGER (14), 3125 ap-options [2] APOptions, 3126 ticket [3] Ticket, 3127 authenticator [4] EncryptedData -- Authenticator 3128 } 3130 APOptions ::= KerberosFlags 3131 -- reserved(0), 3132 -- use-session-key(1), 3133 -- mutual-required(2) 3134 pvno and msg-type 3135 These fields are described above in section 5.4.1. msg-type is 3136 KRB_AP_REQ. ap-options 3137 This field appears in the application request (KRB_AP_REQ) and 3138 affects the way the request is processed. It is a bit-field, where 3139 the selected options are indicated by the bit being set (1), and the 3140 unselected options and reserved fields being reset (0). The encoding 3141 of the bits is specified in section 5.2. The meanings of the options 3142 are: 3144 Bit(s) Name Description 3146 0 reserved Reserved for future expansion of this field. 3148 1 use-session-key The USE-SESSION-KEY option indicates that the 3149 ticket the client is presenting to a server is encrypted in the 3150 session key from the server's ticket-granting ticket. When this 3151 option is not specified, the ticket is encrypted in the server's 3152 secret key. 3154 2 mutual-required The MUTUAL-REQUIRED option tells the server that 3155 the client requires mutual authentication, and that it must respond 3156 with a KRB_AP_REP message. 3158 3-31 reserved Reserved for future use. 3160 ticket 3161 This field is a ticket authenticating the client to the server. 3162 authenticator 3163 This contains the encrypted authenticator, which includes the 3164 client's choice of a subkey. 3166 The encrypted authenticator is included in the AP-REQ; it certifies to a 3167 server that the sender has recent knowledge of the encryption key in the 3168 accompanying ticket, to help the server detect replays. It also assists 3169 in the selection of a "true session key" to use with the particular 3170 session. The DER encoding of the following is encrypted in the ticket's 3171 session key: 3173 -- Unencrypted authenticator 3174 Authenticator ::= [APPLICATION 2] SEQUENCE { 3175 authenticator-vno [0] INTEGER (5), 3176 crealm [1] Realm, 3177 cname [2] PrincipalName, 3178 cksum [3] Checksum OPTIONAL, 3179 cusec [4] Microseconds, 3180 ctime [5] KerberosTime, 3181 subkey [6] EncryptionKey OPTIONAL, 3182 seq-number [7] UInt32 OPTIONAL, 3183 authorization-data [8] AuthorizationData OPTIONAL 3184 } 3186 authenticator-vno 3187 This field specifies the version number for the format of the 3188 authenticator. This document specifies version 5. crealm and cname 3189 These fields are the same as those described for the ticket in 3190 section 5.3.1. 3192 cksum 3193 This field contains a checksum of the the application data that 3194 accompanies the KRB_AP_REQ. 3195 cusec 3196 This field contains the microsecond part of the client's timestamp. 3197 Its value (before encryption) ranges from 0 to 999999. It often 3198 appears along with ctime. The two fields are used together to 3199 specify a reasonably accurate timestamp. 3200 ctime 3201 This field contains the current time on the client's host. subkey 3202 This field contains the client's choice for an encryption key which 3203 is to be used to protect this specific application session. Unless 3204 an application specifies otherwise, if this field is left out the 3205 session key from the ticket will be used. 3206 seq-number 3207 This optional field includes the initial sequence number to be used 3208 by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used 3209 to detect replays (It may also be used by application specific 3210 messages). When included in the authenticator this field specifies 3211 the initial sequence number for messages from the client to the 3212 server. When included in the AP-REP message, the initial sequence 3213 number is that for messages from the server to the client. When used 3214 in KRB_PRIV or KRB_SAFE messages, it is incremented by one after 3215 each message is sent. Sequence numbers fall in the range of 0 3216 through 2^32 - 1 and wrap to zero following the value 2^32 - 1. 3218 For sequence numbers to adequately support the detection of replays 3219 they should be non-repeating, even across connection boundaries. The 3220 initial sequence number should be random and uniformly distributed 3221 across the full space of possible sequence numbers, so that it 3222 cannot be guessed by an attacker and so that it and the successive 3223 sequence numbers do not repeat other sequences. 3225 Implmentation note: historically, some implementations transmit 3226 signed twos-complement numbers for sequence numbers. In the 3227 interests of compatibility, implementations may accept the 3228 equivalent negative number where a positive number greater than 2^31 3229 - 1 is expected. 3231 Implementation note: as noted before, some implementations omit the 3232 optional sequence number when its value would be zero. 3233 Implementations may accept an omitted sequence number when expecting 3234 a value of zero, and should not transmit an Authenticator with a 3235 sequence number of zero. 3237 authorization-data 3238 This field is the same as described for the ticket in section 5.3.1. 3239 It is optional and will only appear when additional restrictions are 3240 to be placed on the use of a ticket, beyond those carried in the 3241 ticket itself. 3243 5.5.2. KRB_AP_REP definition 3245 The KRB_AP_REP message contains the Kerberos protocol version number, 3246 the message type, and an encrypted time- stamp. The message is sent in 3247 response to an application request (KRB_AP_REQ) where the mutual 3248 authentication option has been selected in the ap-options field. 3250 AP-REP ::= [APPLICATION 15] SEQUENCE { 3251 pvno [0] INTEGER (5), 3252 msg-type [1] INTEGER (15), 3253 enc-part [2] EncryptedData -- EncAPRepPart 3254 } 3256 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 3257 ctime [0] KerberosTime, 3258 cusec [1] Microseconds, 3259 subkey [2] EncryptionKey OPTIONAL, 3260 seq-number [3] UInt32 OPTIONAL 3261 } 3263 The encoded EncAPRepPart is encrypted in the shared session key of the 3264 ticket. The optional subkey field can be used in an application-arranged 3265 negotiation to choose a per association session key. 3267 pvno and msg-type 3268 These fields are described above in section 5.4.1. msg-type is 3269 KRB_AP_REP. 3270 enc-part 3271 This field is described above in section 5.4.2. 3272 ctime 3273 This field contains the current time on the client's host. 3274 cusec 3275 This field contains the microsecond part of the client's 3276 timestamp. 3277 subkey 3278 This field contains an encryption key which is to be used to protect 3279 this specific application session. See section 3.2.6 for specifics 3280 on how this field is used to negotiate a key. Unless an application 3281 specifies otherwise, if this field is left out, the sub-session key 3282 from the authenticator, or if also left out, the session key from 3283 the ticket will be used. 3284 seq-number 3285 This field is described above in section 5.3.2. 3287 5.5.3. Error message reply 3289 If an error occurs while processing the application request, the 3290 KRB_ERROR message will be sent in response. See section 5.9.1 for the 3291 format of the error message. The cname and crealm fields may be left out 3292 if the server cannot determine their appropriate values from the 3293 corresponding KRB_AP_REQ message. If the authenticator was decipherable, 3294 the ctime and cusec fields will contain the values from it. 3296 5.6. KRB_SAFE message specification 3298 This section specifies the format of a message that can be used by 3299 either side (client or server) of an application to send a tamper-proof 3300 message to its peer. It presumes that a session key has previously been 3301 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3303 There are two KRB_SAFE messages; the KRB-SAFE message is the one 3304 specified in RFC 1510. The KRB-SAFE2 message is new with this document, 3305 and shares a number of fields with the old KRB-SAFE message. 3307 5.6.1. KRB_SAFE definition 3309 The KRB_SAFE message contains user data along with a collision-proof 3310 checksum keyed with the last encryption key negotiated via subkeys, or 3311 the session key if no negotiation has occurred. The message fields are: 3313 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3314 pvno [0] INTEGER (5), 3315 msg-type [1] INTEGER (20), 3316 safe-body [2] KRB-SAFE-BODY, 3317 cksum [3] Checksum 3318 } 3320 KRB-SAFE-BODY ::= SEQUENCE { 3321 user-data [0] OCTET STRING, 3322 timestamp [1] KerberosTime OPTIONAL, 3323 usec [2] Microseconds OPTIONAL, 3324 seq-number [3] UInt32 OPTIONAL, 3325 s-address [4] HostAddress, 3326 r-address [5] HostAddress OPTIONAL 3327 } 3329 pvno and msg-type 3330 These fields are described above in section 5.4.1. msg-type is 3331 KRB_SAFE or KRB_SAFE2, respectively, for the KRB-SAFE and KRB-SAFE2 3332 messages. 3333 safe-body 3334 This field is a placeholder for the body of the KRB-SAFE message. 3335 cksum 3336 This field contains the checksum of the application data. Checksum 3337 details are described in section 6.4. 3339 The checksum is computed over the encoding of the KRB-SAFE sequence. 3340 First, the cksum is set to a type zero, zero-length value and the 3341 checksum is computed over the encoding of the KRB-SAFE sequence, 3342 then the checksum is set to the result of that computation, and 3343 finally the KRB-SAFE sequence is encoded again. This method, while 3344 different than the one specified in RFC 1510, corresponds to 3345 existing practice. 3347 user-data 3348 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 3349 the application specific data that is being passed from the sender 3350 to the recipient. 3351 timestamp 3352 This field is part of the KRB_SAFE and KRB_PRIV messages. Its 3353 contents are the current time as known by the sender of the message. 3354 By checking the timestamp, the recipient of the message is able to 3355 make sure that it was recently generated, and is not a replay. 3356 usec 3357 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 3358 the microsecond part of the timestamp. 3359 seq-number 3360 This field is described above in section 5.3.2. 3361 s-address 3362 Sender's address. 3364 This field specifies the address in use by the sender of the 3365 message. It may be omitted if not required by the application protocol. 3367 r-address 3368 This field specifies the address in use by the recipient of the 3369 message. It may be omitted for some uses (such as broadcast 3370 protocols), but the recipient may arbitrarily reject such messages. 3371 This field, along with s-address, can be used to help detect 3372 messages which have been incorrectly or maliciously delivered to the 3373 wrong recipient. 3375 5.7. KRB_PRIV message specification 3377 This section specifies the format of a message that can be used by 3378 either side (client or server) of an application to securely and 3379 privately send a message to its peer. It presumes that a session key has 3380 previously been exchanged (for example, by using the 3381 KRB_AP_REQ/KRB_AP_REP messages). 3383 5.7.1. KRB_PRIV definition 3385 The KRB_PRIV message contains user data encrypted in the Session Key. 3386 The message fields are: 3388 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3389 pvno [0] INTEGER (5), 3390 msg-type [1] INTEGER (21), 3391 -- there is no [2] tag 3392 enc-part [3] EncryptedData -- EncKrbPrivPart 3393 } 3395 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 3396 user-data [0] OCTET STRING, 3397 timestamp [1] KerberosTime OPTIONAL, 3398 usec [2] Microseconds OPTIONAL, 3399 seq-number [3] UInt32 OPTIONAL, 3400 s-address [4] HostAddress -- sender's addr --, 3401 r-address [5] HostAddress OPTIONAL -- recip's addr 3402 } 3404 pvno and msg-type 3405 These fields are described above in section 5.4.1. msg-type is 3406 KRB_PRIV. 3407 enc-part 3408 This field holds an encoding of the EncKrbPrivPart sequence 3409 encrypted under the session key[32]. This encrypted encoding is used 3410 for the enc-part field of the KRB-PRIV message. See section 6 for 3411 the format of the ciphertext. 3412 user-data, timestamp, usec, s-address and r-address 3413 These fields are described above in section 5.6.1. seq-number 3414 This field is described above in section 5.3.2. 3416 5.8. KRB_CRED message specification 3418 This section specifies the format of a message that can be used to send 3419 Kerberos credentials from one principal to another. It is presented here 3420 to encourage a common mechanism to be used by applications when 3421 forwarding tickets or providing proxies to subordinate servers. It 3422 presumes that a session key has already been exchanged perhaps by using 3423 the KRB_AP_REQ/KRB_AP_REP messages. 3425 5.8.1. KRB_CRED definition 3427 The KRB_CRED message contains a sequence of tickets to be sent and 3428 information needed to use the tickets, including the session key from 3429 each. The information needed to use the tickets is encrypted under an 3430 encryption key previously exchanged or transferred alongside the 3431 KRB_CRED message. The message fields are: 3433 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3434 pvno [0] INTEGER (5), 3435 msg-type [1] INTEGER (22), 3436 tickets [2] SEQUENCE OF Ticket, 3437 enc-part [3] EncryptedData -- EncKrbCredPart 3438 } 3440 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3441 ticket-info [0] SEQUENCE OF KrbCredInfo, 3442 nonce [1] UInt32 OPTIONAL, 3443 timestamp [2] KerberosTime OPTIONAL, 3444 usec [3] Microseconds OPTIONAL, 3445 s-address [4] HostAddress OPTIONAL, 3446 r-address [5] HostAddress OPTIONAL 3447 } 3449 KrbCredInfo ::= SEQUENCE { 3450 key [0] EncryptionKey, 3451 prealm [1] Realm OPTIONAL, 3452 pname [2] PrincipalName OPTIONAL, 3453 flags [3] TicketFlags OPTIONAL, 3454 authtime [4] KerberosTime OPTIONAL, 3455 starttime [5] KerberosTime OPTIONAL, 3456 endtime [6] KerberosTime OPTIONAL, 3457 renew-till [7] KerberosTime OPTIONAL, 3458 srealm [8] Realm OPTIONAL, 3459 sname [9] PrincipalName OPTIONAL, 3460 caddr [10] HostAddresses OPTIONAL 3461 } 3463 pvno and msg-type 3464 These fields are described above in section 5.4.1. msg-type is 3465 KRB_CRED. 3466 tickets 3467 These are the tickets obtained from the KDC specifically for use by 3468 the intended recipient. Successive tickets are paired with the 3469 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3470 message. 3471 enc-part 3472 This field holds an encoding of the EncKrbCredPart sequence 3473 encrypted under the session key shared between the sender and the 3474 intended recipient. This encrypted encoding is used for the enc-part 3475 field of the KRB-CRED message. See section 6 for the format of the 3476 ciphertext. 3478 Implementation note: implementations of certain applications, most 3479 notably of the Kerberos GSS-API mechanism, do not encrypt the 3480 KRB-CRED message when sending it. In the case of the GSS-API 3481 mechanism, this is not a security vulnerability, as the KRB-CRED 3482 message itself is itself encrypted inside an Authenticator. 3484 nonce 3485 If practical, an application may require the inclusion of a nonce 3486 generated by the recipient of the message. If the same value is 3487 included as the nonce in the message, it provides evidence that the 3488 message is fresh and has not been replayed by an attacker. A nonce 3489 must never be re-used; it should be generated randomly by the 3490 recipient of the message and provided to the sender of the message 3491 in an application specific manner. 3492 timestamp and usec 3493 These fields specify the time that the KRB-CRED message was 3494 generated. The time is used to provide assurance that the message is 3495 fresh. 3496 s-address and r-address 3497 These fields are described above in section 5.6.1. They are used 3498 optionally to provide additional assurance of the integrity of the 3499 KRB-CRED message. 3500 key 3501 This field exists in the corresponding ticket passed by the KRB-CRED 3502 message and is used to pass the session key from the sender to the 3503 intended recipient. The field's encoding is described in section 6.2. 3505 The following fields are optional. If present, they can be associated 3506 with the credentials in the remote ticket file. If left out, then it is 3507 assumed that the recipient of the credentials already knows their value. 3509 prealm and pname 3510 The name and realm of the delegated principal identity. 3511 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3512 These fields contain the values of the corresponding fields from the 3513 ticket found in the ticket field. Descriptions of the fields are 3514 identical to the descriptions in the KDC-REP message. 3516 5.9. Error message specification 3518 This section specifies the format for the KRB_ERROR message. The fields 3519 included in the message are intended to return as much information as 3520 possible about an error. It is not expected that all the information 3521 required by the fields will be available for all types of errors. If the 3522 appropriate information is not available when the message is composed, 3523 the corresponding field will be left out of the message. 3525 Note that since the KRB_ERROR message is not integrity protected, it is 3526 quite possible for an intruder to synthesize or modify such a message. 3527 In particular, this means that the client should not use any fields in 3528 this message for security-critical purposes, such as setting a system 3529 clock or generating a fresh authenticator. The message can be useful, 3530 however, for advising a user on the reason for some failure. 3532 5.9.1. KRB_ERROR definition 3534 The KRB_ERROR message consists of the following fields: 3536 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3537 pvno [0] INTEGER (5), 3538 msg-type [1] INTEGER (30), 3539 ctime [2] KerberosTime OPTIONAL, 3540 cusec [3] Microseconds OPTIONAL, 3541 stime [4] KerberosTime, 3542 susec [5] Microseconds, 3543 error-code [6] Int32, 3544 crealm [7] Realm OPTIONAL, 3545 cname [8] PrincipalName OPTIONAL, 3546 realm [9] Realm -- Correct realm --, 3547 sname [10] PrincipalName -- Correct name --, 3548 e-text [11] KerberosString OPTIONAL, 3549 e-data [12] OCTET STRING OPTIONAL 3550 } 3552 pvno and msg-type 3553 These fields are described above in section 5.4.1. msg-type is 3554 KRB_ERROR. 3555 ctime 3556 This field is described above in section 5.4.1. 3557 cusec 3558 This field is described above in section 5.5.2. 3559 stime 3560 This field contains the current time on the server. It is of type 3561 KerberosTime. 3562 susec 3563 This field contains the microsecond part of the server's timestamp. 3564 Its value ranges from 0 to 999999. It appears along with stime. The 3565 two fields are used in conjunction to specify a reasonably accurate 3566 timestamp. 3567 error-code 3568 This field contains the error code returned by Kerberos or the 3569 server when a request fails. To interpret the value of this field 3570 see the list of error codes in section 8. Implementations are 3571 encouraged to provide for national language support in the display 3572 of error messages. 3573 crealm, cname, srealm and sname 3574 These fields are described above in section 5.3.1. e-text 3575 This field contains additional text to help explain the error code 3576 associated with the failed request (for example, it might include a 3577 principal name which was unknown). 3578 e-data 3579 This field contains additional data about the error for use by the 3580 application to help it recover from or handle the error. If the 3581 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 3582 contain an encoding of a sequence of padata fields, each 3583 corresponding to an acceptable pre- authentication method and 3584 optionally containing data for the method: 3586 METHOD-DATA ::= SEQUENCE OF PA-DATA 3587 5.10. Application Tag Numbers 3589 The following table lists the application class tag numbers used by 3590 various data types defined in this section. 3591 Tag Number(s) Type Name Comments 3592 0 unused 3593 1 Ticket 3594 2 Authenticator 3595 3 EncTicketPart 3596 4-10 unused 3597 10 AS-REQ 3598 11 AS-REP 3599 12 TGS-REQ 3600 13 TGS-REP 3601 14 AP-REQ 3602 15 AP-REP 3603 16 TGT-REQ 3604 17-19 unused 3605 20 KRB-SAFE 3606 21 KRB-PRIV 3607 22 KRB-PRIV 3608 23-24 unused 3609 25 EncASRepPart 3610 26 EncTGSRepPart 3611 27 EncApRepPart 3612 28 EncKrbPrivPart 3613 29 EncKrbCredPart 3614 30 KRB-ERROR 3615 6. Encryption and Checksum Specifications 3617 The Kerberos protocols described in this document are designed to 3618 encrypt blocks of arbitrary sizes, using stream or block encryption 3619 ciphers. Encryption is used to prove the identities of the network 3620 entities participating in message exchanges. The Key Distribution Center 3621 for each realm is trusted by all principals registered in that realm to 3622 store a secret key in confidence. Proof of knowledge of this secret key 3623 is used to verify the authenticity of a principal. 3625 The KDC uses the principal's secret key (in the AS exchange) or a shared 3626 session key (in the TGS exchange) to encrypt responses to ticket 3627 requests; the ability to obtain the secret key or session key implies 3628 the knowledge of the appropriate keys and the identity of the KDC. The 3629 ability of a principal to decrypt the KDC response and present a Ticket 3630 and a properly formed Authenticator (generated with the session key from 3631 the KDC response) to a service verifies the identity of the principal; 3632 likewise the ability of the service to extract the session key from the 3633 Ticket and prove its knowledge thereof in a response verifies the 3634 identity of the service. 3636 [KCRYPTO] defines a framework for defining encryption and checksum 3637 mechanisms for use with Kerberos. It also defines several such 3638 mechanisms, and more may be added in future updates to that document. 3640 The string-to-key operation provided by [KCRYPTO] is used to produce a 3641 long-term key for a principal (generally for a user). The default salt 3642 string, if none is provided via preauthentication data, is the 3643 concatenation of the principal's realm and name components, in order, 3644 with no separators. Unless otherwise indicated, the default 3645 string-to-key opaque parameter set as defined in [KCRYPTO] is used. 3647 The encryption, decryption, and checksum operations used in this 3648 document use the corresponding encryption, decryption, and get_mic 3649 operations described in [KCRYPTO], with implicit "specific key" 3650 generation using the key usage values outlined in section 6.1. Unless 3651 otherwise indicated, no chaining of cipher state is done from one 3652 encryption operation to another. 3654 The EncryptedData object's "etype" and "cipher" fields are the 3655 encryption mechanism type number and encryption operation output. The 3656 EncryptionKey object's "keytype" and "keyvalue" fields are the 3657 encryption mechanism type number and protocol key representation. The 3658 Checksum object's "cksumtype" and "checksum" fields are the checksum 3659 mechanism type number and get_mic operation output. 3661 6.1. Key Usage Values 3663 The encryption and checksum specifications in [KCRYPTO] require as input 3664 a "key usage number", to alter the encryption key used in any specific 3665 message, to make certain types of cryptographic attack more difficult. 3666 This is a list of key usage number definitions and reserved ranges, 3667 including values for all places keys are used in the Kerberos protocol 3668 and associated section numbers. 3670 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the client 3671 key (section 5.4.1) 3672 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key or 3673 application session key), encrypted with the service key (section 5.4.2) 3674 3. AS-REP encrypted part (includes TGS session key or application 3675 session key), encrypted with the client key (section 5.4.2) 3676 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS 3677 session key (section 5.4.1) 3678 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS 3679 authenticator subkey (section 5.4.1) 3680 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed with the 3681 TGS session key (sections 5.3.2, 5.4.1) 3682 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes TGS 3683 authenticator subkey), encrypted with the TGS session key (section 5.3.2) 3684 8. TGS-REP encrypted part (includes application session key), encrypted 3685 with the TGS session key (section 5.4.2) 3686 9. TGS-REP encrypted part (includes application session key), encrypted 3687 with the TGS authenticator subkey (section 5.4.2) 3688 10. AP-REQ Authenticator cksum, keyed with the application session key 3689 (section 5.3.2) 3690 11. AP-REQ Authenticator (includes application authenticator subkey), 3691 encrypted with the application session key (section 5.3.2) 3692 12. AP-REP encrypted part (includes application session subkey), 3693 encrypted with the application session key (section 5.5.2) 3694 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 3695 application (section 5.7.1) 3696 14. KRB-CRED encrypted part, encrypted with a key chosen by the 3697 application (section 5.6.1) 3698 15. KRB-SAFE cksum, keyed with a key chosen by the application (section 3699 5.8.1) 3700 18. KRB-ERROR checksum (e-cksum in section 5.9.1) 3701 19. AD-KDCIssued checksum (ad-checksum in appendix B.4) 3702 20. Checksum for Mandatory Ticket Extensions (appendix B.6) 3703 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) 3704 22-24. Reserved for use in GSSAPI mechanisms derived from RFC 1964. 3705 (raeburn/MIT) 3706 25-511. Reserved for future use in Kerberos and related protocols. 3707 512-1023. Reserved for uses internal to a Kerberos implementation. [6.1] 3709 A few of these key usages need a little clarification. A service which 3710 receives an AP-REQ has no way to know if the enclosed Ticket was part of 3711 an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for 3712 generating a Ticket, whether it is in response to an AS-REQ or TGS-REQ. 3714 Key usage values between 1024 and 2047 (inclusive) are reserved for 3715 application use. Applications should use even values for encryption and 3716 odd values for checksums within this range. 3718 There might exist other documents which define protocols in terms of the 3719 RFC1510 encryption types or checksum types. Such documents would not 3720 know about key usages. In order that these specifications continue to be 3721 meaningful until they are updated, key usages 1024 and 1025 must be used 3722 to derive keys for encryption and checksums, respectively.[6.2] New 3723 protocols defined in terms of the Kerberos encryption and checksum types 3724 should use their own key usage values. Key usages are unsigned 32 bit 3725 integers; zero is not permitted. Usage numbers may be registered with 3726 IANA to avoid conflicts. 3728 6.2. Implementation Notes 3730 While we don't recommend it, undoubtedly some application protocols will 3731 continue to use the key data directly, even if only in some of the 3732 currently existing protocol specifications. An implementation intended 3733 to support general Kerberos applications may therefore need to make the 3734 key data available, as well as the attributes and operations described 3735 in [KCRYPTO]. 3737 7. Naming Constraints 3739 7.1. Realm Names 3741 Although realm names are encoded as GeneralStrings and although a realm 3742 can technically select any name it chooses, interoperability across 3743 realm boundaries requires agreement on how realm names are to be 3744 assigned, and what information they imply. 3746 To enforce these conventions, each realm must conform to the conventions 3747 itself, and it must require that any realms with which inter-realm keys 3748 are shared also conform to the conventions and require the same from its 3749 neighbors. 3751 Kerberos realm names are case sensitive. Realm names that differ only in 3752 the case of the characters are not equivalent. There are presently four 3753 styles of realm names: domain, X500, other, and reserved. Examples of 3754 each style follow: 3756 domain: ATHENA.MIT.EDU (example) 3757 X500: C=US/O=OSF (example) 3758 other: NAMETYPE:rest/of.name=without-restrictions (example) 3759 reserved: reserved, but will not conflict with above 3761 Domain syle realm names must look like domain names: they consist of 3762 components separated by periods (.) and they contain neither colons (:) 3763 nor slashes (/). Though domain names themselves are case insensitive, in 3764 order for realms to match, the case must match as well. When 3765 establishing a new realm name based on an internet domain name it is 3766 recommended by convention that the characters be converted to upper case. 3768 X.500 names contain an equal (=) and cannot contain a colon (:) before 3769 the equal. The realm names for X.500 names will be string 3770 representations of the names with components separated by slashes. 3771 Leading and trailing slashes will not be included. Note that the slash 3772 separator is consistent with Kerberos implementations based on RFC1510, 3773 but it is different from the separator recommended in RFC2253. 3775 Names that fall into the other category must begin with a prefix that 3776 contains no equal (=) or period (.) and the prefix must be followed by a 3777 colon (:) and the rest of the name. All prefixes must be assigned before 3778 they may be used. Presently none are assigned. 3780 The reserved category includes strings which do not fall into the first 3781 three categories. All names in this category are reserved. It is 3782 unlikely that names will be assigned to this category unless there is a 3783 very strong argument for not using the 'other' category. 3785 These rules guarantee that there will be no conflicts between the 3786 various name styles. The following additional constraints apply to the 3787 assignment of realm names in the domain and X.500 categories: the name 3788 of a realm for the domain or X.500 formats must either be used by the 3789 organization owning (to whom it was assigned) an Internet domain name or 3790 X.500 name, or in the case that no such names are registered, authority 3791 to use a realm name may be derived from the authority of the parent 3792 realm. For example, if there is no domain name for E40.MIT.EDU, then the 3793 administrator of the MIT.EDU realm can authorize the creation of a realm 3794 with that name. 3796 This is acceptable because the organization to which the parent is 3797 assigned is presumably the organization authorized to assign names to 3798 its children in the X.500 and domain name systems as well. If the parent 3799 assigns a realm name without also registering it in the domain name or 3800 X.500 hierarchy, it is the parent's responsibility to make sure that 3801 there will not in the future exist a name identical to the realm name of 3802 the child unless it is assigned to the same entity as the realm name. 3804 7.2. Principal Names 3806 As was the case for realm names, conventions are needed to ensure that 3807 all agree on what information is implied by a principal name. The 3808 name-type field that is part of the principal name indicates the kind of 3809 information implied by the name. The name-type should be treated only as 3810 a hint to interpreting the meaning of a name. It is not significant when 3811 checking for equivalence. Principal names that differ only in the 3812 name-type identify the same principal. The name type does not partition 3813 the name space. Ignoring the name type, no two names can be the same 3814 (i.e. at least one of the components, or the realm, must be different). 3815 The following name types are defined: 3817 name-type value meaning 3819 NT-UNKNOWN 0 Name type not known 3820 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) 3821 NT-SRV-INST 2 Service and other unique instance (krbtgt) 3822 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 3823 NT-SRV-XHST 4 Service with slash-separated host name components 3824 NT-UID 5 Unique ID 3825 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 3826 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 3827 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 3829 When a name implies no information other than its uniqueness at a 3830 particular time the name type PRINCIPAL should be used. The principal 3831 name type should be used for users, and it might also be used for a 3832 unique server. If the name is a unique machine generated ID that is 3833 guaranteed never to be reassigned then the name type of UID should be 3834 used (note that it is generally a bad idea to reassign names of any type 3835 since stale entries might remain in access control lists). 3837 If the first component of a name identifies a service and the remaining 3838 components identify an instance of the service in a server specified 3839 manner, then the name type of SRV-INST should be used. An example of 3840 this name type is the Kerberos ticket-granting service whose name has a 3841 first component of krbtgt and a second component identifying the realm 3842 for which the ticket is valid. 3844 If instance is a single component following the service name and the 3845 instance identifies the host on which the server is running, then the 3846 name type SRV-HST should be used. This type is typically used for 3847 Internet services such as telnet and the Berkeley R commands. If the 3848 separate components of the host name appear as successive components 3849 following the name of the service, then the name type SRV-XHST should be 3850 used. This type might be used to identify servers on hosts with X.500 3851 names where the slash (/) might otherwise be ambiguous. 3853 A name type of NT-X500-PRINCIPAL should be used when a name from an 3854 X.509 certificate is translated into a Kerberos name. The encoding of 3855 the X.509 name as a Kerberos principal shall conform to the encoding 3856 rules specified in RFC 2253. 3858 A name type of SMTP allows a name to be of a form that resembles a SMTP 3859 email name. This name, including an "@" and a domain name, is used as 3860 the one component of the principal name. 3862 A name type of UNKNOWN should be used when the form of the name is not 3863 known. When comparing names, a name of type UNKNOWN will match 3864 principals authenticated with names of any type. A principal 3865 authenticated with a name of type UNKNOWN, however, will only match 3866 other names of type UNKNOWN. 3868 Names of any type with an initial component of 'krbtgt' are reserved for 3869 the Kerberos ticket granting service. See section 8.2.4 for the form of 3870 such names. 3872 7.2.1. Name of server principals 3874 The principal identifier for a server on a host will generally be 3875 composed of two parts: (1) the realm of the KDC with which the server is 3876 registered, and (2) a two-component name of type NT-SRV-HST if the host 3877 name is an Internet domain name or a multi-component name of type 3878 NT-SRV-XHST if the name of the host is of a form such as X.500 that 3879 allows slash (/) separators. The first component of the two- or 3880 multi-component name will identify the service and the latter components 3881 will identify the host. Where the name of the host is not case sensitive 3882 (for example, with Internet domain names) the name of the host must be 3883 lower case. If specified by the application protocol for services such 3884 as telnet and the Berkeley R commands which run with system privileges, 3885 the first component may be the string 'host' instead of a service 3886 specific identifier. When a host has an official name and one or more 3887 aliases and the official name can be reliably determined, the official 3888 name of the host should be used when constructing the name of the server 3889 principal. 3891 8. Constants and other defined values 3893 8.1. Host address types 3895 All negative values for the host address type are reserved for local 3896 use. All non-negative values are reserved for officially assigned type 3897 fields and interpretations. 3899 The values of the types for the following addresses are chosen to match 3900 the defined address family constants in the Berkeley Standard 3901 Distributions of Unix. They can be found in with symbolic names AF_xxx 3902 (where xxx is an abbreviation of the address family name). 3904 Internet (IPv4) Addresses 3906 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in 3907 MSB order. The IPv4 loopback address should not appear in a Kerberos 3908 packet. The type of IPv4 addresses is two (2). 3910 Internet (IPv6) Addresses [Westerlund] 3912 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. 3913 The type of IPv6 addresses is twenty-four (24). [RFC2373]. The following 3914 addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 3916 * the Unspecified Address 3917 * the Loopback Address 3918 * Link-Local addresses 3920 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 3922 DECnet Phase IV addresses 3924 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. 3925 The type of DECnet Phase IV addresses is twelve (12). 3927 Netbios addresses 3929 Netbios addresses are 16-octet addresses typically composed of 1 to 15 3930 characters, trailing blank (ascii char 20) filled, with a 16th octet of 3931 0x0. The type of Netbios addresses is 20 (0x14). 3933 Directional Addresses 3935 In many environments, including the sender address in KRB_SAFE and 3936 KRB_PRIV messages is undesirable because the addresses may be changed in 3937 transport by network address translators. However, if these addresses 3938 are removed, the messages may be subject to a reflection attack in which 3939 a message is reflected back to its originator. The directional address 3940 type provides a way to avoid transport addresses and reflection attacks. 3941 Directional addresses are encoded as four byte unsigned integers in 3942 network byte order. If the message is originated by the party sending 3943 the original KRB_AP_REQ message, then an address of 0 should be used. If 3944 the message is originated by the party to whom that KRB_AP_REQ was sent, 3945 then the address 1 should be used. Applications involving multiple 3946 parties can specify the use of other addresses. 3948 Directional addresses MUST only be used for the sender address field in 3949 the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used as a ticket 3950 address or in a KRB_AP_REQ message. This address type SHOULD only be 3951 used in situations where the sending party knows that the receiving 3952 party supports the address type. This generally means that directional 3953 addresses may only be used when the application protocol requires their 3954 support. Directional addresses are type XX (0xXX). 3956 8.2. KDC messaging 3958 8.2.1 IP Transports 3960 Kerberos defines two IP transport mechanisms for communication between 3961 clients and servers: UDP/IP and TCP/IP. 3963 8.2.1.1. UDP/IP transport 3965 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 3966 requests and SHOULD listen for such requests on port 88 (decimal) unless 3967 specifically configured to listen on an alternative UDP port. Alternate 3968 ports MAY be used when running multiple KDCs for multiple realms on the 3969 same host. 3971 Kerberos clients supporting IP transports SHOULD (XXX or is this a 3972 MUST?) the sending of UDP requests. Clients SHOULD use KDC discovery 3973 [8.2.1.3] to identify the IP address and port to which they will send 3974 their request. 3976 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP transport, 3977 the client shall send a UDP datagram containing only an encoding of the 3978 request to the KDC. The KDC will respond with a reply datagram 3979 containing only an encoding of the reply message (either a KRB_ERROR or 3980 8a KRB_KDC_REP) to the sending port at the sender's IP address. The 3981 response to a request made through UDP/IP transport must also use UDP/IP 3982 transport. If the response can not be handled using UDP (for example 3983 because it is too large), the KDC must return an error forcing the 3984 client to retry the request using the TCP transport. 3986 8.2.1.2. TCP/IP transport [Westerlund,Danielsson] 3988 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 3989 requests and SHOULD listen for such requests on port 88 (decimal) unless 3990 specifically configured to listen on an alternate TCP port. Alternate 3991 ports MAY be used when running multiple KDCs for multiple realms on the 3992 same host. 3994 Clients must support the sending of TCP requests, but may choose to 3995 intially try a request using the UDP transport. Clients SHOULD use KDC 3996 discovery [8.2.1.3] to identify the IP address and port to which they 3997 will send their request. 3999 Implementation note: Some extensions to the Kerberos protocol will not 4000 succeed if any client or KDC not supporting the TCP transport is 4001 involved. Implementations of RFC 1510 were not required to support 4002 TCP/IP transports. 4004 [XXX as discussed we believe that the consensus was to allow multiple 4005 requests over a single TCP connection between a client and KDC.] 4007 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, the 4008 response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to the 4009 client on the same TCP stream that was established for the request. The 4010 KDC may close the TCP stream after sending a response, but may leave the 4011 stream open for a reasonable period of time if it expects a followup. 4012 Care must be taken in managing TCP/IP connections on the KDC to prevent 4013 denial of service attacks based on the number of open TCP/IP connections. 4015 The client must be prepared to have the stream closed by the KDC at 4016 anytime after the receipt of a response. A stream closure should not be 4017 treated as a fatal error. Instead, if multiple exchanges are required 4018 (e.g., certain forms of preauthentication) the client should establish a 4019 new connection when it is ready to send subsequent messages. A client 4020 may close the stream after receiving a response, and should close the 4021 stream if it does not expect to send followup messages. 4023 The first four octets of the TCP stream used to transmit the request 4024 request will encode in network byte order the length of the request 4025 (KRB_KDC_REQ), and the length will be followed by the request itself. 4026 The response will similarly be preceded by a 4 octet encoding in network 4027 byte order of the length of the KRB_KDC_REP or the KRB_ERROR message and 4028 will be followed by the KRB_KDC_REP or the KRB_ERROR response. If the 4029 sign bit is set on the integer represented by the first 4 octets, then 4030 the next 4 octets will be read, extending the length of the field by 4031 another 4 octets (less the sign bit of the additional four octets which 4032 is reserved for future expansion and which at present must be zero). 4034 8.2.1.3 KDC Discovery on IP Networks 4036 Kerberos client implementations must provide a means for the client to 4037 determine the location of the Kerberos Key Distribution Centers (KDCs). 4038 Traditionally, Kerberos implementations have stored such configuration 4039 information in a file on each client machine. Experience has shown this 4040 method of storing configuration information presents problems with 4041 out-of-date information and scaling problems, especially when using 4042 cross-realm authentication. This section describes a method for using 4043 the Domain Name System [RFC 1035] for storing KDC location information. 4045 8.2.1.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 4047 In Kerberos, realm names are case sensitive. While it is strongly 4048 encouraged that all realm names be all upper case this recommendation 4049 has not been adopted by all sites. Some sites use all lower case names 4050 and other use mixed case. DNS on the other hand is case insensitive for 4051 queries. Since "MYREALM", "myrealm", and "MyRealm" are all different it 4052 is necessary that only one of the possible combinations of upper and 4053 lower case characters be used. This restriction may be lifted in the 4054 future as the DNS naming scheme is expanded to support non-ASCII names. 4056 8.2.1.3.2. Specifying KDC Location information with DNS SRV 4057 records 4059 KDC location information is to be stored using the DNS SRV RR [RFC 4060 2052]. The format of this RR is as follows: 4062 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 4064 The Service name for Kerberos is always "_kerberos". 4066 The Proto can be one of "_udp", "_tcp". If these SRV records are to be 4067 used, both "_udp" and "_tcp" records MUST be specified for all KDC 4068 deployments. 4070 The Realm is the Kerberos realm that this record corresponds to. 4072 TTL, Class, SRV, Priority, Weight, and Target have the standard meaning 4073 as defined in RFC 2052. 4075 As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV records 4076 SHOULD be the value assigned to "kerberos" by the Internet Assigned 4077 Number Authority: 88 (decimal) unless the KDC is configured to listen on 4078 an alternate TCP port. 4080 Implementation note: Many existing client implementations do not support 4081 KDC Discovery and are configured to send requests to the IANA assigned 4082 port (88 decimal), so it is strongly recommended that KDCs be configured 4083 to listen on that port. 4085 8.2.1.3.3. Example DNS SRV records specifying KDC location 4086 information 4088 These are DNS records for a Kerberos realm ASDF.COM. It has two Ker 4089 beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be 4090 directed to kdc1.asdf.com first as per the specified priority. Weights 4091 are not used in these records. 4093 _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 4094 _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 4095 _kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 4096 _kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 4098 8.2.2. OSI transport 4100 During authentication of an OSI client to an OSI server, the mutual 4101 authentication of an OSI server to an OSI client, the transfer of 4102 credentials from an OSI client to an OSI server, or during exchange of 4103 private or integrity checked messages, Kerberos protocol messages may be 4104 treated as opaque objects and the type of the authentication mechanism 4105 will be: 4107 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} 4109 Depending on the situation, the opaque object will be an authentication 4110 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe 4111 message (KRB_SAFE), a private message (KRB_PRIV), or a credentials 4112 message (KRB_CRED). The opaque data contains an application code as 4113 specified in the ASN.1 description for each message. The application 4114 code may be used by Kerberos to determine the message type. 4116 8.3. Name of the TGS 4118 The principal identifier of the ticket-granting service shall be 4119 composed of three parts: (1) the realm of the KDC issuing the TGS ticket 4120 (2) a two-part name of type NT-SRV-INST, with the first part "krbtgt" 4121 and the second part the name of the realm which will accept the 4122 ticket-granting ticket. For example, a ticket-granting ticket issued by 4123 the ATHENA.MIT.EDU realm to be used to get tickets from the 4124 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" 4125 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket 4126 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the 4127 MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), 4128 ("krbtgt", "MIT.EDU") (name). 4130 8.4. Protocol constants and associated values 4132 The following tables list constants used in the protocol and define 4133 their meanings. Ranges are specified in the "specification" section that 4134 limit the values of constants for which values are defined here. This 4135 allows implementations to make assumptions about the maximum values that 4136 will be received for these constants. Implementation receiving values 4137 outside the range specified in the "specification" section may reject 4138 the request, but they must recover cleanly. 4140 padata and data types padata-type value comment 4142 PA-TGS-REQ 1 4143 PA-ENC-TIMESTAMP 2 4144 PA-PW-SALT 3 4145 [reserved] 4 4146 PA-ENC-UNIX-TIME 5 (depricated) 4147 PA-SANDIA-SECUREID 6 4148 PA-SESAME 7 4149 PA-OSF-DCE 8 4150 PA-CYBERSAFE-SECUREID 9 4151 PA-AFS3-SALT 10 4152 PA-ETYPE-INFO 11 4153 PA-SAM-CHALLENGE 12 (sam/otp) 4154 PA-SAM-RESPONSE 13 (sam/otp) 4155 PA-PK-AS-REQ 14 (pkinit) 4156 PA-PK-AS-REP 15 (pkinit) 4157 PA-USE-SPECIFIED-KVNO 20 4158 PA-SAM-REDIRECT 21 (sam/otp) 4159 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 4160 TD-PADATA 22 (embeds padata) 4161 PA-SAM-ETYPE-INFO 23 (sam/otp) 4162 PA-ALT-PRINC 24 (crawdad@fnal.gov) 4163 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 4164 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 4165 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 4166 TD-KRB-PRINCIPAL 102 PrincipalName (see Sec.5.9.1) 4167 TD-KRB-REALM 103 Realm (see Sec.5.9.1) 4168 TD-TRUSTED-CERTIFIERS 104 from PKINIT 4169 TD-CERTIFICATE-INDEX 105 from PKINIT 4170 TD-APP-DEFINED-ERROR 106 application specific (see Sec.5.9.1) 4171 TD-REQ-NONCE 107 INTEGER (see Sec.5.9.1) 4172 TD-REQ-SEQ 108 INTEGER (see Sec.5.9.1) 4173 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 4174 Address type value 4176 IPV4 2 4177 ChaosNet 5 4178 XNS 6 4179 ISO 7 4180 DECNET Phase IV 12 4181 AppleTalk DDP 16 4182 NetBios 20 4183 IPV6 24 4185 authorization data type ad-type value 4186 AD-IF-RELEVANT 1 4187 AD-INTENDED-FOR-SERVER 2 4188 AD-INTENDED-FOR-APPLICATION-CLASS 3 4189 AD-KDC-ISSUED 4 4190 AD-OR 5 4191 AD-MANDATORY-TICKET-EXTENSIONS 6 4192 AD-IN-TICKET-EXTENSIONS 7 4193 AD-MANDATORY-FOR-KDC 8 4194 reserved values 9-63 4195 OSF-DCE 64 4196 SESAME 65 4197 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 4198 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 4200 Ticket Extension Types 4202 TE-TYPE-NULL 0 Null ticket extension 4203 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 4204 [reserved] 2 TE-TYPE-PKCROSS-KDC (I have reservations) 4205 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 4206 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 4207 [reserved] 5 TE-TYPE-DEST-HOST (I have reservations) 4209 transited encoding type tr-type value 4210 DOMAIN-X500-COMPRESS 1 4211 reserved values all others 4213 Label Value Meaning or MIT code 4215 pvno 5 current Kerberos protocol version number 4217 message types (Will be updated to match section 5) 4219 KRB_AS_REQ 10 Request for initial authentication 4220 KRB_AS_REP 11 Response to KRB_AS_REQ request 4221 KRB_TGS_REQ 12 Request for authentication based on TGT 4222 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4223 KRB_AP_REQ 14 application request to server 4224 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4225 KRB_SAFE 20 Safe (checksummed) application message 4226 KRB_PRIV 21 Private (encrypted) application message 4227 KRB_CRED 22 Private (encrypted) message to forward credentials 4228 KRB_ERROR 30 Error response 4229 name types 4231 KRB_NT_UNKNOWN 0 Name type not known 4232 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4233 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4234 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 4235 KRB_NT_SRV_XHST 4 Service with host as remaining components 4236 KRB_NT_UID 5 Unique ID 4237 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4239 error codes 4241 KDC_ERR_NONE 0 No error 4242 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4243 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4244 KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported 4245 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 4246 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 4247 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4248 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4249 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 4250 KDC_ERR_NULL_KEY 9 The client or server has a null key 4251 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4252 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 4253 KDC_ERR_POLICY 12 KDC policy rejects request 4254 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4255 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4256 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4257 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4258 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4259 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4260 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4261 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4262 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4263 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4264 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset 4265 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 4266 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 4267 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 4268 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 4269 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 4270 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 4271 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 4272 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4273 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4274 KRB_AP_ERR_REPEAT 34 Request is a replay 4275 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4276 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4277 KRB_AP_ERR_SKEW 37 Clock skew too great 4278 KRB_AP_ERR_BADADDR 38 Incorrect net address 4279 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4280 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4281 KRB_AP_ERR_MODIFIED 41 Message stream modified 4282 KRB_AP_ERR_BADORDER 42 Message out of order 4283 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 4284 KRB_AP_ERR_NOKEY 45 Service key not available 4285 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4286 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4287 KRB_AP_ERR_METHOD 48 Alternative authentication method required 4288 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4289 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 4290 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 4291 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 4292 KRB_ERR_GENERIC 60 Generic error (description in e-text) 4293 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 4294 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 4295 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 4296 KDC_ERROR_INVALID_SIG 64 (pkinit) 4297 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 4298 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 4299 KRB_AP_ERR_NO_TGT 67 (user-to-user) 4300 KDC_ERR_WRONG_REALM 68 (user-to-user) 4301 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 4302 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 4303 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 4304 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 4305 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 4306 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 4307 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 4308 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 4309 9. Interoperability requirements 4311 Version 5 of the Kerberos protocol supports a myriad of options. Among 4312 these are multiple encryption and checksum types, alternative encoding 4313 schemes for the transited field, optional mechanisms for 4314 pre-authentication, the handling of tickets with no addresses, options 4315 for mutual authentication, user to user authentication, support for 4316 proxies, forwarding, postdating, and renewing tickets, the format of 4317 realm names, and the handling of authorization data. 4319 In order to ensure the interoperability of realms, it is necessary to 4320 define a minimal configuration which must be supported by all 4321 implementations. This minimal configuration is subject to change as 4322 technology does. For example, if at some later date it is discovered 4323 that one of the required encryption or checksum algorithms is not 4324 secure, it will be replaced. 4326 9.1. Specification 2 4328 This section defines the second specification of these options. 4329 Implementations which are configured in this way can be said to support 4330 Kerberos Version 5 Specification 2 (5.1). Specification 1 (deprecated) 4331 may be found in RFC1510. 4333 Transport 4335 TCP/IP and UDP/IP transport must be supported by clients and KDCs 4336 claiming conformance to specification 2. 4338 Encryption and checksum methods 4340 The following encryption and checksum mechanisms must be supported. 4341 Implementations may support other mechanisms as well, but the additional 4342 mechanisms may only be used when communicating with principals known to 4343 also support them: This list is to be determined and should correspond 4344 to section 6. 4346 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD, RIJNDAEL(decide identifier) 4347 Checksums: CRC-32, DES-MAC, DES-MAC-K, DES-MD5, HMAC-SHA1-DES3-KD 4349 Realm Names 4351 All implementations must understand hierarchical realms in both the 4352 Internet Domain and the X.500 style. When a ticket granting ticket for 4353 an unknown realm is requested, the KDC must be able to determine the 4354 names of the intermediate realms between the KDCs realm and the 4355 requested realm. 4357 Transited field encoding 4359 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 4360 Alternative encodings may be supported, but they may be used only when 4361 that encoding is supported by ALL intermediate realms. 4363 Pre-authentication methods 4365 The TGS-REQ method must be supported. The TGS-REQ method is not used on 4366 the initial request. The PA-ENC-TIMESTAMP method must be supported by 4367 clients but whether it is enabled by default may be determined on a 4368 realm by realm basis. If not used in the initial request and the error 4369 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 4370 acceptable method, the client should retry the initial request using the 4371 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 4372 PA-ENC-TIMESTAMP method, but if not supported the server should ignore 4373 the presence of PA-ENC-TIMESTAMP pre-authentication in a request. 4375 Mutual authentication 4377 Mutual authentication (via the KRB_AP_REP message) must be supported. 4379 Ticket addresses and flags 4381 All KDC's must pass through tickets that carry no addresses (i.e. if a 4382 TGT contains no addresses, the KDC will return derivative tickets), but 4383 each realm may set its own policy for issuing such tickets, and each 4384 application server will set its own policy with respect to accepting them. 4386 Proxies and forwarded tickets must be supported. Individual realms and 4387 application servers can set their own policy on when such tickets will 4388 be accepted. 4390 All implementations must recognize renewable and postdated tickets, but 4391 need not actually implement them. If these options are not supported, 4392 the starttime and endtime in the ticket shall specify a ticket's entire 4393 useful life. When a postdated ticket is decoded by a server, all 4394 implementations shall make the presence of the postdated flag visible to 4395 the calling server. 4397 User-to-user authentication 4399 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC 4400 option) must be provided by implementations, but individual realms may 4401 decide as a matter of policy to reject such requests on a per-principal 4402 or realm-wide basis. 4404 Authorization data 4406 Implementations must pass all authorization data subfields from 4407 ticket-granting tickets to any derivative tickets unless directed to 4408 suppress a subfield as part of the definition of that registered 4409 subfield type (it is never incorrect to pass on a subfield, and no 4410 registered subfield types presently specify suppression at the KDC). 4412 Implementations must make the contents of any authorization data 4413 subfields available to the server when a ticket is used. Implementations 4414 are not required to allow clients to specify the contents of the 4415 authorization data fields. 4417 Constant ranges 4419 All protocol constants are constrained to 32 bit (signed) values unless 4420 further constrained by the protocol definition. This limit is provided 4421 to allow implementations to make assumptions about the maximum values 4422 that will be received for these constants. Implementation receiving 4423 values outside this range may reject the request, but they must recover 4424 cleanly. 4426 9.2. Recommended KDC values 4428 Following is a list of recommended values for a KDC implementation, 4429 based on the list of suggested configuration constants (see section 4.4). 4431 minimum lifetime 5 minutes 4432 maximum renewable lifetime 1 week 4433 maximum ticket lifetime 1 day 4434 empty addresses only when suitable restrictions appear 4435 in authorization data 4436 proxiable, etc. Allowed. 4438 10. IANA considerations 4440 Appendix with all the tables that IANA will need to start maintaining? 4442 * cryptosystem registration 4443 * usage number registration 4445 11. ACKNOWLEDGEMENTS 4447 T.B.S. 4449 12. REFERENCES 4451 [Blumenthal96] 4452 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers", 4453 Proceedings of PRAGOCRYPT '96, 1996. [Bellare98] 4454 Bellare, M., Desai, A., Pointcheval, D., Rogaway, P., "Relations 4455 Among Notions of Security for Public-Key Encryption Schemes". 4456 Extended abstract published in Advances in Cryptology- Crypto 98 4457 Proceedings, Lecture Notes in Computer Science Vol. 1462, H. 4458 Krawcyzk ed., Springer-Verlag, 1998. [DES77] 4459 National Bureau of Standards, U.S. Department of Commerce, "Data 4460 Encryption Standard," Federal Information Processing Standards 4461 Publication 46, Washington, DC (1977). [DESM80] 4462 National Bureau of Standards, U.S. Department of Com- merce, "DES 4463 Modes of Operation," Federal Information Processing Standards 4464 Publication 81, Springfield, VA (December 1980). [Dolev91] 4465 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 4466 Proceedings of the 23rd Annual Symposium on Theory of Computing, 4467 ACM, 1991. [DS81] 4468 Dorothy E. Denning and Giovanni Maria Sacco, "Time- stamps in Key 4469 Distribution Protocols," Communications of the ACM, Vol. 24(8), pp. 4470 533-536 (August 1981). [DS90] 4471 Don Davis and Ralph Swick, "Workstation Services and Kerberos 4472 Authentication at Project Athena," Technical Memorandum TM-424, MIT 4473 Laboratory for Computer Science (February 1990). [Horowitz96] 4474 Horowitz, M., "Key Derivation for Authentication, Integrity, and 4475 Privacy", draft-horowitz-key-derivation-02.txt, August 1998. [HorowitzB96] 4476 Horowitz, M., "Key Derivation for Kerberos V5", draft- 4477 horowitz-kerb-key-derivation-01.txt, September 1998. [IS3309] 4478 International Organization for Standardization, "ISO Information 4479 Processing Systems - Data Communication - High-Level Data Link 4480 Control Procedure - Frame Struc- ture," IS 3309 (October 1984). 3rd 4481 Edition. [KBC96] 4482 H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- Hashing for 4483 Message Authentication," Working Draft 4484 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). [KNT92] 4485 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 4486 Evolution of the Kerberos Authentication Service," in an IEEE 4487 Computer Society Text soon to be published (June 1992). [Krawczyk96] 4488 Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: Keyed-Hashing for 4489 Message Authentication", draft-ietf-ipsec-hmac- md5-01.txt, August, 4490 1996. [LGDSR87] 4491 P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- merfeld, and 4492 K. Raeburn, Section E.1: Service Manage- ment System, M.I.T. Project 4493 Athena, Cambridge, Mas- sachusetts (1987). [MD4-92] 4494 R. Rivest, "The MD4 Message Digest Algorithm," RFC 1320, MIT 4495 Laboratory for Computer Science (April 1992). [MD5-92] 4496 R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, MIT 4497 Laboratory for Computer Science (April 1992). [MNSS87] 4498 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 4499 Section E.2.1: Kerberos Authentication and Authorization System, 4500 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 1987). 4501 [Neu93] 4502 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 4503 Distributed Systems," in Proceedings of the 13th International 4504 Conference on Distributed Com- puting Systems, Pittsburgh, PA (May, 4505 1993). [NS78] 4506 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 4507 Authentication in Large Networks of Com- puters," Communications of 4508 the ACM, Vol. 21(12), pp. 993-999 (December, 1978). [NT94] 4509 B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- cation 4510 Service for Computer Networks," IEEE Communica- tions Magazine, Vol. 4511 32(9), pp. 33-38 (September 1994). [Pat92]. 4512 J. Pato, Using Pre-Authentication to Avoid Password Guessing 4513 Attacks, Open Software Foundation DCE Request for Comments 26 4514 (December 1992). [SG92] 4515 Stuart G. Stubblebine and Virgil D. Gligor, "On Message Integrity in 4516 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 4517 Research in Security and Privacy, Oakland, California (May 1992). [SNS88] 4518 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- beros: An 4519 Authentication Service for Open Network Sys- tems," pp. 191-202 in 4520 Usenix Conference Proceedings, Dallas, Texas (February, 1988). [X509-88] 4521 CCITT, Recommendation X.509: The Directory Authentica- tion 4522 Framework, December 1988. 4524 A. ASN.1 module 4526 Kerberos5 { 4527 iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 4528 } DEFINITIONS ::= BEGIN 4530 Int32 ::= INTEGER (-2147483648..2147483647) 4531 -- signed values representable in 32 bits 4533 UInt32 ::= INTEGER (0..4294967295) 4534 -- unsigned 32 bit values 4536 Microseconds ::= INTEGER (0..999999) 4537 -- microseconds 4539 KerberosString ::= GeneralString (IA5String) 4541 Realm ::= KerberosString 4543 PrincipalName ::= SEQUENCE { 4544 name-type [0] Int32, 4545 name-string [1] SEQUENCE OF KerberosString 4546 } 4548 KerberosTime ::= GeneralizedTime 4549 -- with no fractional seconds 4551 HostAddress ::= SEQUENCE { 4552 addr-type [0] Int32, 4553 address [1] OCTET STRING 4554 } 4555 -- XXX HostAddresses is always used as an OPTIONAL field and can be 4556 -- zero-length. 4557 HostAddresses ::= SEQUENCE OF HostAddress -- XXX subtly different from 1510 4558 -- but encodes the same 4560 -- XXX AuthorizationData is always used as an OPTIONAL field and can 4561 -- be zero-length. 4562 AuthorizationData ::= SEQUENCE OF SEQUENCE { 4563 ad-type [0] Int32, 4564 ad-data [1] OCTET STRING 4565 } 4567 PA-DATA ::= SEQUENCE { 4568 padata-type [1] Int32 -- first tag is [1], not [0] --, 4569 padata-value [2] OCTET STRING -- might be encoded AP-REQ 4570 } 4572 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 4573 -- shall be sent, but no fewer than 32 4575 EncryptedData1510 ::= SEQUENCE { 4576 etype [0] Int32 -- EncryptionType --, 4577 kvno [1] UInt32 OPTIONAL, 4578 cipher [2] OCTET STRING -- ciphertext 4579 } 4580 EncryptedData {Type, UInt32:KeyUsages} ::= SEQUENCE { 4581 etype [0] Int32 -- EncryptionType --, 4582 kvno [1] UInt32 OPTIONAL, 4583 cipher [2] OCTET STRING (CONSTRAINED BY { 4584 -- must be encrypted DER encoding of -- Type, 4585 -- with key usage being one of -- UInt32:KeyUsages 4586 }) 4587 } 4589 EncryptionKey ::= SEQUENCE { 4590 keytype [0] Int32 -- actually encryption type --, 4591 keyvalue [1] OCTET STRING 4592 } 4594 Checksum {UInt32:KeyUsages} ::= SEQUENCE { 4595 cksumtype [0] Int32, 4596 checksum [1] OCTET STRING (CONSTRAINED BY { 4597 -- with key usage being one of -- UInt32:KeyUsages 4598 }) 4599 } 4601 -- key usage numbers 4603 keyuse-pa-enc-ts Int32 ::= 1 4604 keyuse-Ticket Int32 ::= 2 4605 keyuse-EncASRepPart Int32 ::= 3 4606 keyuse-TGSReqAuthData-sesskey Int32 ::= 4 4607 keyuse-TGSReqAuthData-subkey Int32 ::= 5 4608 keyuse-pa-TGSReq-cksum Int32 ::= 6 4609 keyuse-pa-TGSReq-authenticator Int32 ::= 7 4610 keyuse-EncTGSRepPart-sesskey Int32 ::= 8 4611 keyuse-EncTGSRepPart-subkey Int32 ::= 9 4612 keyuse-APReq-cksum Int32 ::= 10 4613 keyuse-APReq-authenticator Int32 ::= 11 4614 keyuse-EncAPRepPart Int32 ::= 12 4615 keyuse-EncKrbPrivPart Int32 ::= 13 4616 keyuse-EncKrbCredPart Int32 ::= 14 4617 keyuse-KrbSafe-cksum Int32 ::= 15 4619 Ticket ::= [APPLICATION 1] SEQUENCE { 4620 tkt-vno [0] INTEGER (5), 4621 realm [1] Realm, 4622 sname [2] PrincipalName, 4623 enc-part [3] EncryptedData {EncTicketPart, {keyuse-Ticket}} 4624 } 4626 -- Encrypted part of ticket 4627 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 4628 flags [0] TicketFlags, 4629 key [1] EncryptionKey, 4630 crealm [2] Realm, 4631 cname [3] PrincipalName, 4632 transited [4] TransitedEncoding, 4633 authtime [5] KerberosTime, 4634 starttime [6] KerberosTime OPTIONAL, 4635 endtime [7] KerberosTime, 4636 renew-till [8] KerberosTime OPTIONAL, 4637 caddr [9] HostAddresses OPTIONAL, 4638 authorization-data [10] AuthorizationData OPTIONAL 4639 } 4640 -- encoded Transited field 4641 TransitedEncoding ::= SEQUENCE { 4642 tr-type [0] Int32 -- must be registered --, 4643 contents [1] OCTET STRING 4644 } 4646 TicketFlags ::= KerberosFlags 4647 -- reserved(0), 4648 -- forwardable(1), 4649 -- forwarded(2), 4650 -- proxiable(3), 4651 -- proxy(4), 4652 -- may-postdate(5), 4653 -- postdated(6), 4654 -- invalid(7), 4655 -- renewable(8), 4656 -- initial(9), 4657 -- pre-authent(10), 4658 -- hw-authent(11), 4659 -- the following are new since 1510; maybe remove from krb-clarifications? 4660 -- transited-policy-checked(12), 4661 -- ok-as-delegate(13), 4662 -- anonymous(14), 4663 -- cksummed-ticket(15) 4665 AS-REQ ::= KDC-REQ {10} 4666 TGS-REQ ::= KDC-REQ {12} 4668 KDC-REQ {INTEGER:tagnum} ::= [APPLICATION tagnum] SEQUENCE { 4669 pvno [1] INTEGER (5) -- first tag is [1], not [0] --, 4670 msg-type [2] INTEGER (tagnum), 4671 padata [3] SEQUENCE OF PA-DATA OPTIONAL -- XXX may be zero-length --, 4672 req-body [4] KDC-REQ-BODY 4673 } 4675 KDC-REQ-BODY ::= SEQUENCE { 4676 kdc-options [0] KDCOptions, 4677 cname [1] PrincipalName OPTIONAL 4678 -- Used only in AS-REQ --, 4679 realm [2] Realm 4680 -- Server's realm 4681 -- Also client's in AS-REQ --, 4682 sname [3] PrincipalName OPTIONAL, 4683 from [4] KerberosTime OPTIONAL, 4684 till [5] KerberosTime, 4685 rtime [6] KerberosTime OPTIONAL, 4686 nonce [7] UInt32, 4687 etype [8] SEQUENCE OF Int32 -- EncryptionType 4688 -- in preference order --, 4689 addresses [9] HostAddresses OPTIONAL, 4690 enc-authorization-data [10] EncryptedData { 4691 AuthorizationData, 4692 { keyuse-TGSReqAuthData-sesskey 4693 | keyuse-TGSReqAuthData-subkey } 4694 } OPTIONAL, 4695 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL -- XXX may be zero-length 4696 } 4697 KDCOptions ::= KerberosFlags 4698 -- reserved(0), 4699 -- forwardable(1), 4700 -- forwarded(2), 4701 -- proxiable(3), 4702 -- proxy(4), 4703 -- allow-postdate(5), 4704 -- postdated(6), 4705 -- unused7(7), 4706 -- renewable(8), 4707 -- unused9(9), 4708 -- unused10(10), 4709 -- unused11(11), 4710 -- unused12(12), 4711 -- unused13(13), 4712 -- 14 through 26 were unused in 1510 4713 -- requestanonymous(14), 4714 -- canonicalize(15), 4715 -- disable-transited-check(26), 4716 -- 4717 -- renewable-ok(27), 4718 -- enc-tkt-in-skey(28), 4719 -- renew(30), 4720 -- validate(31) 4722 AS-REP ::= KDC-REP {11, EncASRepPart, {keyuse-EncASRepPart}} 4723 TGS-REP ::= KDC-REP {13, EncTGSRepPart, 4724 { keyuse-EncTGSRepPart-sesskey 4725 | keyuse-EncTGSRepPart-subkey }} 4727 KDC-REP {INTEGER:tagnum, 4728 TypeToEncrypt, 4729 UInt32:KeyUsages} ::= [APPLICATION tagnum] SEQUENCE { 4730 pvno [0] INTEGER (5), 4731 msg-type [1] INTEGER (tagnum), 4732 padata [2] SEQUENCE OF PA-DATA OPTIONAL -- XXX may be zero length --, 4733 crealm [3] Realm, 4734 cname [4] PrincipalName, 4735 ticket [5] Ticket, 4736 enc-part [6] EncryptedData {TypeToEncrypt, KeyUsages} 4737 } 4739 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 4740 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4742 EncKDCRepPart ::= SEQUENCE { 4743 key [0] EncryptionKey, 4744 last-req [1] LastReq, 4745 nonce [2] UInt32, 4746 key-expiration [3] KerberosTime OPTIONAL, 4747 flags [4] TicketFlags, 4748 authtime [5] KerberosTime, 4749 starttime [6] KerberosTime OPTIONAL, 4750 endtime [7] KerberosTime, 4751 renew-till [8] KerberosTime OPTIONAL, 4752 srealm [9] Realm, 4753 sname [10] PrincipalName, 4754 caddr [11] HostAddresses OPTIONAL 4755 } 4756 LastReq ::= SEQUENCE OF SEQUENCE { 4757 lr-type [0] Int32, 4758 lr-value [1] KerberosTime 4759 } 4761 AP-REQ ::= [APPLICATION 14] SEQUENCE { 4762 pvno [0] INTEGER (5), 4763 msg-type [1] INTEGER (14), 4764 ap-options [2] APOptions, 4765 ticket [3] Ticket, 4766 authenticator [4] EncryptedData {Authenticator, 4767 { keyuse-pa-TGSReq-authenticator 4768 | keyuse-APReq-authenticator }} 4769 } 4771 APOptions ::= KerberosFlags 4772 -- reserved(0), 4773 -- use-session-key(1), 4774 -- mutual-required(2) 4776 -- Unencrypted authenticator 4777 Authenticator ::= [APPLICATION 2] SEQUENCE { 4778 authenticator-vno [0] INTEGER (5), 4779 crealm [1] Realm, 4780 cname [2] PrincipalName, 4781 cksum [3] Checksum {{ 4782 keyuse-pa-TGSReq-cksum 4783 | keyuse-APReq-cksum 4784 }} OPTIONAL, 4785 cusec [4] Microseconds, 4786 ctime [5] KerberosTime, 4787 subkey [6] EncryptionKey OPTIONAL, 4788 seq-number [7] UInt32 OPTIONAL, 4789 authorization-data [8] AuthorizationData OPTIONAL 4790 } 4792 AP-REP ::= [APPLICATION 15] SEQUENCE { 4793 pvno [0] INTEGER (5), 4794 msg-type [1] INTEGER (15), 4795 enc-part [2] EncryptedData {EncAPRepPart, 4796 { keyuse-EncAPRepPart }} 4797 } 4799 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 4800 ctime [0] KerberosTime, 4801 cusec [1] Microseconds, 4802 subkey [2] EncryptionKey OPTIONAL, 4803 seq-number [3] UInt32 OPTIONAL 4804 } 4806 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4807 pvno [0] INTEGER (5), 4808 msg-type [1] INTEGER (20), 4809 safe-body [2] KRB-SAFE-BODY, 4810 cksum [3] Checksum {{keyuse-KrbSafe-cksum}} 4811 } 4812 KRB-SAFE-BODY ::= SEQUENCE { 4813 user-data [0] OCTET STRING, 4814 timestamp [1] KerberosTime OPTIONAL, 4815 usec [2] Microseconds OPTIONAL, 4816 seq-number [3] UInt32 OPTIONAL, 4817 s-address [4] HostAddress, 4818 r-address [5] HostAddress OPTIONAL 4819 } 4821 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4822 pvno [0] INTEGER (5), 4823 msg-type [1] INTEGER (21) -- there is no [2] tag --, 4824 enc-part [3] EncryptedData {EncKrbPrivPart, 4825 {keyuse-EncKrbPrivPart}} 4826 } 4828 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4829 user-data [0] OCTET STRING, 4830 timestamp [1] KerberosTime OPTIONAL, 4831 usec [2] Microseconds OPTIONAL, 4832 seq-number [3] UInt32 OPTIONAL, 4833 s-address [4] HostAddress -- sender's addr --, 4834 r-address [5] HostAddress OPTIONAL -- recip's addr 4835 } 4837 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 4838 pvno [0] INTEGER (5), 4839 msg-type [1] INTEGER (22), 4840 tickets [2] SEQUENCE OF Ticket, 4841 enc-part [3] EncryptedData {EncKrbCredPart, 4842 {keyuse-EncKrbCredPart}} 4843 } 4845 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4846 ticket-info [0] SEQUENCE OF KrbCredInfo, 4847 nonce [1] UInt32 OPTIONAL, 4848 timestamp [2] KerberosTime OPTIONAL, 4849 usec [3] Microseconds OPTIONAL, 4850 s-address [4] HostAddress OPTIONAL, 4851 r-address [5] HostAddress OPTIONAL 4852 } 4854 KrbCredInfo ::= SEQUENCE { 4855 key [0] EncryptionKey, 4856 prealm [1] Realm OPTIONAL, 4857 pname [2] PrincipalName OPTIONAL, 4858 flags [3] TicketFlags OPTIONAL, 4859 authtime [4] KerberosTime OPTIONAL, 4860 starttime [5] KerberosTime OPTIONAL, 4861 endtime [6] KerberosTime OPTIONAL, 4862 renew-till [7] KerberosTime OPTIONAL, 4863 srealm [8] Realm OPTIONAL, 4864 sname [9] PrincipalName OPTIONAL, 4865 caddr [10] HostAddresses OPTIONAL 4866 } 4867 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 4868 pvno [0] INTEGER (5), 4869 msg-type [1] INTEGER (30), 4870 ctime [2] KerberosTime OPTIONAL, 4871 cusec [3] Microseconds OPTIONAL, 4872 stime [4] KerberosTime, 4873 susec [5] Microseconds, 4874 error-code [6] Int32, 4875 crealm [7] Realm OPTIONAL, 4876 cname [8] PrincipalName OPTIONAL, 4877 realm [9] Realm -- Correct realm --, 4878 sname [10] PrincipalName -- Correct name --, 4879 e-text [11] KerberosString OPTIONAL, 4880 e-data [12] OCTET STRING OPTIONAL 4881 } 4883 -- preauth stuff follows 4885 PA-ENC-TIMESTAMP ::= EncryptedData {PA-ENC-TS-ENC, {keyuse-pa-enc-ts}} 4886 PA-ENC-TS-ENC ::= SEQUENCE { 4887 patimestamp [0] KerberosTime -- client's time --, 4888 pausec [1] Microseconds OPTIONAL 4889 } 4891 -- remove PA-ENC-TIMESTAMP2? 4893 PA-ENC-TIMESTAMP2 ::= EncryptedData -- encrypted PA-ENC-TS2-ENC 4894 PA-ENC-TS2-ENC ::= SEQUENCE { 4895 patimestamp [0] KerberosTime -- client's time --, 4896 pausec [1] Microseconds OPTIONAL, 4897 pachecksum [2] Checksum {{}} OPTIONAL 4898 -- keyed checksum of KDC-REQ-BODY 4899 } 4901 END 4902 B. Definition of common authorization data elements 4904 This appendix contains the definitions of basic authorization data 4905 elements that must be understood by all implementations. These common 4906 authorization data elements are recursivly defined, meaning the ad-data 4907 for these types will itself contain a sequence of authorization data 4908 whose interpretation is affected by the encapsulating element. Depending 4909 on the meaning of the encapsulating element, the encapsulated elements 4910 may be ignored, might be interpreted as issued directly by the KDC, or 4911 they might be stored in a separate plaintext part of the ticket. The 4912 types of the encapsulating elements are specified as part of the 4913 Kerberos specification because the behavior based on these values should 4914 be understood across implementations whereas other elements need only be 4915 understood by the applications which they affect. 4917 Authorization data elements are considered critical if present in a 4918 ticket or authenticator. Unless encapsulated in a known authorization 4919 data element amending the criticality of the elements it contains, if an 4920 unknown authorization data element type is received by a server either 4921 in an AP-REQ or in a ticket contained in an AP-REQ, then authentication 4922 SHOULD fail. Authorization data is intended to restrict the use of a 4923 ticket. If the service cannot determine whether the restriction applies 4924 to that service then a security weakness may result if the ticket can be 4925 used for that service. Authorization elements that are optional can be 4926 enclosed in AD-IF-RELEVANT element. 4928 In the definitions that follow, the value of the ad-type for the element 4929 will be specified in the subsection number, and the value of the ad-data 4930 will be as shown in the ASN.1 structure that follows the subsection 4931 heading. 4933 B.1. If relevant 4935 AD-IF-RELEVANT AuthorizationData 4937 AD elements encapsulated within the if-relevant element are intended for 4938 interpretation only by application servers that understand the 4939 particular ad-type of the embedded element. Application servers that do 4940 not understand the type of an element embedded within the if-relevant 4941 element may ignore the uninterpretable element. This element promotes 4942 interoperability across implementations which may have local extensions 4943 for authorization. 4945 B.4. KDC Issued 4947 AD-KDCIssued SEQUENCE { 4948 ad-checksum[0] Checksum, 4949 i-realm[1] Realm OPTIONAL, 4950 i-sname[2] PrincipalName OPTIONAL, 4951 elements[3] AuthorizationData. 4952 } 4954 ad-checksum 4955 A checksum over the elements field using a cryptographic checksum 4956 method that is identical to the checksum used to protect the ticket 4957 itself (i.e. using the same hash function and the same encryption 4958 algorithm used to encrypt the ticket) and using a key derived from 4959 the same key used to protect the ticket. i-realm, i-sname 4960 The name of the issuing principal if different from the KDC itself. 4961 This field would be used when the KDC can verify the authenticity of 4962 elements signed by the issuing principal and it allows this KDC to 4963 notify the application server of the validity of those elements. elements 4964 A sequence of authorization data elements issued by the KDC. 4966 The KDC-issued ad-data field is intended to provide a means for Kerberos 4967 principal credentials to embed within themselves privilege attributes 4968 and other mechanisms for positive authorization, amplifying the 4969 priveleges of the principal beyond what can be done using a credentials 4970 without such an a-data element. 4972 This can not be provided without this element because the definition of 4973 the authorization-data field allows elements to be added at will by the 4974 bearer of a TGT at the time that they request service tickets and 4975 elements may also be added to a delegated ticket by inclusion in the 4976 authenticator. 4978 For KDC-issued elements this is prevented because the elements are 4979 signed by the KDC by including a checksum encrypted using the server's 4980 key (the same key used to encrypt the ticket - or a key derived from 4981 that key). Elements encapsulated with in the KDC-issued element will be 4982 ignored by the application server if this "signature" is not present. 4983 Further, elements encapsulated within this element from a ticket 4984 granting ticket may be interpreted by the KDC, and used as a basis 4985 according to policy for including new signed elements within derivative 4986 tickets, but they will not be copied to a derivative ticket directly. If 4987 they are copied directly to a derivative ticket by a KDC that is not 4988 aware of this element, the signature will not be correct for the 4989 application ticket elements, and the field will be ignored by the 4990 application server. 4992 This element and the elements it encapulates may be safely ignored by 4993 applications, application servers, and KDCs that do not implement this 4994 element. 4996 B.5. And-Or 4998 AD-AND-OR SEQUENCE { 4999 condition-count[0] INTEGER, 5000 elements[1] AuthorizationData 5001 } 5003 When restrictive AD elements are encapsulated within the and-or element 5004 are encountered, only the number specified in condition-count of the 5005 encapsulated conditions must be met in order to satisfy this element. 5006 This element may be used to implement an "or" operation by setting the 5007 condition-count field to 1, and it may specify an "and" operation by 5008 setting the condition count to the number of embedded elements. 5009 Application servers that do not implement this element must reject 5010 tickets that contain authorization data elements of this type. 5012 B.8. If relevant 5014 AD-MANDATORY-FOR-KDC AuthorizationData 5016 AD elements encapsulated within the mandatory-for-kdc element are to be 5017 interpreted by the KDC. KDC's that do not understand the type of an 5018 element embedded within the if-relevant element must reject the request. 5020 Commentary 5022 Section 1: The preamble and introduction does not define the protocol, 5023 mention is made in the introduction regarding the ability to rely on the 5024 KDC to check the transited field, and on the inclusion of a flag in a 5025 ticket indicating that this check has occurred. This is a new capability 5026 not present in RFC1510. Pre-existing implementation may ignore or not 5027 set this flag without negative security implications. 5029 The definition of the secret key says that in the case of a user the key 5030 may be derived from a password. In 1510, it said that the key was 5031 derived from the password. This change was made to accommodate 5032 situations where the user key might be stored on a smart-card, or 5033 otherwise obtained independent of a password. 5035 The introduction also mentions the use of public key for initial 5036 authentication in Kerberos by reference. RFC1510 did not include such a 5037 reference. 5039 Section 1.2 was added to explain that while Kerberos provides 5040 authentication of a named principal, it is still the responsibility of 5041 the application to ensure that the authenticated name is the entity with 5042 which the application wishes to communicate. 5044 Discussion of extensibility has been added to the introduction. Section 5045 2: No changes were made to existing options and flags specified in 5046 RFC1510, though some of the sections in the specification were 5047 renumbered, and text was revised to make the description and intent of 5048 existing options clearer, especially with respect to the ENC-TKT-IN-SKEY 5049 option (now section 2.9.3) which is used for user-to-user authentication. 5051 New options and ticket flags added since RFC1510 include transited 5052 policy checking (section 2.7), anonymous tickets (section 2.8) and name 5053 canonicalization (section 2.9.1). 5055 Section 2.9.1: Name canonicalization was added since RFC 1510. In the 5056 penultimate revision, it covered client name canonicalization as well. 5057 Name canonicalization was then removed and set aside for a separate 5058 document. Section 2.9.2 and .3 were renumbered to .1 and .2. 5060 Discussion of how extensibility affects ticket flags and KDC options was 5061 added to the introduction. Section 3: Added mention of the optional 5062 checksum field in the KRB-ERROR message. Added mention of name 5063 canonicalization and anonymous tickets in exposition on KDC options. 5064 Mention of the name canonicalization case is included in the description 5065 of the KDC reply (3.1.3). A warning regarding generation of session keys 5066 for application use was added, urging the inclusion of key entropy from 5067 the KDC generated session key in the ticket. An example regarding use of 5068 the subsession key was added to section 3.2.6. Descriptions of the 5069 pa-etype-info, and pa-pw-salt preauthentication data items were added. 5071 Changed may preauthenticate to should preauthenticate and included note 5072 about known plaintext attacks. 5074 Removed text about keys that support multiple encryption types. The 5075 crypto draft doesn't really define things that way and it is out of 5076 scope for the protocol spec anyway. 5078 Section 5: Ticket flags and KDC options were added to support the new 5079 functions described elsewhere in this document. The encoding of the 5080 options flags are now described to be no less than 32 bits, and the 5081 smallest number of bits beyond 32 needed to encode any set bits. It also 5082 describes the encoding of the bitstring as using "unnamed" bits. 5084 Definition of the PA-USE-SPECIFIED-KVNO preauthentication data field was 5085 added. 5087 In the KRB-ERROR message, the e-data field was generalized for use in 5088 other than the KDC_ERR_PREAUTH_REQUIRED error. The TypedData structure 5089 was defined. Type tags for TypedData are defined in the same sequence as 5090 the PA-DATA type space to avoid confusion with the use of the PA-DATA 5091 namespace previously used for the e-data field for the 5092 KDC_ERR_PREAUTH_REQUIRED error. 5094 Also for possible discussion is the question of whether implementations 5095 are required to save the original encoding of any part of a message that 5096 might possibly be resent to another party. This is the TicketExtensions 5097 case, but may turn out to be more general. 5099 Section 8: Commentary: Words were added describing the convention that 5100 domain based realm names for newly created realms should be specified as 5101 upper case. This recommendation does not make lower case realm names 5102 illegal. Words were added highlighting that the slash separated 5103 components in the X500 style of realm names is consistent with existing 5104 RFC1510 based implementations, but that it conflicts with the general 5105 recommendation of X.500 name representation specified in RFC2253. 5107 Section 8: Since RFC1510, the definition of the TCP transport for 5108 Kerberos messages was added, and the encryption and checksum number 5109 assignments have been moved out into a separate document. 5111 Regarding the suggestion of weakening the requirement for use of port 88 5112 for cases where the port can be looked up elsewhere - I did not 5113 incorporate this suggestion because cross realm authentication requires 5114 the ability to contact the appropriate KDC, and unless ALL 5115 implementations of Kerberos include support for finding such alternate 5116 port numbers, use of such KDC's would be non-interoperable. (Of course, 5117 we do not yet have a single required mechanism for determining the KDC's 5118 network address.) Section 9: Requirements for supporting 5119 DES3-CBC-SHA1-KD encryption and HMAC-SHA1-DES3-KD checksums were added. 5121 [TM] Project Athena, Athena, and Kerberos are trademarks of the 5122 Massachusetts Institute of Technology (MIT). No commercial use of these 5123 trademarks may be made without prior written permission of MIT. 5125 [1.1] Note, however, that many applications use Kerberos' functions only 5126 upon the initiation of a stream-based network connection. Unless an 5127 application subsequently provides integrity protection for the data 5128 stream, the identity verification applies only to the initiation of the 5129 connection, and does not guarantee that subsequent messages on the 5130 connection originate from the same principal. 5132 [1.2] Secret and private are often used interchangeably in the 5133 literature. In our usage, it takes two (or more) to share a secret, thus 5134 a shared DES key is a secret key. Something is only private when no one 5135 but its owner knows it. Thus, in public key cryptosystems, one has a 5136 public and a private key. 5138 [1.3] Of course, with appropriate permission the client could arrange 5139 registration of a separately-named principal in a remote realm, and 5140 engage in normal exchanges with that realm's services. However, for even 5141 small numbers of clients this becomes cumbersome, and more automatic 5142 methods as described here are necessary. 5144 [2.1] Though it is permissible to request or issue tickets with no 5145 network addresses specified. 5147 [2.2] It is important that the KDC be sent the name as typed by the 5148 user, and not only the canonical form of the name. If the domain name 5149 system was used to find the canonical name on the client side, the 5150 mapping is vulnerable. [3.1] The password-changing request must not be 5151 honored unless the requester can provide the old password (the user's 5152 current secret key). Otherwise, it would be possible for someone to walk 5153 up to an unattended session and change another user's password. 5155 [3.2] To authenticate a user logging on to a local system, the 5156 credentials obtained in the AS exchange may first be used in a TGS 5157 exchange to obtain credentials for a local server. Those credentials 5158 must then be verified by a local server through successful completion of 5159 the Client/Server exchange. 5161 [3.3] "Random" means that, among other things, it should be impossible 5162 to guess the next session key based on knowledge of past session keys. 5163 This can only be achieved in a pseudo-random number generator if it is 5164 based on cryptographic principles. It is more desirable to use a truly 5165 random number generator, such as one based on measurements of random 5166 physical phenomena. 5168 [3.4] Tickets contain both an encrypted and unencrypted portion, so 5169 cleartext here refers to the entire unit, which can be copied from one 5170 message and replayed in another without any cryptographic skill. 5172 [3.5] Note that this can make applications based on unreliable 5173 transports difficult to code correctly. If the transport might deliver 5174 duplicated messages, either a new authenticator must be generated for 5175 each retry, or the application server must match requests and replies 5176 and replay the first reply in response to a detected duplicate. 5178 [3.6] This allows easy implementation of user-to-user authentication 5179 [8], which uses ticket-granting ticket session keys in lieu of secret 5180 server keys in situations where such secret keys could be easily 5181 compromised. 5183 [3.7]Note also that the rejection here is restricted to authenticators 5184 from the same principal to the same server. Other client principals 5185 communicating with the same server principal should not be have their 5186 authenticators rejected if the time and microsecond fields happen to 5187 match some other client's authenticator. 5189 [3.8] If this is not done, an attacker could subvert the authentication 5190 by recording the ticket and authenticator sent over the network to a 5191 server and replaying them following an event that caused the server to 5192 lose track of recently seen authenticators. 5194 [3.9] In the Kerberos version 4 protocol, the timestamp in the reply was 5195 the client's timestamp plus one. This is not necessary in version 5 5196 because version 5 messages are formatted in such a way that it is not 5197 possible to create the reply by judicious message surgery (even in 5198 encrypted form) without knowledge of the appropriate encryption keys. 5200 [3.10] Note that for encrypting the KRB_AP_REP message, the sub-session 5201 key is not used, even if present in the Authenticator. 5203 [3.11] Implementations of the protocol may wish to provide routines to 5204 choose subkeys based on session keys and random numbers and to generate 5205 a negotiated key to be returned in the KRB_AP_REP message. 5207 [3.12]This can be accomplished in several ways. It might be known 5208 beforehand (since the realm is part of the principal identifier), it 5209 might be stored in a nameserver, or it might be obtained from a 5210 configuration file. If the realm to be used is obtained from a 5211 nameserver, there is a danger of being spoofed if the nameservice 5212 providing the realm name is not authenticated. This might result in the 5213 use of a realm which has been compromised, and would result in an 5214 attacker's ability to compromise the authentication of the application 5215 server to the client. 5217 [3.13] If the client selects a sub-session key, care must be taken to 5218 ensure the randomness of the selected sub-session key. One approach 5219 would be to generate a random number and XOR it with the session key 5220 from the ticket-granting ticket. 5222 [6.1] For example, a pseudo-random number generator may be seeded with a 5223 session key, but to protect the original key from any accidental 5224 weakness in the PRNG, use possibly-known data encrypted or checksummed 5225 using the key rather than using the key directly. Usage numbers in this 5226 reserved range should help avoid accidentally seeding the PRNG with a 5227 value also computed and perhaps exposed to an attacker elsewhere. 5229 [6.2] Of course, this does not apply to protocols that do their own 5230 encryption independent of this framework, directly using the key 5231 resulting from the Kerberos authentication exchange. 5233 [6.3] Perhaps one of the more common reasons for directly performing 5234 encryption is direct control over the negotiation and to select a 5235 "sufficiently strong" encryption algorithm (whatever that means in the 5236 context of a given application). While Kerberos directly provides no 5237 facility for negotiating encryption types between the application client 5238 and server, there are other means for accomplishing similar goals. For 5239 example, requesting only "strong" session key types from the KDC, and 5240 assuming that the type actually returned by the KDC will be understood 5241 and supported by the application server.