idnits 2.17.1 draft-ietf-cat-kerberos-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 1 longer page, the longest (page 1) being 8385 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 1832 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 238 instances of too long lines in the document, the longest one being 37 characters in excess of 72. ** There are 92 instances of lines with control characters in the document. == There are 28 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 2179: '... starttime[6] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2186: '... renew-till[8] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2187: '... caddr[9] HostAddresses OPTIONAL,...' RFC 2119 keyword, line 2188: '... authorization-data[10] AuthorizationData OPTIONAL...' RFC 2119 keyword, line 2492: '... cksum[3] Checksum OPTIONAL,...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...s. Note that ...' == Line 13 has weird spacing: '...groups may a...' == Line 17 has weird spacing: '...of six month...' == Line 18 has weird spacing: '...ents at any ...' == Line 19 has weird spacing: '...opriate to us...' == (1827 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (1 September 1992) is 11557 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? '1' on line 4041 looks like a reference -- Missing reference section? '2' on line 3631 looks like a reference -- Missing reference section? '3' on line 3395 looks like a reference -- Missing reference section? '4' on line 3412 looks like a reference -- Missing reference section? '5' on line 3413 looks like a reference -- Missing reference section? '6' on line 3414 looks like a reference -- Missing reference section? '7' on line 3415 looks like a reference -- Missing reference section? '8' on line 3416 looks like a reference -- Missing reference section? '9' on line 3417 looks like a reference -- Missing reference section? '10' on line 3762 looks like a reference -- Missing reference section? '11' on line 3763 looks like a reference -- Missing reference section? '12' on line 3902 looks like a reference -- Missing reference section? '13' on line 3898 looks like a reference -- Missing reference section? '14' on line 3916 looks like a reference -- Missing reference section? '15' on line 3972 looks like a reference -- Missing reference section? '16' on line 4601 looks like a reference -- Missing reference section? '17' on line 1594 looks like a reference -- Missing reference section? '18' on line 1597 looks like a reference -- Missing reference section? '19' on line 1825 looks like a reference -- Missing reference section? '20' on line 1893 looks like a reference -- Missing reference section? '0' on line 6246 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 2165 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 2172 looks like a reference -- Missing reference section? '21' on line 2402 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 2488 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 2577 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 2583 looks like a reference -- Missing reference section? '22' on line 2914 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 2962 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2963 looks like a reference -- Missing reference section? '24' on line 2976 looks like a reference -- Missing reference section? 'APPLICATION 26' on line 2983 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 3102 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 3173 looks like a reference -- Missing reference section? '26' on line 3189 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 3250 looks like a reference -- Missing reference section? 'APPLICATION 21' on line 3327 looks like a reference -- Missing reference section? '28' on line 3346 looks like a reference -- Missing reference section? '29' on line 3397 looks like a reference -- Missing reference section? 'APPLICATION 30' on line 3391 looks like a reference -- Missing reference section? '31' on line 3629 looks like a reference -- Missing reference section? '32' on line 3669 looks like a reference -- Missing reference section? '33' on line 3849 looks like a reference -- Missing reference section? '34' on line 3955 looks like a reference -- Missing reference section? '36' on line 4474 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 47 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Kohl 3 B. Clifford Neuman 4 1 September 1992 6 The Kerberos Network Authentication Service (V5) 8 _S_T_A_T_U_S _O_F _T_H_I_S _M_E_M_O 10 This document is an Internet Draft. Internet Drafts 11 are working documents of the Internet Engineering Task Force 12 (IETF), its Areas, and its Working Groups. Note that other 13 groups may also distribute working documents as Internet 14 Drafts. 16 Internet Drafts are draft documents valid for a maximum 17 of six months. Internet Drafts may be updated, replaced, 18 or obsoleted by other documents at any time. It is not 19 appropriate to use Internet Drafts as reference material or 20 to cite them other than as a "working draft" or "work in 21 progress." 23 Please check the I-D abstract listing contained in each 24 Internet Draft directory to learn the current status of this 25 or any other Internet Draft. Distribution of this memo is 26 unlimited. Please send comments to "krb-protocol@MIT.EDU." 28 _A_B_S_T_R_A_C_T 30 This document gives an overview and specification of 31 Version 5 of the protocol for the Kerberos network authenti- 32 cation system. Version 4, described elsewhere [1,2], is 33 presently in production use at MIT's Project Athena, and at 34 other Internet sites. 36 _O_V_E_R_V_I_E_W 38 This INTERNET-DRAFT describes the concepts and model 39 upon which the Kerberos network authentication system is 40 based. It also specifies Version 5 of the Kerberos proto- 41 col. 43 The motivations, goals, assumptions, and rationale 44 behind most design decisions are treated cursorily; for Ver- 45 sion 4 they are fully described in the Kerberos portion of 46 __________________________ 47 Project Athena, Athena, Athena MUSE, Discuss, Hesiod, 48 Kerberos, Moira, and Zephyr are trademarks of the Mas- 49 sachusetts Institute of Technology (MIT). No commer- 50 cial use of these trademarks may be made without prior 51 written permission of MIT. 53 Overview - 1 - Expires 28 February 1993 55 Version 5 - Revision 5.1 57 the Athena Technical Plan [1]. The protocols are under 58 review, and are not being submitted for consideration as an 59 Internet standard at this time. Comments are encouraged. 60 Requests for addition to an electronic mailing list for dis- 61 cussion of Kerberos, kerberos@MIT.EDU, may be addressed to 62 kerberos-request@MIT.EDU. This mailing list is gatewayed 63 onto the Usenet as the group comp.protocols.kerberos. 64 Requests for further information, including documents and 65 code availability, may be sent to info-kerberos@MIT.EDU. 66 8 67 _B_A_C_K_G_R_O_U_N_D 69 The Kerberos model is based in part on Needham and 70 Schroeder's trusted third-party authentication protocol [3] 71 and on modifications suggested by Denning and Sacco [4]. 72 The original design and implementation of Kerberos Versions 73 1 through 4 was the work of two former Project Athena staff 74 members, Steve Miller of Digital Equipment Corporation and 75 Clifford Neuman (now at the Information Sciences Institute 76 of the University of Southern California), along with Jerome 77 Saltzer, Technical Director of Project Athena, and Jeffrey 78 Schiller, MIT Campus Network Manager. Many other members of 79 Project Athena have also contributed to the work on Ker- 80 beros. Version 4 is publicly available, and has seen wide 81 use across the Internet. 83 Version 5 (described in this document) has evolved from 84 Version 4 based on new requirements and desires for features 85 not available in Version 4. Details on the differences 86 between Kerberos Versions 4 and 5 can be found in [5]. 88 _1. _I_n_t_r_o_d_u_c_t_i_o_n 90 Kerberos provides a means of verifying the identities 91 of principals, (e.g. a workstation user or a network server) 92 on an open (unprotected) network. This is accomplished 93 without relying on authentication by the host operating sys- 94 tem, without basing trust on host addresses, without requir- 95 ing physical security of all the hosts on the network, and 96 under the assumption that packets traveling along the net- 97 work can be read, modified, and inserted at will[1]. Ker- 98 beros performs authentication under these conditions as a 99 trusted third-party authentication service by using conven- 100 tional (shared secret key[2]) cryptography. 101 __________________________ 102 9[1] Note, however, that many applications use Kerberos' 103 functions only upon the initiation of a stream-based 104 network connection, and assume the absence of any ``hi- 105 jackers'' who might subvert such a connection. Such 106 use implicitly trusts the host addresses involved. 107 9[2] _S_e_c_r_e_t and _p_r_i_v_a_t_e are often used interchangeably 108 in the literature. In our usage, it takes two (or 109 more) to share a secret, thus a shared DES key is a 110 _s_e_c_r_e_t key. Something is only private when no one but 112 9Section 1. - 2 - Expires 28 February 1993 114 Version 5 - Revision 5.1 116 The authentication process proceeds as follows: A 117 client sends a request to the authentication server (AS) 118 requesting "credentials" for a given server. The AS 119 responds with these credentials, encrypted in the client's 120 key. The credentials consist of 1) a "ticket" for the 121 server and 2) a temporary encryption key (often called a 122 "session key"). The client transmits the ticket (which con- 123 tains the client's identity and a copy of the session key, 124 all encrypted in the server's key) to the server. The ses- 125 sion key (now shared by the client and server) is used to 126 authenticate the client, and may optionally be used to 127 authenticate the server. It may also be used to encrypt 128 further communication between the two parties or to exchange 129 a separate sub-session key to be used to encrypt further 130 communication. 132 The implementation consists of one or more authentica- 133 tion servers running on physically secure hosts. The 134 authentication servers maintain a database of principals 135 (i.e., users and servers) and their secret keys. Code 136 libraries provide encryption and implement the Kerberos pro- 137 tocol. In order to add authentication to its transactions, 138 a typical network application adds one or two calls to the 139 Kerberos library, which results in the transmission of the 140 necessary messages to achieve authentication. 142 The Kerberos protocol consists of several sub-protocols 143 (or exchanges). There are two methods by which a client can 144 ask a Kerberos server for credentials. In the first 145 approach, the client sends a cleartext request for a ticket 146 for the desired server to the AS. The reply is sent 147 encrypted in the client's secret key. Usually this request 148 is for a ticket-granting ticket (TGT) which can later be 149 used with the ticket-granting server (TGS). In the second 150 method, the client sends a request to the TGS. The client 151 sends the TGT to the TGS in the same manner as if it were 152 contacting any other application server which requires Ker- 153 beros credentials. The reply is encrypted in the session 154 key from the TGT. 156 Once obtained, credentials may be used to verify the 157 identity of the principals in a transaction, to ensure the 158 integrity of messages exchanged between them, or to preserve 159 privacy of the messages. The application is free to choose 160 whatever protection may be necessary. 162 To verify the identities of the principals in a tran- 163 saction, the client transmits the ticket to the server. 164 Since the ticket is sent "in the clear" (parts of it are 165 encrypted, but this encryption doesn't thwart replay) and 166 __________________________ 167 its owner knows it. Thus, in public key cryptosystems, 168 one has a public and a _p_r_i_v_a_t_e key. 170 Section 1. - 3 - Expires 28 February 1993 172 Version 5 - Revision 5.1 174 might be intercepted and reused by an attacker, additional 175 information is sent to prove that the message was originated 176 by the principal to whom the ticket was issued. This infor- 177 mation (called the _a_u_t_h_e_n_t_i_c_a_t_o_r) is encrypted 178 in the session key, and includes a timestamp. The timestamp 179 proves that the message was recently generated and is not a 180 replay. Encrypting the authenticator in the session key proves 181 that it was generated by a party possessing the session key. 182 Since no one except the requesting principal and the server 183 know the session key (it is never sent over the network in 184 the clear) this guarantees the identity of the client. 186 The integrity of the messages exchanged between princi- 187 pals can also be guaranteed using the session key (passed in 188 the ticket and contained in the credentials). This approach 189 provides detection of both replay attacks and message stream 190 modification attacks. It is accomplished by generating and 191 transmitting a collision-proof checksum (elsewhere called a 192 hash or digest function) of the client's message, keyed with 193 the session key. Privacy and integrity of the messages 194 exchanged between principals can be secured by encrypting 195 the data to be passed using the session key passed in the 196 ticket, and contained in the credentials. 198 The authentication exchanges mentioned above require 199 read-only access to the Kerberos database. Sometimes, how- 200 ever, the entries in the database must be modified, such as 201 when adding new principals or changing a principal's key. 202 This is done using a protocol between a client and a third 203 Kerberos server, the Kerberos Administration Server (KADM). 204 The administration protocol is not described in this docu- 205 ment. There is also a protocol for maintaining multiple 206 copies of the Kerberos database, but this can be considered 207 an implementation detail and may vary to support different 208 database technologies. 210 _1._1. _C_r_o_s_s-_R_e_a_l_m _O_p_e_r_a_t_i_o_n 212 The Kerberos protocol is designed to operate across 213 organizational boundaries. A client in one organization can 214 be authenticated to a server in another. Each organization 215 wishing to run a Kerberos server establishes its own 216 "realm". The name of the realm in which a client is 217 registered is part of the client's name, and can be used by 218 the end-service to decide whether to honor a request. 220 By establishing "inter-realm" keys, the administrators 221 of two realms can allow a client authenticated in the local 222 realm to use its authentication remotely[3]. The exchange 223 __________________________ 224 9[3] Of course, with appropriate permission the client 225 could arrange registration of a separately-named prin- 226 cipal in a remote realm, and engage in normal exchanges 227 with that realm's services. However, for even small 229 9Section 1.1. - 4 - Expires 28 February 1993 231 Version 5 - Revision 5.1 233 of inter-realm keys (a separate key may be used for each 234 direction) registers the ticket-granting service of each 235 realm as a principal in the other realm. A client is then 236 able to obtain a ticket-granting ticket for the remote 237 realm's ticket-granting service from its local realm. When 238 that ticket-granting ticket is used, the remote ticket- 239 granting service uses the inter-realm key (which usually 240 differs from its own normal TGS key) to decrypt the ticket- 241 granting ticket, and is thus certain that it was issued by 242 the client's own TGS. Tickets issued by the remote ticket- 243 granting service will indicate to the end-service that the 244 client was authenticated from another realm. 246 A realm is said to _c_o_m_m_u_n_i_c_a_t_e with another realm if 247 the two realms share an inter-realm key, or if the local 248 realm shares an inter-realm key with an intermediate realm 249 that communicates with the remote realm. An _a_u_t_h_e_n_t_i_c_a_t_i_o_n 250 _p_a_t_h is the sequence of intermediate realms that are tran- 251 sited in communicating from one realm to another. 253 Realms are typically organized hierarchically. Each 254 realm shares a key with its parent and a different key with 255 each child. If an inter-realm key is not directly shared by 256 two realms, the hierarchical organization allows an authen- 257 tication path to be easily constructed. If a hierarchical 258 organization is not used, it may be necessary to consult 259 some database in order to construct an authentication path 260 between realms. 262 Although realms are typically hierarchical, intermedi- 263 ate realms may be bypassed to achieve cross-realm authenti- 264 cation through alternate authentication paths (these might 265 be established to make communication between two realms more 266 efficient). It is important for the end-service to know 267 which realms were transited when deciding how much faith to 268 place in the authentication process. To facilitate this 269 decision, a field in each ticket contains the names of the 270 realms that were involved in authenticating the client. 271 8 272 _1._2. _E_n_v_i_r_o_n_m_e_n_t_a_l _a_s_s_u_m_p_t_i_o_n_s 274 Kerberos imposes a few assumptions on the environment in 275 which it can properly function: 277 o+ "Denial of service" attacks are not solved with Ker- 278 beros. There are places in these protocols where an 279 intruder can prevent an application from participating 280 in the proper authentication steps. Detection and 281 solution of such attacks (some of which can appear to 282 be not-uncommon "normal" failure modes for the system) 283 is usually best left to the human administrators and 284 __________________________ 285 numbers of clients this becomes cumbersome, and more 286 automatic methods as described here are necessary. 287 9 289 Section 1.2. - 5 - Expires 28 February 1993 291 Version 5 - Revision 5.1 293 users. 295 o+ Principals must keep their secret keys secret. If an 296 intruder somehow steals a principal's key, it will be 297 able to masquerade as that principal or impersonate any 298 server to the legitimate principal. 300 o+ Each host on the network must have a clock which is 301 "loosely synchronized" to the time of the other hosts; 302 this synchronization is used to reduce the bookkeeping 303 needs of application servers when they do replay detec- 304 tion. The degree of "looseness" can be configured on a 305 per-server basis. If the clocks are synchronized over 306 the network, the clock synchronization protocol must 307 itself be secured from network attackers. 309 o+ Principal identifiers are not recycled on a short-term 310 basis. A typical mode of access control will use 311 access control lists (ACLs) to grant permissions to 312 particular principals. If a stale ACL entry remains 313 for a deleted principal and the principal identifier is 314 reused, the new principal will inherit rights specified 315 in the stale ACL entry. By not re-using principal 316 identifiers, the danger of inadvertent access is 317 removed. 319 _1._3. _G_l_o_s_s_a_r_y _o_f _t_e_r_m_s 321 Below is a list of terms used throughout this document. 323 Authentication Verifying the claimed identity of a 324 principal. 326 Authentication headerA record containing a Ticket and an 327 Authenticator to be presented to a 328 server as part of the authentication 329 process. 331 Authentication path A sequence of intermediate realms tran- 332 sited in the authentication process when 333 communicating from one realm to another. 335 Authenticator A record containing information that can 336 be shown to have been recently generated 337 using the session key known only by the 338 client and server. 340 Authorization The process of determining whether a 341 client may use a service, which objects 343 Section 1.3. - 6 - Expires 28 February 1993 345 Version 5 - Revision 5.1 347 the client is allowed to access, and the 348 type of access allowed for each. 350 Capability A token that grants the bearer permis- 351 sion to access an object or service. In 352 Kerberos, this might be a ticket whose 353 use is restricted by the contents of the 354 authorization data field, but which 355 lists no network addresses, together 356 with the session key necessary to use 357 the ticket. 359 Ciphertext The output of an encryption function. 360 Encryption transforms plaintext into 361 ciphertext. 363 Client A process that makes use of a network 364 service on behalf of a user. Note that 365 in some cases a Server may itself be a 366 client of some other server (e.g. a 367 print server may be a client of a file 368 server). 370 Credentials A ticket plus the secret session key 371 necessary to successfully use that 372 ticket in an authentication exchange. 374 KDC Key Distribution Center, a network ser- 375 vice that supplies tickets and temporary 376 session keys; or an instance of that 377 service or the host on which it runs. 378 The KDC services both initial ticket and 379 ticket-granting ticket requests. The 380 initial ticket portion is sometimes 381 referred to as the Authentication Server 382 (or service). The ticket-granting 383 ticket portion is sometimes referred to 384 as the ticket-granting server (or ser- 385 vice). 387 Kerberos Aside from the 3-headed dog guarding 388 Hades, the name given to Project 389 Athena's authentication service, the 390 protocol used by that service, or the 391 code used to implement the authentica- 392 tion service. 394 Section 1.3. - 7 - Expires 28 February 1993 396 Version 5 - Revision 5.1 398 Plaintext The input to an encryption function or 399 the output of a decryption function. 400 Decryption transforms ciphertext into 401 plaintext. 403 Principal A uniquely named client or server 404 instance that participates in a network 405 communication. 407 Principal identifierThe name used to uniquely identify each 408 different principal. 410 Seal To encipher a record containing several 411 fields in such a way that the fields 412 cannot be individually replaced without 413 either knowledge of the encryption key 414 or leaving evidence of tampering. 416 Secret key An encryption key shared by a principal 417 and the KDC, distributed outside the 418 bounds of the system, with a long life- 419 time. In the case of a human user's 420 principal, the secret key is derived 421 from a password. 423 Server A particular Principal which provides a 424 resource to network clients. 426 Service A resource provided to network clients; 427 often provided by more than one server 428 (for example, remote file service). 430 Session key A temporary encryption key used between 431 two principals, with a lifetime limited 432 to the duration of a single login "ses- 433 sion". 435 Sub-session key A temporary encryption key used between 436 two principals, selected and exchanged 437 by the principals using the session key, 438 and with a lifetime limited to the dura- 439 tion of a single association. 441 Ticket A record that helps a client authenti- 442 cate itself to a server; it contains the 444 Section 1.3. - 8 - Expires 28 February 1993 446 Version 5 - Revision 5.1 448 client's identity, a session key, a 449 timestamp, and other information, all 450 sealed using the server's secret key. 451 It only serves to authenticate a client 452 when presented along with a fresh 453 Authenticator. 455 _2. _T_i_c_k_e_t _f_l_a_g _u_s_e_s _a_n_d _r_e_q_u_e_s_t_s 457 Each Kerberos ticket contains a set of flags which are used 458 to indicate various attributes of that ticket. Most flags 459 may be requested by a client when the ticket is obtained; 460 some are automatically turned on and off by a Kerberos 461 server as required. The following sections explain what the 462 various flags mean, and gives examples of reasons to use 463 such a flag. 465 _2._1. _I_n_i_t_i_a_l _a_n_d _p_r_e-_a_u_t_h_e_n_t_i_c_a_t_e_d _t_i_c_k_e_t_s 467 The INITIAL flag indicates that a ticket was issued 468 using the AS protocol and not issued based on a ticket- 469 granting ticket. Application servers that want to require 470 the knowledge of a client's secret key (e.g. a password- 471 changing program) can insist that this flag be set in any 472 tickets they accept, and thus be assured that the client's 473 key was recently presented to the application client. 475 The PRE-AUTHENT and HW-AUTHENT flags provide addition 476 information about the initial authentication, regardless of 477 whether the current ticket was issued directly (in which 478 case INITIAL will also be set) or issued on the basis of a 479 ticket-granting ticket (in which case the INITIAL flag is 480 clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried 481 forward from the ticket-granting ticket). 483 _2._2. _I_n_v_a_l_i_d _t_i_c_k_e_t_s 485 The INVALID flag indicates that a ticket is invalid. 486 Application servers must reject tickets which have this flag 487 set. A postdated ticket will usually be issued in this 488 form. Invalid tickets must be validated by the KDC before 489 use, by presenting them to the KDC in a TGS request with the 490 VALIDATE option specified. The KDC will only validate tick- 491 ets after their starttime has passed. The validation is 492 required so that postdated tickets which have been stolen 493 before their starttime can be rendered permanently invalid 494 (through a hot-list mechanism). 496 _2._3. _R_e_n_e_w_a_b_l_e _t_i_c_k_e_t_s 498 Applications may desire to hold tickets which can be 499 valid for long periods of time. However, this can expose 500 their credentials to potential theft for equally long 501 periods, and those stolen credentials would be valid until 503 Section 2.3. - 9 - Expires 28 February 1993 505 Version 5 - Revision 5.1 507 the expiration time of the ticket(s). Simply using short- 508 lived tickets and obtaining new ones periodically would 509 require the client to have long-term access to its secret 510 key, an even greater risk. Renewable tickets can be used to 511 mitigate the consequences of theft. Renewable tickets have 512 two "expiration times": the first is when the current 513 instance of the ticket expires, and the second is the latest 514 permissible value for an individual expiration time. An 515 application client must periodically (i.e. before it 516 expires) present a renewable ticket to the KDC, with the 517 RENEW option set in the KDC request. The KDC will issue a 518 new ticket with a new session key and a later expiration 519 time. All other fields of the ticket are left unmodified by 520 the renewal process. When the latest permissible expiration 521 time arrives, the ticket expires permanently. At each 522 renewal, the KDC may consult a hot-list to determine if the 523 ticket had been reported stolen since its last renewal; it 524 will refuse to renew such stolen tickets, and thus the 525 usable lifetime of stolen tickets is reduced. 527 The RENEWABLE flag in a ticket is normally only inter- 528 preted by the ticket-granting service (discussed below in 529 section 3.3). It can usually be ignored by application 530 servers. However, some particularly careful application 531 servers may wish to disallow renewable tickets. 533 If a renewable ticket is not renewed by its expiration 534 time, the KDC will not renew the ticket. The RENEWABLE flag 535 is reset by default, but a client may request it be set by 536 setting the RENEWABLE option in the KRB_AS_REQ message. If 537 it is set, then the renew-till field in the ticket contains 538 the time after which the ticket may not be renewed. 540 _2._4. _P_o_s_t_d_a_t_e_d _t_i_c_k_e_t_s 542 Applications may occasionally need to obtain tickets 543 for use much later, e.g. a batch submission system would 544 need tickets to be valid at the time the batch job is ser- 545 viced. However, it is dangerous to hold valid tickets in a 546 batch queue, since they will be on-line longer and more 547 prone to theft. Postdated tickets provide a way to obtain 548 these tickets from the KDC at job submission time, but to 549 leave them "dormant" until they are activated and validated 550 by a further request of the KDC. If a ticket theft were 551 reported in the interim, the KDC would refuse to validate 552 the ticket, and the thief would be foiled. 554 The MAY-POSTDATE flag in a ticket is normally only 555 interpreted by the ticket-granting service. It can be 556 ignored by application servers. This flag must be set in a 557 ticket-granting ticket in order to issue a postdated ticket 558 based on the presented ticket. It is reset by default; it 559 may be requested by a client by setting the ALLOW-POSTDATE 560 option in the KRB_AS_REQ message. This flag does not allow 562 Section 2.4. - 10 - Expires 28 February 1993 564 Version 5 - Revision 5.1 566 a client to obtain a postdated ticket-granting ticket; post- 567 dated ticket-granting tickets can only by obtained by 568 requesting the postdating in the KRB_AS_REQ message. The 569 life (endtime-starttime) of a postdated ticket will be the 570 remaining life of the ticket-granting ticket at the time of 571 the request, unless the RENEWABLE option is also set, in 572 which case it can be the full life (endtime-starttime) of 573 the ticket-granting ticket. The KDC may limit how far in 574 the future a ticket may be postdated. 576 The POSTDATED flag indicates that a ticket has been 577 postdated. The application server can check the authtime 578 field in the ticket to see when the original authentication 579 occurred. Some services may choose to reject postdated 580 tickets, or they may only accept them within a certain 581 period after the original authentication. When the KDC 582 issues a POSTDATED ticket, it will also be marked as 583 INVALID, so that the application client must present the 584 ticket to the KDC to be validated before use. 586 _2._5. _P_r_o_x_i_a_b_l_e _a_n_d _p_r_o_x_y _t_i_c_k_e_t_s 588 At times it may be necessary for a principal to allow a 589 service to perform an operation on its behalf. The service 590 must be able to take on the identity of the client, but only 591 for a particular purpose. A principal can allow a service 592 to take on the principal's identity for a particular purpose 593 by granting it a proxy. 595 The PROXIABLE flag in a ticket is normally only inter- 596 preted by the ticket-granting service. It can be ignored by 597 application servers. When set, this flag tells the ticket- 598 granting server that it is OK to issue a new ticket (but not 599 a ticket-granting ticket) with a different network address 600 based on this ticket. This flag is set by default. 602 This flag allows a client to pass a proxy to a server 603 to perform a remote request on its behalf, e.g. a print ser- 604 vice client can give the print server a proxy to access the 605 client's files on a particular file server in order to 606 satisfy a print request. 608 In order to complicate the use of stolen credentials, 609 Kerberos tickets are usually valid from only those network 610 addresses specifically included in the ticket[4]. For this 611 reason, a client wishing to grant a proxy must request a new 612 ticket valid for the network address of the service to be 613 granted the proxy. 614 9__________________________ 615 9[4] It is permissible to request or issue tickets with 616 no network addresses specified, but we do not recommend 617 it. 619 Section 2.5. - 11 - Expires 28 February 1993 621 Version 5 - Revision 5.1 623 The PROXY flag is set in a ticket by the TGS when it 624 issues a proxy ticket. Application servers may check this 625 flag and require additional authentication from the agent 626 presenting the proxy in order to provide an audit trail. 628 _2._6. _F_o_r_w_a_r_d_a_b_l_e _t_i_c_k_e_t_s 630 Authentication forwarding is an instance of the proxy 631 case where the service is granted complete use of the 632 client's identity. An example where it might be used is 633 when a user logs in to a remote system and wants authentica- 634 tion to work from that system as if the login were local. 636 The FORWARDABLE flag in a ticket is normally only 637 interpreted by the ticket-granting service. It can be 638 ignored by application servers. The FORWARDABLE flag has an 639 interpretation similar to that of the PROXIABLE flag, except 640 ticket-granting tickets may also be issued with different 641 network addresses. This flag is reset by default, but users 642 may request that it be set by setting the FORWARDABLE option 643 in the AS request when they request their initial ticket- 644 granting ticket. 646 This flag allows for authentication forwarding without 647 requiring the user to enter a password again. If the flag 648 is not set, then authentication forwarding is not permitted, 649 but the same end result can still be achieved if the user 650 engages in the AS exchange with the requested network 651 addresses and supplies a password. 653 The FORWARDED flag is set by the TGS when a client 654 presents a ticket with the FORWARDABLE flag set and requests 655 it be set by specifying the FORWARDED KDC option and supply- 656 ing a set of addresses for the new ticket. It is also set 657 in all tickets issued based on tickets with the FORWARDED 658 flag set. Application servers may wish to process FORWARDED 659 tickets differently than non-FORWARDED tickets. 661 _2._7. _O_t_h_e_r _K_D_C _o_p_t_i_o_n_s 663 There are two additional options which may be set in a 664 client's request of the KDC. 666 The RENEWABLE-OK option indicates that the client will 667 accept a renewable ticket if a ticket with the requested 668 life cannot otherwise be provided. If a ticket with the 669 requested life cannot be provided, then the KDC may issue a 670 renewable ticket with a renew-till equal to the the 671 requested endtime. The value of the renew-till field may 672 still be adjusted by site-determined limits or limits 673 imposed by the individual principal or server. 675 The ENC-TKT-IN-SKEY option is honored only by the 676 ticket-granting service. It indicates that the to-be-issued 678 Section 2.7. - 12 - Expires 28 February 1993 680 Version 5 - Revision 5.1 682 ticket for the end server is to be encrypted in the session 683 key from the additional ticket-granting ticket provided with 684 the request. See section 3.3.3 for specific details. 686 _3. _M_e_s_s_a_g_e _E_x_c_h_a_n_g_e_s 688 The following sections describe the interactions between 689 network clients and servers and the messages involved in 690 those exchanges. 692 _3._1. _T_h_e _A_u_t_h_e_n_t_i_c_a_t_i_o_n _S_e_r_v_i_c_e _E_x_c_h_a_n_g_e 694 Summary 695 _M_e_s_s_a_g_e _d_i_r_e_c_t_i_o_n _M_e_s_s_a_g_e _t_y_p_e _S_e_c_t_i_o_n 696 1. Client to Kerberos KRB_AS_REQ 5.4.1 697 2. Kerberos to client KRB_AS_REP or 5.4.2 698 KRB_ERROR 5.8.1 700 The Authentication Service (AS) Exchange between the 701 client and the Kerberos Authentication Server is usually in- 702 itiated by a client when it wishes to obtain authentication 703 credentials for a given server but currently holds no 704 credentials. The client's secret key is used for encryption 705 and decryption. This exchange is typically used at the ini- 706 tiation of a login session, to obtain credentials for a 707 Ticket-Granting Server, which will subsequently be used to 708 obtain credentials for other servers (see section 3.3) 709 without requiring further use of the client's secret key. 710 This exchange is also used to request credentials for ser- 711 vices which must not be mediated through the Ticket-Granting 712 Service, but rather require a principal's secret key, such 713 as the password-changing service[5]. 715 The exchange consists of two messages: KRB_AS_REQ from 716 the client to Kerberos, and KRB_AS_REP or KRB_ERROR in 717 reply. The formats for these messages are described in sec- 718 tions 5.4.1, 5.4.2, and 5.8.1. 720 In the request, the client sends (in cleartext) its own 721 identity and the identity of the server for which it is 722 requesting credentials. The response, KRB_AS_REP, contains 723 a ticket for the client to present to the server, and a ses- 724 sion key that will be shared by the client and the server. 725 The session key and additional information are encrypted in 726 the client's secret key. The KRB_AS_REP message contains 727 information which can be used to detect replays, and to 728 __________________________ 729 9[5] The password-changing request must not be honored 730 unless the requester can provide the old password (the 731 user's current secret key). Otherwise, it would be 732 possible for someone to walk up to an unattended ses- 733 sion and change another user's password. 734 9 736 Section 3.1. - 13 - Expires 28 February 1993 738 Version 5 - Revision 5.1 740 associate it with the message to which it replies. Various 741 errors can occur; these are indicated by an error response 742 (KRB_ERROR) instead of the KRB_AS_REP response. The error 743 message is not encrypted. The KRB_ERROR message also con- 744 tains information which can be used to associate it with the 745 message to which it replies. The lack of encryption in the 746 KRB_ERROR message precludes the ability to detect replays or 747 fabrications of such messages. 749 In the normal case the authentication server does not 750 know whether the client is actually the principal named in 751 the request. It simply sends a reply without knowing or 752 caring whether they are the same. This is acceptable 753 because nobody but the principal whose identity was given in 754 the request will be able to use the reply. Its critical 755 information is encrypted in that principal's key. The ini- 756 tial request supports an optional field that can be used to 757 pass additional information that might be needed for the 758 initial exchange. This field may be used for pre- 759 authentication if desired, but the mechanism is not 760 currently specified. 762 _3._1._1. _G_e_n_e_r_a_t_i_o_n _o_f _K_R_B__A_S__R_E_Q _m_e_s_s_a_g_e 764 The client may specify a number of options in the ini- 765 tial request. Among these options are whether the requested 766 ticket is to be renewable, proxiable, or forwardable; 767 whether it should be postdated or allow postdating of 768 derivative tickets; and whether a renewable ticket will be 769 accepted in lieu of a non-renewable ticket if the requested 770 ticket expiration date cannot be satisfied by a non- 771 renewable ticket (due to configuration constraints; see sec- 772 tion 4). See section A.1 for pseudocode. 774 The client prepares the KRB_AS_REQ message and sends it 775 to the KDC. 777 _3._1._2. _R_e_c_e_i_p_t _o_f _K_R_B__A_S__R_E_Q _m_e_s_s_a_g_e 779 If all goes well, processing the KRB_AS_REQ message 780 will result in the creation of a ticket for the client to 781 present to the server. The format for the ticket is 782 described in section 5.3.1. The contents of the ticket are 783 determined as follows. 785 _3._1._3. _G_e_n_e_r_a_t_i_o_n _o_f _K_R_B__A_S__R_E_P _m_e_s_s_a_g_e 787 The authentication server looks up the client and 788 server principals named in the KRB_AS_REQ in its database, 789 extracting their respective keys. If the server cannot 790 accommodate the requested encryption type, an error message 791 with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it 792 generates a "random" session key[6]. 793 __________________________ 795 Section 3.1.3. - 14 - Expires 28 February 1993 797 Version 5 - Revision 5.1 799 If the requested start time is absent or indicates a 800 time in the past, then the start time of the ticket is set 801 to the authentication server's current time. If it indicates 802 a time in the future, but the POSTDATED option has not been 803 specified, then the error KDC_ERR_CANNOT_POSTDATE is 804 returned. Otherwise the requested start time is checked 805 against the policy of the local realm (the administrator 806 might decide to prohibit certain types or ranges of post- 807 dated tickets), and if acceptable, the ticket's start time 808 is set as requested and the INVALID flag is set in the new 809 ticket. The postdated ticket must be validated before use by 810 presenting it to the KDC after the start time has been 811 reached. 813 The expiration time of the ticket will be set to the minimum 814 of the following: 816 o+The expiration time (endtime) requested in the KRB_AS_REQ 817 message. 819 o+The ticket's start time plus the maximum allowable lifetime 820 associated with the client principal (the authentication 821 server's database includes a maximum ticket lifetime field 822 in each principal's record; see section 4). 824 o+The ticket's start time plus the maximum allowable lifetime 825 associated with the server principal. 827 o+The ticket's start time plus the maximum lifetime set by 828 the policy of the local realm. 830 If the requested expiration time minus the start time 831 (as determined above) is less than a site-determined minimum 832 lifetime, an error message with code KDC_ERR_NEVER_VALID is 833 returned. If the requested expiration time for the ticket 834 exceeds what was determined as above, and if the 835 "RENEWABLE-OK" option was requested, then the "RENEWABLE" 836 flag is set in the new ticket, and the renew-till value is 837 set as if the "RENEWABLE" option were requested (the field 838 and option names are described fully in section 5.4.1). 840 __________________________ 841 [6] "Random" means that, among other things, it should 842 be impossible to guess the next session key based on 843 knowledge of past session keys. This can only be 844 achieved in a pseudo-random number generator if it is 845 based on cryptographic principles. It would be more 846 desirable to use a truly random number generator, such 847 as one based on measurements of random physical 848 phenomena. 850 Section 3.1.3. - 15 - Expires 28 February 1993 852 Version 5 - Revision 5.1 854 If the RENEWABLE option has been requested or if the 855 RENEWABLE-OK option has been set and a renewable ticket is 856 to be issued, then the renew-till field is set to the 857 minimum of: 859 o+Its requested value. 861 o+The start time of the ticket plus the minimum of the two 862 maximum renewable lifetimes associated with the principals' 863 database entries. 865 o+The start time of the ticket plus the maximum renewable 866 lifetime set by the policy of the local realm. 868 The flags field of the new ticket will have the follow- 869 ing options set if they have been requested and if the pol- 870 icy of the local realm allows: FORWARDABLE, MAY-POSTDATE, 871 POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is post- 872 dated (the start time is in the future), its INVALID flag 873 will also be set. 875 If all of the above succeed, the server formats a 876 KRB_AS_REP message (see section 5.4.2), copying the 877 addresses in the request into the caddr of the response, 878 placing any required pre-authentication data into the padata 879 of the response, and encrypts the ciphertext part in the 880 client's key using the requested encryption method, and 881 sends it to the client. See section A.2 for pseudocode. 883 _3._1._4. _G_e_n_e_r_a_t_i_o_n _o_f _K_R_B__E_R_R_O_R _m_e_s_s_a_g_e 885 Several errors can occur, and the Authentication Server 886 responds by returning an error message, KRB_ERROR, to the 887 client, with the error-code and e-text fields set to 888 appropriate values. The error message contents and details 889 are described in Section 5.8.1. 891 _3._1._5. _R_e_c_e_i_p_t _o_f _K_R_B__A_S__R_E_P _m_e_s_s_a_g_e 893 If the reply message type is KRB_AS_REP, then the 894 client verifies that the cname and crealm fields in the 895 cleartext portion of the reply match what it requested. If 896 any padata fields are present, they may be used to derive 897 the proper secret key to decrypt the message. The client 898 decrypts the encrypted part of the response using its secret 899 key, verifies that the nonce in the encrypted part matches 900 the nonce it supplied in its request (to detect replays). 901 It also verifies that the sname and srealm in the response 902 match those in the request, and that the host address field 903 is also correct. It then stores the ticket, session key, 904 start and expiration times, and other information for later 905 use. The key-expiration field from the encrypted part of 906 the response may be checked to notify the user of impending 907 key expiration (the client program could then suggest 909 Section 3.1.5. - 16 - Expires 28 February 1993 911 Version 5 - Revision 5.1 913 remedial action, such as a password change). See section 914 A.3 for pseudocode. 916 Proper decryption of the KRB_AS_REP message is _n_o_t suf- 917 ficient to verify the identity of the user; the user and an 918 attacker could cooperate to generate a KRB_AS_REP format 919 message which decrypts properly but is not from the proper 920 KDC. If the host wishes to verify the identity of the user, 921 it must require the user to present application credentials 922 which can be verified using a securely-stored secret key. 923 If those credentials can be verified, then the identity of 924 the user can be assured. 926 _3._1._6. _R_e_c_e_i_p_t _o_f _K_R_B__E_R_R_O_R _m_e_s_s_a_g_e 928 If the reply message type is KRB_ERROR, then the client 929 interprets it as an error and performs whatever 930 application-specific tasks are necessary to recover. 932 _3._2. _T_h_e _C_l_i_e_n_t/_S_e_r_v_e_r _A_u_t_h_e_n_t_i_c_a_t_i_o_n _E_x_c_h_a_n_g_e 934 Summary 935 _M_e_s_s_a_g_e _d_i_r_e_c_t_i_o_n _M_e_s_s_a_g_e _t_y_p_e _S_e_c_t_i_o_n 936 Client to Application server KRB_AP_REQ 5.5.1 937 [optional] Application server to client KRB_AP_REP or 5.5.2 938 KRB_ERROR 5.8.1 940 The client/server authentication (CS) exchange is used 941 by network applications to authenticate the client to the 942 server and vice versa. The client must have already 943 acquired credentials for the server using the AS or TGS 944 exchange. 946 _3._2._1. _T_h_e _K_R_B__A_P__R_E_Q _m_e_s_s_a_g_e 948 The KRB_AP_REQ contains authentication information 949 which should be part of the first message in an authenti- 950 cated transaction. It contains a ticket, an authenticator, 951 and some additional bookkeeping information (see section 952 5.5.1 for the exact format). The ticket by itself is insuf- 953 ficient to authenticate a client, since tickets are passed 954 across the network in cleartext[7], so the authenticator is 955 used to prevent invalid replay of tickets by proving to the 956 server that the client knows the session key of the ticket 957 and thus is entitled to use it. The KRB_AP_REQ message is 958 referred to elsewhere as the "authentication header." 959 9__________________________ 960 9[7] Tickets contain both an encrypted and unencrypted 961 portion, so cleartext here refers to the entire unit, 962 which can be copied from one message and replayed in 963 another without any cryptographic skill. 965 Section 3.2.1. - 17 - Expires 28 February 1993 967 Version 5 - Revision 5.1 969 _3._2._2. _G_e_n_e_r_a_t_i_o_n _o_f _a _K_R_B__A_P__R_E_Q _m_e_s_s_a_g_e 971 When a client wishes to initiate authentication to a 972 server, it obtains (either through a credentials cache, the 973 AS exchange, or the TGS exchange) a ticket and session key 974 for the desired service. The client may re-use any tickets 975 it holds until they expire. The client then constructs a 976 new Authenticator from the the system time, its name, and 977 optionally an application specific checksum, an initial 978 sequence number to be used in KRB_SAFE or KRB_PRIV messages, 979 and/or a session subkey to be used in negotiations for a 980 session key unique to this particular session. Authentica- 981 tors may not be re-used and will be rejected if replayed to 982 a server[8]. If a sequence number is to be included, it 983 should be randomly chosen so that even after many messages 984 have been exchanged it is not likely to collide with other 985 sequence numbers in use. 987 The client may indicate a requirement of mutual authen- 988 tication or the use of a session-key based ticket by setting 989 the appropriate flag(s) in the ap-options field of the mes- 990 sage. 992 The Authenticator is encrypted in the session key and 993 combined with the ticket to form the KRB_AP_REQ message 994 which is then sent to the end server along with any addi- 995 tional application-specific information. See section A.9 996 for pseudocode. 998 _3._2._3. _R_e_c_e_i_p_t _o_f _K_R_B__A_P__R_E_Q _m_e_s_s_a_g_e 1000 Authentication is based on the server's current time of 1001 day (clocks must be loosely synchronized), the authentica- 1002 tor, and the ticket. Several errors are possible. If an 1003 error occurs, the server is expected to reply to the client 1004 with a KRB_ERROR message. This message may be encapsulated 1005 in the application protocol if its "raw" form is not accept- 1006 able to the protocol. The format of error messages is 1007 described in section 5.8.1. 1009 The algorithm for verifying authentication information 1010 is as follows. If the message type is not KRB_AP_REQ, the 1011 server returns the KRB_AP_ERR_MSG_TYPE error. If the key 1012 version indicated by the Ticket in the KRB_AP_REQ is not one 1013 the server can use (e.g., it indicates an old key, and the 1014 server no longer possesses a copy of the old key), the 1015 KRB_AP_ERR_BADKEYVER error is returned. If the USE- 1016 __________________________ 1017 9[8] Note that this can make applications based on un- 1018 reliable transports difficult to code correctly, if the 1019 transport might deliver duplicated messages. In such 1020 cases, a new authenticator must be generated for each 1021 retry. 1022 9 1024 Section 3.2.3. - 18 - Expires 28 February 1993 1026 Version 5 - Revision 5.1 1028 SESSION-KEY flag is set in the ap-options field, it indi- 1029 cates to the server that the ticket is encrypted in the ses- 1030 sion key from the server's ticket-granting ticket rather 1031 than its secret key[9]. Since it is possible for the server 1032 to be registered in multiple realms, with different keys in 1033 each, the srealm field in the unencrypted portion of the 1034 ticket in the KRB_AP_REQ is used to specify which secret key 1035 the server should use to decrypt that ticket. The 1036 KRB_AP_ERR_NOKEY error code is returned if the server 1037 doesn't have the proper key to decipher the ticket. 1039 The ticket is decrypted using the version of the 1040 server's key specified by the ticket. If the decryption 1041 routines detect a modification of the ticket (each encryp- 1042 tion system must provide safeguards to detect modified 1043 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY 1044 error is returned (chances are good that different keys were 1045 used to encrypt and decrypt). 1047 The authenticator is decrypted using the session key 1048 extracted from the decrypted ticket. If decryption shows it 1049 to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is 1050 returned. The name and realm of the client from the ticket 1051 are compared against the same fields in the authenticator. 1052 If they don't match, the KRB_AP_ERR_BADMATCH error is 1053 returned (they might not match, for example, if the wrong 1054 session key was used to encrypt the authenticator). The 1055 addresses in the ticket (if any) are then searched for an 1056 address matching the operating-system reported address of 1057 the client. If no match is found or the server insists on 1058 ticket addresses but none are present in the ticket, the 1059 KRB_AP_ERR_BADADDR error is returned. 1061 If the local (server) time and the client time in the 1062 authenticator differ by more than the allowable clock skew 1063 (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned. 1064 If the server name, along with the client name, time and 1065 microsecond fields from the Authenticator match any 1066 recently-seen such tuples, the KRB_AP_ERR_REPEAT error is 1067 returned[10]. The server must remember any authenticator 1068 presented within the allowable clock skew, so that a replay 1069 attempt is guaranteed to fail. If a server loses track of 1070 any authenticator presented within the allowable clock skew, 1071 __________________________ 1072 9[9] This is used for user-to-user authentication as 1073 described in [6]. 1074 9[10] Note that the rejection here is restricted to au- 1075 thenticators from the same principal to the same 1076 server. Other client principals communicating with the 1077 same server principal should not be have their authen- 1078 ticators rejected if the time and microsecond fields 1079 happen to match some other client's authenticator. 1081 Section 3.2.3. - 19 - Expires 28 February 1993 1083 Version 5 - Revision 5.1 1085 it must reject all requests until the clock skew interval 1086 has passed. This assures that any lost or re-played authen- 1087 ticators will fall outside the allowable clock skew and can 1088 no longer be successfully replayed (If this is not done, an 1089 attacker could conceivably record the ticket and authentica- 1090 tor sent over the network to a server, then disable the 1091 client's host, pose as the disabled host, and replay the 1092 ticket and authenticator to subvert the authentication.). 1093 If a sequence number is provided in the authenticator, the 1094 server saves it for later use in processing KRB_SAFE and/or 1095 KRB_PRIV messages. If a subkey is present, the server 1096 either saves it for later use or uses it to help generate 1097 its own choice for a subkey to be returned in a KRB_AP_REP 1098 message. 1100 The server computes the age of the ticket: local 1101 (server) time minus the start time inside the Ticket. If 1102 the start time is later than the current time by more than 1103 the allowable clock skew or if the INVALID flag is set in 1104 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Oth- 1105 erwise, if the current time is later than end time by more 1106 than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED 1107 error is returned. 1109 If all these checks succeed without an error, the 1110 server is assured that the client possesses the credentials 1111 of the principal named in the ticket and thus, the client 1112 has been authenticated to the server. See section A.10 for 1113 pseudocode. 1115 _3._2._4. _G_e_n_e_r_a_t_i_o_n _o_f _a _K_R_B__A_P__R_E_P _m_e_s_s_a_g_e 1117 Typically, a client's request will include both the 1118 authentication information and its initial request in the 1119 same message, and the server need not explicitly reply to 1120 the KRB_AP_REQ. However, if mutual authentication (not only 1121 authenticating the client to the server, but also the server 1122 to the client) is being performed, the KRB_AP_REQ message 1123 will have MUTUAL-REQUIRED set in its ap-options field, and a 1124 KRB_AP_REP message is required in response. As with the 1125 error message, this message may be encapsulated in the 1126 application protocol if its "raw" form is not acceptable to 1127 the application's protocol. The timestamp and microsecond 1128 field used in the reply must be the client's timestamp and 1129 microsecond field (as provided in the authenticator)[11]. 1130 __________________________ 1131 9[11] In the Kerberos version 4 protocol, the timestamp 1132 in the reply was the client's timestamp plus one. This 1133 is not necessary in version 5 because version 5 mes- 1134 sages are formatted in such a way that it is not possi- 1135 ble to create the reply by judicious message surgery 1136 (even in encrypted form) without knowledge of the ap- 1137 propriate encryption keys. 1138 9 1140 Section 3.2.4. - 20 - Expires 28 February 1993 1142 Version 5 - Revision 5.1 1144 If a sequence number is to be included, it should be ran- 1145 domly chosen as described above for the authenticator. A 1146 subkey may be included if the server desires to negotiate a 1147 different subkey. The KRB_AP_REP message is encrypted in 1148 the session key extracted from the ticket. See section A.11 1149 for pseudocode. 1151 _3._2._5. _R_e_c_e_i_p_t _o_f _K_R_B__A_P__R_E_P _m_e_s_s_a_g_e 1153 If a KRB_AP_REP message is returned, the client uses 1154 the session key from the credentials obtained for the 1155 server[12] to decrypt the message, and verifies that the 1156 timestamp and microsecond fields match those in the Authen- 1157 ticator it sent to the server. If they match, then the 1158 client is assured that the server is genuine. The sequence 1159 number and subkey (if present) are retained for later use. 1160 See section A.12 for pseudocode. 1162 _3._2._6. _U_s_i_n_g _t_h_e _e_n_c_r_y_p_t_i_o_n _k_e_y 1164 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, 1165 the client and server share an encryption key which can be 1166 used by the application. The "true session key" to be used 1167 for KRB_PRIV, KRB_SAFE, or other application-specific uses 1168 may be chosen by the application based on the subkeys in the 1169 KRB_AP_REP message and the authenticator[13]. In some 1170 cases, the use of this session key will be implicit in the 1171 protocol; in others the method of use must be chosen from a 1172 several alternatives. We leave the protocol negotiations of 1173 how to use the key (e.g. selecting an encryption or check- 1174 sum type) to the application programmer; the Kerberos proto- 1175 col does not constrain the implementation options. 1177 With both the one-way and mutual authentication 1178 exchanges, the peers should take care not to send sensitive 1179 information to each other without proper assurances. In 1180 particular, applications that require privacy or integrity 1181 should use the KRB_AP_REP or KRB_ERROR responses from the 1182 server to client to assure both client and server of their 1183 peer's identity. If an application protocol requires 1184 privacy of its messages, it can use the KRB_PRIV message 1185 (section 3.5). The KRB_SAFE message (section 3.4) can be 1186 __________________________ 1187 9[12] Note that for encrypting the KRB_AP_REP message, 1188 the sub-session key is not used, even if present in the 1189 Authenticator. 1190 9[13] Implementations of the protocol may wish to pro- 1191 vide routines to choose subkeys based on session keys 1192 and random numbers and to orchestrate a negotiated key 1193 to be returned in the KRB_AP_REP message. 1195 Section 3.2.6. - 21 - Expires 28 February 1993 1197 Version 5 - Revision 5.1 1199 used to assure integrity. 1201 _3._3. _T_h_e _T_i_c_k_e_t-_G_r_a_n_t_i_n_g _S_e_r_v_i_c_e (_T_G_S) _E_x_c_h_a_n_g_e 1203 Summary 1204 _M_e_s_s_a_g_e _d_i_r_e_c_t_i_o_n _M_e_s_s_a_g_e _t_y_p_e _S_e_c_t_i_o_n 1205 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1206 2. Kerberos to client KRB_TGS_REP or 5.4.2 1207 KRB_ERROR 5.8.1 1209 The TGS exchange between a client and the Kerberos 1210 Ticket-Granting Server is initiated by a client when it 1211 wishes to obtain authentication credentials for a given 1212 server (which might be registered in a remote realm), when 1213 it wishes to renew or validate an existing ticket, or when 1214 it wishes to obtain a proxy ticket. In the first case, the 1215 client must already have acquired a ticket for the Ticket- 1216 Granting Service using the AS exchange (the ticket-granting 1217 ticket is usually obtained when a client initially authenti- 1218 cates to the system, such as when a user logs in). The mes- 1219 sage format for the TGS exchange is almost identical to that 1220 for the AS exchange. The primary difference is that encryp- 1221 tion and decryption in the TGS exchange does not take place 1222 under the client's key. Instead, the session key from the 1223 ticket-granting ticket or renewable ticket, or sub-session 1224 key from an Authenticator is used. As is the case for all 1225 application servers, expired tickets are not accepted by the 1226 TGS, so once a renewable or ticket-granting ticket expires, 1227 the client must use a separate exchange to obtain valid 1228 tickets. 1230 The TGS exchange consists of two messages: A request 1231 (KRB_TGS_REQ) from the client to the Kerberos Ticket- 1232 Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR). 1233 The KRB_TGS_REQ message includes information authenticating 1234 the client plus a request for credentials. The authentica- 1235 tion information consists of the authentication header 1236 (KRB_AP_REQ) which includes the client's previously obtained 1237 ticket-granting, renewable, or invalid ticket. In the 1238 ticket-granting ticket and proxy cases, the request may 1239 include one or more of: a list of network addresses, a col- 1240 lection of typed authorization data to be sealed in the 1241 ticket for authorization use by the application server, or 1242 additional tickets (the use of which are described later). 1243 The TGS reply (KRB_TGS_REP) contains the requested creden- 1244 tials, encrypted in the session key from the ticket-granting 1245 ticket or renewable ticket, or if present, in the sub- 1246 session key from the Authenticator (part of the authentica- 1247 tion header). The KRB_ERROR message contains an error code 1248 and text explaining what went wrong. The KRB_ERROR message 1249 is not encrypted. The KRB_TGS_REP message contains informa- 1250 tion which can be used to detect replays, and to associate 1252 Section 3.3. - 22 - Expires 28 February 1993 1254 Version 5 - Revision 5.1 1256 it with the message to which it replies. The KRB_ERROR mes- 1257 sage also contains information which can be used to associ- 1258 ate it with the message to which it replies, but the lack of 1259 encryption in the KRB_ERROR message precludes the ability to 1260 detect replays or fabrications of such messages. 1262 _3._3._1. _G_e_n_e_r_a_t_i_o_n _o_f _K_R_B__T_G_S__R_E_Q _m_e_s_s_a_g_e 1264 Before sending a request to the ticket-granting ser- 1265 vice, the client must determine in which realm the applica- 1266 tion server is registered[14]. If the client does not 1267 already possess a ticket-granting ticket for the appropriate 1268 realm, then one must be obtained. This is first attempted 1269 by requesting a ticket-granting ticket for the destination 1270 realm from the local Kerberos server (using the KRB_TGS_REQ 1271 message recursively). The Kerberos server may return a TGT 1272 for the desired realm in which case one can proceed. Alter- 1273 natively, the Kerberos server may return a TGT for a realm 1274 which is "closer" to the desired realm (further along the 1275 standard hierarchical path), in which case this step must be 1276 repeated with a Kerberos server in the realm specified in 1277 the returned TGT. If neither are returned, then the request 1278 must be retried with a Kerberos server for a realm higher in 1279 the hierarchy. This request will itself require a ticket- 1280 granting ticket for the higher realm which must be obtained 1281 by recursively applying these directions. 1283 Once the client obtains a ticket-granting ticket for 1284 the appropriate realm, it determines which Kerberos servers 1285 serve that realm, and contacts one. The list might be 1286 obtained through a configuration file or network service; as 1287 long as the secret keys exchanged by realms are kept secret, 1288 only denial of service results from a false Kerberos server. 1290 As in the AS exchange, the client may specify a number 1291 of options in the KRB_TGS_REQ message. The client prepares 1292 the KRB_TGS_REQ message, providing an authentication header 1293 as an element of the padata field, and including the same 1294 fields as used in the KRB_AS_REQ message along with several 1295 optional fields: the enc-authorization-data field for 1296 __________________________ 1297 9[14] This can be accomplished in several ways. It 1298 might be known beforehand (since the realm is part of 1299 the principal identifier), or it might be stored in a 1300 nameserver. Presently, however, this information is 1301 obtained from a configuration file. If the realm to be 1302 used is obtained from a nameserver, there is a danger 1303 of being spoofed if the nameservice providing the realm 1304 name is not authenticated. This might result in the 1305 use of a realm which has been compromised, and would 1306 result in an attacker's ability to compromise the au- 1307 thentication of the application server to the client. 1308 9 1310 Section 3.3.1. - 23 - Expires 28 February 1993 1312 Version 5 - Revision 5.1 1314 application server use and additional tickets required by 1315 some options. 1317 In preparing the authentication header, the client can 1318 select a sub-session key under which the response from the 1319 Kerberos server will be encrypted[15]. If the sub-session 1320 key is not specified, the session key from the ticket- 1321 granting ticket will be used. If the enc-authorization-data 1322 is present, it must be encrypted in the sub-session key, if 1323 present, from the authenticator portion of the authentica- 1324 tion header, or if not present in the session key from the 1325 ticket-granting ticket. 1327 Once prepared, the message is sent to a Kerberos server 1328 for the destination realm. See section A.5 for pseudocode. 1330 _3._3._2. _R_e_c_e_i_p_t _o_f _K_R_B__T_G_S__R_E_Q _m_e_s_s_a_g_e 1332 The KRB_TGS_REQ message is processed in a manner simi- 1333 lar to the KRB_AS_REQ message, but there are many additional 1334 checks to be performed. First, the Kerberos server must 1335 determine which server the accompanying ticket is for and it 1336 must select the appropriate key to decrypt it. For a normal 1337 KRB_TGS_REQ message, it will be for the ticket granting ser- 1338 vice, and the TGS's key will be used. If the TGT was issued 1339 by another realm, then the appropriate inter-realm key must 1340 be used. If the accompanying ticket is not a ticket grant- 1341 ing ticket for the current realm, but is for an application 1342 server in the current realm, the RENEW, VALIDATE, or PROXY 1343 options are specified in the request, and the server for 1344 which a ticket is requested is the server named in the 1345 accompanying ticket, then the KDC will decrypt the ticket in 1346 the authentication header using the key of the server for 1347 which it was issued. If no ticket can be found in the 1348 padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is 1349 returned. 1351 Once the accompanying ticket has been decrypted, the 1352 user-supplied checksum in the Authenticator must be verified 1353 against the contents of the request, and the message 1354 rejected if the checksums do not match (with an error code 1355 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or 1356 not collision-proof (with an error code of 1357 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not sup- 1358 ported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If 1359 the authorization-data are present, they are decrypted using 1360 the sub-session key from the Authenticator. 1361 __________________________ 1362 9[15] If the client selects a sub-session key, care must 1363 be taken to ensure the randomness of the selected sub- 1364 session key. One approach would be to generate a ran- 1365 dom number and XOR it with the session key from the 1366 ticket-granting ticket. 1367 9 1369 Section 3.3.2. - 24 - Expires 28 February 1993 1371 Version 5 - Revision 5.1 1373 If any of the decryptions indicate failed integrity 1374 checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned. 1376 _3._3._3. _G_e_n_e_r_a_t_i_o_n _o_f _K_R_B__T_G_S__R_E_P _m_e_s_s_a_g_e 1378 The KRB_TGS_REP message shares its format with the 1379 KRB_AS_REP (KRB_KDC_REP), but with its type field set to 1380 KRB_TGS_REP. The detailed specification is in section 1381 5.4.2. 1383 The response will include a ticket for the requested 1384 server. The Kerberos database is queried to retrieve the 1385 record for the requested server (including the key with 1386 which the ticket will be encrypted). If the request is for 1387 a ticket granting ticket for a remote realm, and if no key 1388 is shared with the requested realm, then the Kerberos server 1389 will select the realm "closest" to the requested realm with 1390 which it does share a key, and use that realm instead. This 1391 is the only case where the response from the KDC will be for 1392 a different server than that requested by the client. 1394 By default, the address field, the client's name and 1395 realm, the list of transited realms, the time of initial 1396 authentication, the expiration time, and the authorization 1397 data of the newly-issued ticket will be copied from the 1398 ticket-granting ticket (TGT) or renewable ticket. If the 1399 transited field needs to be updated, but the transited type 1400 is not supported, the KDC_ERR_TRTYPE_NOSUPP error is 1401 returned. 1403 If the request specifies an endtime, then the endtime 1404 of the new ticket is set to the minimum of (a) that request, 1405 (b) the endtime from the TGT, and (c) the starttime of the 1406 TGT plus the minimum of the maximum life for the application 1407 server and the maximum life for the local realm (the maximum 1408 life for the requesting principal was already applied when 1409 the TGT was issued). If the new ticket is to be a renewal, 1410 then the endtime above is replaced by the minimum of (a) the 1411 value of the renew_till field of the ticket and (b) the 1412 starttime for the new ticket plus the life (endtime- 1413 starttime) of the old ticket. 1415 If the FORWARDED option has been requested, then the 1416 resulting ticket will contain the addresses specified by the 1417 client. This option will only be honored if the FORWARDABLE 1418 flag is set in the TGT. The PROXY option is similar; the 1419 resulting ticket will contain the addresses specified by the 1420 client. It will be honored only if the PROXIABLE flag in 1421 the TGT is set. The PROXY option will not be honored on 1422 requests for additional ticket-granting tickets. 1424 If the requested start time is absent or indicates a 1425 time in the past, then the start time of the ticket is set 1426 to the authentication server's current time. If it 1428 Section 3.3.3. - 25 - Expires 28 February 1993 1430 Version 5 - Revision 5.1 1432 indicates a time in the future, but the POSTDATED option has 1433 not been specified or the MAY-POSTDATE flag is not set in 1434 the TGT, then the error KDC_ERR_CANNOT_POSTDATE is returned. 1435 Otherwise, if the ticket-granting ticket has the MAY- 1436 POSTDATE flag set, then the resulting ticket will be post- 1437 dated and the requested starttime is checked against the 1438 policy of the local realm. If acceptable, the ticket's start 1439 time is set as requested, and the INVALID flag is set. The 1440 postdated ticket must be validated before use by presenting 1441 it to the KDC after the starttime has been reached. How- 1442 ever, in no case may the starttime, endtime, or renew-till 1443 time of a newly-issued postdated ticket extend beyond the 1444 renew-till time of the ticket-granting ticket. 1446 If the ENC-TKT-IN-SKEY option has been specified, and 1447 if an additional ticket has been included in the request, 1448 then the KDC will verify that the principal identifier of 1449 the server in the ticket matches the requested server in the 1450 KDC request (to make sure someone doesn't insert a different 1451 ticket in the request), decrypt the additional ticket using 1452 the key for the server to which it was issued, verify that 1453 it is a ticket-granting ticket, and use the session key from 1454 the additional ticket to encrypt the new ticket it will 1455 issue instead of encrypting the new ticket in the key of the 1456 server for which it is to be issued[16]. 1458 If the name of the server in the ticket that is 1459 presented to the KDC as part of the authentication header is 1460 not that of the ticket-granting server itself, and the 1461 server is registered in the realm of the KDC, If the RENEW 1462 option is requested, then the KDC will verify that the 1463 RENEWABLE flag is set in the ticket and that the renew_till 1464 time is still in the future. If the VALIDATE option is 1465 rqeuested, the KDC will check that the starttime has passed 1466 and the INVALID flag is set. If the PROXY option is 1467 requested, then the KDC will check that the PROXIABLE flag 1468 is set in the ticket. If the tests succeed, the KDC will 1469 issue the appropriate new ticket. 1471 Whenever a request is made to the ticket-granting 1472 server, the presented ticket(s) is(are) checked against a 1473 hot-list of tickets which have been canceled. This hot-list 1474 might be implemented by storing a range of issue dates for 1475 "suspect tickets"; if a presented ticket had an authtime in 1476 that range, it would be rejected. In this way, a stolen 1477 ticket-granting ticket or renewable ticket cannot be used to 1478 gain additional tickets (renewals or otherwise) once the 1479 __________________________ 1480 9[16] This allows easy implementation of user-to-user 1481 authentication [6], which uses ticket-granting ticket 1482 session keys in lieu of secret server keys in situa- 1483 tions where such secret keys could be easily comprom- 1484 ised. 1485 9 1487 Section 3.3.3. - 26 - Expires 28 February 1993 1489 Version 5 - Revision 5.1 1491 theft has been reported. Any normal ticket obtained before 1492 it was reported stolen will still be valid (because they 1493 require no interaction with the KDC), but only until their 1494 normal expiration time. 1496 The ciphertext part of the response in the KRB_TGS_REP 1497 message is encrypted in the sub-session key from the Authen- 1498 ticator, if present, or the session key key from the 1499 ticket-granting ticket. It is not encrypted using the 1500 client's secret key. Furthermore, the client's key's 1501 expiration date and the key version number fields are left 1502 out since these values are stored along with the client's 1503 database record, and that record is not needed to satisfy a 1504 request based on a ticket-granting ticket. See section A.6 1505 for pseudocode. 1507 _3._3._3._1. _E_n_c_o_d_i_n_g _t_h_e _t_r_a_n_s_i_t_e_d _f_i_e_l_d 1509 If the identity of the server in the TGT that is 1510 presented to the KDC as part of the authentication header is 1511 that of the ticket-granting service, but the TGT was issued 1512 from another realm, the KDC will look up the inter-realm key 1513 shared with that realm and use that key to decrypt the 1514 ticket. If the ticket is valid, then the KDC will honor the 1515 request, subject to the constraints outlined above in the 1516 section describing the AS exchange. The realm part of the 1517 client's identity will be taken from the ticket-granting 1518 ticket. The name of the realm that issued the ticket- 1519 granting ticket will be added to the transited field of the 1520 ticket to be issued. This is accomplished by reading the 1521 transited field from the ticket-granting ticket, adding the 1522 new realm, then constructing and writing out its encoded 1523 (shorthand) form (this may involve a rearrangement of the 1524 existing encoding). 1526 Note that the ticket-granting service does not add the 1527 name of its own realm. Instead, its responsibility is to 1528 add the name of the previous realm. This prevents a mali- 1529 cious Kerberos server from intentionally leaving out its own 1530 name (it could, however, omit other realms' names). 1532 The names of neither the local realm nor the 1533 principal's realm are to be included in the transited field. 1534 They appear elsewhere in the ticket and both are known to 1535 have taken part in authenticating the principal. Since the 1536 endpoints are not included, both local and single-hop 1537 inter-realm authentication result in a transited field that 1538 is empty. 1540 Because the name of each realm transited is added to 1541 this field, it might potentially be very long. To decrease 1542 the length of this field, its contents are encoded. The 1543 initially supported encoding is optimized for the normal 1544 case of inter-realm communication: a hierarchical 1546 Section 3.3.3.1. - 27 - Expires 28 February 1993 1548 Version 5 - Revision 5.1 1550 arrangement of realms using either domain or X.500 style 1551 realm names. This encoding (called DOMAIN-X500-COMPRESS) is 1552 now described. 1554 Realm names in the transited field are separated by a 1555 ",". The ",", "\", trailing "."s, and leading spaces (" ") 1556 are special characters, and if they are part of a realm 1557 name, they must be quoted in the transited field by preced- 1558 ing them with a "\". 1560 A realm name ending with a "." is interpreted as being 1561 prepended to the previous realm. For example, we can encode 1562 traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, 1563 and CS.WASHINGTON.EDU as: 1565 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1567 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end- 1568 points, that they would not be included in this field, and 1569 we would have: 1571 "EDU,MIT.,WASHINGTON.EDU" 1573 A realm name beginning with a "/" is interpreted as being 1574 appended to the previous realm[17]. If it is to stand by 1575 itself, then it should be preceded by a space (" "). For 1576 example, we can encode traversal of /COM/HP/APOLLO, /COM/HP, 1577 /COM, and /COM/DEC as: 1579 "/COM,/HP,/APOLLO, /COM/DEC". 1581 Like the example above, if /COM/HP/APOLLO and /COM/DEC are 1582 endpoints, they they would not be included in this field, 1583 and we would have: 1585 "/COM,/HP" 1587 A null subfield preceding or following a "," indicates 1588 that all realms between the previous realm and the next 1589 realm have been traversed[18]. Thus, "," means that all 1590 realms along the path between the client and the server have 1591 been traversed. ",EDU, /COM," means that that all realms 1592 from the client's realm up to EDU (in a domain style 1593 __________________________ 1594 9[17] For the purpose of appending, the realm preceding 1595 the first listed realm is considered to be the null 1596 realm (""). 1597 9[18] For the purpose of interpreting null subfields, 1598 the client's realm is considered to precede those in 1599 the transited field, and the server's realm is con- 1600 sidered to follow them. 1602 Section 3.3.3.1. - 28 - Expires 28 February 1993 1604 Version 5 - Revision 5.1 1606 hierarchy) have been traversed, and that everything from 1607 /COM down to the server's realm in an X.500 style has also 1608 been traversed. This could occur if the EDU realm in one 1609 hierarchy shares an inter-realm key directly with the /COM 1610 realm in another hierarchy. 1612 _3._3._4. _R_e_c_e_i_p_t _o_f _K_R_B__T_G_S__R_E_P _m_e_s_s_a_g_e 1614 When the KRB_TGS_REP is received by the client, it is pro- 1615 cessed in the same manner as the KRB_AS_REP processing 1616 described above. The primary difference is that the cipher- 1617 text part of the response must be decrypted using the ses- 1618 sion key from the ticket-granting ticket rather than the 1619 client's secret key. See section A.7 for pseudocode. 1621 _3._4. _T_h_e _K_R_B__S_A_F_E _E_x_c_h_a_n_g_e 1623 The KRB_SAFE message may be used by clients requiring 1624 the ability to detect modifications of messages they 1625 exchange. It achieves this by including a keyed collision- 1626 proof checksum of the user data and some control informa- 1627 tion. The checksum is keyed with an encryption key (usually 1628 the last key negotiated via subkeys, or the session key if 1629 no negotiation has occured). 1631 _3._4._1. _G_e_n_e_r_a_t_i_o_n _o_f _a _K_R_B__S_A_F_E _m_e_s_s_a_g_e 1633 When an application wishes to send a KRB_SAFE message, it 1634 collects its data and the appropriate control information 1635 and computes a checksum over them. The checksum algorithm 1636 should be some sort of keyed one-way hash function (such as 1637 the RSA-MD5-DES checksum algorithm specified in section 1638 6.4.5, or the DES MAC), generated using the sub-session key 1639 if present, or the session key. Different algorithms may be 1640 selected by changing the checksum type in the message. 1641 Unkeyed or non-collision-proof checksums are not suitable 1642 for this use. 1644 The control information for the KRB_SAFE message 1645 includes both a timestamp and a sequence number. The 1646 designer of an application using the KRB_SAFE message must 1647 choose at least one of the two mechanisms. This choice 1648 should be based on the needs of the application protocol. 1650 Sequence numbers are useful when all messages sent will 1651 be received by one's peer. Connection state is presently 1652 required to maintain the session key, so maintaining the 1653 next sequence number should not present an additional prob- 1654 lem. 1656 If the application protocol is expected to tolerate 1657 lost messages without them being resent, the use of the 1658 timestamp is the appropriate replay detection mechanism. 1659 Using timestamps is also the appropriate mechanism for 1661 Section 3.4.1. - 29 - Expires 28 February 1993 1663 Version 5 - Revision 5.1 1665 multi-cast protocols where all of one's peers share a common 1666 sub-session key, but some messages will be sent to a subset 1667 of one's peers. 1669 After computing the checksum, the client then transmits 1670 the information and checksum to the recipient in the message 1671 format specified in section 5.6.1. 1673 _3._4._2. _R_e_c_e_i_p_t _o_f _K_R_B__S_A_F_E _m_e_s_s_a_g_e 1675 When an application receives a KRB_SAFE message, it verifies 1676 it as follows. If any error occurs, an error code is 1677 reported for use by the application. 1679 The message is first checked by verifying that the pro- 1680 tocol version and type fields match the current version and 1681 KRB_SAFE, respectively. A mismatch generates a 1682 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1683 application verifies that the checksum used is a collision- 1684 proof keyed checksum, and if it is not, a 1685 KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient 1686 verifies that the operating system's report of the sender's 1687 address matches the sender's address in the message, and (if 1688 a recipient address is specified or the recipient requires 1689 an address) that one of the recipient's addresses appears as 1690 the recipient's address in the message. A failed match for 1691 either case generates a KRB_AP_ERR_BADADDR error. Then the 1692 timestamp and usec and/or the sequence number fields are 1693 checked. If timestamp and usec are expected and not 1694 present, or they are present but not current, the 1695 KRB_AP_ERR_SKEW error is generated. If the server name, 1696 along with the client name, time and microsecond fields from 1697 the Authenticator match any recently-seen such tuples, the 1698 KRB_AP_ERR_REPEAT error is generated. If an incorrect 1699 sequence number is included, or a sequence number is 1700 expected but not present, the KRB_AP_ERR_BADORDER error is 1701 generated. If neither a timestamp and usec or a sequence 1702 number is present, a KRB_AP_ERR_MODIFIED error is generated. 1703 Finally, the checksum is computed over the data and control 1704 information, and if it doesn't match the received checksum, 1705 a KRB_AP_ERR_MODIFIED error is generated. 1707 If all the checks succeed, the application is assured 1708 that the message was generated by its peer and was not modi- 1709 fied in transit. 1711 _3._5. _T_h_e _K_R_B__P_R_I_V _E_x_c_h_a_n_g_e 1713 The KRB_PRIV message may be used by clients requiring 1714 confidentiality and the ability to detect modifications of 1715 exchanged messages. It achieves this by encrypting the mes- 1716 sages and adding control information. 1718 Section 3.5. - 30 - Expires 28 February 1993 1720 Version 5 - Revision 5.1 1722 _3._5._1. _G_e_n_e_r_a_t_i_o_n _o_f _a _K_R_B__P_R_I_V _m_e_s_s_a_g_e 1724 When an application wishes to send a KRB_PRIV message, it 1725 collects its data and the appropriate control information 1726 (specified in section 5.7.1) and encrypts them under an 1727 encryption key (usually the last key negotiated via subkeys, 1728 or the session key if no negotiation has occured). As part 1729 of the control information, the client must choose to use 1730 either a timestamp or a sequence number (or both); see the 1731 discussion in section 3.4.1 for guidelines on which to use. 1732 After the user data and control information are encrypted, 1733 the client transmits the ciphertext and some "envelope" 1734 information to the recipient. 1736 _3._5._2. _R_e_c_e_i_p_t _o_f _K_R_B__P_R_I_V _m_e_s_s_a_g_e 1738 When an application receives a KRB_PRIV message, it verifies 1739 it as follows. If any error occurs, an error code is 1740 reported for use by the application. 1742 The message is first checked by verifying that the pro- 1743 tocol version and type fields match the current version and 1744 KRB_PRIV, respectively. A mismatch generates a 1745 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1746 application then decrypts the ciphertext and processes the 1747 resultant plaintext. If decryption shows the data to have 1748 been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- 1749 erated. The recipient verifies that the operating system's 1750 report of the sender's address matches the sender's address 1751 in the message, and (if a recipient address is specified or 1752 the recipient requires an address) that one of the 1753 recipient's addresses appears as the recipient's address in 1754 the message. A failed match for either case generates a 1755 KRB_AP_ERR_BADADDR error. Then the timestamp and usec 1756 and/or the sequence number fields are checked. If timestamp 1757 and usec are expected and not present, or they are present 1758 but not current, the KRB_AP_ERR_SKEW error is generated. If 1759 the server name, along with the client name, time and 1760 microsecond fields from the Authenticator match any 1761 recently-seen such tuples, the KRB_AP_ERR_REPEAT error is 1762 generated. If an incorrect sequence number is included, or 1763 a sequence number is expected but not present, the 1764 KRB_AP_ERR_BADORDER error is generated. If neither a time- 1765 stamp and usec or a sequence number is present, a 1766 KRB_AP_ERR_MODIFIED error is generated. Finally, the check- 1767 sum is computed over the data and control information, and 1768 if it doesn't match the received checksum, a 1769 KRB_AP_ERR_MODIFIED error is generated. 1771 If all the checks succeed, the application can assume 1772 the message was generated by its peer, and was securely 1773 transmitted (without intruders able to see the unencrypted 1774 contents). 1776 Section 3.5.2. - 31 - Expires 28 February 1993 1778 Version 5 - Revision 5.1 1780 _4. _T_h_e _K_e_r_b_e_r_o_s _D_a_t_a_b_a_s_e 1782 The Kerberos server must have access to a database contain- 1783 ing the principal identifiers and secret keys of principals 1784 to be authenticated[19]. 1786 _4._1. _D_a_t_a_b_a_s_e _c_o_n_t_e_n_t_s 1788 A database entry should contain at least the following 1789 fields: 1791 _F_i_e_l_d _V_a_l_u_e 1793 name Principal's identif- 1794 ier 1795 key Principal's secret key 1796 p_kvno Principal's key version 1797 max_life Maximum lifetime for Tickets 1798 max_renewable_life Maximum total lifetime for renewable Tickets 1800 The name field is an encoding of the principal's identifier. 1801 The key field contains an encryption key. This key is the 1802 principal's secret key. (The key can be encrypted before 1803 storage under a Kerberos "master key" to protect it in case 1804 the database is compromised but the master key is not. In 1805 that case, an extra field must be added to indicate the mas- 1806 ter key version used, see below.) The p_kvno field is the 1807 key version number of the principal's secret key. The 1808 max_life field contains the maximum allowable lifetime (end- 1809 time - starttime) for any Ticket issued for this principal. 1810 The max_renewable_life field contains the maximum allowable 1811 total lifetime for any renewable Ticket issued for this 1812 principal. (See section 3.1 for a description of how these 1813 lifetimes are used in determining the lifetime of a given 1814 Ticket.) 1816 A server may provide KDC service to several realms, as 1817 long as the database representation provides a mechanism to 1818 distinguish between principal records with identifiers which 1819 differ only in the realm name. 1821 When an application server's key changes, if the change 1822 is routine (i.e. not the result of disclosure of the old 1823 key), the old key should be retained by the server until all 1824 __________________________ 1825 9[19] The implementation of the Kerberos server need not 1826 combine the database and the server on the same 1827 machine; it is feasible to store the principal database 1828 in, say, a network name service, as long as the entries 1829 stored therein are protected from disclosure to and 1830 modification by unauthorized parties. However, we 1831 recommend against such strategies, as they can make 1832 system management and threat analysis quite complex. 1833 9 1835 Section 4.1. - 32 - Expires 28 February 1993 1837 Version 5 - Revision 5.1 1839 tickets that had been issued using that key have expired. 1840 Because of this, it is possible for several keys to be 1841 active for a single principal. Ciphertext encrypted in a 1842 principal's key is always tagged with the version of the key 1843 that was used for encryption, to help the recipient find the 1844 proper key for decryption. 1846 When more than one key is active for a particular prin- 1847 cipal, the principal will have more than one record in the 1848 Kerberos database. The keys and key version numbers will 1849 differ between the records (the rest of the fields may or 1850 may not be the same). Whenever Kerberos issues a ticket, or 1851 responds to a request for initial authentication, the most 1852 recent key (known by the Kerberos server) will be used for 1853 encryption. This is the key with the highest key version 1854 number. 1856 _4._2. _A_d_d_i_t_i_o_n_a_l _f_i_e_l_d_s 1858 Project Athena's KDC implementation uses additional fields 1859 in its database: 1861 _F_i_e_l_d _V_a_l_u_e 1863 K_kvno Kerberos' key version 1864 expiration Expiration date for entry 1865 attributes Bit field of attributes 1866 mod_date Timestamp of last modification 1867 mod_name Modifying principal's identifier 1869 The K_kvno field indicates the key version of the Kerberos 1870 master key under which the principal's secret key is 1871 encrypted. 1873 After an entry's expiration date has passed, the KDC 1874 will return an error to any client attempting to gain tick- 1875 ets as or for the principal. (A database may want to main- 1876 tain two expiration dates: one for the principal, and one 1877 for the principal's current key. This allows password aging 1878 to work independently of the principal's expiration date. 1879 However, due to the limited space in the responses, the KDC 1880 must combine the key expiration and principal expiration 1881 date into a single value called "key_exp", which is used as 1882 a hint to the user to take administrative action.) 1884 The attributes field is a bitfield used to govern the 1885 operations involving the principal. This field might be 1886 useful in conjunction with user registration procedures, for 1887 site-specific policy implementations (Project Athena 1888 currently uses it for their user registration process con- 1889 trolled by the system-wide database service, Moira [7]),. 1890 or to identify the "string to key" conversion algorithm used 1891 for a principal's key[20]. Other bits are used to indicate 1892 __________________________ 1893 9[20] See the discussion of the padata field in section 1895 9 1897 Version 5 - Revision 5.1 1899 that certain ticket options should not be allowed in tickets 1900 encrypted under a principal's key (one bit each): Disallow 1901 issuing postdated tickets, disallow issuing forwardable 1902 tickets, disallow issuing tickets based on TGT authentica- 1903 tion, disallow issuing renewable tickets, disallow issuing 1904 proxiable tickets, and disallow issuing tickets for which 1905 the principal is the server. 1907 The mod_date field contains the time of last modifica- 1908 tion of the entry, and the mod_name field contains the name 1909 of the principal which last modified the entry. 1911 _4._3. _F_r_e_q_u_e_n_t_l_y _C_h_a_n_g_i_n_g _F_i_e_l_d_s 1913 Some KDC implementations may wish to maintain the last 1914 time that a request was made by a particular principal. 1915 Information that might be maintained includes the time of 1916 the last request, the time of the last request for a 1917 ticket-granting ticket, the time of the last use of a 1918 ticket-granting ticket, or other times. This information 1919 can then be returned to the user in the last-req field (see 1920 section 5.2). 1922 Other frequently changing information that can be main- 1923 tained is the latest expiration time for any tickets that 1924 have been issued using each key. This field would be used 1925 to indicate how long old keys must remain valid to allow the 1926 continued use of outstanding tickets. 1928 _4._4. _S_i_t_e _C_o_n_s_t_a_n_t_s 1930 The KDC implementation should have the following confi- 1931 gurable constants or options, to allow an administrator to 1932 make and enforce policy decisions: 1934 o+ The minimum supported lifetime (used to determine whether 1935 the KDC_ERR_NEVER_VALID error should be returned). This 1936 constant should reflect reasonable expectations of 1937 round-trip time to the KDC, encryption/decryption time, 1938 and processing time by the client and target server, and 1939 it should allow for a minimum "useful" lifetime. 1941 o+ The maximum allowable total (renewable) lifetime of a 1942 ticket (renew_till - starttime). 1944 o+ The maximum allowable lifetime of a ticket (endtime - 1945 starttime). 1947 o+ Whether to allow the issue of tickets with empty address 1948 fields (including the ability to specify that such tick- 1949 ets may only be issued if the request specifies some 1950 __________________________ 1951 5.4.2 for details on why this can be useful. 1953 Section 4.4. - 34 - Expires 28 February 1993 1955 Version 5 - Revision 5.1 1957 authorization_data). 1959 o+ Whether proxiable, forwardable, renewable or post-datable 1960 tickets are to be issued. 1962 _5. _M_e_s_s_a_g_e _S_p_e_c_i_f_i_c_a_t_i_o_n_s 1964 The following sections describe the exact contents and 1965 encoding of protocol messages and objects. The ASN.1 base 1966 definitions are presented in the first subsection. The 1967 remaining subsections specify the protocol objects (tickets 1968 and authenticators) and messages. Specification of encryp- 1969 tion and checksum techniques, and the fields related to 1970 them, appear in section 6. 1972 _5._1. _A_S_N._1 _D_i_s_t_i_n_g_u_i_s_h_e_d _E_n_c_o_d_i_n_g _R_e_p_r_e_s_e_n_t_a_t_i_o_n 1974 All uses of ASN.1 in Kerberos shall use the Dis- 1975 tinguished Encoding Representation of the data elements as 1976 described in the X.509 specification, section 8.7 [8]. 1978 _5._2. _A_S_N._1 _B_a_s_e _D_e_f_i_n_i_t_i_o_n_s 1980 The following ASN.1 base definitions are used in the 1981 rest of this section. Note that since the underscore char- 1982 acter (_) is not permitted in ASN.1 names, the hyphen (-) is 1983 used in its place for the purposes of ASN.1 names. 1985 Realm ::= GeneralString 1986 PrincipalName ::= SEQUENCE { 1987 name-type[0] INTEGER, 1988 name-string[1] SEQUENCE OF GeneralString 1989 } 1991 Kerberos realms are encoded as GeneralStrings. Realms shall 1992 not contain a character with the code 0 (the ASCII NUL). 1993 Most realms will usually consist of several components 1994 separated by periods (.), in the style of Internet Domain 1995 Names, or separated by slashes (/) in the style of X.500 1996 names. Acceptable forms for realm names are specified in 1997 section 7. A PrincipalName is a typed sequence of com- 1998 ponents consisting of the following sub-fields: 2000 name-type This field specifies the type of name that fol- 2001 lows. Pre-defined values for this field are 2002 specified in section 7.2. The name-type should be 2003 treated as a hint. Ignoring the name type, no two 2004 names can be the same (i.e. at least one of the 2005 components, or the realm, must be different). 2006 This constraint may be eliminated in the future. 2008 name-stringThis field encodes a sequence of components that 2010 Section 5.2. - 35 - Expires 28 February 1993 2012 Version 5 - Revision 5.1 2014 form a name, each component encoded as a General- 2015 String. Taken together, a PrincipalName and a 2016 Realm form a principal identifier. Most Princi- 2017 palNames will have only a few components (typi- 2018 cally one or two). 2020 KerberosTime ::= GeneralizedTime 2021 -- Specifying UTC time zone (Z) 2023 The timestamps used in Kerberos are encoded as General- 2024 izedTimes. An encoding shall specify the UTC time zone (Z) 2025 and shall not include any fractional portions of the 2026 seconds. It further shall not include any separators. 2027 Example: The only valid format for UTC time 6 minutes, 27 2028 seconds after 9 pm on 6 November 1985 is 19851106210627Z. 2030 HostAddress ::= SEQUENCE { 2031 addr-type[0] INTEGER, 2032 address[1] OCTET STRING 2033 } 2035 HostAddresses ::= SEQUENCE OF SEQUENCE { 2036 addr-type[0] INTEGER, 2037 address[1] OCTET STRING 2038 } 2040 The host adddress encodings consists of two fields: 2042 addr-type This field specifies the type of address that 2043 follows. Pre-defined values for this field are 2044 specified in section 8.1. 2046 8 2047 address This field encodes a single address of type addr- 2048 type. 2050 The two forms differ slightly. HostAddress contains exactly 2051 one address; HostAddresses contains a sequence of possibly 2052 many addresses. 2054 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2055 ad-type[0] INTEGER, 2056 ad-data[1] OCTET STRING 2057 } 2059 ad-data This field contains authorization data to be 2060 interpreted according to the value of the 2061 corresponding ad-type field. 2063 ad-type This field specifies the format for the ad-data 2065 9Section 5.2. - 36 - Expires 28 February 1993 2067 Version 5 - Revision 5.1 2069 subfield. All negative values are reserved for 2070 local use. Non-negative values are reserved for 2071 registered use. 2073 APOptions ::= BIT STRING { 2074 reserved(0), 2075 use-session-key(1), 2076 mutual-required(2) 2077 } 2079 8 2080 TicketFlags ::= BIT STRING { 2081 reserved(0), 2082 forwardable(1), 2083 forwarded(2), 2084 proxiable(3), 2085 proxy(4), 2086 may-postdate(5), 2087 postdated(6), 2088 invalid(7), 2089 renewable(8), 2090 initial(9), 2091 pre-authent(10), 2092 hw-authent(11) 2093 } 2095 8 2096 KDCOptions ::= BIT STRING { 2097 reserved(0), 2098 forwardable(1), 2099 forwarded(2), 2100 proxiable(3), 2101 proxy(4), 2102 allow-postdate(5), 2103 postdated(6), 2104 unused7(7), 2105 renewable(8), 2106 unused9(9), 2107 unused10(10), 2108 unused11(11), 2109 renewable-ok(27), 2110 enc-tkt-in-skey(28), 2111 renew(30), 2112 validate(31) 2113 } 2115 LastReq ::= SEQUENCE OF SEQUENCE { 2116 lr-type[0] INTEGER, 2117 lr-value[1] KerberosTime 2118 } 2120 lr-type This field indicates how the following lr-value 2121 field is to be interpreted. Negative values 2123 Section 5.2. - 37 - Expires 28 February 1993 2125 Version 5 - Revision 5.1 2127 indicate that the information pertains only to the 2128 responding server. Non-negative values pertain to 2129 all servers for the realm. 2131 If the lr-type field is zero (0), then no informa- 2132 tion is conveyed by the lr-value subfield. If the 2133 absolute value of the lr-type field is one (1), 2134 then the lr-value subfield is the time of last 2135 initial request for a TGT. If it is two (2), then 2136 the lr-value subfield is the time of last initial 2137 request. If it is three (3), then the lr-value 2138 subfield is the time of issue for the newest 2139 ticket-granting ticket used. If it is four (4), 2140 then the lr-value subfield is the time of the last 2141 renewal. If it is five (5), then the lr-value 2142 subfield is the time of last request (of any 2143 type). 2145 lr-value This field contains the time of the last request. 2146 The time must be interpreted according to the con- 2147 tents of the accompanying lr-type subfield. 2149 See section 6 for the definitions of Checksum, Check- 2150 sumType, EncryptedData, EncryptionKey, EncryptionType, and 2151 KeyType. 2153 _5._3. _T_i_c_k_e_t_s _a_n_d _A_u_t_h_e_n_t_i_c_a_t_o_r_s 2155 This section describes the format and encryption param- 2156 eters for tickets and authenticators. When a ticket or 2157 authenticator is included in a protocol message it is 2158 treated as an opaque object. 2160 _5._3._1. _T_i_c_k_e_t_s 2162 A ticket is a record that helps a client authenticate 2163 to a service. A Ticket contains the following information: 2165 Ticket ::= [APPLICATION 1] SEQUENCE { 2166 tkt-vno[0] INTEGER, 2167 realm[1] Realm, 2168 sname[2] PrincipalName, 2169 enc-part[3] EncryptedData 2170 } 2171 -- Encrypted part of ticket 2172 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2173 flags[0] TicketFlags, 2174 key[1] EncryptionKey, 2175 crealm[2] Realm, 2176 cname[3] PrincipalName, 2177 transited[4] TransitedEncoding, 2178 authtime[5] KerberosTime, 2179 starttime[6] KerberosTime OPTIONAL, 2181 Section 5.3.1. - 38 - Expires 28 February 1993 2183 Version 5 - Revision 5.1 2185 endtime[7] KerberosTime, 2186 renew-till[8] KerberosTime OPTIONAL, 2187 caddr[9] HostAddresses OPTIONAL, 2188 authorization-data[10] AuthorizationData OPTIONAL 2189 } 2190 -- encoded Transited field 2191 TransitedEncoding ::= SEQUENCE { 2192 tr-type[0] INTEGER, -- must be registered 2193 contents[1] OCTET STRING 2194 } 2196 The encoding of EncTicketPart is encrypted in the key shared 2197 by Kerberos and the end server (the server's secret key). 2198 See section 6 for the format of the ciphertext. 2200 tkt-vno This field specifies the version number for the 2201 ticket format. This document describes version 2202 number 5. 2204 realm This field specifies the realm that issued a 2205 ticket. It also serves to identify the realm part 2206 of the server's principal identifier. Since a 2207 Kerberos server can only issue tickets for servers 2208 within its realm, the two will always be identi- 2209 cal. 2211 sname This field specifies the name part of the server's 2212 identity. 2214 enc-part This field holds the encrypted encoding of the 2215 EncTicketPart sequence. 2217 flags This field indicates which of various options were 2218 used or requested when the ticket was issued. It 2219 is a bit-field, where the selected options are 2220 indicated by the bit being set (1), and the 2221 unselected options and reserved fields being reset 2222 (0). Bit 0 is the most significant bit. The 2223 encoding of the bits is specified in section 5.2. 2224 The flags are described in more detail above in 2225 section 2. The meanings of the flags are: 2227 _B_i_t(_s) _N_a_m_e _D_e_s_c_r_i_p_t_i_o_n 2229 0 RESERVED 2230 7 Reserved for future expansion of this 2231 field. 2233 Section 5.3.1. - 39 - Expires 28 February 1993 2235 Version 5 - Revision 5.1 2237 1 FORWARDABLE 2238 7 The FORWARDABLE flag is normally only 2239 interpreted by the TGS, and can be 2240 ignored by end servers. When set, this 2241 flag tells the ticket-granting server 2242 that it is OK to issue a new ticket- 2243 granting ticket with a different network 2244 address based on the presented ticket. 2246 2 FORWARDED 2247 7 When set, this flag indicates that the 2248 ticket has either been forwarded or was 2249 issued based on authentication involving 2250 a forwarded ticket-granting ticket. 2252 3 PROXIABLE 2253 7 The PROXIABLE flag is normally only 2254 interpreted by the TGS, and can be 2255 ignored by end servers. The PROXIABLE 2256 flag has an interpretation identical to 2257 that of the FORWARDABLE flag, except 2258 that the PROXIABLE flag tells the 2259 ticket-granting server that only non- 2260 ticket-granting tickets may be issued 2261 with different network addresses. 2263 4 PROXY 2264 7 When set, this flag indicates that a 2265 ticket is a proxy. 2267 5 MAY-POSTDATE 2268 7 The MAY-POSTDATE flag is normally only 2269 interpreted by the TGS, and can be 2270 ignored by end servers. This flag tells 2271 the ticket-granting server that a post- 2272 dated ticket may be issued based on this 2273 ticket-granting ticket. 2275 6 POSTDATED 2276 7 This flag indicates that this ticket has 2277 been postdated. The end-service can 2278 check the authtime field to see when the 2279 original authentication occurred. 2281 7 INVALID 2282 7 This flag indicates that a ticket is 2283 invalid, and it must be validated by the 2284 KDC before use. Application servers 2285 must reject tickets which have this flag 2286 set. 2288 8 RENEWABLE 2289 7 The RENEWABLE flag is normally only 2290 interpreted by the TGS, and can usually 2291 be ignored by end servers (some particu- 2292 larly careful servers may wish to disal- 2293 low renewable tickets). A renewable 2294 ticket can be used to obtain a replace- 2295 ment ticket that expires at a later 2296 date. 2298 Section 5.3.1. - 40 - Expires 28 February 1993 2300 Version 5 - Revision 5.1 2302 9 INITIAL 2303 7 This flag indicates that this ticket was 2304 issued using the AS protocol, and not 2305 issued based on a ticket-granting 2306 ticket. 2308 10 PRE-AUTHENT 2309 7 This flag indicates that during initial 2310 authentication, the client was authenti- 2311 cated by the KDC before a ticket was 2312 issued. The strength of the pre- 2313 authentication method is not indicated, 2314 but is acceptable to the KDC. 2316 11 HW-AUTHENT 2317 7 This flag indicates that the protocol 2318 employed for initial authentication 2319 required the use of hardware expected to 2320 be possessed solely by the named client. 2321 The hardware authentication method is 2322 selected by the KDC and the strength of 2323 the method is not indicated. 2325 12-31 RESERVED 2326 7 Reserved for future use. 2328 key This field exists in the ticket and the KDC 2329 response and is used to pass the session key from 2330 Kerberos to the application server and the client. 2331 The field's encoding is described in section 6.1. 2333 crealm This field contains the name of the realm in which 2334 the client is registered and in which initial 2335 authentication took place. 2337 cname This field contains the name part of the client's 2338 principal identifier. 2340 transited This field lists the names of the Kerberos realms 2341 that took part in authenticating the user to whom 2342 this ticket was issued. It does not specify the 2343 order in which the realms were transited. See 2344 section 3.3.3.1 for details on how this field 2345 encodes the traversed realms. 2347 authtime This field indicates the time of initial authenti- 2348 cation for the named principal. It is the time of 2349 issue for the original ticket on which this ticket 2350 is based. It is included in the ticket to provide 2351 additional information to the end service, and to 2352 provide the necessary information for implementa- 2353 tion of a `hot list' service at the KDC. An end 2354 service that is particularly paranoid could refuse 2356 Section 5.3.1. - 41 - Expires 28 February 1993 2358 Version 5 - Revision 5.1 2360 to accept tickets for which the initial authenti- 2361 cation occurred "too far" in the past. 2363 This field is also returned as part of the 2364 response from the KDC. When returned as part of 2365 the response to initial authentication 2366 (KRB_AS_REP), this is the current time on the Ker- 2367 beros server[21]. 2369 starttime This field in the ticket specifies the time after 2370 which the ticket is valid. Together with endtime, 2371 this field specifies the life of the ticket. If 2372 it is absent from the ticket, its value should be 2373 treated as that of the authtime field. 2375 endtime This field contains the time after which the 2376 ticket will not be honored (its expiration time). 2377 Note that individual services may place their own 2378 limits on the life of a ticket and may reject 2379 tickets which have not yet expired. As such, this 2380 is really an upper bound on the expiration time 2381 for the ticket. 2383 renew-tillThis field is only present in tickets that have 2384 the RENEWABLE flag set in the flags field. It 2385 indicates the maximum endtime that may be included 2386 in a renewal. It can be thought of as the abso- 2387 lute expiration time for the ticket, including all 2388 renewals. 2390 caddr This field in a ticket contains zero (if omitted) 2391 or more (if present) host addresses. These are 2392 the addresses from which the ticket can be used. 2393 If there are no addresses, the ticket can be used 2394 from any location. The decision by the KDC to 2395 issue or by the end server to accept zero-address 2396 tickets is a policy decision and is left to the 2397 Kerberos and end-service administrators; they may 2398 refuse to issue or accept such tickets. The sug- 2399 gested and default policy, however, is that such 2400 tickets will only be issued or accepted when 2401 __________________________ 2402 9[21] This time value might be used (at the host's op- 2403 tion) to adjust the workstation's clock. HOWEVER, this 2404 is not recommended, since the client cannot determine 2405 that such a KRB_AS_REP actually came from the proper 2406 KDC in a timely manner unless the enclosed ticket can 2407 be used in communication with a server whose secrets 2408 are uncompromised. 2409 9 2411 Section 5.3.1. - 42 - Expires 28 February 1993 2413 Version 5 - Revision 5.1 2415 additional information that can be used to res- 2416 trict the use of the ticket is included in the 2417 authorization_data field. Such a ticket is a 2418 capability. 2420 Network addresses are included in the ticket to 2421 make it harder for an attacker to use stolen 2422 credentials. Because the session key is not sent 2423 over the network in cleartext, credentials can't 2424 be stolen simply by listening to the network; an 2425 attacker has to gain access to the session key 2426 (perhaps through operating system security 2427 breaches or a careless user's unattended session) 2428 to make use of stolen tickets. 2430 It is important to note that the network address 2431 from which a connection is received cannot be 2432 reliably determined. Even if it could be, an 2433 attacker who has compromised the client's worksta- 2434 tion could use the credentials from there. 2435 Including the network addresses only makes it more 2436 difficult, not impossible, for an attacker to walk 2437 off with stolen credentials and then use them from 2438 a "safe" location. 2440 authorization-data 2441 The authorization-data field is used to pass 2442 authorization data from the principal on whose 2443 behalf a ticket was issued to the application ser- 2444 vice. If no authorization data is included, this 2445 field will be left out. The data in this field 2446 are specific to the end service. It is expected 2447 that the field will contain the names of service 2448 specific objects, and the rights to those objects. 2449 The format for this field is described in section 2450 5.2. Although Kerberos is not concerned with the 2451 format of the contents of the subfields, it does 2452 carry type information (ad-type). 2454 By using the authorization_data field, a principal 2455 is able to issue a proxy that is valid for a 2456 specific purpose. For example, a client wishing 2457 to print a file can obtain a file server proxy to 2458 be passed to the print server. By specifying the 2459 name of the file in the authorization_data field, 2460 the file server knows that the print server can 2461 only use the client's rights when accessing the 2462 particular file to be printed. 2464 It is interesting to note that if one specifies 2465 the authorization-data field of a proxy and leaves 2466 the host addresses blank, the resulting ticket and 2467 session key can be treated as a capability. See 2469 Section 5.3.1. - 43 - Expires 28 February 1993 2471 Version 5 - Revision 5.1 2473 [9] for some suggested uses of this field. 2475 The authorization-data field is optional and does 2476 not have to be included in a ticket. 2478 _5._3._2. _A_u_t_h_e_n_t_i_c_a_t_o_r_s 2480 An authenticator is a record sent with a ticket to a 2481 server to certify the client's knowledge of the encryption 2482 key in the ticket, to help the server detect replays, and to 2483 help choose a "true session key" to use with the particular 2484 session. The encoding is encrypted in the ticket's session 2485 key shared by the client and the server: 2487 -- Unencrypted authenticator 2488 Authenticator ::= [APPLICATION 2] SEQUENCE { 2489 authenticator-vno[0] INTEGER, 2490 crealm[1] Realm, 2491 cname[2] PrincipalName, 2492 cksum[3] Checksum OPTIONAL, 2493 cusec[4] INTEGER, 2494 ctime[5] KerberosTime, 2495 subkey[6] EncryptionKey OPTIONAL, 2496 seq-number[7] INTEGER OPTIONAL, 2497 authorization-data[8] AuthorizationData OPTIONAL 2498 } 2500 authenticator-vno 2501 This field specifies the version number for the 2502 format of the authenticator. This document speci- 2503 fies version 5. 2505 crealm and cname 2506 These fields are the same as those described for 2507 the ticket in section 5.3.1. 2509 cksum This field contains a checksum of the the applica- 2510 tion data that accompanies the KRB_AP_REQ. 2512 cusec This field contains the microsecond part of the 2513 client's timestamp. Its value (before encryption) 2514 ranges from 0 to 999999. It often appears along 2515 with ctime. The two fields are used together to 2516 specify a reasonably accurate timestamp. 2518 ctime This field contains the current time on the 2519 client's host. 2521 Section 5.3.2. - 44 - Expires 28 February 1993 2523 Version 5 - Revision 5.1 2525 subkey This field contains the client's choice for an 2526 encryption key which is to be used to protect this 2527 specific application session. Unless an applica- 2528 tion specifies otherwise, if this field is left 2529 out the session key from the ticket will be used. 2531 seq-numberThis optional field includes the initial sequence 2532 number to be used by the KRB_PRIV or KRB_SAFE mes- 2533 sages when sequence numbers are used to detect 2534 replays (It may also be used by application 2535 specific messages). When included in the authen- 2536 ticator this field specifies the initial sequence 2537 number for messages from the client to the server. 2538 When included in the AP-REP message, the initial 2539 sequence number is that for messages from the 2540 server to the client. When used in KRB_PRIV or 2541 KRB_SAFE messages, it is incremented by one after 2542 each message is sent. 2544 For sequence numbers to adequately support the 2545 detection of replays they should be non-repeating, 2546 even across connection boundaries. The initial 2547 sequence number should be random and uniformly 2548 distributed across the full space of possible 2549 sequence numbers, so that it cannot be guessed by 2550 an attacker and so that it and the successive 2551 sequence numbers do not repeat other sequences. 2553 authorization-data 2554 This field is the same as described for the ticket 2555 in section 5.3.1. It is optional and will only 2556 appear when additional restrictions are to be 2557 placed on the use of a ticket, beyond those car- 2558 ried in the ticket itself. 2560 _5._4. _S_p_e_c_i_f_i_c_a_t_i_o_n_s _f_o_r _t_h_e _A_S _a_n_d _T_G_S _e_x_c_h_a_n_g_e_s 2562 This section specifies the format of the messages used 2563 in exchange between the client and the Kerberos server. The 2564 format of possible error messages appears in section 5.8.1. 2566 _5._4._1. _K_R_B__K_D_C__R_E_Q _d_e_f_i_n_i_t_i_o_n 2568 The KRB_KDC_REQ message has no type of its own. 2569 Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ 2570 depending on whether the request is for an initial ticket or 2571 an additional ticket. In either case, the message is sent 2572 from the client to the Authentication Server to request 2573 credentials for a service. 2575 The message fields are: 2577 AS-REQ ::= [APPLICATION 10] KDC-REQ 2579 Section 5.4.1. - 45 - Expires 28 February 1993 2581 Version 5 - Revision 5.1 2583 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2585 KDC-REQ ::= SEQUENCE { 2586 pvno[1] INTEGER, 2587 msg-type[2] INTEGER, 2588 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2589 req-body[4] KDC-REQ-BODY 2590 } 2592 PA-DATA ::= SEQUENCE { 2593 padata-type[1] INTEGER, 2594 padata-value[2] OCTET STRING, 2595 -- might be encoded AP-REQ 2596 } 2598 KDC-REQ-BODY ::= SEQUENCE { 2599 kdc-options[0] KDCOptions, 2600 cname[1] PrincipalName OPTIONAL, 2601 -- Used only in AS-REQ 2602 realm[2] Realm, -- Server's realm 2603 -- Also client's in AS-REQ 2604 sname[3] PrincipalName, 2605 from[4] KerberosTime OPTIONAL, 2606 till[5] KerberosTime, 2607 rtime[6] KerberosTime OPTIONAL, 2608 nonce[7] INTEGER, 2609 etype[8] SEQUENCE OF INTEGER, -- EncryptionType, 2610 -- in preference order 2611 addresses[9] HostAddresses OPTIONAL, 2612 enc-authorization-data[10] EncryptedData OPTIONAL, 2613 -- Encrypted AuthorizationData encoding 2614 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2615 } 2617 The fields in this message are: 2619 pvno This field is included in each message, and speci- 2620 fies the protocol version number. This document 2621 specifies protocol version 5. 2623 msg-type This field indicates the type of a protocol mes- 2624 sage. It will almost always be the same as the 2625 application identifier associated with a message. 2626 It is included to make the identifier more readily 2627 accessible to the application. For the KDC-REQ 2628 message, this type will be KRB_AS_REQ or 2629 KRB_TGS_REQ. 2631 padata The padata (pre-authentication data) field con- 2632 tains a sequence of authentication information 2633 which may be needed before credentials can be 2635 Section 5.4.1. - 46 - Expires 28 February 1993 2637 Version 5 - Revision 5.1 2639 issued or decrypted. In the case of requests for 2640 additional tickets (KRB_TGS_REQ), this field will 2641 include an element with padata-type of PA-TGS-REQ 2642 and data of an authentication header (ticket- 2643 granting ticket and authenticator). The checksum 2644 in the authenticator (which must be collision- 2645 proof) is to be computed over the KDC-REQ-BODY 2646 encoding. In most requests for initial authenti- 2647 cation (KRB_AS_REQ) and most replies (KDC-REP), 2648 the padata field will be left out. This field may 2649 also contain information needed by certain exten- 2650 sions to the Kerberos protocol. For example, it 2651 might be used to initially verify the identity of 2652 a client before any response is returned, or it 2653 might contain information needed to help the KDC 2654 or the client select the key needed for generating 2655 or decrypting the response. The latter cases 2656 would be useful for supporting the use of certain 2657 "smartcards" with Kerberos. The details of such 2658 extensions are not presently specified. 2660 padata-type 2661 The padata-type element of the padata field indi- 2662 cates the way that the padata-value element is to 2663 be interpreted. Negative values of padata-type 2664 are reserved for unregistered use; non-negative 2665 values are used for a registered interpretation of 2666 the element type. 2668 req-body This field is a placeholder delimiting the extent 2669 of the remaining fields. If a checksum is to be 2670 calculated over the request, it is calculated over 2671 an encoding of the KDC-REQ-BODY sequence which is 2672 enclosed within the req-body field. 2674 kdc-options 2675 This field appears in the KRB_AS_REQ and 2676 KRB_TGS_REQ requests to the KDC and indicates the 2677 flags that the client wants set on the tickets as 2678 well as other information that is to modify the 2679 behavior of the KDC. Where appropriate, the name 2680 of an option may be the same as the flag that is 2681 set by that option. Although in most case, the 2682 bit in the options field will be the same as that 2683 in the flags field, this is not guaranteed, so it 2684 is not acceptable to simply copy the options field 2685 to the flags field. There are various checks that 2686 must be made before honoring an option anyway. 2688 The kdc_options field is a bit-field, where the 2689 selected options are indicated by the bit being 2691 Section 5.4.1. - 47 - Expires 28 February 1993 2693 Version 5 - Revision 5.1 2695 set (1), and the unselected options and reserved 2696 fields being reset (0). The encoding of the bits 2697 is specified in section 5.2. The options are 2698 described in more detail above in section 2. The 2699 meanings of the options are: 2701 _B_i_t(_s)_N_a_m_e _D_e_s_c_r_i_p_t_i_o_n 2703 0 RESERVED 2704 7 Reserved for future expansion of this 2705 field. 2707 1 FORWARDABLE 2708 7 The FORWARDABLE option indicates that 2709 the ticket to be issued is to have its 2710 forwardable flag set. It may only be 2711 set on the initial request, or in a sub- 2712 sequent request if the ticket-granting 2713 ticket on which it is based is also for- 2714 wardable. 2716 2 FORWARDED 2717 7 The FORWARDED option is only specified 2718 in a request to the ticket-granting 2719 server and will only be honored if the 2720 ticket-granting ticket in the request 2721 has its FORWARDABLE bit set. This 2722 option indicates that this is a request 2723 for forwarding. The address(es) of the 2724 host from which the resulting ticket is 2725 to be valid are included in the 2726 addresses field of the request. 2728 3 PROXIABLE 2729 7 The PROXIABLE option indicates that the 2730 ticket to be issued is to have its prox- 2731 iable flag set. It may only be set on 2732 the initial request, or in a subsequent 2733 request if the ticket-granting ticket on 2734 which it is based is also proxiable. 2736 4 PROXY 2737 7 The PROXY option indicates that this is 2738 a request for a proxy. This option will 2739 only be honored if the ticket-granting 2740 ticket in the request has its PROXIABLE 2741 bit set. The address(es) of the host 2742 from which the resulting ticket is to be 2743 valid are included in the addresses 2744 field of the request. 2746 5 ALLOW-POSTDATE 2747 7 The ALLOW-POSTDATE option indicates that 2748 the ticket to be issued is to have its 2749 MAY-POSTDATE flag set. It may only be 2750 set on the initial request, or in a sub- 2751 sequent request if the ticket-granting 2752 ticket on which it is based also has its 2753 MAY-POSTDATE flag set. 2755 Section 5.4.1. - 48 - Expires 28 February 1993 2757 Version 5 - Revision 5.1 2759 6 POSTDATED 2760 7 The POSTDATED option indicates that this 2761 is a request for a postdated ticket. 2762 This option will only be honored if the 2763 ticket-granting ticket on which it is 2764 based has its MAY-POSTDATE flag set. 2765 The resulting ticket will also have its 2766 INVALID flag set, and that flag may be 2767 reset by a subsequent request to the KDC 2768 after the starttime in the ticket has 2769 been reached. 2771 7 UNUSED 2772 7 This option is presently unused. 2774 8 RENEWABLE 2775 7 The RENEWABLE option indicates that the 2776 ticket to be issued is to have its 2777 RENEWABLE flag set. It may only be set 2778 on the initial request, or when the 2779 ticket-granting ticket on which the 2780 request is based is also renewable. If 2781 this option is requested, then the rtime 2782 field in the request contains the 2783 desired absolute expiration time for the 2784 ticket. 2786 9-26 RESERVED 2787 7 Reserved for future use. 2789 27 RENEWABLE-OK 2790 7 The RENEWABLE-OK option indicates that a 2791 renewable ticket will be acceptable if a 2792 ticket with the requested life cannot 2793 otherwise be provided. If a ticket with 2794 the requested life cannot be provided, 2795 then a renewable ticket may be issued 2796 with a renew-till equal to the the 2797 requested endtime. The value of the 2798 renew-till field may still be limited by 2799 local limits, or limits selected by the 2800 individual principal or server. 2802 28 ENC-TKT-IN-SKEY 2803 7 This option is used only by the ticket- 2804 granting service. The ENC-TKT-IN-SKEY 2805 option indicates that the ticket for the 2806 end server is to be encrypted in the 2807 session key from the additional ticket- 2808 granting ticket provided. 2810 29 RESERVED 2811 7 Reserved for future use. 2813 Section 5.4.1. - 49 - Expires 28 February 1993 2815 Version 5 - Revision 5.1 2817 30 RENEW 2818 7 This option is used only by the ticket- 2819 granting service. The RENEW option 2820 indicates that the present request is 2821 for a renewal. The ticket provided is 2822 encrypted in the secret key for the 2823 server on which it is valid. This 2824 option will only be honored if the 2825 ticket to be renewed has its RENEWABLE 2826 flag set and if the time in its renew- 2827 till field has not passed. The ticket 2828 to be renewed is passed in the padata 2829 field as part of the authentication 2830 header. 2832 31 VALIDATE 2833 7 This option is used only by the ticket- 2834 granting service. The VALIDATE option 2835 indicates that the request is to vali- 2836 date a postdated ticket. It will only 2837 be honored if the ticket presented is 2838 postdated, presently has its INVALID 2839 flag set, and would be otherwise usable 2840 at this time. A ticket cannot be vali- 2841 dated before its starttime. The ticket 2842 presented for validation is encrypted in 2843 the key of the server for which it is 2844 valid and is passed in the padata field 2845 as part of the authentication header. 2847 cname and sname 2848 These fields are the same as those described for 2849 the ticket in section 5.3.1. 2851 enc-authorization-data 2852 The enc-authorization-data, if present (and it can 2853 only be present in the TGS_REQ form), is an encod- 2854 ing of the desired authorization-data encrypted 2855 under the sub-session key if present in the 2856 Authenticator, or alternatively from the session 2857 key in the ticket-granting ticket, both from the 2858 padata field in the KRB_AP_REQ. 2860 realm This field specifies the realm part of the 2861 server's principal identifier. In the AS 2862 exchange, this is also the realm part of the 2863 client's principal identifier. 2865 from This field is included in the KRB_AS_REQ and 2866 KRB_TGS_REQ ticket requests when the requested 2867 ticket is to be postdated. It specifies the 2869 Section 5.4.1. - 50 - Expires 28 February 1993 2871 Version 5 - Revision 5.1 2873 desired start time for the requested ticket. 2875 till This field contains the expiration date requested 2876 by the client in a ticket request. 2878 rtime This field is the requested renew-till time sent 2879 from a client to the KDC in a ticket request. It 2880 is optional. 2882 nonce This field is part of the KDC request and 2883 response. It it intended to hold a random number 2884 generated by the client. If the same number is 2885 included in the encrypted response from the KDC, 2886 it provides evidence that the response is fresh 2887 and has not been replayed by an attacker. Nonces 2888 must never be re-used. Ideally, it should be gen- 2889 erated randomly, but if the correct time is known, 2890 it may suffice[22]. 2892 etype This field specifies the desired encryption algo- 2893 rithm to be used in the response. 2895 addresses This field is included in the initial request for 2896 tickets, and optionally included in requests for 2897 additional tickets from the ticket-granting 2898 server. It specifies the addresses from which the 2899 requested ticket is to be valid. Normally it 2900 includes the addresses for the client's host. If 2901 a proxy is requested, this field will contain 2902 other addresses. The contents of this field are 2903 usually copied by the KDC into the caddr field of 2904 the resulting ticket. 2906 additional-tickets 2907 Additional tickets may be optionally included in a 2908 request to the ticket-granting server. If the 2909 ENC-TKT-IN-SKEY option has been specified, then 2910 the session key from the additional ticket will be 2911 used in place of the server's key to encrypt the 2912 new ticket. If more than one option which 2913 __________________________ 2914 9[22] Note, however, that if the time is used as the 2915 nonce, one must make sure that the workstation time is 2916 monotonically increasing. If the time is ever reset 2917 backwards, there is a small, but finite, probability 2918 that a nonce will be reused. 2919 9 2921 Section 5.4.1. - 51 - Expires 28 February 1993 2923 Version 5 - Revision 5.1 2925 requires additional tickets has been specified, 2926 then the additional tickets are used in the order 2927 specified by the ordering of the options bits (see 2928 kdc-options, above). 2930 The application code will be either ten (10) or twelve 2931 (12) depending on whether the request is for an initial 2932 ticket (AS-REQ) or for an additional ticket (TGS-REQ). 2934 The optional fields (addresses, authorization-data and 2935 additional-tickets) are only included if necessary to per- 2936 form the operation specified in the kdc-options field. 2938 It should be noted that in KRB_TGS_REQ, the protocol 2939 version number appears twice and two different message types 2940 appear: the KRB_TGS_REQ message contains these fields as 2941 does the authentication header (KRB_AP_REQ) that is passed 2942 in the padata field. 2944 _5._4._2. _K_R_B__K_D_C__R_E_P _d_e_f_i_n_i_t_i_o_n 2946 The KRB_KDC_REP message format is used for the reply 2947 from the KDC for either an initial (AS) request or a subse- 2948 quent (TGS) request. There is no message type for 2949 KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 2950 KRB_TGS_REP. The key used to encrypt the ciphertext part of 2951 the reply depends on the message type. For KRB_AS_REP, the 2952 ciphertext is encrypted in the client's secret key, and the 2953 client's key version number is included in the key version 2954 number for the encrypted data. For KRB_TGS_REP, the cipher- 2955 text is encrypted in the sub-session key from the Authenti- 2956 cator, or if absent, the session key from the ticket- 2957 granting ticket used in the request. In that case, no ver- 2958 sion number will be present in the EncryptedData sequence. 2960 The KRB_KDC_REP message contains the following fields: 2962 AS-REP ::= [APPLICATION 11] KDC-REP 2963 TGS-REP ::= [APPLICATION 13] KDC-REP 2965 KDC-REP ::= SEQUENCE { 2966 pvno[0] INTEGER, 2967 msg-type[1] INTEGER, 2968 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 2969 crealm[3] Realm, 2970 cname[4] PrincipalName, 2971 ticket[5] Ticket, 2972 enc-part[6] EncryptedData 2973 } 2975 __________________________ 2976 9[24] An application code in the encrypted part of a 2978 9Section 5.4.2. - 52 - Expires 28 February 1993 2980 Version 5 - Revision 5.1 2982 EncASRepPart ::= [APPLICATION 25[24]] EncKDCRepPart 2983 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 2985 EncKDCRepPart ::= SEQUENCE { 2986 key[0] EncryptionKey, 2987 last-req[1] LastReq, 2988 nonce[2] INTEGER, 2989 key-expiration[3] KerberosTime OPTIONAL, 2990 flags[4] TicketFlags, 2991 authtime[5] KerberosTime, 2992 starttime[6] KerberosTime OPTIONAL, 2993 endtime[7] KerberosTime, 2994 renew-till[8] KerberosTime OPTIONAL, 2995 srealm[9] Realm, 2996 sname[10] PrincipalName, 2997 caddr[11] HostAddresses OPTIONAL 2998 } 3000 pvno and msg-type 3001 These fields are described above in section 5.4.1. 3002 msg-type is either KRB_AS_REP or KRB_TGS_REP. 3004 padata This field is described in detail above. One pos- 3005 sible use for this field is to encode an alternate 3006 "mix-in" string to be used with a string-to-key 3007 algorithm (such as is described in 6.3.2). This 3008 ability is useful to ease transitions if a realm 3009 name needs to change (e.g. when a company is 3010 acquired); in such a case all existing password- 3011 derived entries in the KDC database would be 3012 flagged as needing a special mix-in string until 3013 the next password change. 3015 crealm, cname, srealm and sname 3016 These fields are the same as those described for 3017 the ticket in section 5.3.1. 3019 ticket The newly-issued ticket, from section 5.3.1. 3021 enc-part This field is a place holder for the ciphertext 3022 and related information that forms the encrypted 3023 part of a message. The description of the 3024 encrypted part of the message follows each appear- 3025 ance of this field. The encrypted part is encoded 3026 __________________________ 3027 message provides an additional check that the message 3028 was decrypted properly. 3030 Section 5.4.2. - 53 - Expires 28 February 1993 3032 Version 5 - Revision 5.1 3034 as described in section 6.1. 3036 key This field is the same as described for the ticket 3037 in section 5.3.1. 3039 last-req This field is returned by the KDC and specifies 3040 the time(s) of the last request by a principal. 3041 Depending on what information is available, this 3042 might be the last time that a request for a 3043 ticket-granting ticket was made, or the last time 3044 that a request based on a ticket-granting ticket 3045 was successful. It also might cover all servers 3046 for a realm, or just the particular server. Some 3047 implementations may display this information to 3048 the user to aid in discovering unauthorized use of 3049 one's identity. It is similar in spirit to the 3050 last login time displayed when logging into 3051 timesharing systems. 3053 nonce This field is described above in section 5.4.1. 3055 key-expiration 3056 The key-expiration field is part of the response 3057 from the KDC and specifies the time that the 3058 client's secret key is due to expire. The expira- 3059 tion might be the result of password aging or an 3060 account expiration. This field will usually be 3061 left out of the TGS reply since the response to 3062 the TGS request is encrypted in a session key and 3063 no client information need be retrieved from the 3064 KDC database. It is up to the application client 3065 (usually the login program) to take appropriate 3066 action (such as notifying the user) if the expira- 3067 tion time is imminent. 3069 flags, authtime, starttime, endtime, renew-till and caddr 3070 These fields are duplicates of those found in the 3071 encrypted portion of the attached ticket (see sec- 3072 tion 5.3.1), provided so the client may verify 3073 they match the intended request and to assist in 3074 proper ticket caching. If the message is of type 3075 KRB_TGS_REP, the caddr field will only be filled 3076 in if the request was for a proxy or forwarded 3077 ticket, or if the user is substituting a subset of 3078 the addresses from the ticket granting ticket. If 3079 the client-requested addresses are not present or 3080 not used, then the addresses contained in the 3081 ticket will be the same as those included in the 3082 ticket-granting ticket. 3084 Section 5.4.2. - 54 - Expires 28 February 1993 3086 Version 5 - Revision 5.1 3088 _5._5. _C_l_i_e_n_t/_S_e_r_v_e_r (_C_S) _m_e_s_s_a_g_e _s_p_e_c_i_f_i_c_a_t_i_o_n_s 3090 This section specifies the format of the messages used 3091 for the authentication of the client to the application 3092 server. 3094 _5._5._1. _K_R_B__A_P__R_E_Q _d_e_f_i_n_i_t_i_o_n 3096 The KRB_AP_REQ message contains the Kerberos protocol 3097 version number, the message type KRB_AP_REQ, an options 3098 field to indicate any options in use, and the ticket and 3099 authenticator themselves. The KRB_AP_REQ message is often 3100 referred to as the "authentication header". 3102 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3103 pvno[0] INTEGER, 3104 msg-type[1] INTEGER, 3105 ap-options[2] APOptions, 3106 ticket[3] Ticket, 3107 authenticator[4] EncryptedData 3108 } 3110 APOptions ::= BIT STRING { 3111 reserved(0), 3112 use-session-key(1), 3113 mutual-required(2) 3114 } 3116 pvno and msg-type 3117 These fields are described above in section 5.4.1. 3118 msg-type is KRB_AP_REQ. 3120 ap-optionsThis field appears in the application request 3121 (KRB_AP_REQ) and affects the way the request is 3122 processed. It is a bit-field, where the selected 3123 options are indicated by the bit being set (1), 3124 and the unselected options and reserved fields 3125 being reset (0). The encoding of the bits is 3126 specified in section 5.2. The meanings of the 3127 options are: 3129 _B_i_t(_s)_N_a_m_e _D_e_s_c_r_i_p_t_i_o_n 3131 0 RESERVED 3132 7 Reserved for future expansion of this 3133 field. 3135 Section 5.5.1. - 55 - Expires 28 February 1993 3137 Version 5 - Revision 5.1 3139 1 USE-SESSION-KEY 3140 7 The USE-SESSION-KEY option indicates 3141 that the ticket the client is presenting 3142 to a server is encrypted in the session 3143 key from the server's ticket-granting 3144 ticket. When this option is not speci- 3145 fied, the ticket is encrypted in the 3146 server's secret key. 3148 2 MUTUAL-REQUIRED 3149 7 The MUTUAL-REQUIRED option tells the 3150 server that the client requires mutual 3151 authentication, and that it must respond 3152 with a KRB_AP_REP message. 3154 3-31 RESERVED 3155 7 Reserved for future use. 3157 ticket This field is a ticket authenticating the client 3158 to the server. 3160 authenticator 3161 This contains the authenticator, which includes 3162 the client's choice of a subkey. Its encoding is 3163 described in section 5.3.2. 3165 _5._5._2. _K_R_B__A_P__R_E_P _d_e_f_i_n_i_t_i_o_n 3167 The KRB_AP_REP message contains the Kerberos protocol 3168 version number, the message type, and an encrypted time- 3169 stamp. The message is sent in in response to an application 3170 request (KRB_AP_REQ) where the mutual authentication option 3171 has been selected in the ap-options field. 3173 AP-REP ::= [APPLICATION 15] SEQUENCE { 3174 pvno[0] INTEGER, 3175 msg-type[1] INTEGER, 3176 enc-part[2] EncryptedData 3177 } 3179 EncAPRepPart ::= [APPLICATION 27[26]] SEQUENCE { 3180 ctime[0] KerberosTime, 3181 cusec[1] INTEGER, 3182 subkey[2] EncryptionKey OPTIONAL, 3183 seq-number[3] INTEGER OPTIONAL 3184 } 3186 The encoded EncAPRepPart is encrypted in the shared session 3187 key of the ticket. The optional subkey field can be used in 3188 __________________________ 3189 9[26] An application code in the encrypted part of a 3190 message provides an additional check that the message 3191 was decrypted properly. 3192 9 3194 Section 5.5.2. - 56 - Expires 28 February 1993 3196 Version 5 - Revision 5.1 3198 an application-arranged negotiation to choose a per associa- 3199 tion session key. 3201 pvno and msg-type 3202 These fields are described above in section 5.4.1. 3203 msg-type is KRB_AP_REP. 3205 enc-part This field is described above in section 5.4.2. 3207 ctime This field contains the current time on the 3208 client's host. 3210 cusec This field contains the microsecond part of the 3211 client's timestamp. 3213 subkey This field contains an encryption key which is to 3214 be used to protect this specific application ses- 3215 sion. See section 3.2.6 for specifics on how this 3216 field is used to negotiate a key. Unless an 3217 application specifies otherwise, if this field is 3218 left out, the sub-session key from the authentica- 3219 tor, or if also left out, the session key from the 3220 ticket will be used. 3222 _5._5._3. _E_r_r_o_r _m_e_s_s_a_g_e _r_e_p_l_y 3224 If an error occurs while processing the application 3225 request, the KRB_ERROR message will be sent in response. 3226 See section 5.8.1 for the format of the error message. The 3227 cname and crealm fields may be left out if the server cannot 3228 determine their appropriate values from the corresponding 3229 KRB_AP_REQ message. If the authenticator was decipherable, 3230 the ctime and cusec fields will contain the values from it. 3232 _5._6. _K_R_B__S_A_F_E _m_e_s_s_a_g_e _s_p_e_c_i_f_i_c_a_t_i_o_n 3234 This section specifies the format of a message that can 3235 be used by either side (client or server) of an application 3236 to send a tamper-proof message to its peer. It presumes 3237 that a session key has previously been exchanged (for exam- 3238 ple, by using the KRB_AP_REQ/KRB_AP_REP messages). 3240 _5._6._1. _K_R_B__S_A_F_E _d_e_f_i_n_i_t_i_o_n 3242 The KRB_SAFE message contains user data along with a 3243 collision-proof checksum keyed with the session key. The 3244 message fields are: 3246 Section 5.6.1. - 57 - Expires 28 February 1993 3248 Version 5 - Revision 5.1 3250 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3251 pvno[0] INTEGER, 3252 msg-type[1] INTEGER, 3253 safe-body[2] KRB-SAFE-BODY, 3254 cksum[3] Checksum 3255 } 3257 KRB-SAFE-BODY ::= SEQUENCE { 3258 user-data[0] OCTET STRING, 3259 timestamp[1] KerberosTime OPTIONAL, 3260 usec[2] INTEGER OPTIONAL, 3261 seq-number[3] INTEGER OPTIONAL, 3262 s-address[4] HostAddress, 3263 r-address[5] HostAddress OPTIONAL 3264 } 3266 pvno and msg-type 3267 These fields are described above in section 5.4.1. 3268 msg-type is KRB_SAFE. 3270 safe-body This field is a placeholder for the body of the 3271 KRB-SAFE message. It is to be encoded separately 3272 and then have the checksum computed over it, for 3273 use in the cksum field. 3275 cksum This field contains the checksum of the applica- 3276 tion data. Checksum details are described in sec- 3277 tion 6.4. The checksum is computed over the 3278 encoding of the KRB-SAFE-BODY sequence. 3280 user-data This field is part of the KRB_SAFE and KRB_PRIV 3281 messages and contain the application specific data 3282 that is being passed from the sender to the reci- 3283 pient. 3285 timestamp This field is part of the KRB_SAFE and KRB_PRIV 3286 messages. Its contents are the current time as 3287 known by the sender of the message. By checking 3288 the timestamp, the recipient of the message is 3289 able to make sure that it was recently generated, 3290 and is not a replay. 3292 usec This field is part of the KRB_SAFE and KRB_PRIV 3293 headers. It contains the microsecond part of the 3294 timestamp. 3296 Section 5.6.1. - 58 - Expires 28 February 1993 3298 Version 5 - Revision 5.1 3300 seq-number 3301 This field is described above in section 5.3.2. 3303 s-address This field specifies the address in use by the 3304 sender of the message. 3306 r-address This field specifies the address in use by the 3307 recipient of the message. It may be omitted for 3308 some uses (such as broadcast protocols), but the 3309 recipient may arbitrarily reject such messages. 3310 This field along with s-address can be used to 3311 help detect messages which have been incorrectly 3312 or maliciously delivered to the wrong recipient. 3314 _5._7. _K_R_B__P_R_I_V _m_e_s_s_a_g_e _s_p_e_c_i_f_i_c_a_t_i_o_n 3316 This section specifies the format of a message that can 3317 be used by either side (client or server) of an application 3318 to securely and privately send a message to its peer. It 3319 presumes that a session key has previously been exchanged 3320 (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3322 _5._7._1. _K_R_B__P_R_I_V _d_e_f_i_n_i_t_i_o_n 3324 The KRB_PRIV message contains user data encrypted in 3325 the Session Key. The message fields are: 3327 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3328 pvno[0] INTEGER, 3329 msg-type[1] INTEGER, 3330 enc-part[3] EncryptedData 3331 } 3333 EncKrbPrivPart ::= [APPLICATION 28[28]] SEQUENCE { 3334 user-data[0] OCTET STRING, 3335 timestamp[1] KerberosTime OPTIONAL, 3336 usec[2] INTEGER OPTIONAL, 3337 seq-number[3] INTEGER OPTIONAL, 3338 s-address[4] HostAddress, -- sender's addr 3339 r-address[5] HostAddress OPTIONAL -- recip's addr 3340 } 3342 pvno and msg-type 3343 These fields are described above in section 5.4.1. 3344 msg-type is KRB_PRIV. 3345 __________________________ 3346 9[28] An application code in the encrypted part of a 3347 message provides an additional check that the message 3348 was decrypted properly. 3349 9 3351 Section 5.7.1. - 59 - Expires 28 February 1993 3353 Version 5 - Revision 5.1 3355 enc-part This field holds an encoding of the EncKrbPrivPart 3356 sequence encrypted under the session key[29]. 3357 This encrypted encoding is used for the enc-part 3358 field of the KRB-PRIV message. See section 6 for 3359 the format of the ciphertext. 3361 user-data, timestamp, usec, s-address and r-address 3362 These fields are described above in section 5.6.1. 3364 seq-number 3365 This field is described above in section 5.3.2. 3367 _5._8. _E_r_r_o_r _m_e_s_s_a_g_e _s_p_e_c_i_f_i_c_a_t_i_o_n 3369 This section specifies the format for the KRB_ERROR 3370 message. The fields included in the message are intended to 3371 return as much information as possible about an error. It 3372 is not expected that all the information required by the 3373 fields will be available for all types of errors. If the 3374 appropriate information is not available when the message is 3375 composed, the corresponding field will be left out of the 3376 message. 3378 Note that since the KRB_ERROR message is not protected 3379 by any encryption, it is quite possible for an intruder to 3380 synthesize or modify such a message. In particular, this 3381 means that the client should not use any fields in this mes- 3382 sage for security-critical purposes, such as setting a sys- 3383 tem clock or generating a fresh authenticator. The message 3384 can be useful, however, for advising a user on the reason 3385 for some failure. 3387 _5._8._1. _K_R_B__E_R_R_O_R _d_e_f_i_n_i_t_i_o_n 3389 The KRB_ERROR message consists of the following fields: 3391 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3392 pvno[0] INTEGER, 3393 msg-type[1] INTEGER, 3394 ctime[2] KerberosTime OPTIONAL, 3395 cusec[3] INTEGER OPTIONAL, 3396 __________________________ 3397 9[29] If supported by the encryption method in use, an 3398 initialization vector may be passed to the encryption 3399 procedure, in order to achieve proper cipher chaining. 3400 The initialization vector might come from the last 3401 block of the ciphertext from the previous KRB_PRIV mes- 3402 sage, but it is the application's choice whether or not 3403 to use such an initialization vector. If left out, the 3404 default initialization vector for the encryption algo- 3405 rithm will be used. 3406 9 3408 Section 5.8.1. - 60 - Expires 28 February 1993 3410 Version 5 - Revision 5.1 3412 stime[4] KerberosTime, 3413 susec[5] INTEGER, 3414 error-code[6] INTEGER, 3415 crealm[7] Realm OPTIONAL, 3416 cname[8] PrincipalName OPTIONAL, 3417 realm[9] Realm, -- Correct realm 3418 sname[10] PrincipalName, -- Correct name 3419 e-text[11] GeneralString OPTIONAL, 3420 e-data[12] OCTET STRING OPTIONAL 3421 } 3423 pvno and msg-type 3424 These fields are described above in section 5.4.1. 3425 msg-type is KRB_ERROR. 3427 ctime This field is described above in section 5.4.1. 3429 cusec This field is described above in section 5.5.2. 3431 stime This field contains the current time on the 3432 server. It is of type KerberosTime. 3434 susec This field contains the microsecond part of the 3435 server's timestamp. Its value ranges from 0 to 3436 999. It appears along with stime. The two fields 3437 are used in conjunction to specify a reasonably 3438 accurate timestamp. 3440 error-codeThis field contains the error code returned by 3441 Kerberos or the server when a request fails. To 3442 interpret the value of this field see the list of 3443 error codes in section 8. Implementations are 3444 encouraged to provide for national language sup- 3445 port in the display of error messages. 3447 crealm, cname, srealm and sname 3448 These fields are described above in section 5.3.1. 3450 e-text This field contains additional text to help 3451 explain the error code associated with the failed 3452 request (for example, it might include a principal 3453 name which was unknown). 3455 Section 5.8.1. - 61 - Expires 28 February 1993 3457 Version 5 - Revision 5.1 3459 e-data This field contains additional data about the 3460 error for use by the application to help it 3461 recover from or handle the error. If the error- 3462 code is KRB_AP_ERR_METHOD, then the e-data field 3463 will contain an encoding of the following 3464 sequence: 3466 METHOD-DATA ::= SEQUENCE { 3467 method-type[0] INTEGER, 3468 method-data[1] OCTET STRING OPTIONAL 3469 } 3471 method-type will indicate the required alternate 3472 method; method-data will contain any required 3473 additional information. 3475 _6. _E_n_c_r_y_p_t_i_o_n _a_n_d _C_h_e_c_k_s_u_m _S_p_e_c_i_f_i_c_a_t_i_o_n_s 3477 The Kerberos protocols described in this document are 3478 designed to use stream encryption ciphers, which can be 3479 simulated using commonly available block encryption ciphers, 3480 such as the Data Encryption Standard [10], in conjunction 3481 with block chaining and checksum methods [11]. Encryption 3482 is used to prove the identities of the network entities par- 3483 ticipating in message exchanges. The Key Distribution 3484 Center for each realm is trusted by all principals 3485 registered in that realm to store a secret key in confi- 3486 dence. Proof of knowledge of this secret key is used to 3487 verify the authenticity of a principal. 3489 The KDC uses the principal's secret key (in the AS 3490 exchange) or a shared session key (in the TGS exchange) to 3491 encrypt responses to ticket requests; the ability to obtain 3492 the secret key or session key implies the knowledge of the 3493 appropriate keys and the identity of the KDC. The ability 3494 of a principal to decrypt the KDC response and present a 3495 Ticket and a properly formed Authenticator (generated with 3496 the session key from the KDC response) to a service verifies 3497 the identity of the principal; likewise the ability of the 3498 service to extract the session key from the Ticket and prove 3499 its knowledge thereof in a response verifies the identity of 3500 the service. 3502 The Kerberos protocols generally assume that the 3503 encryption used is secure from cryptanalysis; however, in 3504 some cases, the order of fields in the encrypted portions of 3505 messages are arranged to minimize the effects of poorly 3506 chosen keys. It is still important to choose good keys. If 3507 keys are derived from user-typed passwords, those passwords 3508 need to be well chosen to make brute force attacks more dif- 3509 ficult. Poorly chosen keys still make easy targets for 3510 intruders. 3512 The following sections specify the encryption and 3514 Section 6. - 62 - Expires 28 February 1993 3516 Version 5 - Revision 5.1 3518 checksum mechanisms currently defined for Kerberos. The 3519 encodings, chaining, and padding requirements for each are 3520 described. For encryption methods, it is often desirable to 3521 place random information (often referred to as a _c_o_n_f_o_u_n_d_e_r) 3522 at the start of the message. The requirements for a con- 3523 founder are specified with each encryption mechanism. 3525 Some encryption systems use a block-chaining method to 3526 improve the the security characteristics of the ciphertext. 3527 However, these chaining methods often don't provide an 3528 integrity check upon decryption. Such systems (such as DES 3529 in CBC mode) must be augmented with a checksum of the plain- 3530 text which can be verified at decryption and used to detect 3531 any tampering or damage. Such checksums should be good at 3532 detecting burst errors in the input. If any damage is 3533 detected, the decryption routine is expected to return an 3534 error indicating the failure of an integrity check. Each 3535 encryption type is expected to provide and verify an 3536 appropriate checksum. The specification of each encryption 3537 method sets out its checksum requirements. 3539 Finally, where a key is to be derived from a user's 3540 password, an algorithm for converting the password to a key 3541 of the appropriate type is included. It is desirable for 3542 the string to key function to be one-way, and for the map- 3543 ping to be different in different realms. This is important 3544 because users who are registered in more than one realm will 3545 often use the same password in each, and it is desirable 3546 that an attacker compromising the Kerberos server in one 3547 realm not obtain or derive the user's key in another. 3549 For an discussion of the integrity characteristics of 3550 the candidate encryption and checksum methods considered for 3551 Kerberos, the the reader is referred to [12]. 3553 _6._1. _E_n_c_r_y_p_t_i_o_n _S_p_e_c_i_f_i_c_a_t_i_o_n_s 3555 The following ASN.1 definition describes all encrypted 3556 messages. The enc-part field which appears in the unen- 3557 crypted part of messages in section 5 is a sequence consist- 3558 ing of an encryption type, an optional key version number, 3559 and the ciphertext. 3561 EncryptedData ::= SEQUENCE { 3562 etype[0] INTEGER, -- EncryptionType 3563 kvno[1] INTEGER OPTIONAL, 3564 cipher[2] OCTET STRING -- ciphertext 3565 } 3567 etype This field identifies which encryption algorithm 3568 was used to encipher the cipher. Detailed specif- 3569 ications for selected encryption types appear 3571 Section 6.1. - 63 - Expires 28 February 1993 3573 Version 5 - Revision 5.1 3575 later in this section. 3577 kvno This field contains the version number of the key 3578 under which data is encrypted. It is only present 3579 in messages encrypted under long lasting keys, 3580 such as principals' secret keys. 3582 cipher This field contains the enciphered text, encoded 3583 as an OCTET STRING. 3585 The cipher field is generated by applying the specified 3586 encryption algorithm to data composed of the message and 3587 algorithm-specific inputs. Encryption mechanisms defined 3588 for use with Kerberos must take sufficient measures to 3589 guarantee the integrity of the plaintext, and we recommend 3590 they also take measures to protect against precomputed dic- 3591 tionary attacks. If the encryption algorithm is not itself 3592 capable of doing so, the protections can often be enhanced 3593 by adding a checksum and a confounder. 3595 The suggested format for the data to be encrypted 3596 includes a confounder, a checksum, the encoded plaintext, 3597 and any necessary padding. The msg-seq field contains the 3598 part of the protocol message described in section 5 which is 3599 to be encrypted. The confounder, checksum, and padding are 3600 all untagged and untyped, and their length is exactly suffi- 3601 cient to hold the appropriate item. The type and length is 3602 implicit and specified by the particular encryption type 3603 being used (etype). The format for the data to be encrypted 3604 is described in the following diagram: 3606 +-----------+----------+-------------+-----+ 3607 |confounder | check | msg-seq | pad | 3608 +-----------+----------+-------------+-----+ 3610 The format cannot be described in ASN.1, but for those who 3611 prefer an ASN.1-_l_i_k_e notation: 3613 9__________________________ 3614 9[31] In the above specification, UNTAGGED OCTET 3615 STRING(length) is the notation for an octet string with 3616 its tag and length removed. It is not a valid ASN.1 3617 type. The tag bits and length must be removed from the 3618 confounder since the purpose of the confounder is so 3619 that the message starts with random data, but the tag 3620 and its length are fixed. For other fields, the length 3621 and tag would be redundant if they were included be- 3622 cause they are specified by the encryption type. 3624 Section 6.1. - 64 - Expires 28 February 1993 3626 Version 5 - Revision 5.1 3628 CipherText ::= ENCRYPTED SEQUENCE { 3629 confounder[0] UNTAGGED[31] OCTET STRING(conf_length) OPTIONAL, 3630 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 3631 msg-seq[2] MsgSequence, 3632 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 3633 } 3635 One generates a random confounder of the appropriate 3636 length, placing it in confounder; zeroes out check; calcu- 3637 lates the appropriate checksum over confounder, check, and 3638 msg-seq, placing the result in check; adds the necessary 3639 padding; then encrypts using the specified encryption type 3640 and the appropriate key. 3642 Unless otherwise specified, a definition of an encryp- 3643 tion algorithm that specifies a checksum, a length for the 3644 confounder field, or an octet boundary for padding uses this 3645 ciphertext format[32]. Those fields which are not specified 3646 will be omitted. 3648 In the interest of allowing all implementations using a 3649 particular encryption type to communicate with all others 3650 using that type, the specification of an encryption type 3651 defines any checksum that is needed as part of the encryp- 3652 tion process. If an alternative checksum is to be used, a 3653 new encryption type must be defined. 3655 Some cryptosystems require additional information 3656 beyond the key and the data to be encrypted. For example, 3657 DES, when used in cipher-block-chaining mode, requires an 3658 initialization vector. If required, the description for 3659 each encryption type must specify the source of such addi- 3660 tional information. 3662 _6._2. _E_n_c_r_y_p_t_i_o_n _K_e_y_s 3664 The sequence below shows the encoding of an encryption 3665 key: 3667 EncryptionKey ::= SEQUENCE { 3668 __________________________ 3669 9[32] The ordering of the fields in the CipherText is 3670 important. Additionally, messages encoded in this for- 3671 mat must include a length as part of the msg-seq field. 3672 This allows the recipient to verify that the message 3673 has not been truncated. Without a length, an attacker 3674 could use a chosen plaintext attack to generate a mes- 3675 sage which could be truncated, while leaving the check- 3676 sum intact. Note that if the msg-seq is an encoding of 3677 an ASN.1 SEQUENCE or OCTET STRING, then the length is 3678 part of that encoding. 3679 9 3681 Section 6.2. - 65 - Expires 28 February 1993 3683 Version 5 - Revision 5.1 3685 keytype[0] INTEGER, 3686 keyvalue[1] OCTET STRING 3687 } 3689 keytype This field specifies the type of encryption key 3690 that follows in the keyvalue field. It will 3691 almost always correspond to the encryption algo- 3692 rithm used to generate the EncryptedData, though 3693 more than one algorithm may use the same type of 3694 key (the mapping is many to one). This might hap- 3695 pen, for example, if the encryption algorithm uses 3696 an alternate checksum algorithm for an integrity 3697 check, or a different chaining mechanism. 3699 keyvalue This field contains the key itself, encoded as an 3700 octet string. 3702 All negative values for the encryption key type are 3703 reserved for local use. All non-negative values are 3704 reserved for officially assigned type fields and interpreta- 3705 tions. 3707 _6._3. _E_n_c_r_y_p_t_i_o_n _S_y_s_t_e_m_s 3709 _6._3._1. _T_h_e _N_U_L_L _E_n_c_r_y_p_t_i_o_n _S_y_s_t_e_m (_n_u_l_l) 3711 If no encryption is in use, the encryption system is 3712 said to be the NULL encryption system. In the NULL encryp- 3713 tion system there is no checksum, confounder or padding. 3714 The ciphertext is simply the plaintext. The NULL Key is 3715 used by the null encryption system and is zero octets in 3716 length, with keytype zero (0). 3718 _6._3._2. _D_E_S _i_n _C_B_C _m_o_d_e _w_i_t_h _a _C_R_C-_3_2 _c_h_e_c_k_s_u_m (_d_e_s-_c_b_c-_c_r_c) 3720 The des-cbc-crc encryption mode encrypts information 3721 under the Data Encryption Standard [10] using the cipher 3722 block chaining mode [11]. A CRC-32 checksum (described in 3723 ISO 3309 [13]) is applied to the confounder and message 3724 sequence (msg-seq) and placed in the cksum field. DES 3725 blocks are 8 bytes. As a result, the data to be encrypted 3726 (the concatenation of confounder, checksum, and message) 3727 must be padded to an 8 byte boundary before encryption. The 3728 details of the encryption of this data are identical to 3729 those for the des-cbc-md5 encryption mode. 3731 Note that, since the CRC-32 checksum is not collision- 3732 proof, an attacker could use a probabilistic chosen- 3733 plaintext attack to generate a valid message even if a con- 3734 founder is used [12]. The use of collision-proof checksums 3735 is recommended for environments where such attacks represent 3736 a significant threat. The use of the CRC-32 as the checksum 3738 Section 6.3.2. - 66 - Expires 28 February 1993 3740 Version 5 - Revision 5.1 3742 for ticket or authenticator is no longer mandated as an 3743 interoperability requirement for Kerberos Version 5 Specifi- 3744 cation 1 (See section 9.1 for specific details). 3746 _6._3._3. _D_E_S _i_n _C_B_C _m_o_d_e _w_i_t_h _a_n _M_D_4 _c_h_e_c_k_s_u_m (_d_e_s-_c_b_c-_m_d_4) 3748 The des-cbc-md4 encryption mode encrypts information 3749 under the Data Encryption Standard [10] using the cipher 3750 block chaining mode [11]. An MD4 checksum (described in 3751 [14]) is applied to the confounder and message sequence 3752 (msg-seq) and placed in the cksum field. DES blocks are 8 3753 bytes. As a result, the data to be encrypted (the concate- 3754 nation of confounder, checksum, and message) must be padded 3755 to an 8 byte boundary before encryption. The details of the 3756 encryption of this data are identical to those for the des- 3757 cbc-md5 encryption mode. 3759 _6._3._4. _D_E_S _i_n _C_B_C _m_o_d_e _w_i_t_h _a_n _M_D_5 _c_h_e_c_k_s_u_m (_d_e_s-_c_b_c-_m_d_5) 3761 The des-cbc-md5 encryption mode encrypts information 3762 under the Data Encryption Standard [10] using the cipher 3763 block chaining mode [11]. An MD5 checksum (described in 3764 [15].) is applied to the confounder and message sequence 3765 (msg-seq) and placed in the cksum field. DES blocks are 8 3766 bytes. As a result, the data to be encrypted (the concate- 3767 nation of confounder, checksum, and message) must be padded 3768 to an 8 byte boundary before encryption. 3770 Plaintext and DES ciphtertext are encoded as 8-octet 3771 blocks which are concatenated to make the 64-bit inputs for 3772 the DES algorithms. The first octet supplies the 8 most 3773 significant bits (with the octet's MSbit used as the DES 3774 input block's MSbit, etc.), the second octet the next 8 3775 bits, ..., and the eighth octet supplies the 8 least signi- 3776 ficant bits. 3778 Encryption under DES using cipher block chaining 3779 requires an additional input in the form of an initializa- 3780 tion vector. Unless otherwise specified, zero should be 3781 used as the initialization vector. Kerberos' use of DES 3782 requires an 8-octet confounder. 3784 The DES specifications identify some "weak" and "semi- 3785 weak" keys; those keys shall not be used for encrypting mes- 3786 sages for use in Kerberos. Additionally, because of the way 3787 that keys are derived for the encryption of checksums, keys 3788 shall not be used that yield "weak" or "semi-weak" keys when 3789 eXclusive-ORed with the constant F0F0F0F0F0F0F0F0. 3791 A DES key is 8 octets of data, with keytype one (1). 3792 This consists of 56 bits of key, and 8 parity bits (one per 3793 octet). The key is encoded as a series of 8 octets written 3795 Section 6.3.4. - 67 - Expires 28 February 1993 3797 Version 5 - Revision 5.1 3799 in MSB-first order. The bits within the key are also 3800 encoded in MSB order. For example, if the encryption key is 3801 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 3802 where B1,B2,...,B56 are the key bits in MSB order, and 3803 P1,P2,...,P8 are the parity bits, the first octet of the key 3804 would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the 3805 FIPS 81 introduction for reference.] 3807 To generate a DES key from a text string (password), 3808 the text string normally must have the realm and each com- 3809 ponent of the principal's name appended[33], then padded 3810 with ASCII nulls to an 8 byte boundary. This string is then 3811 fan-folded and eXclusive-ORed with itself to form an 8 byte 3812 DES key. The parity is corrected on the key, and it is used 3813 to generate a DES CBC checksum on the initial string (with 3814 the realm and name appended). Next, parity is corrected on 3815 the CBC checksum. If the result matches a "weak" or "semi- 3816 weak" key as described in the DES specification, it is 3817 eXclusive-ORed with the constant 00000000000000F0. Finally, 3818 the result is returned as the key. Pseudocode follows: 3820 string_to_key(string,realm,name) { 3821 odd = 1; 3822 s = string + realm; 3823 for(each component in name) { 3824 s = s + component; 3825 } 3826 tempkey = NULL; 3827 pad(s); /* with nulls to 8 byte boundary */ 3828 for(8byteblock in s) { 3829 if(odd == 0) { 3830 odd = 1; 3831 reverse(8byteblock) 3832 } 3833 else odd = 0; 3834 tempkey = tempkey XOR 8byteblock; 3835 } 3836 fixparity(tempkey); 3837 key = DES-CBC-check(s,tempkey); 3838 fixparity(key); 3839 if(is_weak_key_key(key)) 3840 key = key XOR 0xF0; 3841 return(key); 3842 } 3844 _6._4. _C_h_e_c_k_s_u_m_s 3846 The following is the ASN.1 definition used for a check- 3847 sum: 3848 __________________________ 3849 9[33] In some cases, it may be necessary to use a dif- 3850 ferent "mix-in" string for compatibility reasons; see 3851 the discussion of padata in section 5.4.2. 3852 9 3854 Section 6.4. - 68 - Expires 28 February 1993 3856 Version 5 - Revision 5.1 3858 Checksum ::= SEQUENCE { 3859 cksumtype[0] INTEGER, 3860 checksum[1] OCTET STRING 3861 } 3863 cksumtype This field indicates the algorithm used to gen- 3864 erate the accompanying checksum. 3866 checksum This field contains the checksum itself, encoded 3867 as an octet string. 3869 Detailed specification of selected checksum types 3870 appear later in this section. Negative values for the 3871 checksum type are reserved for local use. All non-negative 3872 values are reserved for officially assigned type fields and 3873 interpretations. 3875 Checksums used by Kerberos can be classified by two 3876 properties: whether they are collision-proof, and whether 3877 they are keyed. It is infeasible to find two plaintexts 3878 which generate the same checksum value for a collision-proof 3879 checksum. A key is required to perturb or initialize the 3880 algorithm in a keyed checksum. To prevent message-stream 3881 modification by an active attacker, unkeyed checksums should 3882 only be used when the checksum and message will be subse- 3883 quently encrypted (e.g. the checksums defined as part of the 3884 encryption algorithms covered earlier in this section). 3885 Collision-proof checksums can be made tamper-proof as well 3886 if the checksum value is encrypted before inclusion in a 3887 message. In such cases, the composition of the checksum and 3888 the encryption algorithm must be considered a separate 3889 checksum algorithm (e.g. RSA-MD5 encrypted using DES is a 3890 new checksum algorithm of type RSA-MD5-DES). For most keyed 3891 checksums, as well as for the encrypted forms of collision- 3892 proof checksums, Kerberos prepends a confounder before the 3893 checksum is calculated. 3895 _6._4._1. _T_h_e _C_R_C-_3_2 _C_h_e_c_k_s_u_m (_c_r_c_3_2) 3897 The CRC-32 checksum calculates a checksum based on a 3898 cyclic redundancy check as described in ISO 3309 [13]. The 3899 resulting checksum is four (4) octets in length. The CRC-32 3900 is neither keyed nor collision-proof. The use of this 3901 checksum is not recommended. An attacker using a proba- 3902 bilistic chosen-plaintext attack as described in [12] might 3903 be able to generate an alternative message that satisfies 3904 the checksum. The use of collision-proof checksums is 3905 recommended for environments where such attacks represent a 3906 significant threat. 3908 _6._4._2. _T_h_e _R_S_A _M_D_4 _C_h_e_c_k_s_u_m (_r_s_a-_m_d_4) 3910 The RSA-MD4 checksum calculates a checksum using the 3912 Section 6.4.2. - 69 - Expires 28 February 1993 3914 Version 5 - Revision 5.1 3916 RSA MD4 algorithm [14]. The algorithm takes as input an 3917 input message of arbitrary length and produces as output a 3918 128-bit (16 octet) checksum. RSA-MD4 is believed to be 3919 collision-proof. 3921 _6._4._3. _R_S_A _M_D_4 _C_r_y_p_t_o_g_r_a_p_h_i_c _C_h_e_c_k_s_u_m _U_s_i_n_g _D_E_S (_r_s_a-_m_d_4- 3922 _d_e_s) 3924 The RSA-MD4-DES checksum calculates a keyed collision- 3925 proof checksum by prepending an 8 octet confounder before 3926 the text, applying the RSA MD4 checksum algorithm, and 3927 encrypting the confounder and the checksum using DES in 3928 cipher-block-chaining (CBC) mode using a variant of the key, 3929 where the variant is computed by eXclusive-ORing the key 3930 with the constant F0F0F0F0F0F0F0F0[34]. The initialization 3931 vector should be zero. The resulting checksum is 24 octets 3932 long (8 octets of which are redundant). This checksum is 3933 tamper-proof and believed to be collision-proof. 3935 The DES specifications identify some "weak keys"; those 3936 keys shall not be used for generating RSA-MD4 checksums for 3937 use in Kerberos. 3939 The format for the checksum is described in the follow- 3940 ing diagram: 3942 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3943 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 3944 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3946 The format cannot be described in ASN.1, but for those who 3947 prefer an ASN.1-_l_i_k_e notation: 3949 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3950 confounder[0] UNTAGGED OCTET STRING(8), 3951 check[1] UNTAGGED OCTET STRING(16) 3952 } 3954 9__________________________ 3955 9[34] A variant of the key is used to limit the use of a 3956 key to a particular function, separating the functions 3957 of generating a checksum from other encryption per- 3958 formed using the session key. The constant 3959 F0F0F0F0F0F0F0F0 was chosen because it maintains key 3960 parity. The properties of DES precluded the use of the 3961 complement. The same constant is used for similar pur- 3962 pose in the Message Integrity Check in the Privacy 3963 Enhanced Mail standard. 3965 Section 6.4.3. - 70 - Expires 28 February 1993 3967 Version 5 - Revision 5.1 3969 _6._4._4. _T_h_e _R_S_A _M_D_5 _C_h_e_c_k_s_u_m (_r_s_a-_m_d_5) 3971 The RSA-MD5 checksum calculates a checksum using the 3972 RSA MD5 algorithm [15].. The algorithm takes as input an 3973 input message of arbitrary length and produces as output a 3974 128-bit (16 octet) checksum. RSA-MD5 is believed to be 3975 collision-proof. 3977 _6._4._5. _R_S_A _M_D_5 _C_r_y_p_t_o_g_r_a_p_h_i_c _C_h_e_c_k_s_u_m _U_s_i_n_g _D_E_S (_r_s_a-_m_d_5- 3978 _d_e_s) 3980 The RSA-MD5-DES checksum calculates a keyed collision- 3981 proof checksum by prepending an 8 octet confounder before 3982 the text, applying the RSA MD5 checksum algorithm, and 3983 encrypting the confounder and the checksum using DES in 3984 cipher-block-chaining (CBC) mode using a variant of the key, 3985 where the variant is computed by eXclusive-ORing the key 3986 with the constant F0F0F0F0F0F0F0F0. The initialization vec- 3987 tor should be zero. The resulting checksum is 24 octets 3988 long (8 octets of which are redundant). This checksum is 3989 tamper-proof and believed to be collision-proof. 3991 The DES specifications identify some "weak keys"; those 3992 keys shall not be used for encrypting RSA-MD5 checksums for 3993 use in Kerberos. 3995 The format for the checksum is described in the follow- 3996 ing diagram: 3998 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3999 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 4000 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4002 The format cannot be described in ASN.1, but for those who 4003 prefer an ASN.1-_l_i_k_e notation: 4005 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4006 confounder[0] UNTAGGED OCTET STRING(8), 4007 check[1] UNTAGGED OCTET STRING(16) 4008 } 4010 _6._4._6. _D_E_S _c_i_p_h_e_r-_b_l_o_c_k _c_h_a_i_n_e_d _c_h_e_c_k_s_u_m (_d_e_s-_m_a_c) 4012 The DES-MAC checksum is computed by prepending an 8 4013 octet confounder to the plaintext, performing a DES CBC-mode 4014 encryption on the result using the key and an initialization 4015 vector of zero, taking the last block of the ciphertext, 4016 prepending the same confounder and encrypting the pair using 4017 DES in cipher-block-chaining (CBC) mode using a a variant of 4018 the key, where the variant is computed by eXclusive-ORing 4019 the key with the constant F0F0F0F0F0F0F0F0. The initializa- 4020 tion vector should be zero. The resulting checksum is 128 4021 bits (16 octets) long, 64 bits of which are redundant. This 4023 Section 6.4.6. - 71 - Expires 28 February 1993 4025 Version 5 - Revision 5.1 4027 checksum is tamper-proof and collision-proof. 4029 The format for the checksum is described in the follow- 4030 ing diagram: 4032 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 4033 | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | 4034 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 4036 The format cannot be described in ASN.1, but for those who 4037 prefer an ASN.1-_l_i_k_e notation: 4039 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4040 confounder[0] UNTAGGED OCTET STRING(8), 4041 check[1] UNTAGGED OCTET STRING(8) 4042 } 4044 The DES specifications identify some "weak" and "semi- 4045 weak" keys; those keys shall not be used for generating 4046 DES-MAC checksums for use in Kerberos, nor shall a key be 4047 used whose veriant is "weak" or "semi-weak". 4049 _6._4._7. _R_S_A _M_D_4 _C_r_y_p_t_o_g_r_a_p_h_i_c _C_h_e_c_k_s_u_m _U_s_i_n_g _D_E_S _a_l_t_e_r_n_a_t_i_v_e 4050 (_r_s_a-_m_d_4-_d_e_s-_k) 4052 The RSA-MD4-DES-K checksum calculates a keyed 4053 collision-proof checksum by applying the RSA MD4 checksum 4054 algorithm and encrypting the results using DES in cipher- 4055 block-chaining (CBC) mode using a DES key as both key and 4056 initialization vector. The resulting checksum is 16 octets 4057 long. This checksum is tamper-proof and believed to be 4058 collision-proof. Note that this checksum type is the old 4059 method for encoding the RSA-MD4-DES checksum and it is no 4060 longer recommended. 4062 _6._4._8. _D_E_S _c_i_p_h_e_r-_b_l_o_c_k _c_h_a_i_n_e_d _c_h_e_c_k_s_u_m _a_l_t_e_r_n_a_t_i_v_e (_d_e_s- 4063 _m_a_c-_k) 4065 The DES-MAC-K checksum is computed by performing a DES 4066 CBC-mode encryption of the plaintext, and using the last 4067 block of the ciphertext as the checksum value. It is keyed 4068 with an encryption key and an initialization vector; any 4069 uses which do not specify an additional initialization vec- 4070 tor will use the key as both key and initialization vector. 4071 The resulting checksum is 64 bits (8 octets) long. This 4072 checksum is tamper-proof and collision-proof. Note that 4073 this checksum type is the old method for encoding the DES- 4074 MAC checksum and it is no longer recommended. 4076 The DES specifications identify some "weak keys"; those 4077 keys shall not be used for generating DES-MAC checksums for 4078 use in Kerberos. 4080 Section 6.4.8. - 72 - Expires 28 February 1993 4082 Version 5 - Revision 5.1 4084 _7. _N_a_m_i_n_g _C_o_n_s_t_r_a_i_n_t_s 4086 _7._1. _R_e_a_l_m _N_a_m_e_s 4088 Although realm names are encoded as GeneralStrings and 4089 although a realm can technically select any name it chooses, 4090 interoperability across realm boundaries requires agreement 4091 on how realm names are to be assigned, and what information 4092 they imply. 4094 To enforce these conventions, each realm must conform 4095 to the conventions itself, and it must require that any 4096 realms with which inter-realm keys are shared also conform 4097 to the conventions and require the same from its neighbors. 4099 There are presently four styles of realm names: domain, 4100 X500, other, and reserved. Examples of each style follow: 4102 domain: host.subdomain.domain (example) 4103 X500: C=US/O=OSF (example) 4104 other: NAMETYPE:rest/of.name=without-restrictions (example) 4105 reserved: reserved, but will not conflict with above 4107 Domain names must look like domain names: they consist of 4108 components separated by periods (.) and they contain neither 4109 colons (:) nor slashes (/). 4111 X.500 names contain an equal (=) and cannot contain a 4112 colon (:) before the equal. The realm names for X.500 names 4113 will be string representations of the names with components 4114 separated by slashes. Leading and trailing slashes will not 4115 be included. 4117 Names that fall into the other category must begin with 4118 a prefix that contains no equal (=) or period (.) and the 4119 prefix must be followed by a colon (:) and the rest of the 4120 name. All prefixes must be assigned before they may be 4121 used. Presently none are assigned. 4123 The reserved category includes strings which do not 4124 fall into the first three categories. All names in this 4125 category are reserved. It is unlikely that names will be 4126 assigned to this category unless there is a very strong 4127 argument for not using the "other" category. 4129 These rules guarantee that there will be no conflicts 4130 between the various name styles. The following additional 4131 constraints apply to the assignment of realm names in the 4132 domain and X.500 categories: the name of a realm for the 4133 domain or X.500 formats must either be used by the organiza- 4134 tion owning (to whom it was assigned) an Internet domain 4135 name or X.500 name, or in the case that no such names are 4137 Section 7.1. - 73 - Expires 28 February 1993 4139 Version 5 - Revision 5.1 4141 registered, authority to use a realm name may be derived 4142 from the authority of the parent realm. For example, if 4143 there is no domain name for E40.MIT.EDU, then the adminis- 4144 trator of the MIT.EDU realm can authorize the creation of a 4145 realm with that name. 4147 This is acceptable because the organization to which 4148 the parent is assigned is presumably the organization 4149 authorized to assign names to its children in the X.500 and 4150 domain name systems as well. If the parent assigns a realm 4151 name without also registering it in the domain name or X.500 4152 hierarchy, it is the parent's responsibility to make sure 4153 that there will not in the future exists a name identical to 4154 the realm name of the child unless it is assigned to the 4155 same entity as the realm name. 4157 _7._2. _P_r_i_n_c_i_p_a_l _N_a_m_e_s 4159 As was the case for realm names, conventions are needed 4160 to ensure that all agree on what information is implied by a 4161 principal name. The name-type field that is part of the 4162 principal name indicates the kind of information implied by 4163 the name. The name-type should be treated as a hint. 4164 Ignoring the name type, no two names can be the same (i.e. 4165 at least one of the components, or the realm, must be dif- 4166 ferent). This constraint may be eliminated in the future. 4167 The following name types are defined: 4169 name-type value meaning 4170 NT-UNKNOWN 0 Name type not known 4171 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4172 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4173 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4174 NT-SRV-XHST 4 Service with host as remaining components 4175 NT-UID 5 Unique ID 4177 When a name implies no information other than its uniqueness 4178 at a particular time the name type PRINCIPAL should be used. 4179 The principal name type should be used for users, and it 4180 might also be used for a unique server. If the name is a 4181 unique machine generated ID that is guaranteed never to be 4182 reassigned then the name type of UID should be used (note 4183 that it is generally a bad idea to reassign names of any 4184 type since stale entries might remain in access control 4185 lists). 4187 If the first component of a name identifies a service 4188 and the remaining components identify an instance of the 4189 service in a server specified manner, then the name type of 4190 SRV-INST should be used. An example of this name type is 4191 the Kerberos ticket-granting ticket which has a first com- 4192 ponent of krbtgt and a second component identifying the 4194 Section 7.2. - 74 - Expires 28 February 1993 4196 Version 5 - Revision 5.1 4198 realm for which the ticket is valid. 4200 If instance is a single component following the service 4201 name and the instance identifies the host on which the 4202 server is running, then the name type SRV-HST should be 4203 used. This type is typically used for Internet services 4204 such as telnet and the Berkeley R commands. If the separate 4205 components of the host name appear as successive components 4206 following the name of the service, then the name type SRV- 4207 XHST should be used. This type might be used to identify 4208 servers on hosts with X.500 names where the slash (/) might 4209 otherwise be ambiguous. 4211 A name type of UNKNOWN should be used when the form of 4212 the name is not known. When comparing names, a name of type 4213 UNKNOWN will match principals authenticated with names of 4214 any type. A principal authenticated with a name of type 4215 UNKNOWN, however, will only match other names of type UNK- 4216 NOWN. 4218 Names of any type with an initial component of "krbtgt" 4219 are reserved for the Kerberos ticket granting service. See 4220 section 8.2.3 for the form of such names. 4222 _8. _C_o_n_s_t_a_n_t_s _a_n_d _o_t_h_e_r _d_e_f_i_n_e_d _v_a_l_u_e_s 4224 _8._1. _H_o_s_t _a_d_d_r_e_s_s _t_y_p_e_s 4226 All negative values for the host address type are 4227 reserved for local use. All non-negative values are 4228 reserved for officially assigned type fields and interpreta- 4229 tions. 4231 The values of the types for the following addresses are 4232 chosen to match the defined address family constants in the 4233 Berkeley Standard Distributions of Unix. They can be found 4234 in with symbolic names AF_xxx (where xxx is 4235 an abbreviation of the address family name). 4237 _I_n_t_e_r_n_e_t _a_d_d_r_e_s_s_e_s 4239 Internet addresses are 32-bit (4-octet) quantities, 4240 encoded in MSB order. The type of internet addresses is two 4241 (2). 4243 _C_H_A_O_S_n_e_t _a_d_d_r_e_s_s_e_s 4245 CHAOSnet addresses are 16-bit (2-octet) quantities, 4246 encoded in MSB order. The type of CHAOSnet addresses is 4247 five (5). 4249 Section 8.1. - 75 - Expires 28 February 1993 4251 Version 5 - Revision 5.1 4253 _I_S_O _a_d_d_r_e_s_s_e_s 4255 ISO addresses are variable-length. The type of ISO 4256 addresses is seven (7). 4258 _X_e_r_o_x _N_e_t_w_o_r_k _S_e_r_v_i_c_e_s (_X_N_S) _a_d_d_r_e_s_s_e_s 4260 XNS addresses are 48-bit (6-octet) quantities, encoded 4261 in MSB order. The type of XNS addresses is six (6). 4263 _A_p_p_l_e_T_a_l_k _D_a_t_a_g_r_a_m _D_e_l_i_v_e_r_y _P_r_o_t_o_c_o_l (_D_D_P) _a_d_d_r_e_s_s_e_s 4265 AppleTalk DDP addresses consist of an 8-bit node number 4266 and a 16-bit network number. The first octet of the address 4267 is the node number; the remaining two octets encode the net- 4268 work number in MSB order. The type of AppleTalk DDP 4269 addresses is sixteen (16). 4271 _D_E_C_n_e_t _P_h_a_s_e _I_V _a_d_d_r_e_s_s_e_s 4273 DECnet Phase IV addresses are 16-bit addresses, encoded 4274 in LSB order. The type of DECnet Phase IV addresses is 4275 twelve (12). 4277 _8._2. _K_D_C _m_e_s_s_a_g_e_s 4279 _8._2._1. _I_P _t_r_a_n_s_p_o_r_t 4281 When contacting a Kerberos server (KDC) for a 4282 KRB_KDC_REQ request using IP transport, the client shall 4283 send a UDP datagram containing only an encoding of the 4284 request to port 88 (decimal) at the KDC's IP address; the 4285 KDC will respond with a reply datagram containing only an 4286 encoding of the reply message (either a KRB_ERROR or a 4287 KRB_KDC_REP) to the sending port at the sender's IP address. 4289 _8._2._2. _O_S_I _t_r_a_n_s_p_o_r_t 4291 During authentication of an OSI client to and OSI 4292 server, the mutual authentication of an OSI server to an OSI 4293 client, or during exchange of private or integrity checked 4294 messages, Kerberos protocol messages may be treated as 4295 opaque objects and the type of the authentication mechanism 4296 will be: 4298 kerberos OBJECT IDENTIFIER ::= { ?? ?? } 4300 Depending on the situation, the opaque object will be an 4301 authentication header (KRB_AP_REQ), an authentication reply 4302 (KRB_AP_REP), a safe message (KRB_SAFE), or a private mes- 4303 sage (KRB_PRIV). The opaque data contains an application 4304 code as specified in the ASN.1 description for each message. 4305 The application code may be used by Kerberos to determine 4306 the message type. 4308 Section 8.2.2. - 76 - Expires 28 February 1993 4310 Version 5 - Revision 5.1 4312 _8._2._3. _N_a_m_e _o_f _t_h_e _T_G_S 4314 The principal identifier of the ticket-granting service 4315 shall be composed of three parts: (1) the realm of the KDC 4316 issuing the TGS ticket (2) a two-part name of type NT-SRV- 4317 INST, with the first part "krbtgt" and the second part the 4318 name of the realm which will accept the ticket-granting 4319 ticket. For example, a ticket-granting ticket issued by the 4320 ATHENA.MIT.EDU realm to be used to get tickets from the 4321 ATHENA.MIT.EDU KDC has a principal identifier of 4322 "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") 4323 (name). A ticket-granting ticket issued by the 4324 ATHENA.MIT.EDU realm to be used to get tickets from the 4325 MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" 4326 (realm), ("krbtgt", "MIT.EDU") (name). 4328 _8._3. _P_r_o_t_o_c_o_l _c_o_n_s_t_a_n_t_s _a_n_d _a_s_s_o_c_i_a_t_e_d _v_a_l_u_e_s 4330 The following tables list constants used in the proto- 4331 col and defines their meanings. 4333 Encryption type _e_t_y_p_e value block size minimum pad size confounder size 4334 NULL 0 1 0 0 4335 des-cbc-crc 1 8 4 8 4336 des-cbc-md4 2 8 0 8 4337 des-cbc-md5 3 8 0 8 4339 Checksum type _s_u_m_t_y_p_e value checksum size 4340 CRC32 1 4 4341 rsa-md4 2 16 4342 rsa-md4-des 3 24 4343 des-mac 4 16 4344 des-mac-k 5 8 4345 rsa-md4-des-k 6 16 4346 rsa-md5 7 16 4347 rsa-md5-des 8 24 4349 padata type _p_a_d_a_t_a-_t_y_p_e value 4350 PA-TGS-REQ 1 4351 PA-ENC-TIMESTAMPS 2 4352 PA-PW-SALT 3 4354 authorization data type _a_d-_t_y_p_e value 4355 _r_e_s_e_r_v_e_d _v_a_l_u_e_s 0-63 4356 OSF-DCE 64 4358 alternate authentication type _m_e_t_h_o_d-_t_y_p_e value 4359 _r_e_s_e_r_v_e_d _v_a_l_u_e_s 0-63 4360 ATT-CHALLENGE-RESPONSE 64 4362 transited encoding type _t_r-_t_y_p_e value 4363 DOMAIN-X500-COMPRESS 1 4364 _r_e_s_e_r_v_e_d _v_a_l_u_e_s all others 4366 Section 8.3. - 77 - Expires 28 February 1993 4368 Version 5 - Revision 5.1 4370 _L_a_b_e_l _V_a_l_u_e _M_e_a_n_i_n_g _o_r _M_I_T _c_o_d_e 4372 pvno 5 current Kerberos protocol version number 4374 message types 4376 KRB_AS_REQ 10 Request for initial authentication 4377 KRB_AS_REP 11 Response to KRB_AS_REQ request 4378 KRB_TGS_REQ 12 Request for authentication based on TGT 4379 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4380 KRB_AP_REQ 14 application request to server 4381 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4382 KRB_SAFE 20 Safe (checksummed) application message 4383 KRB_PRIV 21 Private (encrypted) application message 4385 KRB_ERROR 30 Error response 4387 name types 4389 KRB_NT_UNKNOWN 0 Name type not known 4390 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4391 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4392 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 4393 KRB_NT_SRV_XHST 4 Service with host as remaining components 4394 KRB_NT_UID 5 Unique ID 4396 error codes 4398 KDC_ERR_NONE 0 No error 4399 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4400 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4401 KDC_ERR_BAD_PVNO 3 Requested protocol version number 4402 not supported 4403 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in 4404 old master key 4405 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in 4406 old master key 4407 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4408 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4409 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple entries for principal 4410 in Kerberos database 4411 KDC_ERR_NULL_KEY 9 The client or server has a null key 4412 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4413 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 4414 KDC_ERR_POLICY 12 KDC policy rejects request 4415 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4416 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4417 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4418 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4419 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4420 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4421 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4422 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4423 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4425 Section 8.3. - 78 - Expires 28 February 1993 4427 Version 5 - Revision 5.1 4429 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4430 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset 4432 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 4433 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4434 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4435 KRB_AP_ERR_REPEAT 34 Request is a replay 4436 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4437 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4438 KRB_AP_ERR_SKEW 37 Clock skew too great 4439 KRB_AP_ERR_BADADDR 38 Incorrect net address 4440 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4441 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4442 KRB_AP_ERR_MODIFIED 41 Message stream modified 4443 KRB_AP_ERR_BADORDER 42 Message out of order 4444 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 4445 KRB_AP_ERR_NOKEY 45 Service key not available 4446 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4447 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4448 KRB_AP_ERR_METHOD 48 Alternative authentication method required[36] 4449 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4450 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 4452 KRB_ERR_GENERIC 60 Generic error (description in e-text) 4453 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 4455 _9. _I_n_t_e_r_o_p_e_r_a_b_i_l_i_t_y _r_e_q_u_i_r_e_m_e_n_t_s 4457 Version 5 of the Kerberos protocol supports a myriad of 4458 options. Among these are multiple encryption and checksum 4459 types, alternative encoding schemes for the transited field, 4460 optional mechanisms for pre-authentication, the handling of 4461 tickets with no addresses, options for mutual authentica- 4462 tion, user to user authentication, support for proxies, for- 4463 warding, postdating, and renewing tickets, the format of 4464 realm names, and the handling of authorization data. 4466 In order to ensure the interoperability of realms, it 4467 is necessary to define a minimal configuration which must be 4468 supported by all implementations. This minimal configura- 4469 tion is subject to change as technology does. For example, 4470 if at some later date it is discovered that one of the 4471 required encryption or checksum algorithms is not secure, it 4472 will be replaced. 4473 __________________________ 4474 9[36] This error carries additional information in the 4475 e-data field. The contents of the e-data field will be 4476 an encoding of the METHOD-DATA sequence (see section 4477 5.8.1). 4478 9 4480 Section 9. - 79 - Expires 28 February 1993 4482 Version 5 - Revision 5.1 4484 _9._1. _S_p_e_c_i_f_i_c_a_t_i_o_n _1 4486 This section defines the first specification of these 4487 options. Implementations which are configured in this way 4488 can be said to support Kerberos Version 5 Specification 1 4489 (5.1). 4491 _E_n_c_r_y_p_t_i_o_n _a_n_d _c_h_e_c_k_s_u_m _m_e_t_h_o_d_s 4493 The following encryption and checksum mechanisms must be 4494 supported. Implementations may support other mechanisms as 4495 well, but the additional mechanisms may only be used when 4496 communicating with principals known to also support them: 4497 Encryption: DES-CBC-MD5 4498 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 4500 _R_e_a_l_m _N_a_m_e_s 4502 All implementations must understand hierarchical realms in 4503 both the Internet Domain and the X.500 style. When a ticket 4504 granting ticket for an unknown realm is requested, the KDC 4505 must be able to determine the names of the intermediate 4506 realms between the KDCs realm and the requested realm. 4508 _T_r_a_n_s_i_t_e_d _f_i_e_l_d _e_n_c_o_d_i_n_g 4510 DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be 4511 supported. Alternative encodings may be supported, but they 4512 may be used only when that encoding is supported by ALL 4513 intermediate realms. 4515 _P_r_e-_a_u_t_h_e_n_t_i_c_a_t_i_o_n _m_e_t_h_o_d_s 4517 The TGS-REQ method must be supported. The TGS-REQ method is 4518 not used on the initial request. 4520 _M_u_t_u_a_l _a_u_t_h_e_n_t_i_c_a_t_i_o_n 4522 Mutual authentication (via the KRB_AP_REP message) must be 4523 supported. 4525 _T_i_c_k_e_t _a_d_d_r_e_s_s_e_s _a_n_d _f_l_a_g_s 4527 All KDC's must pass on tickets that carry no addresses (i.e. 4528 if a TGT contains no addresses, the KDC will return deriva- 4529 tive tickets), but each realm may set its own policy for 4530 issuing such tickets, and each application server will set 4531 its own policy with respect to accepting them. By default, 4532 servers should not accept them. 4534 Proxies and forwarded tickets must be supported. Indi- 4535 vidual realms and application servers can set their own 4537 Section 9.1. - 80 - Expires 28 February 1993 4539 Version 5 - Revision 5.1 4541 policy on when such tickets will be accepted. 4543 All implementations must recognize renewable and post- 4544 dated tickets, but need not actually implement them. If 4545 these options are not supported, the starttime and endtime 4546 in the ticket shall specify a ticket's entire useful life. 4547 When a postdated ticket is decoded by a server, all imple- 4548 mentations shall make the presence of the postdated flag 4549 visible to the calling server. 4551 _U_s_e_r-_t_o-_u_s_e_r _a_u_t_h_e_n_t_i_c_a_t_i_o_n 4553 Support for user to user authentication (via the ENC-TKT- 4554 IN-SKEY KDC option) is not required. 4556 _A_u_t_h_o_r_i_z_a_t_i_o_n _d_a_t_a 4558 Implementations must pass all authorization data subfields 4559 from ticket-granting tickets to any derivative tickets 4560 unless directed to suppress a subfield as part of the defin- 4561 ition of that registered subfield type (it is never 4562 incorrect to pass on a subfield, and no registered subfield 4563 types presently specify suppression at the KDC). 4565 Implementations must make the contents of any authori- 4566 zation data subfields available to the server when a ticket 4567 is used. Implementations are not required to allow clients 4568 to specify the contents of the authorization data fields. 4570 _9._2. _R_e_c_o_m_m_e_n_d_e_d _K_D_C _v_a_l_u_e_s 4572 Following is a list of recommended values for a KDC imple- 4573 mentation, based on the list of suggested configuration con- 4574 stants (see section 4.4). 4576 minimum lifetime 5 minutes 4578 maximum renewable lifetime1 week 4580 maximum ticket lifetime1 day 4582 empty addresses only when suitable restrictions appear 4583 in authorization data 4585 proxiable, etc. Allowed. 4587 _1_0. _A_c_k_n_o_w_l_e_d_g_m_e_n_t_s 4589 Early versions of this document, describing version 4 4590 of the protocol, were written by Jennifer Steiner (formerly 4591 at Project Athena); these drafts provided an excellent 4592 starting point for this current version 5 specification. 4593 Many people in the Internet community have contributed ideas 4594 and suggested protocol changes for version 5. Notable 4596 Section 10. - 81 - Expires 28 February 1993 4598 Version 5 - Revision 5.1 4600 contributions came from Ted Anderson, Steve Bellovin and 4601 Michael Merritt [16], Daniel Bernstein, Mike Burrows, Donald 4602 Davis, Morrie Gasser, Virgil Gligor, Bill Griffeth, Mark 4603 Lillibridge, Mark Lomas, Joe Pato, William Sommerfeld, 4604 Stuart Stubblebine, Ralph Swick, and Stanley Zanarotti. 4605 Many others commented and helped shape this specification 4606 into its current form. 4608 _1_1. _R_E_F_E_R_E_N_C_E_S 4610 1. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 4611 Saltzer, _S_e_c_t_i_o_n _E._2._1: _K_e_r_b_e_r_o_s _A_u_t_h_e_n_t_i_c_a_t_i_o_n _a_n_d 4612 _A_u_t_h_o_r_i_z_a_t_i_o_n _S_y_s_t_e_m, M.I.T. Project Athena, Cambridge, 4613 Massachusetts (December 21, 1987). 4615 2. J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 4616 beros: An Authentication Service for Open Network Sys- 4617 tems," pp. 191-202 in _U_s_e_n_i_x _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s, 4618 Dallas, Texas (February, 1988). 4620 3. Roger M. Needham and Michael D. Schroeder, "Using 4621 Encryption for Authentication in Large Networks of Com- 4622 puters," _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, Vol. 21(12), 4623 pp. 993-999 (December, 1978). 4625 4. Dorothy E. Denning and Giovanni Maria Sacco, "Time- 4626 stamps in Key Distribution Protocols," _C_o_m_m_u_n_i_c_a_t_i_o_n_s 4627 _o_f _t_h_e _A_C_M, Vol. 24(8), pp. 533-536 (August 1981). 4629 5. John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 4630 "The Evolution of the Kerberos Authentication Service," 4631 in _a_n _I_E_E_E _C_o_m_p_u_t_e_r _S_o_c_i_e_t_y _T_e_x_t _s_o_o_n _t_o _b_e _p_u_b_l_i_s_h_e_d 4632 (June 1992). 4634 6. Don Davis and Ralph Swick, "Workstation Services and 4635 Kerberos Authentication at Project Athena," Technical 4636 Memorandum TM-424, MIT Laboratory for Computer Science 4637 (February 1990). 4639 7. P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 4640 merfeld, and K. Raeburn, _S_e_c_t_i_o_n _E._1: _S_e_r_v_i_c_e _M_a_n_a_g_e_- 4641 _m_e_n_t _S_y_s_t_e_m, M.I.T. Project Athena, Cambridge, Mas- 4642 sachusetts (1987). 4644 8. CCITT, _R_e_c_o_m_m_e_n_d_a_t_i_o_n _X._5_0_9: _T_h_e _D_i_r_e_c_t_o_r_y _A_u_t_h_e_n_t_i_c_a_- 4645 _t_i_o_n _F_r_a_m_e_w_o_r_k, December 1988. 4647 9. B. Clifford Neuman, "Proxy-Based Authorization and 4648 Accounting for Distributed Systems," Technical Report 4649 91-02-01, Department of Computer Science and Engineer- 4650 ing, University of Washington (March 1991). 4652 Section 11. - 82 - Expires 28 February 1993 4654 Version 5 - Revision 5.1 4656 10. National Bureau of Standards, U.S. Department of Com- 4657 merce, "Data Encryption Standard," Federal Information 4658 Processing Standards Publication 46, Washington, DC 4659 (1977). 4661 11. National Bureau of Standards, U.S. Department of Com- 4662 merce, "DES Modes of Operation," Federal Information 4663 Processing Standards Publication 81, Springfield, VA 4664 (December 1980). 4666 12. Stuart G. Stubblebine and Virgil D. Gligor, "On Message 4667 Integrity in Cryptographic Protocols," in _P_r_o_c_e_e_d_i_n_g_s 4668 _o_f _t_h_e _I_E_E_E _S_y_m_p_o_s_i_u_m _o_n _R_e_s_e_a_r_c_h _i_n _S_e_c_u_r_i_t_y _a_n_d 4669 _P_r_i_v_a_c_y, Oakland, California (May 1992). 4671 13. International Organization for Standardization, "ISO 4672 Information Processing Systems - Data Communication - 4673 High-Level Data Link Control Procedure - Frame Struc- 4674 ture," IS 3309 (October 1984). 3rd Edition. 4676 14. R. Rivest, "The MD4 Message Digest Algorithm," RFC 4677 1320, MIT Laboratory for Computer Science (April 4678 1992). 4680 15. R. Rivest, "The MD5 Message Digest Algorithm," RFC 4681 1321, MIT Laboratory for Computer Science (April 4682 1992). 4684 16. S. M. Bellovin and M. Merritt, "Limitations of the Ker- 4685 beros Authentication System," _C_o_m_p_u_t_e_r _C_o_m_m_u_n_i_c_a_t_i_o_n_s 4686 _R_e_v_i_e_w, Vol. 20(5), pp. 119-132 (October 1990). 4688 Section 11. - 83 - Expires 28 February 1993 4690 Version 5 - Revision 5.1 4692 A. Pseudo-code for protocol processing 4694 This appendix provides pseudo-code describing how the 4695 messages are to be constructed and interpreted by clients 4696 and servers. 4698 A.1. KRB_AS_REQ generation 4699 request.pvno := protocol version; /* pvno = 5 */ 4700 request.msg-type := message type; /* type = KRB_AS_REQ */ 4702 body.kdc-options := users's preferences; 4703 body.cname := user's name; 4704 body.realm := user's realm; 4705 body.sname := service's name; /* usually "krbtgt", "localrealm" */ 4706 if (body.kdc-options.POSTDATED is set) then 4707 body.from := requested starting time; 4708 else 4709 omit body.from; 4710 endif 4711 body.till := requested end time; 4712 if (body.kdc-options.RENEWABLE is set) then 4713 body.rtime := requested final renewal time; 4714 endif 4715 body.nonce := random_nonce(); 4716 body.etype := requested etypes; 4717 if (user supplied addresses) then 4718 body.addresses := user's addresses; 4719 else 4720 omit body.addresses; 4721 endif 4722 omit body.enc-authorization-data; 4723 request.req-body := body; 4725 kerberos := lookup(name of local kerberos server (or servers)); 4726 send(packet,kerberos); 4728 wait(for response); 4729 if (timed_out) then 4730 retry or use alternate server; 4731 endif 4733 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 4734 decode message into req; 4736 client := lookup(req.cname,req.realm); 4737 server := lookup(req.sname,req.realm); 4739 get system_time; 4740 kdc_time := system_time.seconds; 4742 if (!client) then 4743 /* no client in Database */ 4744 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 4745 endif 4747 Section A.2. - 84 - Expires 28 February 1993 4749 Version 5 - Revision 5.1 4751 if (!server) then 4752 /* no server in Database */ 4753 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 4754 endif 4756 use_etype := first supported etype in req.etypes; 4758 if (no support for req.etypes) then 4759 error_out(KDC_ERR_ETYPE_NOSUPP); 4760 endif 4762 new_tkt.vno := ticket version; /* = 5 */ 4763 new_tkt.sname := req.sname; 4764 new_tkt.srealm := req.srealm; 4765 reset all flags in new_tkt.flags; 4767 /* It should be noted that local policy may affect the */ 4768 /* processing of any of these flags. For example, some */ 4769 /* realms may refuse to issue renewable tickets */ 4771 if (req.kdc-options.FORWARDABLE is set) then 4772 set new_tkt.flags.FORWARDABLE; 4773 endif 4774 if (req.kdc-options.PROXIABLE is set) then 4775 set new_tkt.flags.PROXIABLE; 4776 endif 4777 if (req.kdc-options.ALLOW-POSTDATE is set) then 4778 set new_tkt.flags.ALLOW-POSTDATE; 4779 endif 4780 if ((req.kdc-options.RENEW is set) or 4781 (req.kdc-options.VALIDATE is set) or 4782 (req.kdc-options.PROXY is set) or 4783 (req.kdc-options.FORWARDED is set) or 4784 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 4785 error_out(KDC_ERR_BADOPTION); 4786 endif 4788 new_tkt.session := random_session_key(); 4789 new_tkt.cname := req.cname; 4790 new_tkt.crealm := req.crealm; 4791 new_tkt.transited := empty_transited_field(); 4793 new_tkt.authtime := kdc_time; 4795 if (req.kdc-options.POSTDATED is set) then 4796 if (against_postdate_policy(req.from)) then 4797 error_out(KDC_ERR_POLICY); 4798 endif 4799 set new_tkt.flags.INVALID; 4800 new_tkt.starttime := req.from; 4801 else 4802 omit new_tkt.starttime; /* treated as authtime when omitted */ 4803 endif 4804 if (req.till = 0) then 4806 Section A.2. - 85 - Expires 28 February 1993 4808 Version 5 - Revision 5.1 4810 till := infinity; 4811 else 4812 till := req.till; 4813 endif 4815 new_tkt.endtime := min(till, 4816 new_tkt.starttime+client.max_life, 4817 new_tkt.starttime+server.max_life, 4818 new_tkt.starttime+max_life_for_realm); 4820 if ((req.kdc-options.RENEWABLE-OK is set) and 4821 (new_tkt.endtime < req.till)) then 4822 /* we set the RENEWABLE option for later processing */ 4823 set req.kdc-options.RENEWABLE; 4824 req.rtime := req.till; 4825 endif 4827 if (req.rtime = 0) then 4828 rtime := infinity; 4829 else 4830 rtime := req.rtime; 4831 endif 4833 if (req.kdc-options.RENEWABLE is set) then 4834 set new_tkt.flags.RENEWABLE; 4835 new_tkt.renew-till := min(rtime, 4836 new_tkt.starttime+client.max_rlife, 4837 new_tkt.starttime+server.max_rlife, 4838 new_tkt.starttime+max_rlife_for_realm); 4839 else 4840 omit new_tkt.renew-till; /* only present if RENEWABLE */ 4841 endif 4843 if (req.addresses) then 4844 new_tkt.caddr := req.addresses; 4845 else 4846 omit new_tkt.caddr; 4847 endif 4849 new_tkt.authorization_data := empty_authorization_data(); 4851 encode to-be-encrypted part of ticket into OCTET STRING; 4852 new_tkt.enc-part := encrypt OCTET STRING 4853 using etype_for_key(server.key), server.key, server.p_kvno; 4855 /* Start processing the response */ 4857 resp.pvno := 5; 4858 resp.msg-type := KRB_AS_REP; 4859 resp.cname := req.cname; 4860 resp.crealm := req.realm; 4861 resp.ticket := new_tkt; 4863 Section A.2. - 86 - Expires 28 February 1993 4865 Version 5 - Revision 5.1 4867 resp.key := new_tkt.session; 4868 resp.last-req := fetch_last_request_info(client); 4869 resp.nonce := req.nonce; 4870 resp.key-expiration := client.expiration; 4871 resp.flags := new_tkt.flags; 4873 resp.authtime := new_tkt.authtime; 4874 resp.starttime := new_tkt.starttime; 4875 resp.endtime := new_tkt.endtime; 4877 if (new_tkt.flags.RENEWABLE) then 4878 resp.renew-till := new_tkt.renew-till; 4879 endif 4881 resp.realm := new_tkt.realm; 4882 resp.sname := new_tkt.sname; 4884 resp.caddr := new_tkt.caddr; 4886 encode body of reply into OCTET STRING; 4888 resp.enc-part := encrypt OCTET STRING 4889 using use_etype, client.key, client.p_kvno; 4890 send(resp); 4892 A.3. KRB_AS_REP verification 4893 decode response into resp; 4895 if (resp.msg-type = KRB_ERROR) then 4896 process_error(resp); 4897 return; 4898 endif 4900 /* On error, discard the response, and zero the session key */ 4901 /* from the response immediately */ 4903 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 4904 resp.padata); 4905 unencrypted part of resp := decode of decrypt of resp.enc-part 4906 using resp.enc-part.etype and key; 4907 zero(key); 4909 if (common_as_rep_tgs_rep_checks fail) then 4910 destroy resp.key; 4911 return error; 4912 endif 4914 if near(resp.princ_exp) then 4915 print(warning message); 4916 endif 4917 save_for_later(ticket,session,client,server,times,flags); 4919 Section A.3. - 87 - Expires 28 February 1993 4921 Version 5 - Revision 5.1 4923 A.4. KRB_AS_REP and KRB_TGS_REP common checks 4924 if (decryption_error() or 4925 (req.cname != resp.cname) or 4926 (req.realm != resp.crealm) or 4927 (req.sname != resp.sname) or 4928 (req.realm != resp.realm) or 4929 (req.nonce != resp.nonce) or 4930 (req.addresses != resp.caddr)) then 4931 destroy resp.key; 4932 return KRB_AP_ERR_MODIFIED; 4933 endif 4935 /* make sure no flags are set that shouldn't be, and that all that */ 4936 /* should be are set */ 4937 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 4938 destroy resp.key; 4939 return KRB_AP_ERR_MODIFIED; 4940 endif 4942 if ((req.from = 0) and 4943 (resp.starttime is not within allowable skew)) then 4944 destroy resp.key; 4945 return KRB_AP_ERR_SKEW; 4946 endif 4947 if ((req.from != 0) and (req.from != resp.starttime)) then 4948 destroy resp.key; 4949 return KRB_AP_ERR_MODIFIED; 4950 endif 4951 if ((req.till != 0) and (resp.endtime > req.till)) then 4952 destroy resp.key; 4953 return KRB_AP_ERR_MODIFIED; 4954 endif 4956 if ((req.kdc-options.RENEWABLE is set) and 4957 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 4958 destroy resp.key; 4959 return KRB_AP_ERR_MODIFIED; 4960 endif 4961 if ((req.kdc-options.RENEWABLE-OK is set) and 4962 (resp.flags.RENEWABLE) and 4963 (req.till != 0) and 4964 (resp.renew-till > req.till)) then 4965 destroy resp.key; 4966 return KRB_AP_ERR_MODIFIED; 4967 endif 4969 A.5. KRB_TGS_REQ generation 4970 /* Note that make_application_request might have to recursivly */ 4971 /* call this routine to get the appropriate ticket-granting ticket */ 4973 request.pvno := protocol version; /* pvno = 5 */ 4974 request.msg-type := message type; /* type = KRB_TGS_REQ */ 4976 body.kdc-options := users's preferences; 4978 Section A.5. - 88 - Expires 28 February 1993 4980 Version 5 - Revision 5.1 4982 body.sname := service's name; 4984 if (body.kdc-options.POSTDATED is set) then 4985 body.from := requested starting time; 4986 else 4987 omit body.from; 4988 endif 4989 body.till := requested end time; 4990 if (body.kdc-options.RENEWABLE is set) then 4991 body.rtime := requested final renewal time; 4992 endif 4993 body.nonce := random_nonce(); 4994 body.etype := requested etypes; 4995 if (user supplied addresses) then 4996 body.addresses := user's addresses; 4997 else 4998 omit body.addresses; 4999 endif 5001 body.enc-authorization-data := user-supplied data; 5002 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5003 body.additional-tickets_ticket := second TGT; 5004 endif 5006 request.req-body := body; 5007 check := generate_checksum (req.body,checksumtype); 5009 request.padata[0].padata-type := PA-TGS-REQ; 5010 request.padata[0].padata-value := create a KRB_AP_REQ using 5011 the TGT and checksum 5013 /* add in any other padata as required/supplied */ 5015 kerberos := lookup(name of local kerberose server (or servers)); 5016 send(packet,kerberos); 5018 wait(for response); 5019 if (timed_out) then 5020 retry or use alternate server; 5021 endif 5023 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5024 /* note that reading the application request requires first 5025 determining the server for which a ticket was issued, and choosing the 5026 correct key for decryption. The name of the server appears in the 5027 plaintext part of the ticket. */ 5029 if (no KRB_AP_REQ in req.padata) then 5030 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5031 endif 5032 verify KRB_AP_REQ in req.padata; 5034 /* Note that the realm in which the Kerberos server is operating is 5035 determined by the instance from the ticket-granting ticket. The realm 5037 Section A.6. - 89 - Expires 28 February 1993 5039 Version 5 - Revision 5.1 5041 in the ticket-granting ticket is the realm under which the ticket 5042 granting ticket was issued. It is possible for a single Kerberos 5043 server to support more than one realm. */ 5045 auth_hdr := KRB_AP_REQ; 5046 tgt := auth_hdr.ticket; 5048 if (tgt.sname is not a TGT for local realm and is not req.sname) then 5049 error_out(KRB_AP_ERR_NOT_US); 5051 realm := realm_tgt_is_for(tgt); 5053 decode remainder of request; 5055 if (auth_hdr.authenticator.cksum type is not supported) then 5056 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5057 endif 5058 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 5059 error_out(KRB_AP_ERR_INAPP_CKSUM); 5060 endif 5061 server := lookup(req.sname,realm); 5063 if (!server) then 5064 if (is_foreign_tgt_name(server)) then 5065 server := best_intermediate_tgs(server); 5066 else 5067 /* no server in Database */ 5068 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5069 endif 5070 endif 5072 session := generate_random_session_key(); 5074 use_etype := first supported etype in req.etypes; 5076 if (no support for req.etypes) then 5077 error_out(KDC_ERR_ETYPE_NOSUPP); 5078 endif 5080 new_tkt.vno := ticket version; /* = 5 */ 5081 new_tkt.sname := req.sname; 5082 new_tkt.srealm := realm; 5083 reset all flags in new_tkt.flags; 5085 /* It should be noted that local policy may affect the */ 5086 /* processing of any of these flags. For example, some */ 5087 /* realms may refuse to issue renewable tickets */ 5089 new_tkt.caddr := tgt.caddr; 5090 resp.caddr := NULL; /* We only include this if they change */ 5091 if (req.kdc-options.FORWARDABLE is set) then 5092 if (tgt.flags.FORWARDABLE is reset) then 5093 error_out(KDC_ERR_BADOPTION); 5095 Section A.6. - 90 - Expires 28 February 1993 5097 Version 5 - Revision 5.1 5099 endif 5100 set new_tkt.flags.FORWARDABLE; 5101 endif 5102 if (req.kdc-options.FORWARDED is set) then 5103 if (tgt.flags.FORWARDABLE is reset) then 5104 error_out(KDC_ERR_BADOPTION); 5105 endif 5106 set new_tkt.flags.FORWARDED; 5107 new_tkt.caddr := req.addresses; 5108 resp.caddr := req.addresses; 5109 endif 5110 if (tgt.flags.FORWARDED is set) then 5111 set new_tkt.flags.FORWARDED; 5112 endif 5114 if (req.kdc-options.PROXIABLE is set) then 5115 if (tgt.flags.PROXIABLE is reset) 5116 error_out(KDC_ERR_BADOPTION); 5117 endif 5118 set new_tkt.flags.PROXIABLE; 5119 endif 5120 if (req.kdc-options.PROXY is set) then 5121 if (tgt.flags.PROXIABLE is reset) then 5122 error_out(KDC_ERR_BADOPTION); 5123 endif 5124 set new_tkt.flags.PROXY; 5125 new_tkt.caddr := req.addresses; 5126 resp.caddr := req.addresses; 5127 endif 5129 if (req.kdc-options.POSTDATE is set) then 5130 if (tgt.flags.POSTDATE is reset) 5131 error_out(KDC_ERR_BADOPTION); 5132 endif 5133 set new_tkt.flags.POSTDATE; 5134 endif 5135 if (req.kdc-options.POSTDATED is set) then 5136 if (tgt.flags.POSTDATE is reset) then 5137 error_out(KDC_ERR_BADOPTION); 5138 endif 5139 set new_tkt.flags.POSTDATED; 5140 set new_tkt.flags.INVALID; 5141 if (against_postdate_policy(req.from)) then 5142 error_out(KDC_ERR_POLICY); 5143 endif 5144 new_tkt.starttime := req.from; 5145 endif 5147 if (req.kdc-options.VALIDATE is set) then 5148 if (tgt.flags.INVALID is reset) then 5149 error_out(KDC_ERR_POLICY); 5150 endif 5151 if (tgt.starttime > kdc_time) then 5153 Section A.6. - 91 - Expires 28 February 1993 5155 Version 5 - Revision 5.1 5157 error_out(KRB_AP_ERR_NYV); 5158 endif 5159 if (check_hot_list(tgt)) then 5160 error_out(KRB_AP_ERR_REPEAT); 5161 endif 5162 tkt := tgt; 5163 reset new_tkt.flags.INVALID; 5164 endif 5166 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 5167 and those already processed) is set) then 5168 error_out(KDC_ERR_BADOPTION); 5169 endif 5171 new_tkt.authtime := tgt.authtime; 5173 if (req.kdc-options.RENEW is set) then 5174 /* Note that if the endtime has already passed, the ticket would */ 5175 /* have been rejected in the initial authentication stage, so */ 5176 /* there is no need to check again here */ 5177 if (tgt.flags.RENEWABLE is reset) then 5178 error_out(KDC_ERR_BADOPTION); 5179 endif 5180 if (tgt.renew-till >= kdc_time) then 5181 error_out(KRB_AP_ERR_TKT_EXPIRED); 5182 endif 5183 tkt := tgt; 5184 new_tkt.starttime := kdc_time; 5185 old_life := tgt.endttime - tgt.starttime; 5186 new_tkt.endtime := min(tgt.renew-till, 5187 new_tkt.starttime + old_life); 5188 else 5189 new_tkt.starttime := kdc_time; 5190 if (req.till = 0) then 5191 till := infinity; 5192 else 5193 till := req.till; 5194 endif 5195 new_tkt.endtime := min(till, 5196 new_tkt.starttime+client.max_life, 5197 new_tkt.starttime+server.max_life, 5198 new_tkt.starttime+max_life_for_realm, 5199 tgt.endtime); 5201 if ((req.kdc-options.RENEWABLE-OK is set) and 5202 (new_tkt.endtime < req.till) and 5203 (tgt.flags.RENEWABLE is set) then 5204 /* we set the RENEWABLE option for later processing */ 5205 set req.kdc-options.RENEWABLE; 5206 req.rtime := min(req.till, tgt.renew-till); 5207 endif 5208 endif 5210 if (req.rtime = 0) then 5212 Section A.6. - 92 - Expires 28 February 1993 5214 Version 5 - Revision 5.1 5216 rtime := infinity; 5217 else 5218 rtime := req.rtime; 5219 endif 5221 if ((req.kdc-options.RENEWABLE is set) and 5222 (tgt.flags.RENEWABLE is set)) then 5223 set new_tkt.flags.RENEWABLE; 5224 new_tkt.renew-till := min(rtime, 5225 new_tkt.starttime+client.max_rlife, 5226 new_tkt.starttime+server.max_rlife, 5227 new_tkt.starttime+max_rlife_for_realm, 5228 tgt.renew-till); 5229 else 5230 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 5231 endif 5232 if (req.enc-authorization-data is present) then 5233 decrypt req.enc-authorization-data into decrypted_authorization_data 5234 using auth_hdr.authenticator.subkey; 5235 if (decrypt_error()) then 5236 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5237 endif 5238 endif 5239 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 5240 decrypted_authorization_data; 5242 new_tkt.key := session; 5243 new_tkt.crealm := tgt.crealm; 5244 new_tkt.cname := req.auth_hdr.ticket.cname; 5246 if (realm_tgt_is_for(tgt) := tgt.realm) then 5247 /* tgt issued by local realm */ 5248 new_tkt.transited := tgt.transited; 5249 else 5250 /* was issued for this realm by some other realm */ 5251 if (tgt.transited.tr-type not supported) then 5252 error_out(KDC_ERR_TRTYPE_NOSUPP); 5253 endif 5254 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 5255 endif 5257 encode encrypted part of new_tkt into OCTET STRING; 5258 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 5259 if (req.second_ticket is not a TGT) then 5260 error_out(KDC_ERR_POLICY); 5261 endif 5263 new_tkt.enc-part := encrypt OCTET STRING using 5264 using etype_for_key(second-ticket.key), second-ticket.key; 5265 else 5266 new_tkt.enc-part := encrypt OCTET STRING 5267 using etype_for_key(server.key), server.key, server.p_kvno; 5268 endif 5270 Section A.6. - 93 - Expires 28 February 1993 5272 Version 5 - Revision 5.1 5274 resp.pvno := 5; 5275 resp.msg-type := KRB_TGS_REP; 5276 resp.crealm := tgt.crealm; 5277 resp.cname := tgt.cname; 5279 resp.ticket := new_tkt; 5281 resp.key := session; 5282 resp.nonce := req.nonce; 5283 resp.last-req := fetch_last_request_info(client); 5284 resp.flags := new_tkt.flags; 5286 resp.authtime := new_tkt.authtime; 5287 resp.starttime := new_tkt.starttime; 5288 resp.endtime := new_tkt.endtime; 5290 omit resp.key-expiration; 5292 resp.sname := new_tkt.sname; 5293 resp.realm := new_tkt.realm; 5295 if (new_tkt.flags.RENEWABLE) then 5296 resp.renew-till := new_tkt.renew-till; 5297 endif 5299 encode body of reply into OCTET STRING; 5301 if (req.padata.authenticator.subkey) 5302 resp.enc-part := encrypt OCTET STRING using use_etype, 5303 req.padata.authenticator.subkey; 5304 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 5306 send(resp); 5308 A.7. KRB_TGS_REP verification 5309 decode response into resp; 5311 if (resp.msg-type = KRB_ERROR) then 5312 process_error(resp); 5313 return; 5314 endif 5316 /* On error, discard the response, and zero the session key from 5317 the response immediately */ 5319 if (req.padata.authenticator.subkey) 5320 unencrypted part of resp := decode of decrypt of resp.enc-part 5321 using resp.enc-part.etype and subkey; 5322 else unencrypted part of resp := decode of decrypt of resp.enc-part 5323 using resp.enc-part.etype and tgt's session key; 5324 if (common_as_rep_tgs_rep_checks fail) then 5325 destroy resp.key; 5326 return error; 5328 Section A.7. - 94 - Expires 28 February 1993 5330 Version 5 - Revision 5.1 5332 endif 5334 check authorization_data as necessary; 5335 save_for_later(ticket,session,client,server,times,flags); 5337 A.8. Authenticator generation 5338 body.authenticator-vno := authenticator vno; /* = 5 */ 5339 body.cname, body.crealm := client name; 5340 if (supplying checksum) then 5341 body.cksum := checksum; 5342 endif 5343 get system_time; 5344 body.ctime, body.cusec := system_time; 5345 if (selecting sub-session key) then 5346 select sub-session key; 5347 body.subkey := sub-session key; 5348 endif 5349 if (using sequence numbers) then 5350 select initial sequence number; 5351 body.seq-number := initial sequence; 5352 endif 5354 A.9. KRB_AP_REQ generation 5355 obtain ticket and session_key from cache; 5357 packet.pvno := protocol version; /* 5 */ 5358 packet.msg-type := message type; /* KRB_AP_REQ */ 5360 if (desired(MUTUAL_AUTHENTICATION)) then 5361 set packet.ap-options.MUTUAL-REQUIRED; 5362 else 5363 reset packet.ap-options.MUTUAL-REQUIRED; 5364 endif 5365 if (using session key for ticket) then 5366 set packet.ap-options.USE-SESSION-KEY; 5367 else 5368 reset packet.ap-options.USE-SESSION-KEY; 5369 endif 5370 packet.ticket := ticket; /* ticket */ 5371 generate authenticator; 5372 encode authenticator into OCTET STRING; 5373 encrypt OCTET STRING into packet.authenticator using session_key; 5375 A.10. KRB_AP_REQ verification 5376 receive packet; 5377 if (packet.pvno != 5) then 5378 either process using other protocol spec 5379 or error_out(KRB_AP_ERR_BADVERSION); 5380 endif 5381 if (packet.msg-type != KRB_AP_REQ) then 5382 error_out(KRB_AP_ERR_MSG_TYPE); 5383 endif 5384 if (packet.ticket.tkt_vno != 5) then 5385 either process using other protocol spec 5387 Section A.10. - 95 - Expires 28 February 1993 5389 Version 5 - Revision 5.1 5391 or error_out(KRB_AP_ERR_BADVERSION); 5392 endif 5393 if (packet.ap_options.USE-SESSION-KEY is set) then 5394 retrieve session key from ticket-granting ticket for 5395 packet.ticket.{sname,srealm,enc-part.etype}; 5396 else 5397 retrieve service key for 5398 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 5399 endif 5400 if (no_key_available) then 5401 if (cannot_find_specified_skvno) then 5402 error_out(KRB_AP_ERR_BADKEYVER); 5403 else 5404 error_out(KRB_AP_ERR_NOKEY); 5405 endif 5406 endif 5407 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 5408 if (decryption_error()) then 5409 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5410 endif 5411 decrypt packet.authenticator into decr_authenticator 5412 using decr_ticket.key; 5413 if (decryption_error()) then 5414 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5415 endif 5416 if (decr_authenticator.{cname,crealm} != 5417 decr_ticket.{cname,crealm}) then 5418 error_out(KRB_AP_ERR_BADMATCH); 5419 endif 5420 if (decr_ticket.caddr is present) then 5421 if (sender_address(packet) is not in decr_ticket.caddr) then 5422 error_out(KRB_AP_ERR_BADADDR); 5423 endif 5424 elseif (application requires addresses) then 5425 error_out(KRB_AP_ERR_BADADDR); 5426 endif 5427 if (not in_clock_skew(decr_authenticator.ctime, 5428 decr_authenticator.cusec)) then 5429 error_out(KRB_AP_ERR_SKEW); 5430 endif 5431 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 5432 error_out(KRB_AP_ERR_REPEAT); 5433 endif 5434 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 5435 get system_time; 5436 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 5437 (decr_ticket.flags.INVALID is set)) then 5438 /* it hasn't yet become valid */ 5439 error_out(KRB_AP_ERR_TKT_NYV); 5440 endif 5441 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 5442 error_out(KRB_AP_ERR_TKT_EXPIRED); 5443 endif 5444 /* caller must check decr_ticket.flags for any pertinent details */ 5446 Section A.10. - 96 - Expires 28 February 1993 5448 Version 5 - Revision 5.1 5450 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 5452 A.11. KRB_AP_REP generation 5453 packet.pvno := protocol version; /* 5 */ 5454 packet.msg-type := message type; /* KRB_AP_REP */ 5456 body.ctime := packet.ctime; 5457 body.cusec := packet.cusec; 5458 if (selecting sub-session key) then 5459 select sub-session key; 5460 body.subkey := sub-session key; 5461 endif 5462 if (using sequence numbers) then 5463 select initial sequence number; 5464 body.seq-number := initial sequence; 5465 endif 5467 encode body into OCTET STRING; 5469 select encryption type; 5470 encrypt OCTET STRING into packet.enc-part; 5472 A.12. KRB_AP_REP verification 5473 receive packet; 5474 if (packet.pvno != 5) then 5475 either process using other protocol spec 5476 or error_out(KRB_AP_ERR_BADVERSION); 5477 endif 5478 if (packet.msg-type != KRB_AP_REP) then 5479 error_out(KRB_AP_ERR_MSG_TYPE); 5480 endif 5481 cleartext := decrypt(packet.enc-part) using ticket's session key; 5482 if (decryption_error()) then 5483 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5484 endif 5485 if (cleartext.ctime != authenticator.ctime) then 5486 error_out(KRB_AP_ERR_MUT_FAIL); 5487 endif 5488 if (cleartext.cusec != authenticator.cusec) then 5489 error_out(KRB_AP_ERR_MUT_FAIL); 5490 endif 5491 if (cleartext.subkey is present) then 5492 save cleartext.subkey for future use; 5493 endif 5494 if (cleartext.seq-number is present) then 5495 save cleartext.seq-number for future verifications; 5496 endif 5497 return(AUTHENTICATION_SUCCEEDED); 5499 A.13. KRB_SAFE generation 5500 collect user data in buffer; 5502 /* assemble packet: */ 5503 packet.pvno := protocol version; /* 5 */ 5505 Section A.13. - 97 - Expires 28 February 1993 5507 Version 5 - Revision 5.1 5509 packet.msg-type := message type; /* KRB_SAFE */ 5511 body.user-data := buffer; /* DATA */ 5512 if (using timestamp) then 5513 get system_time; 5514 body.timestamp, body.usec := system_time; 5515 endif 5516 if (using sequence numbers) then 5517 body.seq-number := sequence number; 5518 endif 5519 body.s-address := sender host addresses; 5520 if (only one recipient) then 5521 body.r-address := recipient host address; 5522 endif 5523 checksum.cksumtype := checksum type; 5524 compute checksum over body; 5525 checksum.checksum := checksum value; /* checksum.checksum */ 5526 packet.cksum := checksum; 5527 packet.safe-body := body; 5529 A.14. KRB_SAFE verification 5530 receive packet; 5531 if (packet.pvno != 5) then 5532 either process using other protocol spec 5533 or error_out(KRB_AP_ERR_BADVERSION); 5534 endif 5535 if (packet.msg-type != KRB_SAFE) then 5536 error_out(KRB_AP_ERR_MSG_TYPE); 5537 endif 5538 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 5539 error_out(KRB_AP_ERR_INAPP_CKSUM); 5540 endif 5541 if (safe_priv_common_checks_ok(packet)) then 5542 set computed_checksum := checksum(packet.body); 5543 if (computed_checksum != packet.checksum) then 5544 error_out(KRB_AP_ERR_MODIFIED); 5545 endif 5546 return (packet, PACKET_IS_GENUINE); 5547 else 5548 return common_checks_error; 5549 endif 5551 A.15. KRB_SAFE and KRB_PRIV common checks 5552 if (packet.s-address != O/S_sender(packet)) then 5553 /* O/S report of sender not who claims to have sent it */ 5554 error_out(KRB_AP_ERR_BADADDR); 5555 endif 5556 if ((packet.r-address is present) and 5557 (packet.r-address != local_host_address)) then 5558 /* was not sent to proper place */ 5559 error_out(KRB_AP_ERR_BADADDR); 5560 endif 5561 if (((packet.timestamp is present) and 5562 (not in_clock_skew(packet.timestamp,packet.usec))) or 5564 Section A.15. - 98 - Expires 28 February 1993 5566 Version 5 - Revision 5.1 5568 (packet.timestamp is not present and timestamp expected)) then 5569 error_out(KRB_AP_ERR_SKEW); 5570 endif 5571 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 5572 error_out(KRB_AP_ERR_REPEAT); 5573 endif 5574 if (((packet.seq-number is present) and 5575 ((not in_sequence(packet.seq-number)))) or 5576 (packet.seq-number is not present and sequence expected)) then 5577 error_out(KRB_AP_ERR_BADORDER); 5578 endif 5579 if (packet.timestamp not present and packet.seq-number not present) then 5580 error_out(KRB_AP_ERR_MODIFIED); 5581 endif 5583 save_identifier(packet.{timestamp,usec,s-address}, 5584 sender_principal(packet)); 5586 return PACKET_IS_OK; 5588 A.16. KRB_PRIV generation 5589 collect user data in buffer; 5591 /* assemble packet: */ 5592 packet.pvno := protocol version; /* 5 */ 5593 packet.msg-type := message type; /* KRB_PRIV */ 5595 packet.enc-part.etype := encryption type; 5597 body.user-data := buffer; 5598 if (using timestamp) then 5599 get system_time; 5600 body.timestamp, body.usec := system_time; 5601 endif 5602 if (using sequence numbers) then 5603 body.seq-number := sequence number; 5604 endif 5605 body.s-address := sender host addresses; 5606 if (only one recipient) then 5607 body.r-address := recipient host address; 5608 endif 5610 encode body into OCTET STRING; 5612 select encryption type; 5613 encrypt OCTET STRING into packet.enc-part.cipher; 5615 A.17. KRB_PRIV verification 5616 receive packet; 5617 if (packet.pvno != 5) then 5618 either process using other protocol spec 5619 or error_out(KRB_AP_ERR_BADVERSION); 5620 endif 5622 Section A.17. - 99 - Expires 28 February 1993 5624 Version 5 - Revision 5.1 5626 if (packet.msg-type != KRB_PRIV) then 5627 error_out(KRB_AP_ERR_MSG_TYPE); 5628 endif 5630 cleartext := decrypt(packet.enc-part) using negotiated key; 5631 if (decryption_error()) then 5632 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5633 endif 5635 if (safe_priv_common_checks_ok(cleartext)) then 5636 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 5637 else 5638 return common_checks_error; 5639 endif 5641 A.18. KRB_ERROR generation 5643 /* assemble packet: */ 5644 packet.pvno := protocol version; /* 5 */ 5645 packet.msg-type := message type; /* KRB_ERROR */ 5647 get system_time; 5648 packet.stime, packet.susec := system_time; 5649 packet.realm, packet.sname := server name; 5651 if (client time available) then 5652 packet.ctime, packet.cusec := client_time; 5653 endif 5654 packet.error-code := error code; 5655 if (client name available) then 5656 packet.cname, packet.crealm := client name; 5657 endif 5658 if (error text available) then 5659 packet.e-text := error text; 5660 endif 5661 if (error data available) then 5662 packet.e-data := error data; 5663 endif 5665 - c - Expires 28 February 1993 5667 Table of Contents 5669 Overview .............................................. 1 5671 Background ............................................ 2 5673 1. Introduction ....................................... 2 5675 1.1. Cross-Realm Operation ............................ 4 5677 1.2. Environmental assumptions ........................ 5 5679 1.3. Glossary of terms ................................ 6 5681 2. Ticket flag uses and requests ...................... 9 5683 2.1. Initial and pre-authenticated tickets ............ 9 5685 2.2. Invalid tickets .................................. 9 5687 2.3. Renewable tickets ................................ 9 5689 2.4. Postdated tickets ................................ 10 5691 2.5. Proxiable and proxy tickets ...................... 11 5693 2.6. Forwardable tickets .............................. 12 5695 2.7. Other KDC options ................................ 12 5697 3. Message Exchanges .................................. 13 5699 3.1. The Authentication Service Exchange .............. 13 5701 3.1.1. Generation of KRB_AS_REQ message ............... 14 5703 3.1.2. Receipt of KRB_AS_REQ message .................. 14 5705 3.1.3. Generation of KRB_AS_REP message ............... 14 5707 3.1.4. Generation of KRB_ERROR message ................ 16 5709 3.1.5. Receipt of KRB_AS_REP message .................. 16 5711 3.1.6. Receipt of KRB_ERROR message ................... 17 5713 3.2. The Client/Server Authentication Exchange ........ 17 5715 - i - Expires 28 February 1993 5717 Version 5 - Revision 5.1 5719 3.2.1. The KRB_AP_REQ message ......................... 17 5721 3.2.2. Generation of a KRB_AP_REQ message ............. 18 5723 3.2.3. Receipt of KRB_AP_REQ message .................. 18 5725 3.2.4. Generation of a KRB_AP_REP message ............. 20 5727 3.2.5. Receipt of KRB_AP_REP message .................. 21 5729 3.2.6. Using the encryption key ....................... 21 5731 3.3. The Ticket-Granting Service (TGS) Exchange ....... 22 5733 3.3.1. Generation of KRB_TGS_REQ message .............. 23 5735 3.3.2. Receipt of KRB_TGS_REQ message ................. 24 5737 3.3.3. Generation of KRB_TGS_REP message .............. 25 5739 3.3.3.1. Encoding the transited field ................. 27 5741 3.3.4. Receipt of KRB_TGS_REP message ................. 29 5743 3.4. The KRB_SAFE Exchange ............................ 29 5745 3.4.1. Generation of a KRB_SAFE message ............... 29 5747 3.4.2. Receipt of KRB_SAFE message .................... 30 5749 3.5. The KRB_PRIV Exchange ............................ 30 5751 3.5.1. Generation of a KRB_PRIV message ............... 31 5753 3.5.2. Receipt of KRB_PRIV message .................... 31 5755 4. The Kerberos Database .............................. 32 5757 4.1. Database contents ................................ 32 5759 4.2. Additional fields ................................ 33 5761 4.3. Frequently Changing Fields ....................... 34 5763 4.4. Site Constants ................................... 34 5765 5. Message Specifications ............................. 35 5767 5.1. ASN.1 Distinguished Encoding Representation ...... 35 5769 5.2. ASN.1 Base Definitions ........................... 35 5771 5.3. Tickets and Authenticators ....................... 38 5773 - ii - Expires 28 February 1993 5775 Version 5 - Revision 5.1 5777 5.3.1. Tickets ........................................ 38 5779 5.3.2. Authenticators ................................. 44 5781 5.4. Specifications for the AS and TGS exchanges ...... 45 5783 5.4.1. KRB_KDC_REQ definition ......................... 45 5785 5.4.2. KRB_KDC_REP definition ......................... 52 5787 5.5. Client/Server (CS) message specifications ........ 55 5789 5.5.1. KRB_AP_REQ definition .......................... 55 5791 5.5.2. KRB_AP_REP definition .......................... 56 5793 5.5.3. Error message reply ............................ 57 5795 5.6. KRB_SAFE message specification ................... 57 5797 5.6.1. KRB_SAFE definition ............................ 57 5799 5.7. KRB_PRIV message specification ................... 59 5801 5.7.1. KRB_PRIV definition ............................ 59 5803 5.8. Error message specification ...................... 60 5805 5.8.1. KRB_ERROR definition ........................... 60 5807 6. Encryption and Checksum Specifications ............. 62 5809 6.1. Encryption Specifications ........................ 63 5811 6.2. Encryption Keys .................................. 65 5813 6.3. Encryption Systems ............................... 66 5815 6.3.1. The NULL Encryption System (null) .............. 66 5817 6.3.2. DES in CBC mode with a CRC-32 checksum (des- 5818 cbc-crc) .............................................. 66 5820 6.3.3. DES in CBC mode with an MD4 checksum (des- 5821 cbc-md4) .............................................. 67 5823 6.3.4. DES in CBC mode with an MD5 checksum (des- 5824 cbc-md5) .............................................. 67 5826 6.4. Checksums ........................................ 68 5828 6.4.1. The CRC-32 Checksum (crc32) .................... 69 5830 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 69 5832 - iii - Expires 28 February 1993 5834 Version 5 - Revision 5.1 5836 6.4.3. RSA MD4 Cryptographic Checksum Using DES 5837 (rsa-md4-des) ......................................... 70 5839 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 71 5841 6.4.5. RSA MD5 Cryptographic Checksum Using DES 5842 (rsa-md5-des) ......................................... 71 5844 6.4.6. DES cipher-block chained checksum (des-mac) 5846 6.4.7. RSA MD4 Cryptographic Checksum Using DES 5847 alternative (rsa-md4-des-k) ........................... 72 5849 6.4.8. DES cipher-block chained checksum alternative 5850 (des-mac-k) ........................................... 72 5852 7. Naming Constraints ................................. 73 5854 7.1. Realm Names ...................................... 73 5856 7.2. Principal Names .................................. 74 5858 8. Constants and other defined values ................. 75 5860 8.1. Host address types ............................... 75 5862 8.2. KDC messages ..................................... 76 5864 8.2.1. IP transport ................................... 76 5866 8.2.2. OSI transport .................................. 76 5868 8.2.3. Name of the TGS ................................ 77 5870 8.3. Protocol constants and associated values ......... 77 5872 9. Interoperability requirements ...................... 79 5874 9.1. Specification 1 .................................. 80 5876 9.2. Recommended KDC values ........................... 81 5878 10. Acknowledgments ................................... 81 5880 11. REFERENCES ........................................ 82 5882 A. Pseudo-code for protocol processing ................ 84 5884 A.1. KRB_AS_REQ generation ............................ 84 5886 A.2. KRB_AS_REQ verification and KRB_AS_REP genera- 5887 tion .................................................. 84 5889 A.3. KRB_AS_REP verification .......................... 87 5891 - iv - Expires 28 February 1993 5893 Version 5 - Revision 5.1 5895 A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 88 5897 A.5. KRB_TGS_REQ generation ........................... 88 5899 A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen- 5900 eration ............................................... 89 5902 A.7. KRB_TGS_REP verification ......................... 94 5904 A.8. Authenticator generation ......................... 95 5906 A.9. KRB_AP_REQ generation ............................ 95 5908 A.10. KRB_AP_REQ verification ......................... 95 5910 A.11. KRB_AP_REP generation ........................... 97 5912 A.12. KRB_AP_REP verification ......................... 97 5914 A.13. KRB_SAFE generation ............................. 97 5916 A.14. KRB_SAFE verification ........................... 98 5918 A.15. KRB_SAFE and KRB_PRIV common checks ............. 98 5920 A.16. KRB_PRIV generation ............................. 99 5922 A.17. KRB_PRIV verification ........................... 99 5924 A.18. KRB_ERROR generation ............................ 100 5926 - v - Expires 28 February 1993 5928 A. Pseudo-code for protocol processing 5930 This appendix provides pseudo-code describing how the 5931 messages are to be constructed and interpreted by clients 5932 and servers. 5934 A.1. KRB_AS_REQ generation 5935 request.pvno := protocol version; /* pvno = 5 */ 5936 request.msg-type := message type; /* type = KRB_AS_REQ */ 5938 body.kdc-options := users's preferences; 5939 body.cname := user's name; 5940 body.realm := user's realm; 5941 body.sname := service's name; /* usually "krbtgt", "localrealm" */ 5942 if (body.kdc-options.POSTDATED is set) then 5943 body.from := requested starting time; 5944 else 5945 omit body.from; 5946 endif 5947 body.till := requested end time; 5948 if (body.kdc-options.RENEWABLE is set) then 5949 body.rtime := requested final renewal time; 5950 endif 5951 body.nonce := random_nonce(); 5952 body.etype := requested etypes; 5953 if (user supplied addresses) then 5954 body.addresses := user's addresses; 5955 else 5956 omit body.addresses; 5957 endif 5958 omit body.enc-authorization-data; 5959 request.req-body := body; 5961 kerberos := lookup(name of local kerberos server (or servers)); 5962 send(packet,kerberos); 5964 wait(for response); 5965 if (timed_out) then 5966 retry or use alternate server; 5967 endif 5969 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 5970 decode message into req; 5972 client := lookup(req.cname,req.realm); 5973 server := lookup(req.sname,req.realm); 5975 get system_time; 5976 kdc_time := system_time.seconds; 5978 if (!client) then 5979 /* no client in Database */ 5980 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 5981 endif 5983 Section A.2. - 84 - Expires 28 February 1993 5985 Version 5 - Revision 5.1 5987 if (!server) then 5988 /* no server in Database */ 5989 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5990 endif 5992 use_etype := first supported etype in req.etypes; 5994 if (no support for req.etypes) then 5995 error_out(KDC_ERR_ETYPE_NOSUPP); 5996 endif 5998 new_tkt.vno := ticket version; /* = 5 */ 5999 new_tkt.sname := req.sname; 6000 new_tkt.srealm := req.srealm; 6001 reset all flags in new_tkt.flags; 6003 /* It should be noted that local policy may affect the */ 6004 /* processing of any of these flags. For example, some */ 6005 /* realms may refuse to issue renewable tickets */ 6007 if (req.kdc-options.FORWARDABLE is set) then 6008 set new_tkt.flags.FORWARDABLE; 6009 endif 6010 if (req.kdc-options.PROXIABLE is set) then 6011 set new_tkt.flags.PROXIABLE; 6012 endif 6013 if (req.kdc-options.ALLOW-POSTDATE is set) then 6014 set new_tkt.flags.ALLOW-POSTDATE; 6015 endif 6016 if ((req.kdc-options.RENEW is set) or 6017 (req.kdc-options.VALIDATE is set) or 6018 (req.kdc-options.PROXY is set) or 6019 (req.kdc-options.FORWARDED is set) or 6020 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 6021 error_out(KDC_ERR_BADOPTION); 6022 endif 6024 new_tkt.session := random_session_key(); 6025 new_tkt.cname := req.cname; 6026 new_tkt.crealm := req.crealm; 6027 new_tkt.transited := empty_transited_field(); 6029 new_tkt.authtime := kdc_time; 6031 if (req.kdc-options.POSTDATED is set) then 6032 if (against_postdate_policy(req.from)) then 6033 error_out(KDC_ERR_POLICY); 6034 endif 6035 set new_tkt.flags.INVALID; 6036 new_tkt.starttime := req.from; 6037 else 6038 omit new_tkt.starttime; /* treated as authtime when omitted */ 6039 endif 6040 if (req.till = 0) then 6042 Section A.2. - 85 - Expires 28 February 1993 6044 Version 5 - Revision 5.1 6046 till := infinity; 6047 else 6048 till := req.till; 6049 endif 6051 new_tkt.endtime := min(till, 6052 new_tkt.starttime+client.max_life, 6053 new_tkt.starttime+server.max_life, 6054 new_tkt.starttime+max_life_for_realm); 6056 if ((req.kdc-options.RENEWABLE-OK is set) and 6057 (new_tkt.endtime < req.till)) then 6058 /* we set the RENEWABLE option for later processing */ 6059 set req.kdc-options.RENEWABLE; 6060 req.rtime := req.till; 6061 endif 6063 if (req.rtime = 0) then 6064 rtime := infinity; 6065 else 6066 rtime := req.rtime; 6067 endif 6069 if (req.kdc-options.RENEWABLE is set) then 6070 set new_tkt.flags.RENEWABLE; 6071 new_tkt.renew-till := min(rtime, 6072 new_tkt.starttime+client.max_rlife, 6073 new_tkt.starttime+server.max_rlife, 6074 new_tkt.starttime+max_rlife_for_realm); 6075 else 6076 omit new_tkt.renew-till; /* only present if RENEWABLE */ 6077 endif 6079 if (req.addresses) then 6080 new_tkt.caddr := req.addresses; 6081 else 6082 omit new_tkt.caddr; 6083 endif 6085 new_tkt.authorization_data := empty_authorization_data(); 6087 encode to-be-encrypted part of ticket into OCTET STRING; 6088 new_tkt.enc-part := encrypt OCTET STRING 6089 using etype_for_key(server.key), server.key, server.p_kvno; 6091 /* Start processing the response */ 6093 resp.pvno := 5; 6094 resp.msg-type := KRB_AS_REP; 6095 resp.cname := req.cname; 6096 resp.crealm := req.realm; 6097 resp.ticket := new_tkt; 6099 Section A.2. - 86 - Expires 28 February 1993 6101 Version 5 - Revision 5.1 6103 resp.key := new_tkt.session; 6104 resp.last-req := fetch_last_request_info(client); 6105 resp.nonce := req.nonce; 6106 resp.key-expiration := client.expiration; 6107 resp.flags := new_tkt.flags; 6109 resp.authtime := new_tkt.authtime; 6110 resp.starttime := new_tkt.starttime; 6111 resp.endtime := new_tkt.endtime; 6113 if (new_tkt.flags.RENEWABLE) then 6114 resp.renew-till := new_tkt.renew-till; 6115 endif 6117 resp.realm := new_tkt.realm; 6118 resp.sname := new_tkt.sname; 6120 resp.caddr := new_tkt.caddr; 6122 encode body of reply into OCTET STRING; 6124 resp.enc-part := encrypt OCTET STRING 6125 using use_etype, client.key, client.p_kvno; 6126 send(resp); 6128 A.3. KRB_AS_REP verification 6129 decode response into resp; 6131 if (resp.msg-type = KRB_ERROR) then 6132 process_error(resp); 6133 return; 6134 endif 6136 /* On error, discard the response, and zero the session key */ 6137 /* from the response immediately */ 6139 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 6140 resp.padata); 6141 unencrypted part of resp := decode of decrypt of resp.enc-part 6142 using resp.enc-part.etype and key; 6143 zero(key); 6145 if (common_as_rep_tgs_rep_checks fail) then 6146 destroy resp.key; 6147 return error; 6148 endif 6150 if near(resp.princ_exp) then 6151 print(warning message); 6152 endif 6153 save_for_later(ticket,session,client,server,times,flags); 6155 Section A.3. - 87 - Expires 28 February 1993 6157 Version 5 - Revision 5.1 6159 A.4. KRB_AS_REP and KRB_TGS_REP common checks 6160 if (decryption_error() or 6161 (req.cname != resp.cname) or 6162 (req.realm != resp.crealm) or 6163 (req.sname != resp.sname) or 6164 (req.realm != resp.realm) or 6165 (req.nonce != resp.nonce) or 6166 (req.addresses != resp.caddr)) then 6167 destroy resp.key; 6168 return KRB_AP_ERR_MODIFIED; 6169 endif 6171 /* make sure no flags are set that shouldn't be, and that all that */ 6172 /* should be are set */ 6173 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 6174 destroy resp.key; 6175 return KRB_AP_ERR_MODIFIED; 6176 endif 6178 if ((req.from = 0) and 6179 (resp.starttime is not within allowable skew)) then 6180 destroy resp.key; 6181 return KRB_AP_ERR_SKEW; 6182 endif 6183 if ((req.from != 0) and (req.from != resp.starttime)) then 6184 destroy resp.key; 6185 return KRB_AP_ERR_MODIFIED; 6186 endif 6187 if ((req.till != 0) and (resp.endtime > req.till)) then 6188 destroy resp.key; 6189 return KRB_AP_ERR_MODIFIED; 6190 endif 6192 if ((req.kdc-options.RENEWABLE is set) and 6193 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 6194 destroy resp.key; 6195 return KRB_AP_ERR_MODIFIED; 6196 endif 6197 if ((req.kdc-options.RENEWABLE-OK is set) and 6198 (resp.flags.RENEWABLE) and 6199 (req.till != 0) and 6200 (resp.renew-till > req.till)) then 6201 destroy resp.key; 6202 return KRB_AP_ERR_MODIFIED; 6203 endif 6205 A.5. KRB_TGS_REQ generation 6206 /* Note that make_application_request might have to recursivly */ 6207 /* call this routine to get the appropriate ticket-granting ticket */ 6209 request.pvno := protocol version; /* pvno = 5 */ 6210 request.msg-type := message type; /* type = KRB_TGS_REQ */ 6212 body.kdc-options := users's preferences; 6214 Section A.5. - 88 - Expires 28 February 1993 6216 Version 5 - Revision 5.1 6218 body.sname := service's name; 6220 if (body.kdc-options.POSTDATED is set) then 6221 body.from := requested starting time; 6222 else 6223 omit body.from; 6224 endif 6225 body.till := requested end time; 6226 if (body.kdc-options.RENEWABLE is set) then 6227 body.rtime := requested final renewal time; 6228 endif 6229 body.nonce := random_nonce(); 6230 body.etype := requested etypes; 6231 if (user supplied addresses) then 6232 body.addresses := user's addresses; 6233 else 6234 omit body.addresses; 6235 endif 6237 body.enc-authorization-data := user-supplied data; 6238 if (body.kdc-options.ENC-TKT-IN-SKEY) then 6239 body.additional-tickets_ticket := second TGT; 6240 endif 6242 request.req-body := body; 6243 check := generate_checksum (req.body,checksumtype); 6245 request.padata[0].padata-type := PA-TGS-REQ; 6246 request.padata[0].padata-value := create a KRB_AP_REQ using 6247 the TGT and checksum 6249 /* add in any other padata as required/supplied */ 6251 kerberos := lookup(name of local kerberose server (or servers)); 6252 send(packet,kerberos); 6254 wait(for response); 6255 if (timed_out) then 6256 retry or use alternate server; 6257 endif 6259 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 6260 /* note that reading the application request requires first 6261 determining the server for which a ticket was issued, and choosing the 6262 correct key for decryption. The name of the server appears in the 6263 plaintext part of the ticket. */ 6265 if (no KRB_AP_REQ in req.padata) then 6266 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 6267 endif 6268 verify KRB_AP_REQ in req.padata; 6270 /* Note that the realm in which the Kerberos server is operating is 6271 determined by the instance from the ticket-granting ticket. The realm 6273 Section A.6. - 89 - Expires 28 February 1993 6275 Version 5 - Revision 5.1 6277 in the ticket-granting ticket is the realm under which the ticket 6278 granting ticket was issued. It is possible for a single Kerberos 6279 server to support more than one realm. */ 6281 auth_hdr := KRB_AP_REQ; 6282 tgt := auth_hdr.ticket; 6284 if (tgt.sname is not a TGT for local realm and is not req.sname) then 6285 error_out(KRB_AP_ERR_NOT_US); 6287 realm := realm_tgt_is_for(tgt); 6289 decode remainder of request; 6291 if (auth_hdr.authenticator.cksum type is not supported) then 6292 error_out(KDC_ERR_SUMTYPE_NOSUPP); 6293 endif 6294 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 6295 error_out(KRB_AP_ERR_INAPP_CKSUM); 6296 endif 6297 server := lookup(req.sname,realm); 6299 if (!server) then 6300 if (is_foreign_tgt_name(server)) then 6301 server := best_intermediate_tgs(server); 6302 else 6303 /* no server in Database */ 6304 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 6305 endif 6306 endif 6308 session := generate_random_session_key(); 6310 use_etype := first supported etype in req.etypes; 6312 if (no support for req.etypes) then 6313 error_out(KDC_ERR_ETYPE_NOSUPP); 6314 endif 6316 new_tkt.vno := ticket version; /* = 5 */ 6317 new_tkt.sname := req.sname; 6318 new_tkt.srealm := realm; 6319 reset all flags in new_tkt.flags; 6321 /* It should be noted that local policy may affect the */ 6322 /* processing of any of these flags. For example, some */ 6323 /* realms may refuse to issue renewable tickets */ 6325 new_tkt.caddr := tgt.caddr; 6326 resp.caddr := NULL; /* We only include this if they change */ 6327 if (req.kdc-options.FORWARDABLE is set) then 6328 if (tgt.flags.FORWARDABLE is reset) then 6329 error_out(KDC_ERR_BADOPTION); 6331 Section A.6. - 90 - Expires 28 February 1993 6333 Version 5 - Revision 5.1 6335 endif 6336 set new_tkt.flags.FORWARDABLE; 6337 endif 6338 if (req.kdc-options.FORWARDED is set) then 6339 if (tgt.flags.FORWARDABLE is reset) then 6340 error_out(KDC_ERR_BADOPTION); 6341 endif 6342 set new_tkt.flags.FORWARDED; 6343 new_tkt.caddr := req.addresses; 6344 resp.caddr := req.addresses; 6345 endif 6346 if (tgt.flags.FORWARDED is set) then 6347 set new_tkt.flags.FORWARDED; 6348 endif 6350 if (req.kdc-options.PROXIABLE is set) then 6351 if (tgt.flags.PROXIABLE is reset) 6352 error_out(KDC_ERR_BADOPTION); 6353 endif 6354 set new_tkt.flags.PROXIABLE; 6355 endif 6356 if (req.kdc-options.PROXY is set) then 6357 if (tgt.flags.PROXIABLE is reset) then 6358 error_out(KDC_ERR_BADOPTION); 6359 endif 6360 set new_tkt.flags.PROXY; 6361 new_tkt.caddr := req.addresses; 6362 resp.caddr := req.addresses; 6363 endif 6365 if (req.kdc-options.POSTDATE is set) then 6366 if (tgt.flags.POSTDATE is reset) 6367 error_out(KDC_ERR_BADOPTION); 6368 endif 6369 set new_tkt.flags.POSTDATE; 6370 endif 6371 if (req.kdc-options.POSTDATED is set) then 6372 if (tgt.flags.POSTDATE is reset) then 6373 error_out(KDC_ERR_BADOPTION); 6374 endif 6375 set new_tkt.flags.POSTDATED; 6376 set new_tkt.flags.INVALID; 6377 if (against_postdate_policy(req.from)) then 6378 error_out(KDC_ERR_POLICY); 6379 endif 6380 new_tkt.starttime := req.from; 6381 endif 6383 if (req.kdc-options.VALIDATE is set) then 6384 if (tgt.flags.INVALID is reset) then 6385 error_out(KDC_ERR_POLICY); 6386 endif 6387 if (tgt.starttime > kdc_time) then 6389 Section A.6. - 91 - Expires 28 February 1993 6391 Version 5 - Revision 5.1 6393 error_out(KRB_AP_ERR_NYV); 6394 endif 6395 if (check_hot_list(tgt)) then 6396 error_out(KRB_AP_ERR_REPEAT); 6397 endif 6398 tkt := tgt; 6399 reset new_tkt.flags.INVALID; 6400 endif 6402 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 6403 and those already processed) is set) then 6404 error_out(KDC_ERR_BADOPTION); 6405 endif 6407 new_tkt.authtime := tgt.authtime; 6409 if (req.kdc-options.RENEW is set) then 6410 /* Note that if the endtime has already passed, the ticket would */ 6411 /* have been rejected in the initial authentication stage, so */ 6412 /* there is no need to check again here */ 6413 if (tgt.flags.RENEWABLE is reset) then 6414 error_out(KDC_ERR_BADOPTION); 6415 endif 6416 if (tgt.renew-till >= kdc_time) then 6417 error_out(KRB_AP_ERR_TKT_EXPIRED); 6418 endif 6419 tkt := tgt; 6420 new_tkt.starttime := kdc_time; 6421 old_life := tgt.endttime - tgt.starttime; 6422 new_tkt.endtime := min(tgt.renew-till, 6423 new_tkt.starttime + old_life); 6424 else 6425 new_tkt.starttime := kdc_time; 6426 if (req.till = 0) then 6427 till := infinity; 6428 else 6429 till := req.till; 6430 endif 6431 new_tkt.endtime := min(till, 6432 new_tkt.starttime+client.max_life, 6433 new_tkt.starttime+server.max_life, 6434 new_tkt.starttime+max_life_for_realm, 6435 tgt.endtime); 6437 if ((req.kdc-options.RENEWABLE-OK is set) and 6438 (new_tkt.endtime < req.till) and 6439 (tgt.flags.RENEWABLE is set) then 6440 /* we set the RENEWABLE option for later processing */ 6441 set req.kdc-options.RENEWABLE; 6442 req.rtime := min(req.till, tgt.renew-till); 6443 endif 6444 endif 6446 if (req.rtime = 0) then 6448 Section A.6. - 92 - Expires 28 February 1993 6450 Version 5 - Revision 5.1 6452 rtime := infinity; 6453 else 6454 rtime := req.rtime; 6455 endif 6457 if ((req.kdc-options.RENEWABLE is set) and 6458 (tgt.flags.RENEWABLE is set)) then 6459 set new_tkt.flags.RENEWABLE; 6460 new_tkt.renew-till := min(rtime, 6461 new_tkt.starttime+client.max_rlife, 6462 new_tkt.starttime+server.max_rlife, 6463 new_tkt.starttime+max_rlife_for_realm, 6464 tgt.renew-till); 6465 else 6466 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 6467 endif 6468 if (req.enc-authorization-data is present) then 6469 decrypt req.enc-authorization-data into decrypted_authorization_data 6470 using auth_hdr.authenticator.subkey; 6471 if (decrypt_error()) then 6472 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6473 endif 6474 endif 6475 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 6476 decrypted_authorization_data; 6478 new_tkt.key := session; 6479 new_tkt.crealm := tgt.crealm; 6480 new_tkt.cname := req.auth_hdr.ticket.cname; 6482 if (realm_tgt_is_for(tgt) := tgt.realm) then 6483 /* tgt issued by local realm */ 6484 new_tkt.transited := tgt.transited; 6485 else 6486 /* was issued for this realm by some other realm */ 6487 if (tgt.transited.tr-type not supported) then 6488 error_out(KDC_ERR_TRTYPE_NOSUPP); 6489 endif 6490 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 6491 endif 6493 encode encrypted part of new_tkt into OCTET STRING; 6494 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 6495 if (req.second_ticket is not a TGT) then 6496 error_out(KDC_ERR_POLICY); 6497 endif 6499 new_tkt.enc-part := encrypt OCTET STRING using 6500 using etype_for_key(second-ticket.key), second-ticket.key; 6501 else 6502 new_tkt.enc-part := encrypt OCTET STRING 6503 using etype_for_key(server.key), server.key, server.p_kvno; 6504 endif 6506 Section A.6. - 93 - Expires 28 February 1993 6508 Version 5 - Revision 5.1 6510 resp.pvno := 5; 6511 resp.msg-type := KRB_TGS_REP; 6512 resp.crealm := tgt.crealm; 6513 resp.cname := tgt.cname; 6515 resp.ticket := new_tkt; 6517 resp.key := session; 6518 resp.nonce := req.nonce; 6519 resp.last-req := fetch_last_request_info(client); 6520 resp.flags := new_tkt.flags; 6522 resp.authtime := new_tkt.authtime; 6523 resp.starttime := new_tkt.starttime; 6524 resp.endtime := new_tkt.endtime; 6526 omit resp.key-expiration; 6528 resp.sname := new_tkt.sname; 6529 resp.realm := new_tkt.realm; 6531 if (new_tkt.flags.RENEWABLE) then 6532 resp.renew-till := new_tkt.renew-till; 6533 endif 6535 encode body of reply into OCTET STRING; 6537 if (req.padata.authenticator.subkey) 6538 resp.enc-part := encrypt OCTET STRING using use_etype, 6539 req.padata.authenticator.subkey; 6540 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 6542 send(resp); 6544 A.7. KRB_TGS_REP verification 6545 decode response into resp; 6547 if (resp.msg-type = KRB_ERROR) then 6548 process_error(resp); 6549 return; 6550 endif 6552 /* On error, discard the response, and zero the session key from 6553 the response immediately */ 6555 if (req.padata.authenticator.subkey) 6556 unencrypted part of resp := decode of decrypt of resp.enc-part 6557 using resp.enc-part.etype and subkey; 6558 else unencrypted part of resp := decode of decrypt of resp.enc-part 6559 using resp.enc-part.etype and tgt's session key; 6560 if (common_as_rep_tgs_rep_checks fail) then 6561 destroy resp.key; 6562 return error; 6564 Section A.7. - 94 - Expires 28 February 1993 6566 Version 5 - Revision 5.1 6568 endif 6570 check authorization_data as necessary; 6571 save_for_later(ticket,session,client,server,times,flags); 6573 A.8. Authenticator generation 6574 body.authenticator-vno := authenticator vno; /* = 5 */ 6575 body.cname, body.crealm := client name; 6576 if (supplying checksum) then 6577 body.cksum := checksum; 6578 endif 6579 get system_time; 6580 body.ctime, body.cusec := system_time; 6581 if (selecting sub-session key) then 6582 select sub-session key; 6583 body.subkey := sub-session key; 6584 endif 6585 if (using sequence numbers) then 6586 select initial sequence number; 6587 body.seq-number := initial sequence; 6588 endif 6590 A.9. KRB_AP_REQ generation 6591 obtain ticket and session_key from cache; 6593 packet.pvno := protocol version; /* 5 */ 6594 packet.msg-type := message type; /* KRB_AP_REQ */ 6596 if (desired(MUTUAL_AUTHENTICATION)) then 6597 set packet.ap-options.MUTUAL-REQUIRED; 6598 else 6599 reset packet.ap-options.MUTUAL-REQUIRED; 6600 endif 6601 if (using session key for ticket) then 6602 set packet.ap-options.USE-SESSION-KEY; 6603 else 6604 reset packet.ap-options.USE-SESSION-KEY; 6605 endif 6606 packet.ticket := ticket; /* ticket */ 6607 generate authenticator; 6608 encode authenticator into OCTET STRING; 6609 encrypt OCTET STRING into packet.authenticator using session_key; 6611 A.10. KRB_AP_REQ verification 6612 receive packet; 6613 if (packet.pvno != 5) then 6614 either process using other protocol spec 6615 or error_out(KRB_AP_ERR_BADVERSION); 6616 endif 6617 if (packet.msg-type != KRB_AP_REQ) then 6618 error_out(KRB_AP_ERR_MSG_TYPE); 6619 endif 6620 if (packet.ticket.tkt_vno != 5) then 6621 either process using other protocol spec 6623 Section A.10. - 95 - Expires 28 February 1993 6625 Version 5 - Revision 5.1 6627 or error_out(KRB_AP_ERR_BADVERSION); 6628 endif 6629 if (packet.ap_options.USE-SESSION-KEY is set) then 6630 retrieve session key from ticket-granting ticket for 6631 packet.ticket.{sname,srealm,enc-part.etype}; 6632 else 6633 retrieve service key for 6634 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 6635 endif 6636 if (no_key_available) then 6637 if (cannot_find_specified_skvno) then 6638 error_out(KRB_AP_ERR_BADKEYVER); 6639 else 6640 error_out(KRB_AP_ERR_NOKEY); 6641 endif 6642 endif 6643 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 6644 if (decryption_error()) then 6645 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6646 endif 6647 decrypt packet.authenticator into decr_authenticator 6648 using decr_ticket.key; 6649 if (decryption_error()) then 6650 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6651 endif 6652 if (decr_authenticator.{cname,crealm} != 6653 decr_ticket.{cname,crealm}) then 6654 error_out(KRB_AP_ERR_BADMATCH); 6655 endif 6656 if (decr_ticket.caddr is present) then 6657 if (sender_address(packet) is not in decr_ticket.caddr) then 6658 error_out(KRB_AP_ERR_BADADDR); 6659 endif 6660 elseif (application requires addresses) then 6661 error_out(KRB_AP_ERR_BADADDR); 6662 endif 6663 if (not in_clock_skew(decr_authenticator.ctime, 6664 decr_authenticator.cusec)) then 6665 error_out(KRB_AP_ERR_SKEW); 6666 endif 6667 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 6668 error_out(KRB_AP_ERR_REPEAT); 6669 endif 6670 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 6671 get system_time; 6672 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 6673 (decr_ticket.flags.INVALID is set)) then 6674 /* it hasn't yet become valid */ 6675 error_out(KRB_AP_ERR_TKT_NYV); 6676 endif 6677 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 6678 error_out(KRB_AP_ERR_TKT_EXPIRED); 6679 endif 6680 /* caller must check decr_ticket.flags for any pertinent details */ 6682 Section A.10. - 96 - Expires 28 February 1993 6684 Version 5 - Revision 5.1 6686 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 6688 A.11. KRB_AP_REP generation 6689 packet.pvno := protocol version; /* 5 */ 6690 packet.msg-type := message type; /* KRB_AP_REP */ 6692 body.ctime := packet.ctime; 6693 body.cusec := packet.cusec; 6694 if (selecting sub-session key) then 6695 select sub-session key; 6696 body.subkey := sub-session key; 6697 endif 6698 if (using sequence numbers) then 6699 select initial sequence number; 6700 body.seq-number := initial sequence; 6701 endif 6703 encode body into OCTET STRING; 6705 select encryption type; 6706 encrypt OCTET STRING into packet.enc-part; 6708 A.12. KRB_AP_REP verification 6709 receive packet; 6710 if (packet.pvno != 5) then 6711 either process using other protocol spec 6712 or error_out(KRB_AP_ERR_BADVERSION); 6713 endif 6714 if (packet.msg-type != KRB_AP_REP) then 6715 error_out(KRB_AP_ERR_MSG_TYPE); 6716 endif 6717 cleartext := decrypt(packet.enc-part) using ticket's session key; 6718 if (decryption_error()) then 6719 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6720 endif 6721 if (cleartext.ctime != authenticator.ctime) then 6722 error_out(KRB_AP_ERR_MUT_FAIL); 6723 endif 6724 if (cleartext.cusec != authenticator.cusec) then 6725 error_out(KRB_AP_ERR_MUT_FAIL); 6726 endif 6727 if (cleartext.subkey is present) then 6728 save cleartext.subkey for future use; 6729 endif 6730 if (cleartext.seq-number is present) then 6731 save cleartext.seq-number for future verifications; 6732 endif 6733 return(AUTHENTICATION_SUCCEEDED); 6735 A.13. KRB_SAFE generation 6736 collect user data in buffer; 6738 /* assemble packet: */ 6739 packet.pvno := protocol version; /* 5 */ 6741 Section A.13. - 97 - Expires 28 February 1993 6743 Version 5 - Revision 5.1 6745 packet.msg-type := message type; /* KRB_SAFE */ 6747 body.user-data := buffer; /* DATA */ 6748 if (using timestamp) then 6749 get system_time; 6750 body.timestamp, body.usec := system_time; 6751 endif 6752 if (using sequence numbers) then 6753 body.seq-number := sequence number; 6754 endif 6755 body.s-address := sender host addresses; 6756 if (only one recipient) then 6757 body.r-address := recipient host address; 6758 endif 6759 checksum.cksumtype := checksum type; 6760 compute checksum over body; 6761 checksum.checksum := checksum value; /* checksum.checksum */ 6762 packet.cksum := checksum; 6763 packet.safe-body := body; 6765 A.14. KRB_SAFE verification 6766 receive packet; 6767 if (packet.pvno != 5) then 6768 either process using other protocol spec 6769 or error_out(KRB_AP_ERR_BADVERSION); 6770 endif 6771 if (packet.msg-type != KRB_SAFE) then 6772 error_out(KRB_AP_ERR_MSG_TYPE); 6773 endif 6774 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 6775 error_out(KRB_AP_ERR_INAPP_CKSUM); 6776 endif 6777 if (safe_priv_common_checks_ok(packet)) then 6778 set computed_checksum := checksum(packet.body); 6779 if (computed_checksum != packet.checksum) then 6780 error_out(KRB_AP_ERR_MODIFIED); 6781 endif 6782 return (packet, PACKET_IS_GENUINE); 6783 else 6784 return common_checks_error; 6785 endif 6787 A.15. KRB_SAFE and KRB_PRIV common checks 6788 if (packet.s-address != O/S_sender(packet)) then 6789 /* O/S report of sender not who claims to have sent it */ 6790 error_out(KRB_AP_ERR_BADADDR); 6791 endif 6792 if ((packet.r-address is present) and 6793 (packet.r-address != local_host_address)) then 6794 /* was not sent to proper place */ 6795 error_out(KRB_AP_ERR_BADADDR); 6796 endif 6797 if (((packet.timestamp is present) and 6798 (not in_clock_skew(packet.timestamp,packet.usec))) or 6800 Section A.15. - 98 - Expires 28 February 1993 6802 Version 5 - Revision 5.1 6804 (packet.timestamp is not present and timestamp expected)) then 6805 error_out(KRB_AP_ERR_SKEW); 6806 endif 6807 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6808 error_out(KRB_AP_ERR_REPEAT); 6809 endif 6810 if (((packet.seq-number is present) and 6811 ((not in_sequence(packet.seq-number)))) or 6812 (packet.seq-number is not present and sequence expected)) then 6813 error_out(KRB_AP_ERR_BADORDER); 6814 endif 6815 if (packet.timestamp not present and packet.seq-number not present) then 6816 error_out(KRB_AP_ERR_MODIFIED); 6817 endif 6819 save_identifier(packet.{timestamp,usec,s-address}, 6820 sender_principal(packet)); 6822 return PACKET_IS_OK; 6824 A.16. KRB_PRIV generation 6825 collect user data in buffer; 6827 /* assemble packet: */ 6828 packet.pvno := protocol version; /* 5 */ 6829 packet.msg-type := message type; /* KRB_PRIV */ 6831 packet.enc-part.etype := encryption type; 6833 body.user-data := buffer; 6834 if (using timestamp) then 6835 get system_time; 6836 body.timestamp, body.usec := system_time; 6837 endif 6838 if (using sequence numbers) then 6839 body.seq-number := sequence number; 6840 endif 6841 body.s-address := sender host addresses; 6842 if (only one recipient) then 6843 body.r-address := recipient host address; 6844 endif 6846 encode body into OCTET STRING; 6848 select encryption type; 6849 encrypt OCTET STRING into packet.enc-part.cipher; 6851 A.17. KRB_PRIV verification 6852 receive packet; 6853 if (packet.pvno != 5) then 6854 either process using other protocol spec 6855 or error_out(KRB_AP_ERR_BADVERSION); 6856 endif 6858 Section A.17. - 99 - Expires 28 February 1993 6860 Version 5 - Revision 5.1 6862 if (packet.msg-type != KRB_PRIV) then 6863 error_out(KRB_AP_ERR_MSG_TYPE); 6864 endif 6866 cleartext := decrypt(packet.enc-part) using negotiated key; 6867 if (decryption_error()) then 6868 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6869 endif 6871 if (safe_priv_common_checks_ok(cleartext)) then 6872 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 6873 else 6874 return common_checks_error; 6875 endif 6877 A.18. KRB_ERROR generation 6879 /* assemble packet: */ 6880 packet.pvno := protocol version; /* 5 */ 6881 packet.msg-type := message type; /* KRB_ERROR */ 6883 get system_time; 6884 packet.stime, packet.susec := system_time; 6885 packet.realm, packet.sname := server name; 6887 if (client time available) then 6888 packet.ctime, packet.cusec := client_time; 6889 endif 6890 packet.error-code := error code; 6891 if (client name available) then 6892 packet.cname, packet.crealm := client name; 6893 endif 6894 if (error text available) then 6895 packet.e-text := error text; 6896 endif 6897 if (error data available) then 6898 packet.e-data := error data; 6899 endif 6901 - c - Expires 28 February 1993 6903 Table of Contents 6905 Overview .............................................. 1 6907 Background ............................................ 2 6909 1. Introduction ....................................... 2 6911 1.1. Cross-Realm Operation ............................ 4 6913 1.2. Environmental assumptions ........................ 5 6915 1.3. Glossary of terms ................................ 6 6917 2. Ticket flag uses and requests ...................... 9 6919 2.1. Initial and pre-authenticated tickets ............ 9 6921 2.2. Invalid tickets .................................. 9 6923 2.3. Renewable tickets ................................ 9 6925 2.4. Postdated tickets ................................ 10 6927 2.5. Proxiable and proxy tickets ...................... 11 6929 2.6. Forwardable tickets .............................. 12 6931 2.7. Other KDC options ................................ 12 6933 3. Message Exchanges .................................. 13 6935 3.1. The Authentication Service Exchange .............. 13 6937 3.1.1. Generation of KRB_AS_REQ message ............... 14 6939 3.1.2. Receipt of KRB_AS_REQ message .................. 14 6941 3.1.3. Generation of KRB_AS_REP message ............... 14 6943 3.1.4. Generation of KRB_ERROR message ................ 16 6945 3.1.5. Receipt of KRB_AS_REP message .................. 16 6947 3.1.6. Receipt of KRB_ERROR message ................... 17 6949 3.2. The Client/Server Authentication Exchange ........ 17 6951 - i - Expires 28 February 1993 6953 Version 5 - Revision 5.1 6955 3.2.1. The KRB_AP_REQ message ......................... 17 6957 3.2.2. Generation of a KRB_AP_REQ message ............. 18 6959 3.2.3. Receipt of KRB_AP_REQ message .................. 18 6961 3.2.4. Generation of a KRB_AP_REP message ............. 20 6963 3.2.5. Receipt of KRB_AP_REP message .................. 21 6965 3.2.6. Using the encryption key ....................... 21 6967 3.3. The Ticket-Granting Service (TGS) Exchange ....... 22 6969 3.3.1. Generation of KRB_TGS_REQ message .............. 23 6971 3.3.2. Receipt of KRB_TGS_REQ message ................. 24 6973 3.3.3. Generation of KRB_TGS_REP message .............. 25 6975 3.3.3.1. Encoding the transited field ................. 27 6977 3.3.4. Receipt of KRB_TGS_REP message ................. 29 6979 3.4. The KRB_SAFE Exchange ............................ 29 6981 3.4.1. Generation of a KRB_SAFE message ............... 29 6983 3.4.2. Receipt of KRB_SAFE message .................... 30 6985 3.5. The KRB_PRIV Exchange ............................ 30 6987 3.5.1. Generation of a KRB_PRIV message ............... 31 6989 3.5.2. Receipt of KRB_PRIV message .................... 31 6991 4. The Kerberos Database .............................. 32 6993 4.1. Database contents ................................ 32 6995 4.2. Additional fields ................................ 33 6997 4.3. Frequently Changing Fields ....................... 34 6999 4.4. Site Constants ................................... 34 7001 5. Message Specifications ............................. 35 7003 5.1. ASN.1 Distinguished Encoding Representation ...... 35 7005 5.2. ASN.1 Base Definitions ........................... 35 7007 5.3. Tickets and Authenticators ....................... 38 7009 - ii - Expires 28 February 1993 7011 Version 5 - Revision 5.1 7013 5.3.1. Tickets ........................................ 38 7015 5.3.2. Authenticators ................................. 44 7017 5.4. Specifications for the AS and TGS exchanges ...... 45 7019 5.4.1. KRB_KDC_REQ definition ......................... 45 7021 5.4.2. KRB_KDC_REP definition ......................... 52 7023 5.5. Client/Server (CS) message specifications ........ 55 7025 5.5.1. KRB_AP_REQ definition .......................... 55 7027 5.5.2. KRB_AP_REP definition .......................... 56 7029 5.5.3. Error message reply ............................ 57 7031 5.6. KRB_SAFE message specification ................... 57 7033 5.6.1. KRB_SAFE definition ............................ 57 7035 5.7. KRB_PRIV message specification ................... 59 7037 5.7.1. KRB_PRIV definition ............................ 59 7039 5.8. Error message specification ...................... 60 7041 5.8.1. KRB_ERROR definition ........................... 60 7043 6. Encryption and Checksum Specifications ............. 62 7045 6.1. Encryption Specifications ........................ 63 7047 6.2. Encryption Keys .................................. 65 7049 6.3. Encryption Systems ............................... 66 7051 6.3.1. The NULL Encryption System (null) .............. 66 7053 6.3.2. DES in CBC mode with a CRC-32 checksum (des- 7054 cbc-crc) .............................................. 66 7056 6.3.3. DES in CBC mode with an MD4 checksum (des- 7057 cbc-md4) .............................................. 67 7059 6.3.4. DES in CBC mode with an MD5 checksum (des- 7060 cbc-md5) .............................................. 67 7062 6.4. Checksums ........................................ 68 7064 6.4.1. The CRC-32 Checksum (crc32) .................... 69 7066 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 69 7068 - iii - Expires 28 February 1993 7070 Version 5 - Revision 5.1 7072 6.4.3. RSA MD4 Cryptographic Checksum Using DES 7073 (rsa-md4-des) ......................................... 70 7075 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 71 7077 6.4.5. RSA MD5 Cryptographic Checksum Using DES 7078 (rsa-md5-des) ......................................... 71 7080 6.4.6. DES cipher-block chained checksum (des-mac) 7082 6.4.7. RSA MD4 Cryptographic Checksum Using DES 7083 alternative (rsa-md4-des-k) ........................... 72 7085 6.4.8. DES cipher-block chained checksum alternative 7086 (des-mac-k) ........................................... 72 7088 7. Naming Constraints ................................. 73 7090 7.1. Realm Names ...................................... 73 7092 7.2. Principal Names .................................. 74 7094 8. Constants and other defined values ................. 75 7096 8.1. Host address types ............................... 75 7098 8.2. KDC messages ..................................... 76 7100 8.2.1. IP transport ................................... 76 7102 8.2.2. OSI transport .................................. 76 7104 8.2.3. Name of the TGS ................................ 77 7106 8.3. Protocol constants and associated values ......... 77 7108 9. Interoperability requirements ...................... 79 7110 9.1. Specification 1 .................................. 80 7112 9.2. Recommended KDC values ........................... 81 7114 10. Acknowledgments ................................... 81 7116 11. REFERENCES ........................................ 82 7118 A. Pseudo-code for protocol processing ................ 84 7120 A.1. KRB_AS_REQ generation ............................ 84 7122 A.2. KRB_AS_REQ verification and KRB_AS_REP genera- 7123 tion .................................................. 84 7125 A.3. KRB_AS_REP verification .......................... 87 7127 - iv - Expires 28 February 1993 7129 Version 5 - Revision 5.1 7131 A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 88 7133 A.5. KRB_TGS_REQ generation ........................... 88 7135 A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen- 7136 eration ............................................... 89 7138 A.7. KRB_TGS_REP verification ......................... 94 7140 A.8. Authenticator generation ......................... 95 7142 A.9. KRB_AP_REQ generation ............................ 95 7144 A.10. KRB_AP_REQ verification ......................... 95 7146 A.11. KRB_AP_REP generation ........................... 97 7148 A.12. KRB_AP_REP verification ......................... 97 7150 A.13. KRB_SAFE generation ............................. 97 7152 A.14. KRB_SAFE verification ........................... 98 7154 A.15. KRB_SAFE and KRB_PRIV common checks ............. 98 7156 A.16. KRB_PRIV generation ............................. 99 7158 A.17. KRB_PRIV verification ........................... 99 7160 A.18. KRB_ERROR generation ............................ 100 7162 - v - Expires 28 February 1993