idnits 2.17.1 draft-ietf-cat-kerberos-02.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-25) 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 7590 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 1720 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 19 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** There are 4255 instances of lines with control characters in the document. ** The abstract seems to contain references ([1,2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 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 2272: '... starttime[6] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2274: '... renew-till[8] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2275: '... caddr[9] HostAddresses OPTIONAL,...' RFC 2119 keyword, line 2276: '... authorization-data[10] AuthorizationData OPTIONAL...' RFC 2119 keyword, line 2564: '... cksum[3] Checksum OPTIONAL,...' (53 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...e that other...' == Line 13 has weird spacing: '...ups may also ...' == Line 17 has weird spacing: '...of six month...' == Line 18 has weird spacing: '...ents at any ...' == Line 19 has weird spacing: '...opriate to us...' == (1715 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. -- Couldn't find a document date in the document -- date freshness check skipped. -- 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 4258 looks like a reference -- Missing reference section? '2' on line 3831 looks like a reference -- Missing reference section? '3' on line 3615 looks like a reference -- Missing reference section? '4' on line 3616 looks like a reference -- Missing reference section? '5' on line 3617 looks like a reference -- Missing reference section? '6' on line 3618 looks like a reference -- Missing reference section? '7' on line 3619 looks like a reference -- Missing reference section? '8' on line 3620 looks like a reference -- Missing reference section? '9' on line 3621 looks like a reference -- Missing reference section? '10' on line 3622 looks like a reference -- Missing reference section? '11' on line 3978 looks like a reference -- Missing reference section? '12' on line 3979 looks like a reference -- Missing reference section? '13' on line 4119 looks like a reference -- Missing reference section? '14' on line 4115 looks like a reference -- Missing reference section? '15' on line 4128 looks like a reference -- Missing reference section? '16' on line 4174 looks like a reference -- Missing reference section? '17' on line 4844 looks like a reference -- Missing reference section? '18' on line 1624 looks like a reference -- Missing reference section? '19' on line 1627 looks like a reference -- Missing reference section? '20' on line 1916 looks like a reference -- Missing reference section? '21' on line 2039 looks like a reference -- Missing reference section? '0' on line 5305 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 2253 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 2260 looks like a reference -- Missing reference section? '22' on line 2481 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 2560 looks like a reference -- Missing reference section? '23' on line 2977 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 3051 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 3052 looks like a reference -- Missing reference section? 'APPLICATION 26' on line 3065 looks like a reference -- Missing reference section? '25' on line 3091 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 3188 looks like a reference -- Missing reference section? '27' on line 3304 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 3333 looks like a reference -- Missing reference section? '29' on line 3413 looks like a reference -- Missing reference section? 'APPLICATION 21' on line 3420 looks like a reference -- Missing reference section? '30' on line 3459 looks like a reference -- Missing reference section? 'APPLICATION 22' on line 3486 looks like a reference -- Missing reference section? 'APPLICATION 29' on line 3493 looks like a reference -- Missing reference section? 'APPLICATION 30' on line 3611 looks like a reference -- Missing reference section? '32' on line 3840 looks like a reference -- Missing reference section? '33' on line 3897 looks like a reference -- Missing reference section? '34' on line 4076 looks like a reference -- Missing reference section? '35' on line 4186 looks like a reference Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 46 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 21 April 1993 6 The Kerberos Network Authentication Service (V5) 8 STATUS OF THIS MEMO 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 ABSTRACT 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 OVERVIEW 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 15 October 1993 55 Version 5 - Revision 5.2 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. 67 BACKGROUND 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. Introduction 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 [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. 108 [2] Secret and private are often used interchangeably 109 in the literature. In our usage, it takes two (or 110 more) to share a secret, thus a shared DES key is a 111 secret key. Something is only private when no one but 113 Section 1. - 2 - Expires 15 October 1993 115 Version 5 - Revision 5.2 117 The authentication process proceeds as follows: A 118 client sends a request to the authentication server (AS) 119 requesting "credentials" for a given server. The AS 120 responds with these credentials, encrypted in the client's 121 key. The credentials consist of 1) a "ticket" for the 122 server and 2) a temporary encryption key (often called a 123 "session key"). The client transmits the ticket (which con- 124 tains the client's identity and a copy of the session key, 125 all encrypted in the server's key) to the server. The ses- 126 sion key (now shared by the client and server) is used to 127 authenticate the client, and may optionally be used to 128 authenticate the server. It may also be used to encrypt 129 further communication between the two parties or to exchange 130 a separate sub-session key to be used to encrypt further 131 communication. 133 The implementation consists of one or more authentica- 134 tion servers running on physically secure hosts. The 135 authentication servers maintain a database of principals 136 (i.e., users and servers) and their secret keys. Code 137 libraries provide encryption and implement the Kerberos pro- 138 tocol. In order to add authentication to its transactions, 139 a typical network application adds one or two calls to the 140 Kerberos library, which results in the transmission of the 141 necessary messages to achieve authentication. 143 The Kerberos protocol consists of several sub-protocols 144 (or exchanges). There are two methods by which a client can 145 ask a Kerberos server for credentials. In the first 146 approach, the client sends a cleartext request for a ticket 147 for the desired server to the AS. The reply is sent 148 encrypted in the client's secret key. Usually this request 149 is for a ticket-granting ticket (TGT) which can later be 150 used with the ticket-granting server (TGS). In the second 151 method, the client sends a request to the TGS. The client 152 sends the TGT to the TGS in the same manner as if it were 153 contacting any other application server which requires Ker- 154 beros credentials. The reply is encrypted in the session 155 key from the TGT. 157 Once obtained, credentials may be used to verify the 158 identity of the principals in a transaction, to ensure the 159 integrity of messages exchanged between them, or to preserve 160 privacy of the messages. The application is free to choose 161 whatever protection may be necessary. 163 To verify the identities of the principals in a tran- 164 saction, the client transmits the ticket to the server. 165 Since the ticket is sent "in the clear" (parts of it are 166 encrypted, but this encryption doesn't thwart replay) and 167 __________________________ 168 its owner knows it. Thus, in public key cryptosystems, 169 one has a public and a private key. 171 Section 1. - 3 - Expires 15 October 1993 173 Version 5 - Revision 5.2 175 might be intercepted and reused by an attacker, additional 176 information is sent to prove that the message was originated 177 by the principal to whom the ticket was issued. This infor- 178 mation (called the authenticator) is encrypted in the ses- 179 sion key, and includes a timestamp. The timestamp proves 180 that the message was recently generated and is not a replay. 181 Encrypting the authenticator in the session key proves that 182 it was generated by a party possessing the session key. 183 Since no one except the requesting principal and the server 184 know the session key (it is never sent over the network in 185 the clear) this guarantees the identity of the client. 187 The integrity of the messages exchanged between princi- 188 pals can also be guaranteed using the session key (passed in 189 the ticket and contained in the credentials). This approach 190 provides detection of both replay attacks and message stream 191 modification attacks. It is accomplished by generating and 192 transmitting a collision-proof checksum (elsewhere called a 193 hash or digest function) of the client's message, keyed with 194 the session key. Privacy and integrity of the messages 195 exchanged between principals can be secured by encrypting 196 the data to be passed using the session key passed in the 197 ticket, and contained in the credentials. 199 The authentication exchanges mentioned above require 200 read-only access to the Kerberos database. Sometimes, how- 201 ever, the entries in the database must be modified, such as 202 when adding new principals or changing a principal's key. 203 This is done using a protocol between a client and a third 204 Kerberos server, the Kerberos Administration Server (KADM). 205 The administration protocol is not described in this docu- 206 ment. There is also a protocol for maintaining multiple 207 copies of the Kerberos database, but this can be considered 208 an implementation detail and may vary to support different 209 database technologies. 211 1.1. Cross-Realm Operation 213 The Kerberos protocol is designed to operate across 214 organizational boundaries. A client in one organization can 215 be authenticated to a server in another. Each organization 216 wishing to run a Kerberos server establishes its own 217 "realm". The name of the realm in which a client is 218 registered is part of the client's name, and can be used by 219 the end-service to decide whether to honor a request. 221 By establishing "inter-realm" keys, the administrators 222 of two realms can allow a client authenticated in the local 223 realm to use its authentication remotely[3]. The exchange 224 __________________________ 226 [3] Of course, with appropriate permission the client 227 could arrange registration of a separately-named prin- 228 cipal in a remote realm, and engage in normal exchanges 229 with that realm's services. However, for even small 231 Section 1.1. - 4 - Expires 15 October 1993 233 Version 5 - Revision 5.2 235 of inter-realm keys (a separate key may be used for each 236 direction) registers the ticket-granting service of each 237 realm as a principal in the other realm. A client is then 238 able to obtain a ticket-granting ticket for the remote 239 realm's ticket-granting service from its local realm. When 240 that ticket-granting ticket is used, the remote ticket- 241 granting service uses the inter-realm key (which usually 242 differs from its own normal TGS key) to decrypt the ticket- 243 granting ticket, and is thus certain that it was issued by 244 the client's own TGS. Tickets issued by the remote ticket- 245 granting service will indicate to the end-service that the 246 client was authenticated from another realm. 248 A realm is said to communicate with another realm if 249 the two realms share an inter-realm key, or if the local 250 realm shares an inter-realm key with an intermediate realm 251 that communicates with the remote realm. An authentication 252 path is the sequence of intermediate realms that are tran- 253 sited in communicating from one realm to another. 255 Realms are typically organized hierarchically. Each 256 realm shares a key with its parent and a different key with 257 each child. If an inter-realm key is not directly shared by 258 two realms, the hierarchical organization allows an authen- 259 tication path to be easily constructed. If a hierarchical 260 organization is not used, it may be necessary to consult 261 some database in order to construct an authentication path 262 between realms. 264 Although realms are typically hierarchical, intermedi- 265 ate realms may be bypassed to achieve cross-realm authenti- 266 cation through alternate authentication paths (these might 267 be established to make communication between two realms more 268 efficient). It is important for the end-service to know 269 which realms were transited when deciding how much faith to 270 place in the authentication process. To facilitate this 271 decision, a field in each ticket contains the names of the 272 realms that were involved in authenticating the client. 274 1.2. Environmental assumptions 276 Kerberos imposes a few assumptions on the environment in 277 which it can properly function: 279 + "Denial of service" attacks are not solved with Ker- 280 beros. There are places in these protocols where an 281 intruder can prevent an application from participating 282 in the proper authentication steps. Detection and 283 solution of such attacks (some of which can appear to 284 be not-uncommon "normal" failure modes for the system) 285 is usually best left to the human administrators and 286 __________________________ 287 numbers of clients this becomes cumbersome, and more 288 automatic methods as described here are necessary. 290 Section 1.2. - 5 - Expires 15 October 1993 292 Version 5 - Revision 5.2 294 users. 296 + Principals must keep their secret keys secret. If an 297 intruder somehow steals a principal's key, it will be 298 able to masquerade as that principal or impersonate any 299 server to the legitimate principal. 301 + "Password guessing" attacks are not solved by Kerberos. 302 If a user chooses a poor password, it is possible for 303 an attacker to successfully mount an offline dictionary 304 attack by repeatedly attempting to decrypt, with suc- 305 cessive entries from a dictionary, messages obtained 306 which are encrypted under a key derived from the user's 307 password. 309 + Each host on the network must have a clock which is 310 "loosely synchronized" to the time of the other hosts; 311 this synchronization is used to reduce the bookkeeping 312 needs of application servers when they do replay detec- 313 tion. The degree of "looseness" can be configured on a 314 per-server basis. If the clocks are synchronized over 315 the network, the clock synchronization protocol must 316 itself be secured from network attackers. 318 + Principal identifiers are not recycled on a short-term 319 basis. A typical mode of access control will use 320 access control lists (ACLs) to grant permissions to 321 particular principals. If a stale ACL entry remains 322 for a deleted principal and the principal identifier is 323 reused, the new principal will inherit rights specified 324 in the stale ACL entry. By not re-using principal 325 identifiers, the danger of inadvertent access is 326 removed. 328 1.3. Glossary of terms 330 Below is a list of terms used throughout this document. 332 Authentication Verifying the claimed identity of a 333 principal. 335 Authentication headerA record containing a Ticket and an 336 Authenticator to be presented to a 337 server as part of the authentication 338 process. 340 Authentication path A sequence of intermediate realms tran- 341 sited in the authentication process when 342 communicating from one realm to another. 344 Section 1.3. - 6 - Expires 15 October 1993 346 Version 5 - Revision 5.2 348 Authenticator A record containing information that can 349 be shown to have been recently generated 350 using the session key known only by the 351 client and server. 353 Authorization The process of determining whether a 354 client may use a service, which objects 355 the client is allowed to access, and the 356 type of access allowed for each. 358 Capability A token that grants the bearer permis- 359 sion to access an object or service. In 360 Kerberos, this might be a ticket whose 361 use is restricted by the contents of the 362 authorization data field, but which 363 lists no network addresses, together 364 with the session key necessary to use 365 the ticket. 367 Ciphertext The output of an encryption function. 368 Encryption transforms plaintext into 369 ciphertext. 371 Client A process that makes use of a network 372 service on behalf of a user. Note that 373 in some cases a Server may itself be a 374 client of some other server (e.g. a 375 print server may be a client of a file 376 server). 378 Credentials A ticket plus the secret session key 379 necessary to successfully use that 380 ticket in an authentication exchange. 382 KDC Key Distribution Center, a network ser- 383 vice that supplies tickets and temporary 384 session keys; or an instance of that 385 service or the host on which it runs. 386 The KDC services both initial ticket and 387 ticket-granting ticket requests. The 388 initial ticket portion is sometimes 389 referred to as the Authentication Server 390 (or service). The ticket-granting 391 ticket portion is sometimes referred to 392 as the ticket-granting server (or ser- 393 vice). 395 Section 1.3. - 7 - Expires 15 October 1993 397 Version 5 - Revision 5.2 399 Kerberos Aside from the 3-headed dog guarding 400 Hades, the name given to Project 401 Athena's authentication service, the 402 protocol used by that service, or the 403 code used to implement the authentica- 404 tion service. 406 Plaintext The input to an encryption function or 407 the output of a decryption function. 408 Decryption transforms ciphertext into 409 plaintext. 411 Principal A uniquely named client or server 412 instance that participates in a network 413 communication. 415 Principal identifierThe name used to uniquely identify each 416 different principal. 418 Seal To encipher a record containing several 419 fields in such a way that the fields 420 cannot be individually replaced without 421 either knowledge of the encryption key 422 or leaving evidence of tampering. 424 Secret key An encryption key shared by a principal 425 and the KDC, distributed outside the 426 bounds of the system, with a long life- 427 time. In the case of a human user's 428 principal, the secret key is derived 429 from a password. 431 Server A particular Principal which provides a 432 resource to network clients. 434 Service A resource provided to network clients; 435 often provided by more than one server 436 (for example, remote file service). 438 Session key A temporary encryption key used between 439 two principals, with a lifetime limited 440 to the duration of a single login "ses- 441 sion". 443 Sub-session key A temporary encryption key used between 445 Section 1.3. - 8 - Expires 15 October 1993 447 Version 5 - Revision 5.2 449 two principals, selected and exchanged 450 by the principals using the session key, 451 and with a lifetime limited to the dura- 452 tion of a single association. 454 Ticket A record that helps a client authenti- 455 cate itself to a server; it contains the 456 client's identity, a session key, a 457 timestamp, and other information, all 458 sealed using the server's secret key. 459 It only serves to authenticate a client 460 when presented along with a fresh 461 Authenticator. 463 2. Ticket flag uses and requests 465 Each Kerberos ticket contains a set of flags which are used 466 to indicate various attributes of that ticket. Most flags 467 may be requested by a client when the ticket is obtained; 468 some are automatically turned on and off by a Kerberos 469 server as required. The following sections explain what the 470 various flags mean, and gives examples of reasons to use 471 such a flag. 473 2.1. Initial and pre-authenticated tickets 475 The INITIAL flag indicates that a ticket was issued 476 using the AS protocol and not issued based on a ticket- 477 granting ticket. Application servers that want to require 478 the knowledge of a client's secret key (e.g. a password- 479 changing program) can insist that this flag be set in any 480 tickets they accept, and thus be assured that the client's 481 key was recently presented to the application client. 483 The PRE-AUTHENT and HW-AUTHENT flags provide addition 484 information about the initial authentication, regardless of 485 whether the current ticket was issued directly (in which 486 case INITIAL will also be set) or issued on the basis of a 487 ticket-granting ticket (in which case the INITIAL flag is 488 clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried 489 forward from the ticket-granting ticket). 491 2.2. Invalid tickets 493 The INVALID flag indicates that a ticket is invalid. 494 Application servers must reject tickets which have this flag 495 set. A postdated ticket will usually be issued in this 496 form. Invalid tickets must be validated by the KDC before 497 use, by presenting them to the KDC in a TGS request with the 498 VALIDATE option specified. The KDC will only validate tick- 499 ets after their starttime has passed. The validation is 500 required so that postdated tickets which have been stolen 501 before their starttime can be rendered permanently invalid 503 Section 2.2. - 9 - Expires 15 October 1993 505 Version 5 - Revision 5.2 507 (through a hot-list mechanism). 509 2.3. Renewable tickets 511 Applications may desire to hold tickets which can be 512 valid for long periods of time. However, this can expose 513 their credentials to potential theft for equally long 514 periods, and those stolen credentials would be valid until 515 the expiration time of the ticket(s). Simply using short- 516 lived tickets and obtaining new ones periodically would 517 require the client to have long-term access to its secret 518 key, an even greater risk. Renewable tickets can be used to 519 mitigate the consequences of theft. Renewable tickets have 520 two "expiration times": the first is when the current 521 instance of the ticket expires, and the second is the latest 522 permissible value for an individual expiration time. An 523 application client must periodically (i.e. before it 524 expires) present a renewable ticket to the KDC, with the 525 RENEW option set in the KDC request. The KDC will issue a 526 new ticket with a new session key and a later expiration 527 time. All other fields of the ticket are left unmodified by 528 the renewal process. When the latest permissible expiration 529 time arrives, the ticket expires permanently. At each 530 renewal, the KDC may consult a hot-list to determine if the 531 ticket had been reported stolen since its last renewal; it 532 will refuse to renew such stolen tickets, and thus the 533 usable lifetime of stolen tickets is reduced. 535 The RENEWABLE flag in a ticket is normally only inter- 536 preted by the ticket-granting service (discussed below in 537 section 3.3). It can usually be ignored by application 538 servers. However, some particularly careful application 539 servers may wish to disallow renewable tickets. 541 If a renewable ticket is not renewed by its expiration 542 time, the KDC will not renew the ticket. The RENEWABLE flag 543 is reset by default, but a client may request it be set by 544 setting the RENEWABLE option in the KRB_AS_REQ message. If 545 it is set, then the renew-till field in the ticket contains 546 the time after which the ticket may not be renewed. 548 2.4. Postdated tickets 550 Applications may occasionally need to obtain tickets 551 for use much later, e.g. a batch submission system would 552 need tickets to be valid at the time the batch job is ser- 553 viced. However, it is dangerous to hold valid tickets in a 554 batch queue, since they will be on-line longer and more 555 prone to theft. Postdated tickets provide a way to obtain 556 these tickets from the KDC at job submission time, but to 557 leave them "dormant" until they are activated and validated 558 by a further request of the KDC. If a ticket theft were 559 reported in the interim, the KDC would refuse to validate 560 the ticket, and the thief would be foiled. 562 Section 2.4. - 10 - Expires 15 October 1993 564 Version 5 - Revision 5.2 566 The MAY-POSTDATE flag in a ticket is normally only 567 interpreted by the ticket-granting service. It can be 568 ignored by application servers. This flag must be set in a 569 ticket-granting ticket in order to issue a postdated ticket 570 based on the presented ticket. It is reset by default; it 571 may be requested by a client by setting the ALLOW-POSTDATE 572 option in the KRB_AS_REQ message. This flag does not allow 573 a client to obtain a postdated ticket-granting ticket; post- 574 dated ticket-granting tickets can only by obtained by 575 requesting the postdating in the KRB_AS_REQ message. The 576 life (endtime-starttime) of a postdated ticket will be the 577 remaining life of the ticket-granting ticket at the time of 578 the request, unless the RENEWABLE option is also set, in 579 which case it can be the full life (endtime-starttime) of 580 the ticket-granting ticket. The KDC may limit how far in 581 the future a ticket may be postdated. 583 The POSTDATED flag indicates that a ticket has been 584 postdated. The application server can check the authtime 585 field in the ticket to see when the original authentication 586 occurred. Some services may choose to reject postdated 587 tickets, or they may only accept them within a certain 588 period after the original authentication. When the KDC 589 issues a POSTDATED ticket, it will also be marked as 590 INVALID, so that the application client must present the 591 ticket to the KDC to be validated before use. 593 2.5. Proxiable and proxy tickets 595 At times it may be necessary for a principal to allow a 596 service to perform an operation on its behalf. The service 597 must be able to take on the identity of the client, but only 598 for a particular purpose. A principal can allow a service 599 to take on the principal's identity for a particular purpose 600 by granting it a proxy. 602 The PROXIABLE flag in a ticket is normally only inter- 603 preted by the ticket-granting service. It can be ignored by 604 application servers. When set, this flag tells the ticket- 605 granting server that it is OK to issue a new ticket (but not 606 a ticket-granting ticket) with a different network address 607 based on this ticket. This flag is set by default. 609 This flag allows a client to pass a proxy to a server 610 to perform a remote request on its behalf, e.g. a print ser- 611 vice client can give the print server a proxy to access the 612 client's files on a particular file server in order to 613 satisfy a print request. 615 In order to complicate the use of stolen credentials, 616 Kerberos tickets are usually valid from only those network 617 addresses specifically included in the ticket[4]. For this 618 __________________________ 620 [4] It is permissible to request or issue tickets with 622 Section 2.5. - 11 - Expires 15 October 1993 624 Version 5 - Revision 5.2 626 reason, a client wishing to grant a proxy must request a new 627 ticket valid for the network address of the service to be 628 granted the proxy. 630 The PROXY flag is set in a ticket by the TGS when it 631 issues a proxy ticket. Application servers may check this 632 flag and require additional authentication from the agent 633 presenting the proxy in order to provide an audit trail. 635 2.6. Forwardable tickets 637 Authentication forwarding is an instance of the proxy 638 case where the service is granted complete use of the 639 client's identity. An example where it might be used is 640 when a user logs in to a remote system and wants authentica- 641 tion to work from that system as if the login were local. 643 The FORWARDABLE flag in a ticket is normally only 644 interpreted by the ticket-granting service. It can be 645 ignored by application servers. The FORWARDABLE flag has an 646 interpretation similar to that of the PROXIABLE flag, except 647 ticket-granting tickets may also be issued with different 648 network addresses. This flag is reset by default, but users 649 may request that it be set by setting the FORWARDABLE option 650 in the AS request when they request their initial ticket- 651 granting ticket. 653 This flag allows for authentication forwarding without 654 requiring the user to enter a password again. If the flag 655 is not set, then authentication forwarding is not permitted, 656 but the same end result can still be achieved if the user 657 engages in the AS exchange with the requested network 658 addresses and supplies a password. 660 The FORWARDED flag is set by the TGS when a client 661 presents a ticket with the FORWARDABLE flag set and requests 662 it be set by specifying the FORWARDED KDC option and supply- 663 ing a set of addresses for the new ticket. It is also set 664 in all tickets issued based on tickets with the FORWARDED 665 flag set. Application servers may wish to process FORWARDED 666 tickets differently than non-FORWARDED tickets. 668 2.7. Other KDC options 670 There are two additional options which may be set in a 671 client's request of the KDC. The RENEWABLE-OK option indi- 672 cates that the client will accept a renewable ticket if a 673 ticket with the requested life cannot otherwise be provided. 674 If a ticket with the requested life cannot be provided, then 675 the KDC may issue a renewable ticket with a renew-till equal 676 __________________________ 677 no network addresses specified, but we do not recommend 678 it. 680 Section 2.7. - 12 - Expires 15 October 1993 682 Version 5 - Revision 5.2 684 to the the requested endtime. The value of the renew-till 685 field may still be adjusted by site-determined limits or 686 limits imposed by the individual principal or server. 688 The ENC-TKT-IN-SKEY option is honored only by the 689 ticket-granting service. It indicates that the to-be-issued 690 ticket for the end server is to be encrypted in the session 691 key from the additional ticket-granting ticket provided with 692 the request. See section 3.3.3 for specific details. 694 __________________________ 696 [5] The password-changing request must not be honored 697 unless the requester can provide the old password (the 698 user's current secret key). Otherwise, it would be 699 possible for someone to walk up to an unattended ses- 700 sion and change another user's password. 701 [6] To authenticate a user logging on to a local sys- 702 tem, the credentials obtained in the AS exchange may 703 first be used in a TGS exchange to obtain credentials 704 for a local server. Those credentials must then be 705 verified by the local server through successful comple- 706 tion of the Client/Server exchange. 708 Section 3.1. - 13 - Expires 15 October 1993 710 Version 5 - Revision 5.2 712 3. Message Exchanges 714 The following sections describe the interactions between 715 network clients and servers and the messages involved in 716 those exchanges. 718 3.1. The Authentication Service Exchange 720 Summary 721 Message direction Message type Section 722 1. Client to Kerberos KRB_AS_REQ 5.4.1 723 2. Kerberos to client KRB_AS_REP or 5.4.2 724 KRB_ERROR 5.9.1 726 The Authentication Service (AS) Exchange between the 727 client and the Kerberos Authentication Server is usually in- 728 itiated by a client when it wishes to obtain authentication 729 credentials for a given server but currently holds no 730 credentials. The client's secret key is used for encryption 731 and decryption. This exchange is typically used at the ini- 732 tiation of a login session, to obtain credentials for a 733 Ticket-Granting Server, which will subsequently be used to 734 obtain credentials for other servers (see section 3.3) 735 without requiring further use of the client's secret key. 736 This exchange is also used to request credentials for ser- 737 vices which must not be mediated through the Ticket-Granting 738 Service, but rather require a principal's secret key, such 739 as the password-changing service[5]. This exchange does not 740 by itself provide any assurance of the the identity of the 741 user[6]. 743 The exchange consists of two messages: KRB_AS_REQ from 744 the client to Kerberos, and KRB_AS_REP or KRB_ERROR in 745 reply. The formats for these messages are described in sec- 746 tions 5.4.1, 5.4.2, and 5.9.1. 748 In the request, the client sends (in cleartext) its own 749 identity and the identity of the server for which it is 750 requesting credentials. The response, KRB_AS_REP, contains 751 a ticket for the client to present to the server, and a ses- 752 sion key that will be shared by the client and the server. 753 The session key and additional information are encrypted in 754 the client's secret key. The KRB_AS_REP message contains 755 information which can be used to detect replays, and to 756 associate it with the message to which it replies. Various 757 errors can occur; these are indicated by an error response 758 (KRB_ERROR) instead of the KRB_AS_REP response. The error 759 message is not encrypted. The KRB_ERROR message also con- 760 tains information which can be used to associate it with the 761 message to which it replies. The lack of encryption in the 762 KRB_ERROR message precludes the ability to detect replays or 763 fabrications of such messages. 765 Section 3.1. - 14 - Expires 15 October 1993 767 Version 5 - Revision 5.2 769 In the normal case the authentication server does not 770 know whether the client is actually the principal named in 771 the request. It simply sends a reply without knowing or 772 caring whether they are the same. This is acceptable 773 because nobody but the principal whose identity was given in 774 the request will be able to use the reply. Its critical 775 information is encrypted in that principal's key. The ini- 776 tial request supports an optional field that can be used to 777 pass additional information that might be needed for the 778 initial exchange. This field may be used for pre- 779 authentication if desired, but the mechanism is not 780 currently specified. 782 3.1.1. Generation of KRB_AS_REQ message 784 The client may specify a number of options in the ini- 785 tial request. Among these options are whether pre- 786 authentication is to be performed; whether the requested 787 ticket is to be renewable, proxiable, or forwardable; 788 whether it should be postdated or allow postdating of 789 derivative tickets; and whether a renewable ticket will be 790 accepted in lieu of a non-renewable ticket if the requested 791 ticket expiration date cannot be satisfied by a non- 792 renewable ticket (due to configuration constraints; see sec- 793 tion 4). See section A.1 for pseudocode. 795 The client prepares the KRB_AS_REQ message and sends it 796 to the KDC. 798 3.1.2. Receipt of KRB_AS_REQ message 800 If all goes well, processing the KRB_AS_REQ message 801 will result in the creation of a ticket for the client to 802 present to the server. The format for the ticket is 803 described in section 5.3.1. The contents of the ticket are 804 determined as follows. 806 3.1.3. Generation of KRB_AS_REP message 808 The authentication server looks up the client and 809 server principals named in the KRB_AS_REQ in its database, 810 extracting their respective keys. If required, the server 811 pre-authenticates the request, and if the pre-authentication 812 check fails, an error message with the code 813 KDC_ERR_PREAUTH_FAILED is returned. If the server cannot 814 accommodate the requested encryption type, an error message 815 with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it 816 generates a "random" session key[7]. 817 __________________________ 819 [7] "Random" means that, among other things, it should 820 be impossible to guess the next session key based on 821 knowledge of past session keys. This can only be 822 achieved in a pseudo-random number generator if it is 823 based on cryptographic principles. It would be more 825 Section 3.1.3. - 15 - Expires 15 October 1993 827 Version 5 - Revision 5.2 829 If the requested start time is absent or indicates a 830 time in the past, then the start time of the ticket is set 831 to the authentication server's current time. If it indicates 832 a time in the future, but the POSTDATED option has not been 833 specified, then the error KDC_ERR_CANNOT_POSTDATE is 834 returned. Otherwise the requested start time is checked 835 against the policy of the local realm (the administrator 836 might decide to prohibit certain types or ranges of post- 837 dated tickets), and if acceptable, the ticket's start time 838 is set as requested and the INVALID flag is set in the new 839 ticket. The postdated ticket must be validated before use by 840 presenting it to the KDC after the start time has been 841 reached. 843 The expiration time of the ticket will be set to the minimum 844 of the following: 846 +The expiration time (endtime) requested in the KRB_AS_REQ 847 message. 849 +The ticket's start time plus the maximum allowable lifetime 850 associated with the client principal (the authentication 851 server's database includes a maximum ticket lifetime field 852 in each principal's record; see section 4). 854 +The ticket's start time plus the maximum allowable lifetime 855 associated with the server principal. 857 +The ticket's start time plus the maximum lifetime set by 858 the policy of the local realm. 860 If the requested expiration time minus the start time 861 (as determined above) is less than a site-determined minimum 862 lifetime, an error message with code KDC_ERR_NEVER_VALID is 863 returned. If the requested expiration time for the ticket 864 exceeds what was determined as above, and if the 865 "RENEWABLE-OK" option was requested, then the "RENEWABLE" 866 flag is set in the new ticket, and the renew-till value is 867 set as if the "RENEWABLE" option were requested (the field 868 and option names are described fully in section 5.4.1). 870 __________________________ 871 desirable to use a truly random number generator, such 872 as one based on measurements of random physical 873 phenomena. 875 Section 3.1.3. - 16 - Expires 15 October 1993 877 Version 5 - Revision 5.2 879 If the RENEWABLE option has been requested or if the 880 RENEWABLE-OK option has been set and a renewable ticket is 881 to be issued, then the renew-till field is set to the 882 minimum of: 884 +Its requested value. 886 +The start time of the ticket plus the minimum of the two 887 maximum renewable lifetimes associated with the principals' 888 database entries. 890 +The start time of the ticket plus the maximum renewable 891 lifetime set by the policy of the local realm. 893 The flags field of the new ticket will have the follow- 894 ing options set if they have been requested and if the pol- 895 icy of the local realm allows: FORWARDABLE, MAY-POSTDATE, 896 POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is post- 897 dated (the start time is in the future), its INVALID flag 898 will also be set. 900 If all of the above succeed, the server formats a 901 KRB_AS_REP message (see section 5.4.2), copying the 902 addresses in the request into the caddr of the response, 903 placing any required pre-authentication data into the padata 904 of the response, and encrypts the ciphertext part in the 905 client's key using the requested encryption method, and 906 sends it to the client. See section A.2 for pseudocode. 908 3.1.4. Generation of KRB_ERROR message 910 Several errors can occur, and the Authentication Server 911 responds by returning an error message, KRB_ERROR, to the 912 client, with the error-code and e-text fields set to 913 appropriate values. The error message contents and details 914 are described in Section 5.9.1. 916 3.1.5. Receipt of KRB_AS_REP message 918 If the reply message type is KRB_AS_REP, then the 919 client verifies that the cname and crealm fields in the 920 cleartext portion of the reply match what it requested. If 921 any padata fields are present, they may be used to derive 922 the proper secret key to decrypt the message. The client 923 decrypts the encrypted part of the response using its secret 924 key, verifies that the nonce in the encrypted part matches 925 the nonce it supplied in its request (to detect replays). 926 It also verifies that the sname and srealm in the response 927 match those in the request, and that the host address field 928 is also correct. It then stores the ticket, session key, 929 start and expiration times, and other information for later 930 use. The key-expiration field from the encrypted part of 931 the response may be checked to notify the user of impending 932 key expiration (the client program could then suggest 934 Section 3.1.5. - 17 - Expires 15 October 1993 936 Version 5 - Revision 5.2 938 remedial action, such as a password change). See section 939 A.3 for pseudocode. 941 Proper decryption of the KRB_AS_REP message is not suf- 942 ficient to verify the identity of the user; the user and an 943 attacker could cooperate to generate a KRB_AS_REP format 944 message which decrypts properly but is not from the proper 945 KDC. If the host wishes to verify the identity of the user, 946 it must require the user to present application credentials 947 which can be verified using a securely-stored secret key. 948 If those credentials can be verified, then the identity of 949 the user can be assured. 951 3.1.6. Receipt of KRB_ERROR message 953 If the reply message type is KRB_ERROR, then the client 954 interprets it as an error and performs whatever 955 application-specific tasks are necessary to recover. 957 3.2. The Client/Server Authentication Exchange 959 Summary 960 Message direction Message type Section 961 Client to Application server KRB_AP_REQ 5.5.1 962 [optional] Application server to client KRB_AP_REP or 5.5.2 963 KRB_ERROR 5.9.1 965 The client/server authentication (CS) exchange is used 966 by network applications to authenticate the client to the 967 server and vice versa. The client must have already 968 acquired credentials for the server using the AS or TGS 969 exchange. 971 3.2.1. The KRB_AP_REQ message 973 The KRB_AP_REQ contains authentication information 974 which should be part of the first message in an authenti- 975 cated transaction. It contains a ticket, an authenticator, 976 and some additional bookkeeping information (see section 977 5.5.1 for the exact format). The ticket by itself is insuf- 978 ficient to authenticate a client, since tickets are passed 979 across the network in cleartext[8], so the authenticator is 980 used to prevent invalid replay of tickets by proving to the 981 server that the client knows the session key of the ticket 982 and thus is entitled to use it. The KRB_AP_REQ message is 983 referred to elsewhere as the "authentication header." 985 __________________________ 986 [8] Tickets contain both an encrypted and unencrypted 987 portion, so cleartext here refers to the entire unit, 988 which can be copied from one message and replayed in 989 another without any cryptographic skill. 991 Section 3.2.1. - 18 - Expires 15 October 1993 993 Version 5 - Revision 5.2 995 3.2.2. Generation of a KRB_AP_REQ message 997 When a client wishes to initiate authentication to a 998 server, it obtains (either through a credentials cache, the 999 AS exchange, or the TGS exchange) a ticket and session key 1000 for the desired service. The client may re-use any tickets 1001 it holds until they expire. The client then constructs a 1002 new Authenticator from the the system time, its name, and 1003 optionally an application specific checksum, an initial 1004 sequence number to be used in KRB_SAFE or KRB_PRIV messages, 1005 and/or a session subkey to be used in negotiations for a 1006 session key unique to this particular session. Authentica- 1007 tors may not be re-used and will be rejected if replayed to 1008 a server[9]. If a sequence number is to be included, it 1009 should be randomly chosen so that even after many messages 1010 have been exchanged it is not likely to collide with other 1011 sequence numbers in use. 1013 The client may indicate a requirement of mutual authen- 1014 tication or the use of a session-key based ticket by setting 1015 the appropriate flag(s) in the ap-options field of the mes- 1016 sage. 1018 The Authenticator is encrypted in the session key and 1019 combined with the ticket to form the KRB_AP_REQ message 1020 which is then sent to the end server along with any addi- 1021 tional application-specific information. See section A.9 1022 for pseudocode. 1024 3.2.3. Receipt of KRB_AP_REQ message 1026 Authentication is based on the server's current time of 1027 day (clocks must be loosely synchronized), the authentica- 1028 tor, and the ticket. Several errors are possible. If an 1029 error occurs, the server is expected to reply to the client 1030 with a KRB_ERROR message. This message may be encapsulated 1031 in the application protocol if its "raw" form is not accept- 1032 able to the protocol. The format of error messages is 1033 described in section 5.9.1. 1035 The algorithm for verifying authentication information 1036 is as follows. If the message type is not KRB_AP_REQ, the 1037 server returns the KRB_AP_ERR_MSG_TYPE error. If the key 1038 version indicated by the Ticket in the KRB_AP_REQ is not one 1039 the server can use (e.g., it indicates an old key, and the 1040 server no longer possesses a copy of the old key), the 1041 KRB_AP_ERR_BADKEYVER error is returned. If the USE- 1042 __________________________ 1044 [9] Note that this can make applications based on un- 1045 reliable transports difficult to code correctly, if the 1046 transport might deliver duplicated messages. In such 1047 cases, a new authenticator must be generated for each 1048 retry. 1050 Section 3.2.3. - 19 - Expires 15 October 1993 1052 Version 5 - Revision 5.2 1054 SESSION-KEY flag is set in the ap-options field, it indi- 1055 cates to the server that the ticket is encrypted in the ses- 1056 sion key from the server's ticket-granting ticket rather 1057 than its secret key[10]. Since it is possible for the 1058 server to be registered in multiple realms, with different 1059 keys in each, the srealm field in the unencrypted portion of 1060 the ticket in the KRB_AP_REQ is used to specify which secret 1061 key the server should use to decrypt that ticket. The 1062 KRB_AP_ERR_NOKEY error code is returned if the server 1063 doesn't have the proper key to decipher the ticket. 1065 The ticket is decrypted using the version of the 1066 server's key specified by the ticket. If the decryption 1067 routines detect a modification of the ticket (each encryp- 1068 tion system must provide safeguards to detect modified 1069 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY 1070 error is returned (chances are good that different keys were 1071 used to encrypt and decrypt). 1073 The authenticator is decrypted using the session key 1074 extracted from the decrypted ticket. If decryption shows it 1075 to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is 1076 returned. The name and realm of the client from the ticket 1077 are compared against the same fields in the authenticator. 1078 If they don't match, the KRB_AP_ERR_BADMATCH error is 1079 returned (they might not match, for example, if the wrong 1080 session key was used to encrypt the authenticator). The 1081 addresses in the ticket (if any) are then searched for an 1082 address matching the operating-system reported address of 1083 the client. If no match is found or the server insists on 1084 ticket addresses but none are present in the ticket, the 1085 KRB_AP_ERR_BADADDR error is returned. 1087 If the local (server) time and the client time in the 1088 authenticator differ by more than the allowable clock skew 1089 (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned. 1090 If the server name, along with the client name, time and 1091 microsecond fields from the Authenticator match any 1092 recently-seen such tuples, the KRB_AP_ERR_REPEAT error is 1093 returned[11]. The server must remember any authenticator 1094 presented within the allowable clock skew, so that a replay 1095 attempt is guaranteed to fail. If a server loses track of 1096 any authenticator presented within the allowable clock skew, 1097 __________________________ 1099 [10] This is used for user-to-user authentication as 1100 described in [6]. 1101 [11] Note that the rejection here is restricted to au- 1102 thenticators from the same principal to the same 1103 server. Other client principals communicating with the 1104 same server principal should not be have their authen- 1105 ticators rejected if the time and microsecond fields 1106 happen to match some other client's authenticator. 1108 Section 3.2.3. - 20 - Expires 15 October 1993 1110 Version 5 - Revision 5.2 1112 it must reject all requests until the clock skew interval 1113 has passed. This assures that any lost or re-played authen- 1114 ticators will fall outside the allowable clock skew and can 1115 no longer be successfully replayed (If this is not done, an 1116 attacker could conceivably record the ticket and authentica- 1117 tor sent over the network to a server, then disable the 1118 client's host, pose as the disabled host, and replay the 1119 ticket and authenticator to subvert the authentication.). 1120 If a sequence number is provided in the authenticator, the 1121 server saves it for later use in processing KRB_SAFE and/or 1122 KRB_PRIV messages. If a subkey is present, the server 1123 either saves it for later use or uses it to help generate 1124 its own choice for a subkey to be returned in a KRB_AP_REP 1125 message. 1127 The server computes the age of the ticket: local 1128 (server) time minus the start time inside the Ticket. If 1129 the start time is later than the current time by more than 1130 the allowable clock skew or if the INVALID flag is set in 1131 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Oth- 1132 erwise, if the current time is later than end time by more 1133 than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED 1134 error is returned. 1136 If all these checks succeed without an error, the 1137 server is assured that the client possesses the credentials 1138 of the principal named in the ticket and thus, the client 1139 has been authenticated to the server. See section A.10 for 1140 pseudocode. 1142 3.2.4. Generation of a KRB_AP_REP message 1144 Typically, a client's request will include both the 1145 authentication information and its initial request in the 1146 same message, and the server need not explicitly reply to 1147 the KRB_AP_REQ. However, if mutual authentication (not only 1148 authenticating the client to the server, but also the server 1149 to the client) is being performed, the KRB_AP_REQ message 1150 will have MUTUAL-REQUIRED set in its ap-options field, and a 1151 KRB_AP_REP message is required in response. As with the 1152 error message, this message may be encapsulated in the 1153 application protocol if its "raw" form is not acceptable to 1154 the application's protocol. The timestamp and microsecond 1155 field used in the reply must be the client's timestamp and 1156 microsecond field (as provided in the authenticator)[12]. 1157 __________________________ 1159 [12] In the Kerberos version 4 protocol, the timestamp 1160 in the reply was the client's timestamp plus one. This 1161 is not necessary in version 5 because version 5 mes- 1162 sages are formatted in such a way that it is not possi- 1163 ble to create the reply by judicious message surgery 1164 (even in encrypted form) without knowledge of the ap- 1165 propriate encryption keys. 1167 Section 3.2.4. - 21 - Expires 15 October 1993 1169 Version 5 - Revision 5.2 1171 If a sequence number is to be included, it should be ran- 1172 domly chosen as described above for the authenticator. A 1173 subkey may be included if the server desires to negotiate a 1174 different subkey. The KRB_AP_REP message is encrypted in 1175 the session key extracted from the ticket. See section A.11 1176 for pseudocode. 1178 3.2.5. Receipt of KRB_AP_REP message 1180 If a KRB_AP_REP message is returned, the client uses 1181 the session key from the credentials obtained for the 1182 server[13] to decrypt the message, and verifies that the 1183 timestamp and microsecond fields match those in the Authen- 1184 ticator it sent to the server. If they match, then the 1185 client is assured that the server is genuine. The sequence 1186 number and subkey (if present) are retained for later use. 1187 See section A.12 for pseudocode. 1189 3.2.6. Using the encryption key 1191 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, 1192 the client and server share an encryption key which can be 1193 used by the application. The "true session key" to be used 1194 for KRB_PRIV, KRB_SAFE, or other application-specific uses 1195 may be chosen by the application based on the subkeys in the 1196 KRB_AP_REP message and the authenticator[14]. In some 1197 cases, the use of this session key will be implicit in the 1198 protocol; in others the method of use must be chosen from a 1199 several alternatives. We leave the protocol negotiations of 1200 how to use the key (e.g. selecting an encryption or check- 1201 sum type) to the application programmer; the Kerberos proto- 1202 col does not constrain the implementation options. 1204 With both the one-way and mutual authentication 1205 exchanges, the peers should take care not to send sensitive 1206 information to each other without proper assurances. In 1207 particular, applications that require privacy or integrity 1208 should use the KRB_AP_REP or KRB_ERROR responses from the 1209 server to client to assure both client and server of their 1210 peer's identity. If an application protocol requires 1211 privacy of its messages, it can use the KRB_PRIV message 1212 (section 3.5). The KRB_SAFE message (section 3.4) can be 1213 __________________________ 1215 [13] Note that for encrypting the KRB_AP_REP message, 1216 the sub-session key is not used, even if present in the 1217 Authenticator. 1218 [14] Implementations of the protocol may wish to pro- 1219 vide routines to choose subkeys based on session keys 1220 and random numbers and to orchestrate a negotiated key 1221 to be returned in the KRB_AP_REP message. 1223 Section 3.2.6. - 22 - Expires 15 October 1993 1225 Version 5 - Revision 5.2 1227 used to assure integrity. 1229 3.3. The Ticket-Granting Service (TGS) Exchange 1231 Summary 1232 Message direction Message type Section 1233 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1234 2. Kerberos to client KRB_TGS_REP or 5.4.2 1235 KRB_ERROR 5.9.1 1237 The TGS exchange between a client and the Kerberos 1238 Ticket-Granting Server is initiated by a client when it 1239 wishes to obtain authentication credentials for a given 1240 server (which might be registered in a remote realm), when 1241 it wishes to renew or validate an existing ticket, or when 1242 it wishes to obtain a proxy ticket. In the first case, the 1243 client must already have acquired a ticket for the Ticket- 1244 Granting Service using the AS exchange (the ticket-granting 1245 ticket is usually obtained when a client initially authenti- 1246 cates to the system, such as when a user logs in). The mes- 1247 sage format for the TGS exchange is almost identical to that 1248 for the AS exchange. The primary difference is that encryp- 1249 tion and decryption in the TGS exchange does not take place 1250 under the client's key. Instead, the session key from the 1251 ticket-granting ticket or renewable ticket, or sub-session 1252 key from an Authenticator is used. As is the case for all 1253 application servers, expired tickets are not accepted by the 1254 TGS, so once a renewable or ticket-granting ticket expires, 1255 the client must use a separate exchange to obtain valid 1256 tickets. 1258 The TGS exchange consists of two messages: A request 1259 (KRB_TGS_REQ) from the client to the Kerberos Ticket- 1260 Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR). 1261 The KRB_TGS_REQ message includes information authenticating 1262 the client plus a request for credentials. The authentica- 1263 tion information consists of the authentication header 1264 (KRB_AP_REQ) which includes the client's previously obtained 1265 ticket-granting, renewable, or invalid ticket. In the 1266 ticket-granting ticket and proxy cases, the request may 1267 include one or more of: a list of network addresses, a col- 1268 lection of typed authorization data to be sealed in the 1269 ticket for authorization use by the application server, or 1270 additional tickets (the use of which are described later). 1271 The TGS reply (KRB_TGS_REP) contains the requested creden- 1272 tials, encrypted in the session key from the ticket-granting 1273 ticket or renewable ticket, or if present, in the sub- 1274 session key from the Authenticator (part of the authentica- 1275 tion header). The KRB_ERROR message contains an error code 1276 and text explaining what went wrong. The KRB_ERROR message 1277 is not encrypted. The KRB_TGS_REP message contains informa- 1278 tion which can be used to detect replays, and to associate 1280 Section 3.3. - 23 - Expires 15 October 1993 1282 Version 5 - Revision 5.2 1284 it with the message to which it replies. The KRB_ERROR mes- 1285 sage also contains information which can be used to associ- 1286 ate it with the message to which it replies, but the lack of 1287 encryption in the KRB_ERROR message precludes the ability to 1288 detect replays or fabrications of such messages. 1290 3.3.1. Generation of KRB_TGS_REQ message 1292 Before sending a request to the ticket-granting ser- 1293 vice, the client must determine in which realm the applica- 1294 tion server is registered[15]. If the client does not 1295 already possess a ticket-granting ticket for the appropriate 1296 realm, then one must be obtained. This is first attempted 1297 by requesting a ticket-granting ticket for the destination 1298 realm from the local Kerberos server (using the KRB_TGS_REQ 1299 message recursively). The Kerberos server may return a TGT 1300 for the desired realm in which case one can proceed. Alter- 1301 natively, the Kerberos server may return a TGT for a realm 1302 which is "closer" to the desired realm (further along the 1303 standard hierarchical path), in which case this step must be 1304 repeated with a Kerberos server in the realm specified in 1305 the returned TGT. If neither are returned, then the request 1306 must be retried with a Kerberos server for a realm higher in 1307 the hierarchy. This request will itself require a ticket- 1308 granting ticket for the higher realm which must be obtained 1309 by recursively applying these directions. 1311 Once the client obtains a ticket-granting ticket for 1312 the appropriate realm, it determines which Kerberos servers 1313 serve that realm, and contacts one. The list might be 1314 obtained through a configuration file or network service; as 1315 long as the secret keys exchanged by realms are kept secret, 1316 only denial of service results from a false Kerberos server. 1318 As in the AS exchange, the client may specify a number 1319 of options in the KRB_TGS_REQ message. The client prepares 1320 the KRB_TGS_REQ message, providing an authentication header 1321 as an element of the padata field, and including the same 1322 fields as used in the KRB_AS_REQ message along with several 1323 optional fields: the enc-authorization-data field for 1324 __________________________ 1326 [15] This can be accomplished in several ways. It 1327 might be known beforehand (since the realm is part of 1328 the principal identifier), or it might be stored in a 1329 nameserver. Presently, however, this information is 1330 obtained from a configuration file. If the realm to be 1331 used is obtained from a nameserver, there is a danger 1332 of being spoofed if the nameservice providing the realm 1333 name is not authenticated. This might result in the 1334 use of a realm which has been compromised, and would 1335 result in an attacker's ability to compromise the au- 1336 thentication of the application server to the client. 1338 Section 3.3.1. - 24 - Expires 15 October 1993 1340 Version 5 - Revision 5.2 1342 application server use and additional tickets required by 1343 some options. 1345 In preparing the authentication header, the client can 1346 select a sub-session key under which the response from the 1347 Kerberos server will be encrypted[16]. If the sub-session 1348 key is not specified, the session key from the ticket- 1349 granting ticket will be used. If the enc-authorization-data 1350 is present, it must be encrypted in the sub-session key, if 1351 present, from the authenticator portion of the authentica- 1352 tion header, or if not present in the session key from the 1353 ticket-granting ticket. 1355 Once prepared, the message is sent to a Kerberos server 1356 for the destination realm. See section A.5 for pseudocode. 1358 3.3.2. Receipt of KRB_TGS_REQ message 1360 The KRB_TGS_REQ message is processed in a manner simi- 1361 lar to the KRB_AS_REQ message, but there are many additional 1362 checks to be performed. First, the Kerberos server must 1363 determine which server the accompanying ticket is for and it 1364 must select the appropriate key to decrypt it. For a normal 1365 KRB_TGS_REQ message, it will be for the ticket granting ser- 1366 vice, and the TGS's key will be used. If the TGT was issued 1367 by another realm, then the appropriate inter-realm key must 1368 be used. If the accompanying ticket is not a ticket grant- 1369 ing ticket for the current realm, but is for an application 1370 server in the current realm, the RENEW, VALIDATE, or PROXY 1371 options are specified in the request, and the server for 1372 which a ticket is requested is the server named in the 1373 accompanying ticket, then the KDC will decrypt the ticket in 1374 the authentication header using the key of the server for 1375 which it was issued. If no ticket can be found in the 1376 padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is 1377 returned. 1379 Once the accompanying ticket has been decrypted, the 1380 user-supplied checksum in the Authenticator must be verified 1381 against the contents of the request, and the message 1382 rejected if the checksums do not match (with an error code 1383 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or 1384 not collision-proof (with an error code of 1385 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not sup- 1386 ported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If 1387 the authorization-data are present, they are decrypted using 1388 the sub-session key from the Authenticator. 1389 __________________________ 1391 [16] If the client selects a sub-session key, care must 1392 be taken to ensure the randomness of the selected sub- 1393 session key. One approach would be to generate a ran- 1394 dom number and XOR it with the session key from the 1395 ticket-granting ticket. 1397 Section 3.3.2. - 25 - Expires 15 October 1993 1399 Version 5 - Revision 5.2 1401 If any of the decryptions indicate failed integrity 1402 checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned. 1404 3.3.3. Generation of KRB_TGS_REP message 1406 The KRB_TGS_REP message shares its format with the 1407 KRB_AS_REP (KRB_KDC_REP), but with its type field set to 1408 KRB_TGS_REP. The detailed specification is in section 1409 5.4.2. 1411 The response will include a ticket for the requested 1412 server. The Kerberos database is queried to retrieve the 1413 record for the requested server (including the key with 1414 which the ticket will be encrypted). If the request is for 1415 a ticket granting ticket for a remote realm, and if no key 1416 is shared with the requested realm, then the Kerberos server 1417 will select the realm "closest" to the requested realm with 1418 which it does share a key, and use that realm instead. This 1419 is the only case where the response from the KDC will be for 1420 a different server than that requested by the client. 1422 By default, the address field, the client's name and 1423 realm, the list of transited realms, the time of initial 1424 authentication, the expiration time, and the authorization 1425 data of the newly-issued ticket will be copied from the 1426 ticket-granting ticket (TGT) or renewable ticket. If the 1427 transited field needs to be updated, but the transited type 1428 is not supported, the KDC_ERR_TRTYPE_NOSUPP error is 1429 returned. 1431 If the request specifies an endtime, then the endtime 1432 of the new ticket is set to the minimum of (a) that request, 1433 (b) the endtime from the TGT, and (c) the starttime of the 1434 TGT plus the minimum of the maximum life for the application 1435 server and the maximum life for the local realm (the maximum 1436 life for the requesting principal was already applied when 1437 the TGT was issued). If the new ticket is to be a renewal, 1438 then the endtime above is replaced by the minimum of (a) the 1439 value of the renew_till field of the ticket and (b) the 1440 starttime for the new ticket plus the life (endtime- 1441 starttime) of the old ticket. 1443 If the FORWARDED option has been requested, then the 1444 resulting ticket will contain the addresses specified by the 1445 client. This option will only be honored if the FORWARDABLE 1446 flag is set in the TGT. The PROXY option is similar; the 1447 resulting ticket will contain the addresses specified by the 1448 client. It will be honored only if the PROXIABLE flag in 1449 the TGT is set. The PROXY option will not be honored on 1450 requests for additional ticket-granting tickets. 1452 If the requested start time is absent or indicates a 1453 time in the past, then the start time of the ticket is set 1454 to the authentication server's current time. If it 1456 Section 3.3.3. - 26 - Expires 15 October 1993 1458 Version 5 - Revision 5.2 1460 indicates a time in the future, but the POSTDATED option has 1461 not been specified or the MAY-POSTDATE flag is not set in 1462 the TGT, then the error KDC_ERR_CANNOT_POSTDATE is returned. 1463 Otherwise, if the ticket-granting ticket has the MAY- 1464 POSTDATE flag set, then the resulting ticket will be post- 1465 dated and the requested starttime is checked against the 1466 policy of the local realm. If acceptable, the ticket's start 1467 time is set as requested, and the INVALID flag is set. The 1468 postdated ticket must be validated before use by presenting 1469 it to the KDC after the starttime has been reached. How- 1470 ever, in no case may the starttime, endtime, or renew-till 1471 time of a newly-issued postdated ticket extend beyond the 1472 renew-till time of the ticket-granting ticket. 1474 If the ENC-TKT-IN-SKEY option has been specified and an 1475 additional ticket has been included in the request, the KDC 1476 will decrypt the additional ticket using the key for the 1477 server to which the additional ticket was issued and verify 1478 that it is a ticket-granting ticket. If the name of the 1479 requested server is missing from the request, the name of 1480 the client in the additional ticket will be used. Otherwise 1481 the name of the requested server will be compared to the 1482 name of the client in the additional ticket and if dif- 1483 ferent, the request will be rejected. If the request 1484 succeeds, the session key from the additional ticket will be 1485 used to encrypt the new ticket that is issued instead of 1486 using the key of the server for which the new ticket will be 1487 used[17]. 1489 If the name of the server in the ticket that is 1490 presented to the KDC as part of the authentication header is 1491 not that of the ticket-granting server itself, and the 1492 server is registered in the realm of the KDC, If the RENEW 1493 option is requested, then the KDC will verify that the 1494 RENEWABLE flag is set in the ticket and that the renew_till 1495 time is still in the future. If the VALIDATE option is 1496 rqeuested, the KDC will check that the starttime has passed 1497 and the INVALID flag is set. If the PROXY option is 1498 requested, then the KDC will check that the PROXIABLE flag 1499 is set in the ticket. If the tests succeed, the KDC will 1500 issue the appropriate new ticket. 1502 Whenever a request is made to the ticket-granting 1503 server, the presented ticket(s) is(are) checked against a 1504 hot-list of tickets which have been canceled. This hot-list 1505 might be implemented by storing a range of issue dates for 1506 "suspect tickets"; if a presented ticket had an authtime in 1507 __________________________ 1509 [17] This allows easy implementation of user-to-user 1510 authentication [6], which uses ticket-granting ticket 1511 session keys in lieu of secret server keys in situa- 1512 tions where such secret keys could be easily comprom- 1513 ised. 1515 Section 3.3.3. - 27 - Expires 15 October 1993 1517 Version 5 - Revision 5.2 1519 that range, it would be rejected. In this way, a stolen 1520 ticket-granting ticket or renewable ticket cannot be used to 1521 gain additional tickets (renewals or otherwise) once the 1522 theft has been reported. Any normal ticket obtained before 1523 it was reported stolen will still be valid (because they 1524 require no interaction with the KDC), but only until their 1525 normal expiration time. 1527 The ciphertext part of the response in the KRB_TGS_REP 1528 message is encrypted in the sub-session key from the Authen- 1529 ticator, if present, or the session key key from the 1530 ticket-granting ticket. It is not encrypted using the 1531 client's secret key. Furthermore, the client's key's 1532 expiration date and the key version number fields are left 1533 out since these values are stored along with the client's 1534 database record, and that record is not needed to satisfy a 1535 request based on a ticket-granting ticket. See section A.6 1536 for pseudocode. 1538 3.3.3.1. Encoding the transited field 1540 If the identity of the server in the TGT that is 1541 presented to the KDC as part of the authentication header is 1542 that of the ticket-granting service, but the TGT was issued 1543 from another realm, the KDC will look up the inter-realm key 1544 shared with that realm and use that key to decrypt the 1545 ticket. If the ticket is valid, then the KDC< will honor 1546 the request, subject to the constraints outlined above in 1547 the section describing the AS exchange. The realm part of 1548 the client's identity will be taken from the ticket-granting 1549 ticket. The name of the realm that issued the ticket- 1550 granting ticket will be added to the transited field of the 1551 ticket to be issued. This is accomplished by reading the 1552 transited field from the ticket-granting ticket (which is 1553 treated as an unordered set of realm names), adding the new 1554 realm to the set, then constructing and writing out its 1555 encoded (shorthand) form (this may involve a rearrangement 1556 of the existing encoding). 1558 Note that the ticket-granting service does not add the 1559 name of its own realm. Instead, its responsibility is to 1560 add the name of the previous realm. This prevents a mali- 1561 cious Kerberos server from intentionally leaving out its own 1562 name (it could, however, omit other realms' names). 1564 The names of neither the local realm nor the 1565 principal's realm are to be included in the transited field. 1566 They appear elsewhere in the ticket and both are known to 1567 have taken part in authenticating the principal. Since the 1568 endpoints are not included, both local and single-hop 1569 inter-realm authentication result in a transited field that 1570 is empty. 1572 Because the name of each realm transited is added to 1574 Section 3.3.3.1. - 28 - Expires 15 October 1993 1576 Version 5 - Revision 5.2 1578 this field, it might potentially be very long. To decrease 1579 the length of this field, its contents are encoded. The 1580 initially supported encoding is optimized for the normal 1581 case of inter-realm communication: a hierarchical arrange- 1582 ment of realms using either domain or X.500 style realm 1583 names. This encoding (called DOMAIN-X500-COMPRESS) is now 1584 described. 1586 Realm names in the transited field are separated by a 1587 ",". The ",", "\", trailing "."s, and leading spaces (" ") 1588 are special characters, and if they are part of a realm 1589 name, they must be quoted in the transited field by preced- 1590 ing them with a "\". 1592 A realm name ending with a "." is interpreted as being 1593 prepended to the previous realm. For example, we can encode 1594 traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, 1595 and CS.WASHINGTON.EDU as: 1597 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1599 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end- 1600 points, that they would not be included in this field, and 1601 we would have: 1603 "EDU,MIT.,WASHINGTON.EDU" 1605 A realm name beginning with a "/" is interpreted as being 1606 appended to the previous realm[18]. If it is to stand by 1607 itself, then it should be preceded by a space (" "). For 1608 example, we can encode traversal of /COM/HP/APOLLO, /COM/HP, 1609 /COM, and /COM/DEC as: 1611 "/COM,/HP,/APOLLO, /COM/DEC". 1613 Like the example above, if /COM/HP/APOLLO and /COM/DEC are 1614 endpoints, they they would not be included in this field, 1615 and we would have: 1617 "/COM,/HP" 1619 A null subfield preceding or following a "," indicates 1620 that all realms between the previous realm and the next 1621 realm have been traversed[19]. Thus, "," means that all 1622 __________________________ 1624 [18] For the purpose of appending, the realm preceding 1625 the first listed realm is considered to be the null 1626 realm (""). 1627 [19] For the purpose of interpreting null subfields, 1628 the client's realm is considered to precede those in 1629 the transited field, and the server's realm is con- 1630 sidered to follow them. 1632 Section 3.3.3.1. - 29 - Expires 15 October 1993 1634 Version 5 - Revision 5.2 1636 realms along the path between the client and the server have 1637 been traversed. ",EDU, /COM," means that that all realms 1638 from the client's realm up to EDU (in a domain style hierar- 1639 chy) have been traversed, and that everything from /COM down 1640 to the server's realm in an X.500 style has also been 1641 traversed. This could occur if the EDU realm in one hierar- 1642 chy shares an inter-realm key directly with the /COM realm 1643 in another hierarchy. 1645 3.3.4. Receipt of KRB_TGS_REP message 1647 When the KRB_TGS_REP is received by the client, it is pro- 1648 cessed in the same manner as the KRB_AS_REP processing 1649 described above. The primary difference is that the cipher- 1650 text part of the response must be decrypted using the ses- 1651 sion key from the ticket-granting ticket rather than the 1652 client's secret key. See section A.7 for pseudocode. 1654 3.4. The KRB_SAFE Exchange 1656 The KRB_SAFE message may be used by clients requiring 1657 the ability to detect modifications of messages they 1658 exchange. It achieves this by including a keyed collision- 1659 proof checksum of the user data and some control informa- 1660 tion. The checksum is keyed with an encryption key (usually 1661 the last key negotiated via subkeys, or the session key if 1662 no negotiation has occured). 1664 3.4.1. Generation of a KRB_SAFE message 1666 When an application wishes to send a KRB_SAFE message, it 1667 collects its data and the appropriate control information 1668 and computes a checksum over them. The checksum algorithm 1669 should be some sort of keyed one-way hash function (such as 1670 the RSA-MD5-DES checksum algorithm specified in section 1671 6.4.5, or the DES MAC), generated using the sub-session key 1672 if present, or the session key. Different algorithms may be 1673 selected by changing the checksum type in the message. 1674 Unkeyed or non-collision-proof checksums are not suitable 1675 for this use. 1677 The control information for the KRB_SAFE message 1678 includes both a timestamp and a sequence number. The 1679 designer of an application using the KRB_SAFE message must 1680 choose at least one of the two mechanisms. This choice 1681 should be based on the needs of the application protocol. 1683 Sequence numbers are useful when all messages sent will 1684 be received by one's peer. Connection state is presently 1685 required to maintain the session key, so maintaining the 1686 next sequence number should not present an additional prob- 1687 lem. 1689 If the application protocol is expected to tolerate 1691 Section 3.4.1. - 30 - Expires 15 October 1993 1693 Version 5 - Revision 5.2 1695 lost messages without them being resent, the use of the 1696 timestamp is the appropriate replay detection mechanism. 1697 Using timestamps is also the appropriate mechanism for 1698 multi-cast protocols where all of one's peers share a common 1699 sub-session key, but some messages will be sent to a subset 1700 of one's peers. 1702 After computing the checksum, the client then transmits 1703 the information and checksum to the recipient in the message 1704 format specified in section 5.6.1. 1706 3.4.2. Receipt of KRB_SAFE message 1708 When an application receives a KRB_SAFE message, it verifies 1709 it as follows. If any error occurs, an error code is 1710 reported for use by the application. 1712 The message is first checked by verifying that the pro- 1713 tocol version and type fields match the current version and 1714 KRB_SAFE, respectively. A mismatch generates a 1715 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1716 application verifies that the checksum used is a collision- 1717 proof keyed checksum, and if it is not, a 1718 KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient 1719 verifies that the operating system's report of the sender's 1720 address matches the sender's address in the message, and (if 1721 a recipient address is specified or the recipient requires 1722 an address) that one of the recipient's addresses appears as 1723 the recipient's address in the message. A failed match for 1724 either case generates a KRB_AP_ERR_BADADDR error. Then the 1725 timestamp and usec and/or the sequence number fields are 1726 checked. If timestamp and usec are expected and not 1727 present, or they are present but not current, the 1728 KRB_AP_ERR_SKEW error is generated. If the server name, 1729 along with the client name, time and microsecond fields from 1730 the Authenticator match any recently-seen such tuples, the 1731 KRB_AP_ERR_REPEAT error is generated. If an incorrect 1732 sequence number is included, or a sequence number is 1733 expected but not present, the KRB_AP_ERR_BADORDER error is 1734 generated. If neither a timestamp and usec or a sequence 1735 number is present, a KRB_AP_ERR_MODIFIED error is generated. 1736 Finally, the checksum is computed over the data and control 1737 information, and if it doesn't match the received checksum, 1738 a KRB_AP_ERR_MODIFIED error is generated. 1740 If all the checks succeed, the application is assured 1741 that the message was generated by its peer and was not modi- 1742 fied in transit. 1744 3.5. The KRB_PRIV Exchange 1746 The KRB_PRIV message may be used by clients requiring 1747 confidentiality and the ability to detect modifications of 1748 exchanged messages. It achieves this by encrypting the 1750 Section 3.5. - 31 - Expires 15 October 1993 1752 Version 5 - Revision 5.2 1754 messages and adding control information. 1756 3.5.1. Generation of a KRB_PRIV message 1758 When an application wishes to send a KRB_PRIV message, it 1759 collects its data and the appropriate control information 1760 (specified in section 5.7.1) and encrypts them under an 1761 encryption key (usually the last key negotiated via subkeys, 1762 or the session key if no negotiation has occured). As part 1763 of the control information, the client must choose to use 1764 either a timestamp or a sequence number (or both); see the 1765 discussion in section 3.4.1 for guidelines on which to use. 1766 After the user data and control information are encrypted, 1767 the client transmits the ciphertext and some "envelope" 1768 information to the recipient. 1770 3.5.2. Receipt of KRB_PRIV message 1772 When an application receives a KRB_PRIV message, it verifies 1773 it as follows. If any error occurs, an error code is 1774 reported for use by the application. 1776 The message is first checked by verifying that the pro- 1777 tocol version and type fields match the current version and 1778 KRB_PRIV, respectively. A mismatch generates a 1779 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1780 application then decrypts the ciphertext and processes the 1781 resultant plaintext. If decryption shows the data to have 1782 been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- 1783 erated. The recipient verifies that the operating system's 1784 report of the sender's address matches the sender's address 1785 in the message, and (if a recipient address is specified or 1786 the recipient requires an address) that one of the 1787 recipient's addresses appears as the recipient's address in 1788 the message. A failed match for either case generates a 1789 KRB_AP_ERR_BADADDR error. Then the timestamp and usec 1790 and/or the sequence number fields are checked. If timestamp 1791 and usec are expected and not present, or they are present 1792 but not current, the KRB_AP_ERR_SKEW error is generated. If 1793 the server name, along with the client name, time and 1794 microsecond fields from the Authenticator match any 1795 recently-seen such tuples, the KRB_AP_ERR_REPEAT error is 1796 generated. If an incorrect sequence number is included, or 1797 a sequence number is expected but not present, the 1798 KRB_AP_ERR_BADORDER error is generated. If neither a time- 1799 stamp and usec or a sequence number is present, a 1800 KRB_AP_ERR_MODIFIED error is generated. 1802 If all the checks succeed, the application can assume 1803 the message was generated by its peer, and was securely 1804 transmitted (without intruders able to see the unencrypted 1805 contents). 1807 Section 3.5.2. - 32 - Expires 15 October 1993 1809 Version 5 - Revision 5.2 1811 3.6. The KRB_CRED Exchange 1813 The KRB_CRED message may be used by clients requiring 1814 the ability to send Kerberos credentials from one host to 1815 another. It achieves this by sending the tickets together 1816 with encrypted data containing the session keys and other 1817 information associated with the tickets. 1819 3.6.1. Generation of a KRB_CRED message 1821 When an application wishes to send a KRB_CRED message it 1822 first (using the KRB_TGS exchange) obtains credentials to be 1823 sent to the remote host. It then constructs a KRB_CRED mes- 1824 sage using the ticket or tickets so obtained, placing the 1825 session key needed to use each ticket in the key field of 1826 the corresponding KrbCredInfo sequence of the encrypted part 1827 of the the KRB_CRED message. 1829 Other information associated with each ticket and 1830 obtained during the KRB_TGS exchange is also placed in the 1831 corresponding KrbCredInfo sequence in the encrypted part of 1832 the KRB_CRED message. The current time and, if specifically 1833 required by the application the nonce, s-address, and r- 1834 address fields, are placed in the encrypted part of the 1835 KRB_CRED message which is then encrypted under an encryption 1836 key previosuly exchanged in the KRB_AP exchange (usually the 1837 last key negotiated via subkeys, or the session key if no 1838 negotiation has occured). 1840 3.6.2. Receipt of KRB_CRED message 1842 When an application receives a KRB_CRED message, it verifies 1843 it. If any error occurs, an error code is reported for use 1844 by the application. The message is verified by checking 1845 that the protocol version and type fields match the current 1846 version and KRB_CRED, respectively. A mismatch generates a 1847 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1848 application then decrypts the ciphertext and processes the 1849 resultant plaintext. If decryption shows the data to have 1850 been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen- 1851 erated. 1853 If present or required, the recipient verifies that the 1854 operating system's report of the sender's address matches 1855 the sender's address in the message, and that one of the 1856 recipient's addresses appears as the recipient's address in 1857 the message. A failed match for either case generates a 1858 KRB_AP_ERR_BADADDR error. The timestamp and usec fields 1859 (and the nonce field if required) are checked next. If the 1860 timestamp and usec are not present, or they are present but 1861 not current, the KRB_AP_ERR_SKEW error is generated. 1863 If all the checks succeed, the application stores each 1864 of the new tickets in its ticket cache together with the 1866 Section 3.6.2. - 33 - Expires 15 October 1993 1868 Version 5 - Revision 5.2 1870 session key and other information in the corresponding 1871 KrbCredInfo sequence from the encrypted part of the KRB_CRED 1872 message. 1874 4. The Kerberos Database 1876 The Kerberos server must have access to a database contain- 1877 ing the principal identifiers and secret keys of principals 1878 to be authenticated[20]. 1880 4.1. Database contents 1882 A database entry should contain at least the following 1883 fields: 1885 Field Value 1887 name Principal's identif- 1888 ier 1889 key Principal's secret key 1890 p_kvno Principal's key version 1891 max_life Maximum lifetime for Tickets 1892 max_renewable_life Maximum total lifetime for renewable Tickets 1894 The name field is an encoding of the principal's identifier. 1895 The key field contains an encryption key. This key is the 1896 principal's secret key. (The key can be encrypted before 1897 storage under a Kerberos "master key" to protect it in case 1898 the database is compromised but the master key is not. In 1899 that case, an extra field must be added to indicate the mas- 1900 ter key version used, see below.) The p_kvno field is the 1901 key version number of the principal's secret key. The 1902 max_life field contains the maximum allowable lifetime (end- 1903 time - starttime) for any Ticket issued for this principal. 1904 The max_renewable_life field contains the maximum allowable 1905 total lifetime for any renewable Ticket issued for this 1906 principal. (See section 3.1 for a description of how these 1907 lifetimes are used in determining the lifetime of a given 1908 Ticket.) 1910 A server may provide KDC service to several realms, as 1911 long as the database representation provides a mechanism to 1912 distinguish between principal records with identifiers which 1913 differ only in the realm name. 1914 __________________________ 1916 [20] The implementation of the Kerberos server need not 1917 combine the database and the server on the same 1918 machine; it is feasible to store the principal database 1919 in, say, a network name service, as long as the entries 1920 stored therein are protected from disclosure to and 1921 modification by unauthorized parties. However, we 1922 recommend against such strategies, as they can make 1923 system management and threat analysis quite complex. 1925 Section 4.1. - 34 - Expires 15 October 1993 1927 Version 5 - Revision 5.2 1929 When an application server's key changes, if the change 1930 is routine (i.e. not the result of disclosure of the old 1931 key), the old key should be retained by the server until all 1932 tickets that had been issued using that key have expired. 1933 Because of this, it is possible for several keys to be 1934 active for a single principal. Ciphertext encrypted in a 1935 principal's key is always tagged with the version of the key 1936 that was used for encryption, to help the recipient find the 1937 proper key for decryption. 1939 When more than one key is active for a particular prin- 1940 cipal, the principal will have more than one record in the 1941 Kerberos database. The keys and key version numbers will 1942 differ between the records (the rest of the fields may or 1943 may not be the same). Whenever Kerberos issues a ticket, or 1944 responds to a request for initial authentication, the most 1945 recent key (known by the Kerberos server) will be used for 1946 encryption. This is the key with the highest key version 1947 number. 1949 4.2. Additional fields 1951 Project Athena's KDC implementation uses additional fields 1952 in its database: 1954 Field Value 1956 K_kvno Kerberos' key version 1957 expiration Expiration date for entry 1958 attributes Bit field of attributes 1959 mod_date Timestamp of last modification 1960 mod_name Modifying principal's identifier 1962 The K_kvno field indicates the key version of the Kerberos 1963 master key under which the principal's secret key is 1964 encrypted. 1966 After an entry's expiration date has passed, the KDC 1967 will return an error to any client attempting to gain tick- 1968 ets as or for the principal. (A database may want to main- 1969 tain two expiration dates: one for the principal, and one 1970 for the principal's current key. This allows password aging 1971 to work independently of the principal's expiration date. 1972 However, due to the limited space in the responses, the KDC 1973 must combine the key expiration and principal expiration 1974 date into a single value called "key_exp", which is used as 1975 a hint to the user to take administrative action.) 1977 The attributes field is a bitfield used to govern the 1978 operations involving the principal. This field might be 1979 useful in conjunction with user registration procedures, for 1980 site-specific policy implementations (Project Athena 1981 currently uses it for their user registration process 1983 Section 4.2. - 35 - Expires 15 October 1993 1985 Version 5 - Revision 5.2 1987 controlled by the system-wide database service, Moira [7]),. 1988 or to identify the "string to key" conversion algorithm used 1989 for a principal's key[21]. Other bits are used to indicate 1990 that certain ticket options should not be allowed in tickets 1991 encrypted under a principal's key (one bit each): Disallow 1992 issuing postdated tickets, disallow issuing forwardable 1993 tickets, disallow issuing tickets based on TGT authentica- 1994 tion, disallow issuing renewable tickets, disallow issuing 1995 proxiable tickets, and disallow issuing tickets for which 1996 the principal is the server. 1998 The mod_date field contains the time of last modifica- 1999 tion of the entry, and the mod_name field contains the name 2000 of the principal which last modified the entry. 2002 4.3. Frequently Changing Fields 2004 Some KDC implementations may wish to maintain the last 2005 time that a request was made by a particular principal. 2006 Information that might be maintained includes the time of 2007 the last request, the time of the last request for a 2008 ticket-granting ticket, the time of the last use of a 2009 ticket-granting ticket, or other times. This information 2010 can then be returned to the user in the last-req field (see 2011 section 5.2). 2013 Other frequently changing information that can be main- 2014 tained is the latest expiration time for any tickets that 2015 have been issued using each key. This field would be used 2016 to indicate how long old keys must remain valid to allow the 2017 continued use of outstanding tickets. 2019 4.4. Site Constants 2021 The KDC implementation should have the following confi- 2022 gurable constants or options, to allow an administrator to 2023 make and enforce policy decisions: 2025 + The minimum supported lifetime (used to determine whether 2026 the KDC_ERR_NEVER_VALID error should be returned). This 2027 constant should reflect reasonable expectations of 2028 round-trip time to the KDC, encryption/decryption time, 2029 and processing time by the client and target server, and 2030 it should allow for a minimum "useful" lifetime. 2032 + The maximum allowable total (renewable) lifetime of a 2033 ticket (renew_till - starttime). 2035 + The maximum allowable lifetime of a ticket (endtime - 2036 starttime). 2037 __________________________ 2039 [21] See the discussion of the padata field in section 2040 5.4.2 for details on why this can be useful. 2042 Section 4.4. - 36 - Expires 15 October 1993 2044 Version 5 - Revision 5.2 2046 + Whether to allow the issue of tickets with empty address 2047 fields (including the ability to specify that such tick- 2048 ets may only be issued if the request specifies some 2049 authorization_data). 2051 + Whether proxiable, forwardable, renewable or post-datable 2052 tickets are to be issued. 2054 5. Message Specifications 2056 The following sections describe the exact contents and 2057 encoding of protocol messages and objects. The ASN.1 base 2058 definitions are presented in the first subsection. The 2059 remaining subsections specify the protocol objects (tickets 2060 and authenticators) and messages. Specification of encryp- 2061 tion and checksum techniques, and the fields related to 2062 them, appear in section 6. 2064 5.1. ASN.1 Distinguished Encoding Representation 2066 All uses of ASN.1 in Kerberos shall use the Dis- 2067 tinguished Encoding Representation of the data elements as 2068 described in the X.509 specification, section 8.7 [8]. 2070 5.2. ASN.1 Base Definitions 2072 The following ASN.1 base definitions are used in the 2073 rest of this section. Note that since the underscore char- 2074 acter (_) is not permitted in ASN.1 names, the hyphen (-) is 2075 used in its place for the purposes of ASN.1 names. 2077 Realm ::= GeneralString 2078 PrincipalName ::= SEQUENCE { 2079 name-type[0] INTEGER, 2080 name-string[1] SEQUENCE OF GeneralString 2081 } 2083 Kerberos realms are encoded as GeneralStrings. Realms shall 2084 not contain a character with the code 0 (the ASCII NUL). 2085 Most realms will usually consist of several components 2086 separated by periods (.), in the style of Internet Domain 2087 Names, or separated by slashes (/) in the style of X.500 2088 names. Acceptable forms for realm names are specified in 2089 section 7. A PrincipalName is a typed sequence of com- 2090 ponents consisting of the following sub-fields: 2092 name-type This field specifies the type of name that fol- 2093 lows. Pre-defined values for this field are 2094 specified in section 7.2. The name-type should be 2095 treated as a hint. Ignoring the name type, no two 2096 names can be the same (i.e. at least one of the 2097 components, or the realm, must be different). 2099 Section 5.2. - 37 - Expires 15 October 1993 2101 Version 5 - Revision 5.2 2103 This constraint may be eliminated in the future. 2105 name-stringThis field encodes a sequence of components that 2106 form a name, each component encoded as a General- 2107 String. Taken together, a PrincipalName and a 2108 Realm form a principal identifier. Most Princi- 2109 palNames will have only a few components (typi- 2110 cally one or two). 2112 KerberosTime ::= GeneralizedTime 2113 -- Specifying UTC time zone (Z) 2115 The timestamps used in Kerberos are encoded as General- 2116 izedTimes. An encoding shall specify the UTC time zone (Z) 2117 and shall not include any fractional portions of the 2118 seconds. It further shall not include any separators. 2119 Example: The only valid format for UTC time 6 minutes, 27 2120 seconds after 9 pm on 6 November 1985 is 19851106210627Z. 2122 HostAddress ::= SEQUENCE { 2123 addr-type[0] INTEGER, 2124 address[1] OCTET STRING 2125 } 2127 HostAddresses ::= SEQUENCE OF SEQUENCE { 2128 addr-type[0] INTEGER, 2129 address[1] OCTET STRING 2130 } 2132 The host adddress encodings consists of two fields: 2134 addr-type This field specifies the type of address that 2135 follows. Pre-defined values for this field are 2136 specified in section 8.1. 2138 address This field encodes a single address of type addr- 2139 type. 2141 The two forms differ slightly. HostAddress contains exactly 2142 one address; HostAddresses contains a sequence of possibly 2143 many addresses. 2145 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2146 ad-type[0] INTEGER, 2147 ad-data[1] OCTET STRING 2148 } 2150 ad-data This field contains authorization data to be 2151 interpreted according to the value of the 2153 Section 5.2. - 38 - Expires 15 October 1993 2155 Version 5 - Revision 5.2 2157 corresponding ad-type field. 2159 ad-type This field specifies the format for the ad-data 2160 subfield. All negative values are reserved for 2161 local use. Non-negative values are reserved for 2162 registered use. 2164 APOptions ::= BIT STRING { 2165 reserved(0), 2166 use-session-key(1), 2167 mutual-required(2) 2168 } 2170 TicketFlags ::= BIT STRING { 2171 reserved(0), 2172 forwardable(1), 2173 forwarded(2), 2174 proxiable(3), 2175 proxy(4), 2176 may-postdate(5), 2177 postdated(6), 2178 invalid(7), 2179 renewable(8), 2180 initial(9), 2181 pre-authent(10), 2182 hw-authent(11) 2183 } 2185 KDCOptions ::= BIT STRING { 2186 reserved(0), 2187 forwardable(1), 2188 forwarded(2), 2189 proxiable(3), 2190 proxy(4), 2191 allow-postdate(5), 2192 postdated(6), 2193 unused7(7), 2194 renewable(8), 2195 unused9(9), 2196 unused10(10), 2197 unused11(11), 2198 renewable-ok(27), 2199 enc-tkt-in-skey(28), 2200 renew(30), 2201 validate(31) 2202 } 2204 LastReq ::= SEQUENCE OF SEQUENCE { 2205 lr-type[0] INTEGER, 2206 lr-value[1] KerberosTime 2207 } 2209 Section 5.2. - 39 - Expires 15 October 1993 2211 Version 5 - Revision 5.2 2213 lr-type This field indicates how the following lr-value 2214 field is to be interpreted. Negative values indi- 2215 cate that the information pertains only to the 2216 responding server. Non-negative values pertain to 2217 all servers for the realm. 2219 If the lr-type field is zero (0), then no informa- 2220 tion is conveyed by the lr-value subfield. If the 2221 absolute value of the lr-type field is one (1), 2222 then the lr-value subfield is the time of last 2223 initial request for a TGT. If it is two (2), then 2224 the lr-value subfield is the time of last initial 2225 request. If it is three (3), then the lr-value 2226 subfield is the time of issue for the newest 2227 ticket-granting ticket used. If it is four (4), 2228 then the lr-value subfield is the time of the last 2229 renewal. If it is five (5), then the lr-value 2230 subfield is the time of last request (of any 2231 type). 2233 lr-value This field contains the time of the last request. 2234 The time must be interpreted according to the con- 2235 tents of the accompanying lr-type subfield. 2237 See section 6 for the definitions of Checksum, Check- 2238 sumType, EncryptedData, EncryptionKey, EncryptionType, and 2239 KeyType. 2241 5.3. Tickets and Authenticators 2243 This section describes the format and encryption param- 2244 eters for tickets and authenticators. When a ticket or 2245 authenticator is included in a protocol message it is 2246 treated as an opaque object. 2248 5.3.1. Tickets 2250 A ticket is a record that helps a client authenticate 2251 to a service. A Ticket contains the following information: 2253 Ticket ::= [APPLICATION 1] SEQUENCE { 2254 tkt-vno[0] INTEGER, 2255 realm[1] Realm, 2256 sname[2] PrincipalName, 2257 enc-part[3] EncryptedData 2258 } 2259 -- Encrypted part of ticket 2260 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2261 flags[0] TicketFlags, 2262 key[1] EncryptionKey, 2263 crealm[2] Realm, 2264 cname[3] PrincipalName, 2266 Section 5.3.1. - 40 - Expires 15 October 1993 2268 Version 5 - Revision 5.2 2270 transited[4] TransitedEncoding, 2271 authtime[5] KerberosTime, 2272 starttime[6] KerberosTime OPTIONAL, 2273 endtime[7] KerberosTime, 2274 renew-till[8] KerberosTime OPTIONAL, 2275 caddr[9] HostAddresses OPTIONAL, 2276 authorization-data[10] AuthorizationData OPTIONAL 2277 } 2278 -- encoded Transited field 2279 TransitedEncoding ::= SEQUENCE { 2280 tr-type[0] INTEGER, -- must be registered 2281 contents[1] OCTET STRING 2282 } 2284 The encoding of EncTicketPart is encrypted in the key shared 2285 by Kerberos and the end server (the server's secret key). 2286 See section 6 for the format of the ciphertext. 2288 tkt-vno This field specifies the version number for the 2289 ticket format. This document describes version 2290 number 5. 2292 realm This field specifies the realm that issued a 2293 ticket. It also serves to identify the realm part 2294 of the server's principal identifier. Since a 2295 Kerberos server can only issue tickets for servers 2296 within its realm, the two will always be identi- 2297 cal. 2299 sname This field specifies the name part of the server's 2300 identity. 2302 enc-part This field holds the encrypted encoding of the 2303 EncTicketPart sequence. 2305 flags This field indicates which of various options were 2306 used or requested when the ticket was issued. It 2307 is a bit-field, where the selected options are 2308 indicated by the bit being set (1), and the 2309 unselected options and reserved fields being reset 2310 (0). Bit 0 is the most significant bit. The 2311 encoding of the bits is specified in section 5.2. 2312 The flags are described in more detail above in 2313 section 2. The meanings of the flags are: 2315 Bit(s) Name Description 2317 0 RESERVED Reserved for future expansion of this 2318 field. 2320 Section 5.3.1. - 41 - Expires 15 October 1993 2322 Version 5 - Revision 5.2 2324 1 FORWARDABLE The FORWARDABLE flag is normally only 2325 interpreted by the TGS, and can be 2326 ignored by end servers. When set, this 2327 flag tells the ticket-granting server 2328 that it is OK to issue a new ticket- 2329 granting ticket with a different network 2330 address based on the presented ticket. 2332 2 FORWARDED When set, this flag indicates that the 2333 ticket has either been forwarded or was 2334 issued based on authentication involving 2335 a forwarded ticket-granting ticket. 2337 3 PROXIABLE The PROXIABLE flag is normally only 2338 interpreted by the TGS, and can be 2339 ignored by end servers. The PROXIABLE 2340 flag has an interpretation identical to 2341 that of the FORWARDABLE flag, except 2342 that the PROXIABLE flag tells the 2343 ticket-granting server that only non- 2344 ticket-granting tickets may be issued 2345 with different network addresses. 2347 4 PROXY When set, this flag indicates that a 2348 ticket is a proxy. 2350 5 MAY-POSTDATE The MAY-POSTDATE flag is normally only 2351 interpreted by the TGS, and can be 2352 ignored by end servers. This flag tells 2353 the ticket-granting server that a post- 2354 dated ticket may be issued based on this 2355 ticket-granting ticket. 2357 6 POSTDATED This flag indicates that this ticket has 2358 been postdated. The end-service can 2359 check the authtime field to see when the 2360 original authentication occurred. 2362 7 INVALID This flag indicates that a ticket is 2363 invalid, and it must be validated by the 2364 KDC before use. Application servers 2365 must reject tickets which have this flag 2366 set. 2368 8 RENEWABLE The RENEWABLE flag is normally only 2369 interpreted by the TGS, and can usually 2370 be ignored by end servers (some particu- 2371 larly careful servers may wish to disal- 2372 low renewable tickets). A renewable 2373 ticket can be used to obtain a replace- 2374 ment ticket that expires at a later 2375 date. 2377 Section 5.3.1. - 42 - Expires 15 October 1993 2379 Version 5 - Revision 5.2 2381 9 INITIAL This flag indicates that this ticket was 2382 issued using the AS protocol, and not 2383 issued based on a ticket-granting 2384 ticket. 2386 10 PRE-AUTHENT This flag indicates that during initial 2387 authentication, the client was authenti- 2388 cated by the KDC before a ticket was 2389 issued. The strength of the pre- 2390 authentication method is not indicated, 2391 but is acceptable to the KDC. 2393 11 HW-AUTHENT This flag indicates that the protocol 2394 employed for initial authentication 2395 required the use of hardware expected to 2396 be possessed solely by the named client. 2397 The hardware authentication method is 2398 selected by the KDC and the strength of 2399 the method is not indicated. 2401 12-31 RESERVED Reserved for future use. 2403 key This field exists in the ticket and the KDC 2404 response and is used to pass the session key from 2405 Kerberos to the application server and the client. 2406 The field's encoding is described in section 6.2. 2408 crealm This field contains the name of the realm in which 2409 the client is registered and in which initial 2410 authentication took place. 2412 cname This field contains the name part of the client's 2413 principal identifier. 2415 transited This field lists the names of the Kerberos realms 2416 that took part in authenticating the user to whom 2417 this ticket was issued. It does not specify the 2418 order in which the realms were transited. See 2419 section 3.3.3.1 for details on how this field 2420 encodes the traversed realms. 2422 authtime This field indicates the time of initial authenti- 2423 cation for the named principal. It is the time of 2424 issue for the original ticket on which this ticket 2425 is based. It is included in the ticket to provide 2426 additional information to the end service, and to 2427 provide the necessary information for implementa- 2428 tion of a `hot list' service at the KDC. An end 2429 service that is particularly paranoid could refuse 2431 Section 5.3.1. - 43 - Expires 15 October 1993 2433 Version 5 - Revision 5.2 2435 to accept tickets for which the initial authenti- 2436 cation occurred "too far" in the past. 2438 This field is also returned as part of the 2439 response from the KDC. When returned as part of 2440 the response to initial authentication 2441 (KRB_AS_REP), this is the current time on the Ker- 2442 beros server[22]. 2444 starttime This field in the ticket specifies the time after 2445 which the ticket is valid. Together with endtime, 2446 this field specifies the life of the ticket. If 2447 it is absent from the ticket, its value should be 2448 treated as that of the authtime field. 2450 endtime This field contains the time after which the 2451 ticket will not be honored (its expiration time). 2452 Note that individual services may place their own 2453 limits on the life of a ticket and may reject 2454 tickets which have not yet expired. As such, this 2455 is really an upper bound on the expiration time 2456 for the ticket. 2458 renew-tillThis field is only present in tickets that have 2459 the RENEWABLE flag set in the flags field. It 2460 indicates the maximum endtime that may be included 2461 in a renewal. It can be thought of as the abso- 2462 lute expiration time for the ticket, including all 2463 renewals. 2465 caddr This field in a ticket contains zero (if omitted) 2466 or more (if present) host addresses. These are 2467 the addresses from which the ticket can be used. 2468 If there are no addresses, the ticket can be used 2469 from any location. The decision by the KDC to 2470 issue or by the end server to accept zero-address 2471 tickets is a policy decision and is left to the 2472 Kerberos and end-service administrators; they may 2473 refuse to issue or accept such tickets. The sug- 2474 gested and default policy, however, is that such 2475 tickets will only be issued or accepted when addi- 2476 tional information that can be used to restrict 2477 the use of the ticket is included in the 2478 authorization_data field. Such a ticket is a 2479 __________________________ 2481 [22] It is NOT recommended that this time value be used 2482 to adjust the workstation's clock since the workstation 2483 cannot reliably determine that such a KRB_AS_REP actu- 2484 ally came from the proper KDC in a timely manner. 2486 Section 5.3.1. - 44 - Expires 15 October 1993 2488 Version 5 - Revision 5.2 2490 capability. 2492 Network addresses are included in the ticket to 2493 make it harder for an attacker to use stolen 2494 credentials. Because the session key is not sent 2495 over the network in cleartext, credentials can't 2496 be stolen simply by listening to the network; an 2497 attacker has to gain access to the session key 2498 (perhaps through operating system security 2499 breaches or a careless user's unattended session) 2500 to make use of stolen tickets. 2502 It is important to note that the network address 2503 from which a connection is received cannot be 2504 reliably determined. Even if it could be, an 2505 attacker who has compromised the client's worksta- 2506 tion could use the credentials from there. 2507 Including the network addresses only makes it more 2508 difficult, not impossible, for an attacker to walk 2509 off with stolen credentials and then use them from 2510 a "safe" location. 2512 authorization-data 2513 The authorization-data field is used to pass 2514 authorization data from the principal on whose 2515 behalf a ticket was issued to the application ser- 2516 vice. If no authorization data is included, this 2517 field will be left out. The data in this field 2518 are specific to the end service. It is expected 2519 that the field will contain the names of service 2520 specific objects, and the rights to those objects. 2521 The format for this field is described in section 2522 5.2. Although Kerberos is not concerned with the 2523 format of the contents of the subfields, it does 2524 carry type information (ad-type). 2526 By using the authorization_data field, a principal 2527 is able to issue a proxy that is valid for a 2528 specific purpose. For example, a client wishing 2529 to print a file can obtain a file server proxy to 2530 be passed to the print server. By specifying the 2531 name of the file in the authorization_data field, 2532 the file server knows that the print server can 2533 only use the client's rights when accessing the 2534 particular file to be printed. 2536 It is interesting to note that if one specifies 2537 the authorization-data field of a proxy and leaves 2538 the host addresses blank, the resulting ticket and 2539 session key can be treated as a capability. See 2540 [9] for some suggested uses of this field. 2542 The authorization-data field is optional and does 2544 Section 5.3.1. - 45 - Expires 15 October 1993 2546 Version 5 - Revision 5.2 2548 not have to be included in a ticket. 2550 5.3.2. Authenticators 2552 An authenticator is a record sent with a ticket to a 2553 server to certify the client's knowledge of the encryption 2554 key in the ticket, to help the server detect replays, and to 2555 help choose a "true session key" to use with the particular 2556 session. The encoding is encrypted in the ticket's session 2557 key shared by the client and the server: 2559 -- Unencrypted authenticator 2560 Authenticator ::= [APPLICATION 2] SEQUENCE { 2561 authenticator-vno[0] INTEGER, 2562 crealm[1] Realm, 2563 cname[2] PrincipalName, 2564 cksum[3] Checksum OPTIONAL, 2565 cusec[4] INTEGER, 2566 ctime[5] KerberosTime, 2567 subkey[6] EncryptionKey OPTIONAL, 2568 seq-number[7] INTEGER OPTIONAL, 2569 authorization-data[8] AuthorizationData OPTIONAL 2570 } 2572 authenticator-vno 2573 This field specifies the version number for the 2574 format of the authenticator. This document speci- 2575 fies version 5. 2577 crealm and cname 2578 These fields are the same as those described for 2579 the ticket in section 5.3.1. 2581 cksum This field contains a checksum of the the applica- 2582 tion data that accompanies the KRB_AP_REQ. 2584 cusec This field contains the microsecond part of the 2585 client's timestamp. Its value (before encryption) 2586 ranges from 0 to 999999. It often appears along 2587 with ctime. The two fields are used together to 2588 specify a reasonably accurate timestamp. 2590 ctime This field contains the current time on the 2591 client's host. 2593 subkey This field contains the client's choice for an 2594 encryption key which is to be used to protect this 2595 specific application session. Unless an 2597 Section 5.3.2. - 46 - Expires 15 October 1993 2599 Version 5 - Revision 5.2 2601 application specifies otherwise, if this field is 2602 left out the session key from the ticket will be 2603 used. 2605 seq-numberThis optional field includes the initial sequence 2606 number to be used by the KRB_PRIV or KRB_SAFE mes- 2607 sages when sequence numbers are used to detect 2608 replays (It may also be used by application 2609 specific messages). When included in the authen- 2610 ticator this field specifies the initial sequence 2611 number for messages from the client to the server. 2612 When included in the AP-REP message, the initial 2613 sequence number is that for messages from the 2614 server to the client. When used in KRB_PRIV or 2615 KRB_SAFE messages, it is incremented by one after 2616 each message is sent. 2618 For sequence numbers to adequately support the 2619 detection of replays they should be non-repeating, 2620 even across connection boundaries. The initial 2621 sequence number should be random and uniformly 2622 distributed across the full space of possible 2623 sequence numbers, so that it cannot be guessed by 2624 an attacker and so that it and the successive 2625 sequence numbers do not repeat other sequences. 2627 authorization-data 2628 This field is the same as described for the ticket 2629 in section 5.3.1. It is optional and will only 2630 appear when additional restrictions are to be 2631 placed on the use of a ticket, beyond those car- 2632 ried in the ticket itself. 2634 5.4. Specifications for the AS and TGS exchanges 2636 This section specifies the format of the messages used 2637 in exchange between the client and the Kerberos server. The 2638 format of possible error messages appears in section 5.9.1. 2640 5.4.1. KRB_KDC_REQ definition 2642 The KRB_KDC_REQ message has no type of its own. 2643 Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ 2644 depending on whether the request is for an initial ticket or 2645 an additional ticket. In either case, the message is sent 2646 from the client to the Authentication Server to request 2647 credentials for a service. 2649 The message fields are: 2651 AS-REQ ::= [APPLICATION 10] KDC-REQ 2652 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2654 Section 5.4.1. - 47 - Expires 15 October 1993 2656 Version 5 - Revision 5.2 2658 KDC-REQ ::= SEQUENCE { 2659 pvno[1] INTEGER, 2660 msg-type[2] INTEGER, 2661 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2662 req-body[4] KDC-REQ-BODY 2663 } 2665 PA-DATA ::= SEQUENCE { 2666 padata-type[1] INTEGER, 2667 padata-value[2] OCTET STRING, 2668 -- might be encoded AP-REQ 2669 } 2671 KDC-REQ-BODY ::= SEQUENCE { 2672 kdc-options[0] KDCOptions, 2673 cname[1] PrincipalName OPTIONAL, 2674 -- Used only in AS-REQ 2675 realm[2] Realm, -- Server's realm 2676 -- Also client's in AS-REQ 2677 sname[3] PrincipalName OPTIONAL, 2678 from[4] KerberosTime OPTIONAL, 2679 till[5] KerberosTime, 2680 rtime[6] KerberosTime OPTIONAL, 2681 nonce[7] INTEGER, 2682 etype[8] SEQUENCE OF INTEGER, -- EncryptionType, 2683 -- in preference order 2684 addresses[9] HostAddresses OPTIONAL, 2685 enc-authorization-data[10] EncryptedData OPTIONAL, 2686 -- Encrypted AuthorizationData encoding 2687 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2688 } 2690 The fields in this message are: 2692 pvno This field is included in each message, and speci- 2693 fies the protocol version number. This document 2694 specifies protocol version 5. 2696 msg-type This field indicates the type of a protocol mes- 2697 sage. It will almost always be the same as the 2698 application identifier associated with a message. 2699 It is included to make the identifier more readily 2700 accessible to the application. For the KDC-REQ 2701 message, this type will be KRB_AS_REQ or 2702 KRB_TGS_REQ. 2704 padata The padata (pre-authentication data) field con- 2705 tains a sequence of authentication information 2706 which may be needed before credentials can be 2707 issued or decrypted. In the case of requests for 2708 additional tickets (KRB_TGS_REQ), this field will 2710 Section 5.4.1. - 48 - Expires 15 October 1993 2712 Version 5 - Revision 5.2 2714 include an element with padata-type of PA-TGS-REQ 2715 and data of an authentication header (ticket- 2716 granting ticket and authenticator). The checksum 2717 in the authenticator (which must be collision- 2718 proof) is to be computed over the KDC-REQ-BODY 2719 encoding. In most requests for initial authenti- 2720 cation (KRB_AS_REQ) and most replies (KDC-REP), 2721 the padata field will be left out. 2723 This field may also contain information needed by 2724 certain extensions to the Kerberos protocol. For 2725 example, it might be used to initially verify the 2726 identity of a client before any response is 2727 returned. This is accomplished with a padata 2728 field with padata-type equal to PA-ENC-TIMESTAMP 2729 and padata-value defined as follows: 2731 padata-type ::= PA-ENC-TIMESTAMP 2732 padata-value ::= EncryptedData -- PA-ENC-TS-ENC 2734 PA-ENC-TS-ENC ::= SEQUENCE { 2735 patimestamp[0] KerberosTime, -- client's time 2736 pausec[1] INTEGER OPTIONAL 2737 } 2739 with patimestamp containing the client's time and 2740 pausec containing the microseconds which may be 2741 omitted if a client will not generate more than 2742 one request per second. The ciphertext (padata- 2743 value) consists of the PA-ENC-TS-ENC sequence, 2744 encrypted using the client's secret key. 2746 The padata field can also contain information 2747 needed to help the KDC or the client select the 2748 key needed for generating or decrypting the 2749 response. This form of the padata is useful for 2750 supporting the use of certain "smartcards" with 2751 Kerberos. The details of such extensions are 2752 beyond the scope of this specification. See [10] 2753 for additional uses of this field. 2755 padata-type 2756 The padata-type element of the padata field indi- 2757 cates the way that the padata-value element is to 2758 be interpreted. Negative values of padata-type 2759 are reserved for unregistered use; non-negative 2760 values are used for a registered interpretation of 2761 the element type. 2763 req-body This field is a placeholder delimiting the extent 2764 of the remaining fields. If a checksum is to be 2765 calculated over the request, it is calculated over 2766 an encoding of the KDC-REQ-BODY sequence which is 2768 Section 5.4.1. - 49 - Expires 15 October 1993 2770 Version 5 - Revision 5.2 2772 enclosed within the req-body field. 2774 kdc-options 2775 This field appears in the KRB_AS_REQ and 2776 KRB_TGS_REQ requests to the KDC and indicates the 2777 flags that the client wants set on the tickets as 2778 well as other information that is to modify the 2779 behavior of the KDC. Where appropriate, the name 2780 of an option may be the same as the flag that is 2781 set by that option. Although in most case, the 2782 bit in the options field will be the same as that 2783 in the flags field, this is not guaranteed, so it 2784 is not acceptable to simply copy the options field 2785 to the flags field. There are various checks that 2786 must be made before honoring an option anyway. 2788 The kdc_options field is a bit-field, where the 2789 selected options are indicated by the bit being 2790 set (1), and the unselected options and reserved 2791 fields being reset (0). The encoding of the bits 2792 is specified in section 5.2. The options are 2793 described in more detail above in section 2. The 2794 meanings of the options are: 2796 Bit(s)Name Description 2798 0 RESERVED Reserved for future expansion of this 2799 field. 2801 1 FORWARDABLE The FORWARDABLE option indicates that 2802 the ticket to be issued is to have its 2803 forwardable flag set. It may only be 2804 set on the initial request, or in a sub- 2805 sequent request if the ticket-granting 2806 ticket on which it is based is also for- 2807 wardable. 2809 2 FORWARDED The FORWARDED option is only specified 2810 in a request to the ticket-granting 2811 server and will only be honored if the 2812 ticket-granting ticket in the request 2813 has its FORWARDABLE bit set. This 2814 option indicates that this is a request 2815 for forwarding. The address(es) of the 2816 host from which the resulting ticket is 2817 to be valid are included in the 2818 addresses field of the request. 2820 Section 5.4.1. - 50 - Expires 15 October 1993 2822 Version 5 - Revision 5.2 2824 3 PROXIABLE The PROXIABLE option indicates that the 2825 ticket to be issued is to have its prox- 2826 iable flag set. It may only be set on 2827 the initial request, or in a subsequent 2828 request if the ticket-granting ticket on 2829 which it is based is also proxiable. 2831 4 PROXY The PROXY option indicates that this is 2832 a request for a proxy. This option will 2833 only be honored if the ticket-granting 2834 ticket in the request has its PROXIABLE 2835 bit set. The address(es) of the host 2836 from which the resulting ticket is to be 2837 valid are included in the addresses 2838 field of the request. 2840 5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates that 2841 the ticket to be issued is to have its 2842 MAY-POSTDATE flag set. It may only be 2843 set on the initial request, or in a sub- 2844 sequent request if the ticket-granting 2845 ticket on which it is based also has its 2846 MAY-POSTDATE flag set. 2848 6 POSTDATED The POSTDATED option indicates that this 2849 is a request for a postdated ticket. 2850 This option will only be honored if the 2851 ticket-granting ticket on which it is 2852 based has its MAY-POSTDATE flag set. 2853 The resulting ticket will also have its 2854 INVALID flag set, and that flag may be 2855 reset by a subsequent request to the KDC 2856 after the starttime in the ticket has 2857 been reached. 2859 7 UNUSED This option is presently unused. 2861 8 RENEWABLE The RENEWABLE option indicates that the 2862 ticket to be issued is to have its 2863 RENEWABLE flag set. It may only be set 2864 on the initial request, or when the 2865 ticket-granting ticket on which the 2866 request is based is also renewable. If 2867 this option is requested, then the rtime 2868 field in the request contains the 2869 desired absolute expiration time for the 2870 ticket. 2872 9-26 RESERVED Reserved for future use. 2874 Section 5.4.1. - 51 - Expires 15 October 1993 2876 Version 5 - Revision 5.2 2878 27 RENEWABLE-OK The RENEWABLE-OK option indicates that a 2879 renewable ticket will be acceptable if a 2880 ticket with the requested life cannot 2881 otherwise be provided. If a ticket with 2882 the requested life cannot be provided, 2883 then a renewable ticket may be issued 2884 with a renew-till equal to the the 2885 requested endtime. The value of the 2886 renew-till field may still be limited by 2887 local limits, or limits selected by the 2888 individual principal or server. 2890 28 ENC-TKT-IN-SKEYThis option is used only by the ticket- 2891 granting service. The ENC-TKT-IN-SKEY 2892 option indicates that the ticket for the 2893 end server is to be encrypted in the 2894 session key from the additional ticket- 2895 granting ticket provided. 2897 29 RESERVED Reserved for future use. 2899 30 RENEW This option is used only by the ticket- 2900 granting service. The RENEW option 2901 indicates that the present request is 2902 for a renewal. The ticket provided is 2903 encrypted in the secret key for the 2904 server on which it is valid. This 2905 option will only be honored if the 2906 ticket to be renewed has its RENEWABLE 2907 flag set and if the time in its renew- 2908 till field has not passed. The ticket 2909 to be renewed is passed in the padata 2910 field as part of the authentication 2911 header. 2913 31 VALIDATE This option is used only by the ticket- 2914 granting service. The VALIDATE option 2915 indicates that the request is to vali- 2916 date a postdated ticket. It will only 2917 be honored if the ticket presented is 2918 postdated, presently has its INVALID 2919 flag set, and would be otherwise usable 2920 at this time. A ticket cannot be vali- 2921 dated before its starttime. The ticket 2922 presented for validation is encrypted in 2923 the key of the server for which it is 2924 valid and is passed in the padata field 2925 as part of the authentication header. 2927 cname and sname 2928 These fields are the same as those described for 2929 the ticket in section 5.3.1. sname may only be 2931 Section 5.4.1. - 52 - Expires 15 October 1993 2933 Version 5 - Revision 5.2 2935 absent when the ENC-TKT-IN-SKEY option is speci- 2936 fied. If absent, the name of the server is taken 2937 from the name of the client in the ticket passed 2938 as additional-tickets. 2940 enc-authorization-data 2941 The enc-authorization-data, if present (and it can 2942 only be present in the TGS_REQ form), is an encod- 2943 ing of the desired authorization-data encrypted 2944 under the sub-session key if present in the 2945 Authenticator, or alternatively from the session 2946 key in the ticket-granting ticket, both from the 2947 padata field in the KRB_AP_REQ. 2949 realm This field specifies the realm part of the 2950 server's principal identifier. In the AS 2951 exchange, this is also the realm part of the 2952 client's principal identifier. 2954 from This field is included in the KRB_AS_REQ and 2955 KRB_TGS_REQ ticket requests when the requested 2956 ticket is to be postdated. It specifies the 2957 desired start time for the requested ticket. 2959 till This field contains the expiration date requested 2960 by the client in a ticket request. 2962 rtime This field is the requested renew-till time sent 2963 from a client to the KDC in a ticket request. It 2964 is optional. 2966 nonce This field is part of the KDC request and 2967 response. It it intended to hold a random number 2968 generated by the client. If the same number is 2969 included in the encrypted response from the KDC, 2970 it provides evidence that the response is fresh 2971 and has not been replayed by an attacker. Nonces 2972 must never be re-used. Ideally, it should be gen- 2973 erated randomly, but if the correct time is known, 2974 it may suffice[23]. 2975 __________________________ 2977 [23] Note, however, that if the time is used as the 2978 nonce, one must make sure that the workstation time is 2979 monotonically increasing. If the time is ever reset 2980 backwards, there is a small, but finite, probability 2981 that a nonce will be reused. 2983 Section 5.4.1. - 53 - Expires 15 October 1993 2985 Version 5 - Revision 5.2 2987 etype This field specifies the desired encryption algo- 2988 rithm to be used in the response. 2990 addresses This field is included in the initial request for 2991 tickets, and optionally included in requests for 2992 additional tickets from the ticket-granting 2993 server. It specifies the addresses from which the 2994 requested ticket is to be valid. Normally it 2995 includes the addresses for the client's host. If 2996 a proxy is requested, this field will contain 2997 other addresses. The contents of this field are 2998 usually copied by the KDC into the caddr field of 2999 the resulting ticket. 3001 additional-tickets 3002 Additional tickets may be optionally included in a 3003 request to the ticket-granting server. If the 3004 ENC-TKT-IN-SKEY option has been specified, then 3005 the session key from the additional ticket will be 3006 used in place of the server's key to encrypt the 3007 new ticket. If more than one option which 3008 requires additional tickets has been specified, 3009 then the additional tickets are used in the order 3010 specified by the ordering of the options bits (see 3011 kdc-options, above). 3013 The application code will be either ten (10) or twelve 3014 (12) depending on whether the request is for an initial 3015 ticket (AS-REQ) or for an additional ticket (TGS-REQ). 3017 The optional fields (addresses, authorization-data and 3018 additional-tickets) are only included if necessary to per- 3019 form the operation specified in the kdc-options field. 3021 It should be noted that in KRB_TGS_REQ, the protocol 3022 version number appears twice and two different message types 3023 appear: the KRB_TGS_REQ message contains these fields as 3024 does the authentication header (KRB_AP_REQ) that is passed 3025 in the padata field. 3027 5.4.2. KRB_KDC_REP definition 3029 The KRB_KDC_REP message format is used for the reply 3030 from the KDC for either an initial (AS) request or a subse- 3031 quent (TGS) request. There is no message type for 3032 KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 3033 KRB_TGS_REP. The key used to encrypt the ciphertext part of 3034 the reply depends on the message type. For KRB_AS_REP, the 3035 ciphertext is encrypted in the client's secret key, and the 3036 client's key version number is included in the key version 3037 number for the encrypted data. For KRB_TGS_REP, the 3039 Section 5.4.2. - 54 - Expires 15 October 1993 3041 Version 5 - Revision 5.2 3043 ciphertext is encrypted in the sub-session key from the 3044 Authenticator, or if absent, the session key from the 3045 ticket-granting ticket used in the request. In that case, 3046 no version number will be present in the EncryptedData 3047 sequence. 3049 The KRB_KDC_REP message contains the following fields: 3051 AS-REP ::= [APPLICATION 11] KDC-REP 3052 TGS-REP ::= [APPLICATION 13] KDC-REP 3054 KDC-REP ::= SEQUENCE { 3055 pvno[0] INTEGER, 3056 msg-type[1] INTEGER, 3057 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 3058 crealm[3] Realm, 3059 cname[4] PrincipalName, 3060 ticket[5] Ticket, 3061 enc-part[6] EncryptedData 3062 } 3064 EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart 3065 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 3067 EncKDCRepPart ::= SEQUENCE { 3068 key[0] EncryptionKey, 3069 last-req[1] LastReq, 3070 nonce[2] INTEGER, 3071 key-expiration[3] KerberosTime OPTIONAL, 3072 flags[4] TicketFlags, 3073 authtime[5] KerberosTime, 3074 starttime[6] KerberosTime OPTIONAL, 3075 endtime[7] KerberosTime, 3076 renew-till[8] KerberosTime OPTIONAL, 3077 srealm[9] Realm, 3078 sname[10] PrincipalName, 3079 caddr[11] HostAddresses OPTIONAL 3080 } 3082 pvno and msg-type 3083 These fields are described above in section 5.4.1. 3084 msg-type is either KRB_AS_REP or KRB_TGS_REP. 3086 padata This field is described in detail in section 3087 5.4.1. One possible use for this field is to 3088 encode an alternate "mix-in" string to be used 3089 __________________________ 3091 [25] An application code in the encrypted part of a 3092 message provides an additional check that the message 3093 was decrypted properly. 3095 Section 5.4.2. - 55 - Expires 15 October 1993 3097 Version 5 - Revision 5.2 3099 with a string-to-key algorithm (such as is 3100 described in section 6.3.2). This ability is use- 3101 ful to ease transitions if a realm name needs to 3102 change (e.g. when a company is acquired); in such 3103 a case all existing password-derived entries in 3104 the KDC database would be flagged as needing a 3105 special mix-in string until the next password 3106 change. 3108 crealm, cname, srealm and sname 3109 These fields are the same as those described for 3110 the ticket in section 5.3.1. 3112 ticket The newly-issued ticket, from section 5.3.1. 3114 enc-part This field is a place holder for the ciphertext 3115 and related information that forms the encrypted 3116 part of a message. The description of the 3117 encrypted part of the message follows each appear- 3118 ance of this field. The encrypted part is encoded 3119 as described in section 6.1. 3121 key This field is the same as described for the ticket 3122 in section 5.3.1. 3124 last-req This field is returned by the KDC and specifies 3125 the time(s) of the last request by a principal. 3126 Depending on what information is available, this 3127 might be the last time that a request for a 3128 ticket-granting ticket was made, or the last time 3129 that a request based on a ticket-granting ticket 3130 was successful. It also might cover all servers 3131 for a realm, or just the particular server. Some 3132 implementations may display this information to 3133 the user to aid in discovering unauthorized use of 3134 one's identity. It is similar in spirit to the 3135 last login time displayed when logging into 3136 timesharing systems. 3138 nonce This field is described above in section 5.4.1. 3140 key-expiration 3141 The key-expiration field is part of the response 3142 from the KDC and specifies the time that the 3143 client's secret key is due to expire. The expira- 3144 tion might be the result of password aging or an 3145 account expiration. This field will usually be 3147 Section 5.4.2. - 56 - Expires 15 October 1993 3149 Version 5 - Revision 5.2 3151 left out of the TGS reply since the response to 3152 the TGS request is encrypted in a session key and 3153 no client information need be retrieved from the 3154 KDC database. It is up to the application client 3155 (usually the login program) to take appropriate 3156 action (such as notifying the user) if the expira- 3157 tion time is imminent. 3159 flags, authtime, starttime, endtime, renew-till and caddr 3160 These fields are duplicates of those found in the 3161 encrypted portion of the attached ticket (see sec- 3162 tion 5.3.1), provided so the client may verify 3163 they match the intended request and to assist in 3164 proper ticket caching. If the message is of type 3165 KRB_TGS_REP, the caddr field will only be filled 3166 in if the request was for a proxy or forwarded 3167 ticket, or if the user is substituting a subset of 3168 the addresses from the ticket granting ticket. If 3169 the client-requested addresses are not present or 3170 not used, then the addresses contained in the 3171 ticket will be the same as those included in the 3172 ticket-granting ticket. 3174 5.5. Client/Server (CS) message specifications 3176 This section specifies the format of the messages used 3177 for the authentication of the client to the application 3178 server. 3180 5.5.1. KRB_AP_REQ definition 3182 The KRB_AP_REQ message contains the Kerberos protocol 3183 version number, the message type KRB_AP_REQ, an options 3184 field to indicate any options in use, and the ticket and 3185 authenticator themselves. The KRB_AP_REQ message is often 3186 referred to as the "authentication header". 3188 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3189 pvno[0] INTEGER, 3190 msg-type[1] INTEGER, 3191 ap-options[2] APOptions, 3192 ticket[3] Ticket, 3193 authenticator[4] EncryptedData 3194 } 3196 APOptions ::= BIT STRING { 3197 reserved(0), 3198 use-session-key(1), 3199 mutual-required(2) 3200 } 3202 Section 5.5.1. - 57 - Expires 15 October 1993 3204 Version 5 - Revision 5.2 3206 pvno and msg-type 3207 These fields are described above in section 5.4.1. 3208 msg-type is KRB_AP_REQ. 3210 ap-optionsThis field appears in the application request 3211 (KRB_AP_REQ) and affects the way the request is 3212 processed. It is a bit-field, where the selected 3213 options are indicated by the bit being set (1), 3214 and the unselected options and reserved fields 3215 being reset (0). The encoding of the bits is 3216 specified in section 5.2. The meanings of the 3217 options are: 3219 Bit(s)Name Description 3221 0 RESERVED Reserved for future expansion of this 3222 field. 3224 1 USE-SESSION-KEYThe USE-SESSION-KEY option indicates 3225 that the ticket the client is presenting 3226 to a server is encrypted in the session 3227 key from the server's ticket-granting 3228 ticket. When this option is not speci- 3229 fied, the ticket is encrypted in the 3230 server's secret key. 3232 2 MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the 3233 server that the client requires mutual 3234 authentication, and that it must respond 3235 with a KRB_AP_REP message. 3237 3-31 RESERVED Reserved for future use. 3239 ticket This field is a ticket authenticating the client 3240 to the server. 3242 authenticator 3243 This contains the authenticator, which includes 3244 the client's choice of a subkey. Its encoding is 3245 described in section 5.3.2. 3247 5.5.2. KRB_AP_REP definition 3249 The KRB_AP_REP message contains the Kerberos protocol 3250 version number, the message type, and an encrypted time- 3251 stamp. The message is sent in in response to an application 3252 request (KRB_AP_REQ) where the mutual authentication option 3253 has been selected in the ap-options field. 3255 __________________________ 3257 Section 5.5.2. - 58 - Expires 15 October 1993 3259 Version 5 - Revision 5.2 3261 AP-REP ::= [APPLICATION 15] SEQUENCE { 3262 pvno[0] INTEGER, 3263 msg-type[1] INTEGER, 3264 enc-part[2] EncryptedData 3265 } 3267 EncAPRepPart ::= [APPLICATION 27[27]] SEQUENCE { 3268 ctime[0] KerberosTime, 3269 cusec[1] INTEGER, 3270 subkey[2] EncryptionKey OPTIONAL, 3271 seq-number[3] INTEGER OPTIONAL 3272 } 3274 The encoded EncAPRepPart is encrypted in the shared session 3275 key of the ticket. The optional subkey field can be used in 3276 an application-arranged negotiation to choose a per associa- 3277 tion session key. 3279 pvno and msg-type 3280 These fields are described above in section 5.4.1. 3281 msg-type is KRB_AP_REP. 3283 enc-part This field is described above in section 5.4.2. 3285 ctime This field contains the current time on the 3286 client's host. 3288 cusec This field contains the microsecond part of the 3289 client's timestamp. 3291 subkey This field contains an encryption key which is to 3292 be used to protect this specific application ses- 3293 sion. See section 3.2.6 for specifics on how this 3294 field is used to negotiate a key. Unless an 3295 application specifies otherwise, if this field is 3296 left out, the sub-session key from the authentica- 3297 tor, or if also left out, the session key from the 3298 ticket will be used. 3300 5.5.3. Error message reply 3302 If an error occurs while processing the application 3303 __________________________ 3304 [27] An application code in the encrypted part of a 3305 message provides an additional check that the message 3306 was decrypted properly. 3308 Section 5.5.3. - 59 - Expires 15 October 1993 3310 Version 5 - Revision 5.2 3312 request, the KRB_ERROR message will be sent in response. 3313 See section 5.9.1 for the format of the error message. The 3314 cname and crealm fields may be left out if the server cannot 3315 determine their appropriate values from the corresponding 3316 KRB_AP_REQ message. If the authenticator was decipherable, 3317 the ctime and cusec fields will contain the values from it. 3319 5.6. KRB_SAFE message specification 3321 This section specifies the format of a message that can 3322 be used by either side (client or server) of an application 3323 to send a tamper-proof message to its peer. It presumes 3324 that a session key has previously been exchanged (for exam- 3325 ple, by using the KRB_AP_REQ/KRB_AP_REP messages). 3327 5.6.1. KRB_SAFE definition 3329 The KRB_SAFE message contains user data along with a 3330 collision-proof checksum keyed with the session key. The 3331 message fields are: 3333 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3334 pvno[0] INTEGER, 3335 msg-type[1] INTEGER, 3336 safe-body[2] KRB-SAFE-BODY, 3337 cksum[3] Checksum 3338 } 3340 KRB-SAFE-BODY ::= SEQUENCE { 3341 user-data[0] OCTET STRING, 3342 timestamp[1] KerberosTime OPTIONAL, 3343 usec[2] INTEGER OPTIONAL, 3344 seq-number[3] INTEGER OPTIONAL, 3345 s-address[4] HostAddress, 3346 r-address[5] HostAddress OPTIONAL 3347 } 3349 pvno and msg-type 3350 These fields are described above in section 5.4.1. 3351 msg-type is KRB_SAFE. 3353 safe-body This field is a placeholder for the body of the 3354 KRB-SAFE message. It is to be encoded separately 3355 and then have the checksum computed over it, for 3356 use in the cksum field. 3358 cksum This field contains the checksum of the applica- 3359 tion data. Checksum details are described in sec- 3360 tion 6.4. The checksum is computed over the 3362 Section 5.6.1. - 60 - Expires 15 October 1993 3364 Version 5 - Revision 5.2 3366 encoding of the KRB-SAFE-BODY sequence. 3368 user-data This field is part of the KRB_SAFE and KRB_PRIV 3369 messages and contain the application specific data 3370 that is being passed from the sender to the reci- 3371 pient. 3373 timestamp This field is part of the KRB_SAFE and KRB_PRIV 3374 messages. Its contents are the current time as 3375 known by the sender of the message. By checking 3376 the timestamp, the recipient of the message is 3377 able to make sure that it was recently generated, 3378 and is not a replay. 3380 usec This field is part of the KRB_SAFE and KRB_PRIV 3381 headers. It contains the microsecond part of the 3382 timestamp. 3384 seq-number 3385 This field is described above in section 5.3.2. 3387 s-address This field specifies the address in use by the 3388 sender of the message. 3390 r-address This field specifies the address in use by the 3391 recipient of the message. It may be omitted for 3392 some uses (such as broadcast protocols), but the 3393 recipient may arbitrarily reject such messages. 3394 This field along with s-address can be used to 3395 help detect messages which have been incorrectly 3396 or maliciously delivered to the wrong recipient. 3398 5.7. KRB_PRIV message specification 3400 This section specifies the format of a message that can 3401 be used by either side (client or server) of an application 3402 to securely and privately send a message to its peer. It 3403 presumes that a session key has previously been exchanged 3404 (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3406 5.7.1. KRB_PRIV definition 3408 The KRB_PRIV message contains user data encrypted in 3409 the Session Key. The message fields are: 3411 __________________________ 3413 [29] An application code in the encrypted part of a 3414 message provides an additional check that the message 3416 Section 5.7.1. - 61 - Expires 15 October 1993 3418 Version 5 - Revision 5.2 3420 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3421 pvno[0] INTEGER, 3422 msg-type[1] INTEGER, 3423 enc-part[3] EncryptedData 3424 } 3426 EncKrbPrivPart ::= [APPLICATION 28[29]] SEQUENCE { 3427 user-data[0] OCTET STRING, 3428 timestamp[1] KerberosTime OPTIONAL, 3429 usec[2] INTEGER OPTIONAL, 3430 seq-number[3] INTEGER OPTIONAL, 3431 s-address[4] HostAddress, -- sender's addr 3432 r-address[5] HostAddress OPTIONAL -- recip's addr 3433 } 3435 pvno and msg-type 3436 These fields are described above in section 5.4.1. 3437 msg-type is KRB_PRIV. 3439 enc-part This field holds an encoding of the EncKrbPrivPart 3440 sequence encrypted under the session key[30]. 3441 This encrypted encoding is used for the enc-part 3442 field of the KRB-PRIV message. See section 6 for 3443 the format of the ciphertext. 3445 user-data, timestamp, usec, s-address and r-address 3446 These fields are described above in section 5.6.1. 3448 seq-number 3449 This field is described above in section 5.3.2. 3451 5.8. KRB_CRED message specification 3453 This section specifies the format of a message that can 3454 be used to send Kerberos credentials from one principal to 3455 another. It is presented here to encourage a common 3456 __________________________ 3457 was decrypted properly. 3459 [30] If supported by the encryption method in use, an 3460 initialization vector may be passed to the encryption 3461 procedure, in order to achieve proper cipher chaining. 3462 The initialization vector might come from the last 3463 block of the ciphertext from the previous KRB_PRIV mes- 3464 sage, but it is the application's choice whether or not 3465 to use such an initialization vector. If left out, the 3466 default initialization vector for the encryption algo- 3467 rithm will be used. 3469 Section 5.8. - 62 - Expires 15 October 1993 3471 Version 5 - Revision 5.2 3473 mechanism to be used by applications when forwarding tickets 3474 or providing proxies to subordinate servers. It presumes 3475 that a session key has already been exchanged perhaps by 3476 using the KRB_AP_REQ/KRB_AP_REP messages. 3478 5.8.1. KRB_CRED definition 3480 The KRB_CRED message contains a sequence of tickets to 3481 be sent and information needed to use the tickets, including 3482 the session key from each. The information needed to use 3483 the tickets is encryped under an encryption key previously 3484 exchanged. The message fields are: 3486 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3487 pvno[0] INTEGER, 3488 msg-type[1] INTEGER, -- KRB_CRED 3489 tickets[2] SEQUENCE OF Ticket, 3490 enc-part[3] EncryptedData 3491 } 3493 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3494 ticket-info[0] SEQUENCE OF KrbCredInfo, 3495 nonce[1] INTEGER OPTIONAL, 3496 timestamp[2] KerberosTime OPTIONAL, 3497 usec[3] INTEGER OPTIONAL, 3498 s-address[4] HostAddress OPTIONAL, 3499 r-address[5] HostAddress OPTIONAL 3500 } 3502 KrbCredInfo ::= SEQUENCE { 3503 key[0] EncryptionKey, 3504 prealm[1] Realm OPTIONAL, 3505 pname[2] PrincipalName OPTIONAL, 3506 flags[3] TicketFlags OPTIONAL, 3507 authtime[4] KerberosTime OPTIONAL, 3508 starttime[5] KerberosTime OPTIONAL, 3509 endtime[6] KerberosTime OPTIONAL 3510 renew-till[7] KerberosTime OPTIONAL, 3511 srealm[8] Realm OPTIONAL, 3512 sname[9] PrincipalName OPTIONAL, 3513 caddr[10] HostAddresses OPTIONAL 3514 } 3516 pvno and msg-type 3517 These fields are described above in section 5.4.1. 3518 msg-type is KRB_CRED. 3520 tickets 3521 These are the tickets obtained from the KDC 3523 Section 5.8.1. - 63 - Expires 15 October 1993 3525 Version 5 - Revision 5.2 3527 specifically for use by the intended recipient. 3528 Successive tickets are paired with the correspond- 3529 ing KrbCredInfo sequence from the enc-part of the 3530 KRB-CRED message. 3532 enc-part This field holds an encoding of the EncKrbCredPart 3533 sequence encrypted under the session key shared 3534 between the sender and the intended recipient. 3535 This encrypted encoding is used for the enc-part 3536 field of the KRB-CRED message. See section 6 for 3537 the format of the ciphertext. 3539 nonce If practical, an application may require the 3540 inclusion of a nonce generated by the recipient of 3541 the message. If the same value is included as the 3542 nonce in the message, it provides evidence that 3543 the message is fresh and has not been replayed by 3544 an attacker. A nonce must never be re-used; it 3545 should be generated randomly by the recipient of 3546 the message and provided to the sender of the mes- 3547 sage in an application specific manner. 3549 timestamp and usec 3551 These fields specify the time that the KRB-CRED 3552 message was generated. The time is used to pro- 3553 vide assurance that the message is fresh. 3555 s-address and r-address 3556 These fields are described above in section 5.6.1. 3557 They are used optionally to provide additional 3558 assurance of the integrity of the KRB-CRED mes- 3559 sage. 3561 key This field exists in the corresponding ticket 3562 passed by the KRB-CRED message and is used to pass 3563 the session key from the sender to the intended 3564 recipient. The field's encoding is described in 3565 section 6.2. 3567 The following fields are optional. If present, they 3568 can be associated with the credentials in the remote ticket 3569 file. If left out, then it is assumed that the recipient of 3570 the credentials already knows their value. 3572 prealm and pname 3573 The name and realm of the delegated principal 3574 identity. 3576 Section 5.8.1. - 64 - Expires 15 October 1993 3578 Version 5 - Revision 5.2 3580 flags, authtime, starttime, endtime, renew-till, srealm, 3581 sname, and caddr 3582 These fields contain the values of the correspond- 3583 ing fields from the ticket found in the ticket 3584 field. Descriptions of the fields are identical 3585 to the descriptions in the KDC-REP message. 3587 5.9. Error message specification 3589 This section specifies the format for the KRB_ERROR 3590 message. The fields included in the message are intended to 3591 return as much information as possible about an error. It 3592 is not expected that all the information required by the 3593 fields will be available for all types of errors. If the 3594 appropriate information is not available when the message is 3595 composed, the corresponding field will be left out of the 3596 message. 3598 Note that since the KRB_ERROR message is not protected 3599 by any encryption, it is quite possible for an intruder to 3600 synthesize or modify such a message. In particular, this 3601 means that the client should not use any fields in this mes- 3602 sage for security-critical purposes, such as setting a sys- 3603 tem clock or generating a fresh authenticator. The message 3604 can be useful, however, for advising a user on the reason 3605 for some failure. 3607 5.9.1. KRB_ERROR definition 3609 The KRB_ERROR message consists of the following fields: 3611 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3612 pvno[0] INTEGER, 3613 msg-type[1] INTEGER, 3614 ctime[2] KerberosTime OPTIONAL, 3615 cusec[3] INTEGER OPTIONAL, 3616 stime[4] KerberosTime, 3617 susec[5] INTEGER, 3618 error-code[6] INTEGER, 3619 crealm[7] Realm OPTIONAL, 3620 cname[8] PrincipalName OPTIONAL, 3621 realm[9] Realm, -- Correct realm 3622 sname[10] PrincipalName, -- Correct name 3623 e-text[11] GeneralString OPTIONAL, 3624 e-data[12] OCTET STRING OPTIONAL 3625 } 3627 pvno and msg-type 3628 These fields are described above in section 5.4.1. 3629 msg-type is KRB_ERROR. 3631 Section 5.9.1. - 65 - Expires 15 October 1993 3633 Version 5 - Revision 5.2 3635 ctime This field is described above in section 5.4.1. 3637 cusec This field is described above in section 5.5.2. 3639 stime This field contains the current time on the 3640 server. It is of type KerberosTime. 3642 susec This field contains the microsecond part of the 3643 server's timestamp. Its value ranges from 0 to 3644 999. It appears along with stime. The two fields 3645 are used in conjunction to specify a reasonably 3646 accurate timestamp. 3648 error-codeThis field contains the error code returned by 3649 Kerberos or the server when a request fails. To 3650 interpret the value of this field see the list of 3651 error codes in section 8. Implementations are 3652 encouraged to provide for national language sup- 3653 port in the display of error messages. 3655 crealm, cname, srealm and sname 3656 These fields are described above in section 5.3.1. 3658 e-text This field contains additional text to help 3659 explain the error code associated with the failed 3660 request (for example, it might include a principal 3661 name which was unknown). 3663 e-data This field contains additional data about the 3664 error for use by the application to help it 3665 recover from or handle the error. If the error- 3666 code is KDC_ERR_PREAUTH_REQUIRED, then the e-data 3667 field will contain an encoding of a sequence of 3668 padata fields, each corresponding to an acceptable 3669 pre-authentication method and optionally contain- 3670 ing data for the method: 3672 METHOD-DATA ::= SEQUENCE of PA-DATA 3674 If the error-code is KRB_AP_ERR_METHOD, then the 3675 e-data field will contain an encoding of the fol- 3676 lowing sequence: 3678 METHOD-DATA ::= SEQUENCE { 3679 method-type[0] INTEGER, 3681 Section 5.9.1. - 66 - Expires 15 October 1993 3683 Version 5 - Revision 5.2 3685 method-data[1] OCTET STRING OPTIONAL 3686 } 3688 method-type will indicate the required alternate 3689 method; method-data will contain any required 3690 additional information. 3692 6. Encryption and Checksum Specifications 3694 The Kerberos protocols described in this document are 3695 designed to use stream encryption ciphers, which can be 3696 simulated using commonly available block encryption ciphers, 3697 such as the Data Encryption Standard [11], in conjunction 3698 with block chaining and checksum methods [12]. Encryption 3699 is used to prove the identities of the network entities par- 3700 ticipating in message exchanges. The Key Distribution 3701 Center for each realm is trusted by all principals 3702 registered in that realm to store a secret key in confi- 3703 dence. Proof of knowledge of this secret key is used to 3704 verify the authenticity of a principal. 3706 The KDC uses the principal's secret key (in the AS 3707 exchange) or a shared session key (in the TGS exchange) to 3708 encrypt responses to ticket requests; the ability to obtain 3709 the secret key or session key implies the knowledge of the 3710 appropriate keys and the identity of the KDC. The ability 3711 of a principal to decrypt the KDC response and present a 3712 Ticket and a properly formed Authenticator (generated with 3713 the session key from the KDC response) to a service verifies 3714 the identity of the principal; likewise the ability of the 3715 service to extract the session key from the Ticket and prove 3716 its knowledge thereof in a response verifies the identity of 3717 the service. 3719 The Kerberos protocols generally assume that the 3720 encryption used is secure from cryptanalysis; however, in 3721 some cases, the order of fields in the encrypted portions of 3722 messages are arranged to minimize the effects of poorly 3723 chosen keys. It is still important to choose good keys. If 3724 keys are derived from user-typed passwords, those passwords 3725 need to be well chosen to make brute force attacks more dif- 3726 ficult. Poorly chosen keys still make easy targets for 3727 intruders. 3729 The following sections specify the encryption and 3730 checksum mechanisms currently defined for Kerberos. The 3731 encodings, chaining, and padding requirements for each are 3732 described. For encryption methods, it is often desirable to 3733 place random information (often referred to as a confounder) 3734 at the start of the message. The requirements for a con- 3735 founder are specified with each encryption mechanism. 3737 Section 6. - 67 - Expires 15 October 1993 3739 Version 5 - Revision 5.2 3741 Some encryption systems use a block-chaining method to 3742 improve the the security characteristics of the ciphertext. 3743 However, these chaining methods often don't provide an 3744 integrity check upon decryption. Such systems (such as DES 3745 in CBC mode) must be augmented with a checksum of the plain- 3746 text which can be verified at decryption and used to detect 3747 any tampering or damage. Such checksums should be good at 3748 detecting burst errors in the input. If any damage is 3749 detected, the decryption routine is expected to return an 3750 error indicating the failure of an integrity check. Each 3751 encryption type is expected to provide and verify an 3752 appropriate checksum. The specification of each encryption 3753 method sets out its checksum requirements. 3755 Finally, where a key is to be derived from a user's 3756 password, an algorithm for converting the password to a key 3757 of the appropriate type is included. It is desirable for 3758 the string to key function to be one-way, and for the map- 3759 ping to be different in different realms. This is important 3760 because users who are registered in more than one realm will 3761 often use the same password in each, and it is desirable 3762 that an attacker compromising the Kerberos server in one 3763 realm not obtain or derive the user's key in another. 3765 For an discussion of the integrity characteristics of 3766 the candidate encryption and checksum methods considered for 3767 Kerberos, the the reader is referred to [13]. 3769 6.1. Encryption Specifications 3771 The following ASN.1 definition describes all encrypted 3772 messages. The enc-part field which appears in the unen- 3773 crypted part of messages in section 5 is a sequence consist- 3774 ing of an encryption type, an optional key version number, 3775 and the ciphertext. 3777 EncryptedData ::= SEQUENCE { 3778 etype[0] INTEGER, -- EncryptionType 3779 kvno[1] INTEGER OPTIONAL, 3780 cipher[2] OCTET STRING -- ciphertext 3781 } 3783 etype This field identifies which encryption algorithm 3784 was used to encipher the cipher. Detailed specif- 3785 ications for selected encryption types appear 3786 later in this section. 3788 kvno This field contains the version number of the key 3789 under which data is encrypted. It is only present 3790 in messages encrypted under long lasting keys, 3791 such as principals' secret keys. 3793 Section 6.1. - 68 - Expires 15 October 1993 3795 Version 5 - Revision 5.2 3797 cipher This field contains the enciphered text, encoded 3798 as an OCTET STRING. 3800 The cipher field is generated by applying the specified 3801 encryption algorithm to data composed of the message and 3802 algorithm-specific inputs. Encryption mechanisms defined 3803 for use with Kerberos must take sufficient measures to 3804 guarantee the integrity of the plaintext, and we recommend 3805 they also take measures to protect against precomputed dic- 3806 tionary attacks. If the encryption algorithm is not itself 3807 capable of doing so, the protections can often be enhanced 3808 by adding a checksum and a confounder. 3810 The suggested format for the data to be encrypted 3811 includes a confounder, a checksum, the encoded plaintext, 3812 and any necessary padding. The msg-seq field contains the 3813 part of the protocol message described in section 5 which is 3814 to be encrypted. The confounder, checksum, and padding are 3815 all untagged and untyped, and their length is exactly suffi- 3816 cient to hold the appropriate item. The type and length is 3817 implicit and specified by the particular encryption type 3818 being used (etype). The format for the data to be encrypted 3819 is described in the following diagram: 3821 +-----------+----------+-------------+-----+ 3822 |confounder | check | msg-seq | pad | 3823 +-----------+----------+-------------+-----+ 3825 The format cannot be described in ASN.1, but for those who 3826 prefer an ASN.1-like notation: 3828 CipherText ::= ENCRYPTED SEQUENCE { 3829 confounder[0] UNTAGGED[32] OCTET STRING(conf_length) OPTIONAL, 3830 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 3831 msg-seq[2] MsgSequence, 3832 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 3833 } 3835 One generates a random confounder of the appropriate 3836 length, placing it in confounder; zeroes out check; calcu- 3837 lates the appropriate checksum over confounder, check, and 3838 __________________________ 3840 [32] In the above specification, UNTAGGED OCTET 3841 STRING(length) is the notation for an octet string with 3842 its tag and length removed. It is not a valid ASN.1 3843 type. The tag bits and length must be removed from the 3844 confounder since the purpose of the confounder is so 3845 that the message starts with random data, but the tag 3846 and its length are fixed. For other fields, the length 3847 and tag would be redundant if they were included be- 3848 cause they are specified by the encryption type. 3850 Section 6.1. - 69 - Expires 15 October 1993 3852 Version 5 - Revision 5.2 3854 msg-seq, placing the result in check; adds the necessary 3855 padding; then encrypts using the specified encryption type 3856 and the appropriate key. 3858 Unless otherwise specified, a definition of an encryp- 3859 tion algorithm that specifies a checksum, a length for the 3860 confounder field, or an octet boundary for padding uses this 3861 ciphertext format[33]. Those fields which are not specified 3862 will be omitted. 3864 In the interest of allowing all implementations using a 3865 particular encryption type to communicate with all others 3866 using that type, the specification of an encryption type 3867 defines any checksum that is needed as part of the encryp- 3868 tion process. If an alternative checksum is to be used, a 3869 new encryption type must be defined. 3871 Some cryptosystems require additional information 3872 beyond the key and the data to be encrypted. For example, 3873 DES, when used in cipher-block-chaining mode, requires an 3874 initialization vector. If required, the description for 3875 each encryption type must specify the source of such addi- 3876 tional information. 3878 6.2. Encryption Keys 3880 The sequence below shows the encoding of an encryption 3881 key: 3883 EncryptionKey ::= SEQUENCE { 3884 keytype[0] INTEGER, 3885 keyvalue[1] OCTET STRING 3886 } 3888 keytype This field specifies the type of encryption key 3889 that follows in the keyvalue field. It will 3890 almost always correspond to the encryption algo- 3891 rithm used to generate the EncryptedData, though 3892 more than one algorithm may use the same type of 3893 key (the mapping is many to one). This might hap- 3894 pen, for example, if the encryption algorithm uses 3895 __________________________ 3897 [33] The ordering of the fields in the CipherText is 3898 important. Additionally, messages encoded in this for- 3899 mat must include a length as part of the msg-seq field. 3900 This allows the recipient to verify that the message 3901 has not been truncated. Without a length, an attacker 3902 could use a chosen plaintext attack to generate a mes- 3903 sage which could be truncated, while leaving the check- 3904 sum intact. Note that if the msg-seq is an encoding of 3905 an ASN.1 SEQUENCE or OCTET STRING, then the length is 3906 part of that encoding. 3908 Section 6.2. - 70 - Expires 15 October 1993 3910 Version 5 - Revision 5.2 3912 an alternate checksum algorithm for an integrity 3913 check, or a different chaining mechanism. 3915 keyvalue This field contains the key itself, encoded as an 3916 octet string. 3918 All negative values for the encryption key type are 3919 reserved for local use. All non-negative values are 3920 reserved for officially assigned type fields and interpreta- 3921 tions. 3923 6.3. Encryption Systems 3925 6.3.1. The NULL Encryption System (null) 3927 If no encryption is in use, the encryption system is 3928 said to be the NULL encryption system. In the NULL encryp- 3929 tion system there is no checksum, confounder or padding. 3930 The ciphertext is simply the plaintext. The NULL Key is 3931 used by the null encryption system and is zero octets in 3932 length, with keytype zero (0). 3934 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) 3936 The des-cbc-crc encryption mode encrypts information 3937 under the Data Encryption Standard [11] using the cipher 3938 block chaining mode [12]. A CRC-32 checksum (described in 3939 ISO 3309 [14]) is applied to the confounder and message 3940 sequence (msg-seq) and placed in the cksum field. DES 3941 blocks are 8 bytes. As a result, the data to be encrypted 3942 (the concatenation of confounder, checksum, and message) 3943 must be padded to an 8 byte boundary before encryption. The 3944 details of the encryption of this data are identical to 3945 those for the des-cbc-md5 encryption mode. 3947 Note that, since the CRC-32 checksum is not collision- 3948 proof, an attacker could use a probabilistic chosen- 3949 plaintext attack to generate a valid message even if a con- 3950 founder is used [13]. The use of collision-proof checksums 3951 is recommended for environments where such attacks represent 3952 a significant threat. The use of the CRC-32 as the checksum 3953 for ticket or authenticator is no longer mandated as an 3954 interoperability requirement for Kerberos Version 5 Specifi- 3955 cation 1 (See section 9.1 for specific details). 3957 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) 3959 The des-cbc-md4 encryption mode encrypts information 3960 under the Data Encryption Standard [11] using the cipher 3961 block chaining mode [12]. An MD4 checksum (described in 3962 [15]) is applied to the confounder and message sequence 3963 (msg-seq) and placed in the cksum field. DES blocks are 8 3965 Section 6.3.3. - 71 - Expires 15 October 1993 3967 Version 5 - Revision 5.2 3969 bytes. As a result, the data to be encrypted (the concate- 3970 nation of confounder, checksum, and message) must be padded 3971 to an 8 byte boundary before encryption. The details of the 3972 encryption of this data are identical to those for the des- 3973 cbc-md5 encryption mode. 3975 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) 3977 The des-cbc-md5 encryption mode encrypts information 3978 under the Data Encryption Standard [11] using the cipher 3979 block chaining mode [12]. An MD5 checksum (described in 3980 [16].) is applied to the confounder and message sequence 3981 (msg-seq) and placed in the cksum field. DES blocks are 8 3982 bytes. As a result, the data to be encrypted (the concate- 3983 nation of confounder, checksum, and message) must be padded 3984 to an 8 byte boundary before encryption. 3986 Plaintext and DES ciphtertext are encoded as 8-octet 3987 blocks which are concatenated to make the 64-bit inputs for 3988 the DES algorithms. The first octet supplies the 8 most 3989 significant bits (with the octet's MSbit used as the DES 3990 input block's MSbit, etc.), the second octet the next 8 3991 bits, ..., and the eighth octet supplies the 8 least signi- 3992 ficant bits. 3994 Encryption under DES using cipher block chaining 3995 requires an additional input in the form of an initializa- 3996 tion vector. Unless otherwise specified, zero should be 3997 used as the initialization vector. Kerberos' use of DES 3998 requires an 8-octet confounder. 4000 The DES specifications identify some "weak" and "semi- 4001 weak" keys; those keys shall not be used for encrypting mes- 4002 sages for use in Kerberos. Additionally, because of the way 4003 that keys are derived for the encryption of checksums, keys 4004 shall not be used that yield "weak" or "semi-weak" keys when 4005 eXclusive-ORed with the constant F0F0F0F0F0F0F0F0. 4007 A DES key is 8 octets of data, with keytype one (1). 4008 This consists of 56 bits of key, and 8 parity bits (one per 4009 octet). The key is encoded as a series of 8 octets written 4010 in MSB-first order. The bits within the key are also 4011 encoded in MSB order. For example, if the encryption key is 4012 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 4013 where B1,B2,...,B56 are the key bits in MSB order, and 4014 P1,P2,...,P8 are the parity bits, the first octet of the key 4015 would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the 4016 FIPS 81 introduction for reference.] 4018 To generate a DES key from a text string (password), 4019 the text string normally must have the realm and each com- 4020 ponent of the principal's name appended[34], then padded 4021 __________________________ 4023 Section 6.3.4. - 72 - Expires 15 October 1993 4025 Version 5 - Revision 5.2 4027 with ASCII nulls to an 8 byte boundary. This string is then 4028 fan-folded and eXclusive-ORed with itself to form an 8 byte 4029 DES key. The parity is corrected on the key, and it is used 4030 to generate a DES CBC checksum on the initial string (with 4031 the realm and name appended). Next, parity is corrected on 4032 the CBC checksum. If the result matches a "weak" or "semi- 4033 weak" key as described in the DES specification, it is 4034 eXclusive-ORed with the constant 00000000000000F0. Finally, 4035 the result is returned as the key. Pseudocode follows: 4037 string_to_key(string,realm,name) { 4038 odd = 1; 4039 s = string + realm; 4040 for(each component in name) { 4041 s = s + component; 4042 } 4043 tempkey = NULL; 4044 pad(s); /* with nulls to 8 byte boundary */ 4045 for(8byteblock in s) { 4046 if(odd == 0) { 4047 odd = 1; 4048 reverse(8byteblock) 4049 } 4050 else odd = 0; 4051 tempkey = tempkey XOR 8byteblock; 4052 } 4053 fixparity(tempkey); 4054 key = DES-CBC-check(s,tempkey); 4055 fixparity(key); 4056 if(is_weak_key_key(key)) 4057 key = key XOR 0xF0; 4058 return(key); 4059 } 4061 6.4. Checksums 4063 The following is the ASN.1 definition used for a check- 4064 sum: 4066 Checksum ::= SEQUENCE { 4067 cksumtype[0] INTEGER, 4068 checksum[1] OCTET STRING 4069 } 4071 cksumtype This field indicates the algorithm used to gen- 4072 erate the accompanying checksum. 4074 checksum This field contains the checksum itself, encoded 4075 __________________________ 4076 [34] In some cases, it may be necessary to use a dif- 4077 ferent "mix-in" string for compatibility reasons; see 4078 the discussion of padata in section 5.4.2. 4080 Section 6.4. - 73 - Expires 15 October 1993 4082 Version 5 - Revision 5.2 4084 as an octet string. 4086 Detailed specification of selected checksum types 4087 appear later in this section. Negative values for the 4088 checksum type are reserved for local use. All non-negative 4089 values are reserved for officially assigned type fields and 4090 interpretations. 4092 Checksums used by Kerberos can be classified by two 4093 properties: whether they are collision-proof, and whether 4094 they are keyed. It is infeasible to find two plaintexts 4095 which generate the same checksum value for a collision-proof 4096 checksum. A key is required to perturb or initialize the 4097 algorithm in a keyed checksum. To prevent message-stream 4098 modification by an active attacker, unkeyed checksums should 4099 only be used when the checksum and message will be subse- 4100 quently encrypted (e.g. the checksums defined as part of the 4101 encryption algorithms covered earlier in this section). 4102 Collision-proof checksums can be made tamper-proof as well 4103 if the checksum value is encrypted before inclusion in a 4104 message. In such cases, the composition of the checksum and 4105 the encryption algorithm must be considered a separate 4106 checksum algorithm (e.g. RSA-MD5 encrypted using DES is a 4107 new checksum algorithm of type RSA-MD5-DES). For most keyed 4108 checksums, as well as for the encrypted forms of collision- 4109 proof checksums, Kerberos prepends a confounder before the 4110 checksum is calculated. 4112 6.4.1. The CRC-32 Checksum (crc32) 4114 The CRC-32 checksum calculates a checksum based on a 4115 cyclic redundancy check as described in ISO 3309 [14]. The 4116 resulting checksum is four (4) octets in length. The CRC-32 4117 is neither keyed nor collision-proof. The use of this 4118 checksum is not recommended. An attacker using a proba- 4119 bilistic chosen-plaintext attack as described in [13] might 4120 be able to generate an alternative message that satisfies 4121 the checksum. The use of collision-proof checksums is 4122 recommended for environments where such attacks represent a 4123 significant threat. 4125 6.4.2. The RSA MD4 Checksum (rsa-md4) 4127 The RSA-MD4 checksum calculates a checksum using the 4128 RSA MD4 algorithm [15]. The algorithm takes as input an 4129 input message of arbitrary length and produces as output a 4130 128-bit (16 octet) checksum. RSA-MD4 is believed to be 4131 collision-proof. 4133 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4- 4134 des) 4136 The RSA-MD4-DES checksum calculates a keyed collision- 4137 proof checksum by prepending an 8 octet confounder before 4139 Section 6.4.3. - 74 - Expires 15 October 1993 4141 Version 5 - Revision 5.2 4143 the text, applying the RSA MD4 checksum algorithm, and 4144 encrypting the confounder and the checksum using DES in 4145 cipher-block-chaining (CBC) mode using a variant of the key, 4146 where the variant is computed by eXclusive-ORing the key 4147 with the constant F0F0F0F0F0F0F0F0[35]. The initialization 4148 vector should be zero. The resulting checksum is 24 octets 4149 long (8 octets of which are redundant). This checksum is 4150 tamper-proof and believed to be collision-proof. 4152 The DES specifications identify some "weak keys"; those 4153 keys shall not be used for generating RSA-MD4 checksums for 4154 use in Kerberos. 4156 The format for the checksum is described in the follow- 4157 ing diagram: 4159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4160 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 4161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4163 The format cannot be described in ASN.1, but for those who 4164 prefer an ASN.1-like notation: 4166 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4167 confounder[0] UNTAGGED OCTET STRING(8), 4168 check[1] UNTAGGED OCTET STRING(16) 4169 } 4171 6.4.4. The RSA MD5 Checksum (rsa-md5) 4173 The RSA-MD5 checksum calculates a checksum using the 4174 RSA MD5 algorithm [16].. The algorithm takes as input an 4175 input message of arbitrary length and produces as output a 4176 128-bit (16 octet) checksum. RSA-MD5 is believed to be 4177 collision-proof. 4179 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5- 4180 des) 4182 The RSA-MD5-DES checksum calculates a keyed collision- 4183 proof checksum by prepending an 8 octet confounder before 4184 __________________________ 4186 [35] A variant of the key is used to limit the use of a 4187 key to a particular function, separating the functions 4188 of generating a checksum from other encryption per- 4189 formed using the session key. The constant 4190 F0F0F0F0F0F0F0F0 was chosen because it maintains key 4191 parity. The properties of DES precluded the use of the 4192 complement. The same constant is used for similar pur- 4193 pose in the Message Integrity Check in the Privacy 4194 Enhanced Mail standard. 4196 Section 6.4.5. - 75 - Expires 15 October 1993 4198 Version 5 - Revision 5.2 4200 the text, applying the RSA MD5 checksum algorithm, and 4201 encrypting the confounder and the checksum using DES in 4202 cipher-block-chaining (CBC) mode using a variant of the key, 4203 where the variant is computed by eXclusive-ORing the key 4204 with the constant F0F0F0F0F0F0F0F0. The initialization vec- 4205 tor should be zero. The resulting checksum is 24 octets 4206 long (8 octets of which are redundant). This checksum is 4207 tamper-proof and believed to be collision-proof. 4209 The DES specifications identify some "weak keys"; those 4210 keys shall not be used for encrypting RSA-MD5 checksums for 4211 use in Kerberos. 4213 The format for the checksum is described in the follow- 4214 ing diagram: 4216 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4217 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 4218 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4220 The format cannot be described in ASN.1, but for those who 4221 prefer an ASN.1-like notation: 4223 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4224 confounder[0] UNTAGGED OCTET STRING(8), 4225 check[1] UNTAGGED OCTET STRING(16) 4226 } 4228 6.4.6. DES cipher-block chained checksum (des-mac) 4230 The DES-MAC checksum is computed by prepending an 8 4231 octet confounder to the plaintext, performing a DES CBC-mode 4232 encryption on the result using the key and an initialization 4233 vector of zero, taking the last block of the ciphertext, 4234 prepending the same confounder and encrypting the pair using 4235 DES in cipher-block-chaining (CBC) mode using a a variant of 4236 the key, where the variant is computed by eXclusive-ORing 4237 the key with the constant F0F0F0F0F0F0F0F0. The initializa- 4238 tion vector should be zero. The resulting checksum is 128 4239 bits (16 octets) long, 64 bits of which are redundant. This 4240 checksum is tamper-proof and collision-proof. 4242 The format for the checksum is described in the follow- 4243 ing diagram: 4245 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 4246 | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | 4247 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 4249 The format cannot be described in ASN.1, but for those who 4250 prefer an ASN.1-like notation: 4252 Section 6.4.6. - 76 - Expires 15 October 1993 4254 Version 5 - Revision 5.2 4256 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4257 confounder[0] UNTAGGED OCTET STRING(8), 4258 check[1] UNTAGGED OCTET STRING(8) 4259 } 4261 The DES specifications identify some "weak" and "semi- 4262 weak" keys; those keys shall not be used for generating 4263 DES-MAC checksums for use in Kerberos, nor shall a key be 4264 used whose veriant is "weak" or "semi-weak". 4266 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative 4267 (rsa-md4-des-k) 4269 The RSA-MD4-DES-K checksum calculates a keyed 4270 collision-proof checksum by applying the RSA MD4 checksum 4271 algorithm and encrypting the results using DES in cipher- 4272 block-chaining (CBC) mode using a DES key as both key and 4273 initialization vector. The resulting checksum is 16 octets 4274 long. This checksum is tamper-proof and believed to be 4275 collision-proof. Note that this checksum type is the old 4276 method for encoding the RSA-MD4-DES checksum and it is no 4277 longer recommended. 4279 6.4.8. DES cipher-block chained checksum alternative (des- 4280 mac-k) 4282 The DES-MAC-K checksum is computed by performing a DES 4283 CBC-mode encryption of the plaintext, and using the last 4284 block of the ciphertext as the checksum value. It is keyed 4285 with an encryption key and an initialization vector; any 4286 uses which do not specify an additional initialization vec- 4287 tor will use the key as both key and initialization vector. 4288 The resulting checksum is 64 bits (8 octets) long. This 4289 checksum is tamper-proof and collision-proof. Note that 4290 this checksum type is the old method for encoding the DES- 4291 MAC checksum and it is no longer recommended. 4293 The DES specifications identify some "weak keys"; those 4294 keys shall not be used for generating DES-MAC checksums for 4295 use in Kerberos. 4297 7. Naming Constraints 4299 7.1. Realm Names 4301 Although realm names are encoded as GeneralStrings and 4302 although a realm can technically select any name it chooses, 4303 interoperability across realm boundaries requires agreement 4304 on how realm names are to be assigned, and what information 4305 they imply. 4307 Section 7.1. - 77 - Expires 15 October 1993 4309 Version 5 - Revision 5.2 4311 To enforce these conventions, each realm must conform 4312 to the conventions itself, and it must require that any 4313 realms with which inter-realm keys are shared also conform 4314 to the conventions and require the same from its neighbors. 4316 There are presently four styles of realm names: domain, 4317 X500, other, and reserved. Examples of each style follow: 4319 domain: host.subdomain.domain (example) 4320 X500: C=US/O=OSF (example) 4321 other: NAMETYPE:rest/of.name=without-restrictions (example) 4322 reserved: reserved, but will not conflict with above 4324 Domain names must look like domain names: they consist of 4325 components separated by periods (.) and they contain neither 4326 colons (:) nor slashes (/). 4328 X.500 names contain an equal (=) and cannot contain a 4329 colon (:) before the equal. The realm names for X.500 names 4330 will be string representations of the names with components 4331 separated by slashes. Leading and trailing slashes will not 4332 be included. 4334 Names that fall into the other category must begin with 4335 a prefix that contains no equal (=) or period (.) and the 4336 prefix must be followed by a colon (:) and the rest of the 4337 name. All prefixes must be assigned before they may be 4338 used. Presently none are assigned. 4340 The reserved category includes strings which do not 4341 fall into the first three categories. All names in this 4342 category are reserved. It is unlikely that names will be 4343 assigned to this category unless there is a very strong 4344 argument for not using the "other" category. 4346 These rules guarantee that there will be no conflicts 4347 between the various name styles. The following additional 4348 constraints apply to the assignment of realm names in the 4349 domain and X.500 categories: the name of a realm for the 4350 domain or X.500 formats must either be used by the organiza- 4351 tion owning (to whom it was assigned) an Internet domain 4352 name or X.500 name, or in the case that no such names are 4353 registered, authority to use a realm name may be derived 4354 from the authority of the parent realm. For example, if 4355 there is no domain name for E40.MIT.EDU, then the adminis- 4356 trator of the MIT.EDU realm can authorize the creation of a 4357 realm with that name. 4359 This is acceptable because the organization to which 4360 the parent is assigned is presumably the organization 4361 authorized to assign names to its children in the X.500 and 4362 domain name systems as well. If the parent assigns a realm 4363 name without also registering it in the domain name or X.500 4365 Section 7.1. - 78 - Expires 15 October 1993 4367 Version 5 - Revision 5.2 4369 hierarchy, it is the parent's responsibility to make sure 4370 that there will not in the future exists a name identical to 4371 the realm name of the child unless it is assigned to the 4372 same entity as the realm name. 4374 7.2. Principal Names 4376 As was the case for realm names, conventions are needed 4377 to ensure that all agree on what information is implied by a 4378 principal name. The name-type field that is part of the 4379 principal name indicates the kind of information implied by 4380 the name. The name-type should be treated as a hint. 4381 Ignoring the name type, no two names can be the same (i.e. 4382 at least one of the components, or the realm, must be dif- 4383 ferent). This constraint may be eliminated in the future. 4384 The following name types are defined: 4386 name-type value meaning 4387 NT-UNKNOWN 0 Name type not known 4388 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4389 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4390 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4391 NT-SRV-XHST 4 Service with host as remaining components 4392 NT-UID 5 Unique ID 4394 When a name implies no information other than its uniqueness 4395 at a particular time the name type PRINCIPAL should be used. 4396 The principal name type should be used for users, and it 4397 might also be used for a unique server. If the name is a 4398 unique machine generated ID that is guaranteed never to be 4399 reassigned then the name type of UID should be used (note 4400 that it is generally a bad idea to reassign names of any 4401 type since stale entries might remain in access control 4402 lists). 4404 If the first component of a name identifies a service 4405 and the remaining components identify an instance of the 4406 service in a server specified manner, then the name type of 4407 SRV-INST should be used. An example of this name type is 4408 the Kerberos ticket-granting ticket which has a first com- 4409 ponent of krbtgt and a second component identifying the 4410 realm for which the ticket is valid. 4412 If instance is a single component following the service 4413 name and the instance identifies the host on which the 4414 server is running, then the name type SRV-HST should be 4415 used. This type is typically used for Internet services 4416 such as telnet and the Berkeley R commands. If the separate 4417 components of the host name appear as successive components 4418 following the name of the service, then the name type SRV- 4419 XHST should be used. This type might be used to identify 4420 servers on hosts with X.500 names where the slash (/) might 4422 Section 7.2. - 79 - Expires 15 October 1993 4424 Version 5 - Revision 5.2 4426 otherwise be ambiguous. 4428 A name type of UNKNOWN should be used when the form of 4429 the name is not known. When comparing names, a name of type 4430 UNKNOWN will match principals authenticated with names of 4431 any type. A principal authenticated with a name of type 4432 UNKNOWN, however, will only match other names of type UNK- 4433 NOWN. 4435 Names of any type with an initial component of "krbtgt" 4436 are reserved for the Kerberos ticket granting service. See 4437 section 8.2.3 for the form of such names. 4439 7.2.1. Name of server principals 4441 The principal identifier for a server on a host will 4442 generally be composed of two parts: (1) the realm of the KDC 4443 with which the server is registered, and (2) a two-component 4444 name of type NT-SRV-HST if the host name is an Internet 4445 domain name or a multi-component name of type NT-SRV-XHST if 4446 the name of the host is of a form such as X.500 that allows 4447 slash (/) separators. The first component of the two- or 4448 multi-component name will identify the service and the 4449 latter components will identify the host. Where the name of 4450 the host is not case sensitive (for example, with Internet 4451 domain names) the name of the host must be lower case. For 4452 services such as telnet and the Berkeley R commands which 4453 run with system privileges, the first component will be the 4454 string "host" instead of a service specific identifier. 4456 8. Constants and other defined values 4458 8.1. Host address types 4460 All negative values for the host address type are 4461 reserved for local use. All non-negative values are 4462 reserved for officially assigned type fields and interpreta- 4463 tions. 4465 The values of the types for the following addresses are 4466 chosen to match the defined address family constants in the 4467 Berkeley Standard Distributions of Unix. They can be found 4468 in with symbolic names AF_xxx (where xxx is 4469 an abbreviation of the address family name). 4471 Internet addresses 4473 Internet addresses are 32-bit (4-octet) quantities, 4474 encoded in MSB order. The type of internet addresses is two 4475 (2). 4477 Section 8.1. - 80 - Expires 15 October 1993 4479 Version 5 - Revision 5.2 4481 CHAOSnet addresses 4483 CHAOSnet addresses are 16-bit (2-octet) quantities, 4484 encoded in MSB order. The type of CHAOSnet addresses is 4485 five (5). 4487 ISO addresses 4489 ISO addresses are variable-length. The type of ISO 4490 addresses is seven (7). 4492 Xerox Network Services (XNS) addresses 4494 XNS addresses are 48-bit (6-octet) quantities, encoded 4495 in MSB order. The type of XNS addresses is six (6). 4497 AppleTalk Datagram Delivery Protocol (DDP) addresses 4499 AppleTalk DDP addresses consist of an 8-bit node number 4500 and a 16-bit network number. The first octet of the address 4501 is the node number; the remaining two octets encode the net- 4502 work number in MSB order. The type of AppleTalk DDP 4503 addresses is sixteen (16). 4505 DECnet Phase IV addresses 4507 DECnet Phase IV addresses are 16-bit addresses, encoded 4508 in LSB order. The type of DECnet Phase IV addresses is 4509 twelve (12). 4511 8.2. KDC messages 4513 8.2.1. IP transport 4515 When contacting a Kerberos server (KDC) for a 4516 KRB_KDC_REQ request using IP transport, the client shall 4517 send a UDP datagram containing only an encoding of the 4518 request to port 88 (decimal) at the KDC's IP address; the 4519 KDC will respond with a reply datagram containing only an 4520 encoding of the reply message (either a KRB_ERROR or a 4521 KRB_KDC_REP) to the sending port at the sender's IP address. 4523 8.2.2. OSI transport 4525 During authentication of an OSI client to and OSI 4526 server, the mutual authentication of an OSI server to an OSI 4527 client, the transfer of credentials from an OSI client to an 4528 OSI server, or during exchange of private or integrity 4529 checked messages, Kerberos protocol messages may be treated 4530 as opaque objects and the type of the authentication mechan- 4531 ism will be: 4533 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1), security(5), kerberosv5(2)} 4535 Section 8.2.2. - 81 - Expires 15 October 1993 4537 Version 5 - Revision 5.2 4539 Depending on the situation, the opaque object will be an 4540 authentication header (KRB_AP_REQ), an authentication reply 4541 (KRB_AP_REP), a safe message (KRB_SAFE), a private message 4542 (KRB_PRIV), or a credentials message (KRB_CRED). The opaque 4543 data contains an application code as specified in the ASN.1 4544 description for each message. The application code may be 4545 used by Kerberos to determine the message type. 4547 8.2.3. Name of the TGS 4549 The principal identifier of the ticket-granting service 4550 shall be composed of three parts: (1) the realm of the KDC 4551 issuing the TGS ticket (2) a two-part name of type NT-SRV- 4552 INST, with the first part "krbtgt" and the second part the 4553 name of the realm which will accept the ticket-granting 4554 ticket. For example, a ticket-granting ticket issued by the 4555 ATHENA.MIT.EDU realm to be used to get tickets from the 4556 ATHENA.MIT.EDU KDC has a principal identifier of 4557 "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") 4558 (name). A ticket-granting ticket issued by the 4559 ATHENA.MIT.EDU realm to be used to get tickets from the 4560 MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" 4561 (realm), ("krbtgt", "MIT.EDU") (name). 4563 8.3. Protocol constants and associated values 4565 The following tables list constants used in the proto- 4566 col and defines their meanings. 4568 Encryption type etype value block size minimum pad size confounder size 4569 NULL 0 1 0 0 4570 des-cbc-crc 1 8 4 8 4571 des-cbc-md4 2 8 0 8 4572 des-cbc-md5 3 8 0 8 4574 Checksum type sumtype value checksum size 4575 CRC32 1 4 4576 rsa-md4 2 16 4577 rsa-md4-des 3 24 4578 des-mac 4 16 4579 des-mac-k 5 8 4580 rsa-md4-des-k 6 16 4581 rsa-md5 7 16 4582 rsa-md5-des 8 24 4584 padata type padata-type value 4585 PA-TGS-REQ 1 4586 PA-ENC-TIMESTAMP 2 4587 PA-PW-SALT 3 4589 authorization data type ad-type value 4590 reserved values 0-63 4591 OSF-DCE 64 4592 SESAME 65 4594 Section 8.3. - 82 - Expires 15 October 1993 4596 Version 5 - Revision 5.2 4598 alternate authentication type method-type value 4599 reserved values 0-63 4600 ATT-CHALLENGE-RESPONSE 64 4602 transited encoding type tr-type value 4603 DOMAIN-X500-COMPRESS 1 4604 reserved values all others 4606 Label Value Meaning or MIT code 4608 pvno 5 current Kerberos protocol version number 4610 message types 4612 KRB_AS_REQ 10 Request for initial authentication 4613 KRB_AS_REP 11 Response to KRB_AS_REQ request 4614 KRB_TGS_REQ 12 Request for authentication based on TGT 4615 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4616 KRB_AP_REQ 14 application request to server 4617 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4618 KRB_SAFE 20 Safe (checksummed) application message 4619 KRB_PRIV 21 Private (encrypted) application message 4620 KRB_CRED 22 Private (encrypted) message to forward credentials 4621 KRB_ERROR 30 Error response 4623 name types 4625 KRB_NT_UNKNOWN 0 Name type not known 4626 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4627 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4628 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 4629 KRB_NT_SRV_XHST 4 Service with host as remaining components 4630 KRB_NT_UID 5 Unique ID 4632 error codes 4634 KDC_ERR_NONE 0 No error 4635 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4636 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4637 KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported 4638 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 4639 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 4640 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4641 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4642 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 4643 KDC_ERR_NULL_KEY 9 The client or server has a null key 4644 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4645 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 4646 KDC_ERR_POLICY 12 KDC policy rejects request 4647 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4648 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4649 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4650 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4652 Section 8.3. - 83 - Expires 15 October 1993 4654 Version 5 - Revision 5.2 4656 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4657 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4658 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4659 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4660 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4661 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4662 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset 4663 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 4664 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired- 4665 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 4666 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4667 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4668 KRB_AP_ERR_REPEAT 34 Request is a replay 4669 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4670 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4671 KRB_AP_ERR_SKEW 37 Clock skew too great 4672 KRB_AP_ERR_BADADDR 38 Incorrect net address 4673 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4674 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4675 KRB_AP_ERR_MODIFIED 41 Message stream modified 4676 KRB_AP_ERR_BADORDER 42 Message out of order 4677 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 4678 KRB_AP_ERR_NOKEY 45 Service key not available 4679 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4680 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4681 KRB_AP_ERR_METHOD 48 Alternative authentication method required- 4682 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4683 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 4685 KRB_ERR_GENERIC 60 Generic error (description in e-text) 4686 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 4688 9. Interoperability requirements 4690 Version 5 of the Kerberos protocol supports a myriad of 4691 options. Among these are multiple encryption and checksum 4692 types, alternative encoding schemes for the transited field, 4693 optional mechanisms for pre-authentication, the handling of 4694 tickets with no addresses, options for mutual authentica- 4695 tion, user to user authentication, support for proxies, for- 4696 warding, postdating, and renewing tickets, the format of 4697 realm names, and the handling of authorization data. 4699 In order to ensure the interoperability of realms, it 4700 is necessary to define a minimal configuration which must be 4701 supported by all implementations. This minimal configura- 4702 tion is subject to change as technology does. For example, 4703 __________________________ 4705 - This error carries additional information in the e- 4706 data field. The contents of the e-data field for this 4707 message is described in section 5.9.1. 4709 Section 9. - 84 - Expires 15 October 1993 4711 Version 5 - Revision 5.2 4713 if at some later date it is discovered that one of the 4714 required encryption or checksum algorithms is not secure, it 4715 will be replaced. 4717 9.1. Specification 1 4719 This section defines the first specification of these 4720 options. Implementations which are configured in this way 4721 can be said to support Kerberos Version 5 Specification 1 4722 (5.1). 4724 Encryption and checksum methods 4726 The following encryption and checksum mechanisms must be 4727 supported. Implementations may support other mechanisms as 4728 well, but the additional mechanisms may only be used when 4729 communicating with principals known to also support them: 4730 Encryption: DES-CBC-MD5 4731 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 4733 Realm Names 4735 All implementations must understand hierarchical realms in 4736 both the Internet Domain and the X.500 style. When a ticket 4737 granting ticket for an unknown realm is requested, the KDC 4738 must be able to determine the names of the intermediate 4739 realms between the KDCs realm and the requested realm. 4741 Transited field encoding 4743 DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be 4744 supported. Alternative encodings may be supported, but they 4745 may be used only when that encoding is supported by ALL 4746 intermediate realms. 4748 Pre-authentication methods 4750 The TGS-REQ method must be supported. The TGS-REQ method is 4751 not used on the initial request. The PA-ENC-TIMESTAMP 4752 method must be supported by clients but whether it is 4753 enabled by default may be determined on a realm by realm 4754 basis. If not used in the initial request and the error 4755 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC- 4756 TIMESTAMP as an acceptable method, the client should retry 4757 the initial request using the PA-ENC-TIMESTAMP pre- 4758 authentication method. Servers need not support the PA- 4759 ENC-TIMESTAMP method, but if not supported the server should 4760 ignore the presence of PA-ENC-TIMESTAMP pre-authentication 4761 in a request. 4763 Mutual authentication 4765 Mutual authentication (via the KRB_AP_REP message) must be 4766 supported. 4768 Section 9.1. - 85 - Expires 15 October 1993 4770 Version 5 - Revision 5.2 4772 Ticket addresses and flags 4774 All KDC's must pass on tickets that carry no addresses (i.e. 4775 if a TGT contains no addresses, the KDC will return deriva- 4776 tive tickets), but each realm may set its own policy for 4777 issuing such tickets, and each application server will set 4778 its own policy with respect to accepting them. By default, 4779 servers should not accept them. 4781 Proxies and forwarded tickets must be supported. Indi- 4782 vidual realms and application servers can set their own pol- 4783 icy on when such tickets will be accepted. 4785 All implementations must recognize renewable and post- 4786 dated tickets, but need not actually implement them. If 4787 these options are not supported, the starttime and endtime 4788 in the ticket shall specify a ticket's entire useful life. 4789 When a postdated ticket is decoded by a server, all imple- 4790 mentations shall make the presence of the postdated flag 4791 visible to the calling server. 4793 User-to-user authentication 4795 Support for user to user authentication (via the ENC-TKT- 4796 IN-SKEY KDC option) must be provided by implementations, but 4797 individual realms may decide as a matter of policy to reject 4798 such requests on a per-principal or realm-wide basis. 4800 Authorization data 4802 Implementations must pass all authorization data subfields 4803 from ticket-granting tickets to any derivative tickets 4804 unless directed to suppress a subfield as part of the defin- 4805 ition of that registered subfield type (it is never 4806 incorrect to pass on a subfield, and no registered subfield 4807 types presently specify suppression at the KDC). 4809 Implementations must make the contents of any authori- 4810 zation data subfields available to the server when a ticket 4811 is used. Implementations are not required to allow clients 4812 to specify the contents of the authorization data fields. 4814 9.2. Recommended KDC values 4816 Following is a list of recommended values for a KDC imple- 4817 mentation, based on the list of suggested configuration con- 4818 stants (see section 4.4). 4820 minimum lifetime 5 minutes 4822 maximum renewable lifetime1 week 4824 maximum ticket lifetime1 day 4826 Section 9.2. - 86 - Expires 15 October 1993 4828 Version 5 - Revision 5.2 4830 empty addresses only when suitable restrictions appear 4831 in authorization data 4833 proxiable, etc. Allowed. 4835 10. Acknowledgments 4837 Early versions of this document, describing version 4 4838 of the protocol, were written by Jennifer Steiner (formerly 4839 at Project Athena); these drafts provided an excellent 4840 starting point for this current version 5 specification. 4841 Many people in the Internet community have contributed ideas 4842 and suggested protocol changes for version 5. Notable con- 4843 tributions came from Ted Anderson, Steve Bellovin and 4844 Michael Merritt [17], Daniel Bernstein, Mike Burrows, Donald 4845 Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill 4846 Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers 4847 McMahon, Joe Pato, William Sommerfeld, Stuart Stubblebine, 4848 Ralph Swick, Ted T'so, and Stanley Zanarotti. Many others 4849 commented and helped shape this specification into its 4850 current form. 4852 Section 10. - 87 - Expires 15 October 1993 4854 Version 5 - Revision 5.2 4856 11. REFERENCES 4858 1. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 4859 Saltzer, Section E.2.1: Kerberos Authentication and 4860 Authorization System, M.I.T. Project Athena, Cambridge, 4861 Massachusetts (December 21, 1987). 4863 2. J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 4864 beros: An Authentication Service for Open Network Sys- 4865 tems," pp. 191-202 in Usenix Conference Proceedings, 4866 Dallas, Texas (February, 1988). 4868 3. Roger M. Needham and Michael D. Schroeder, "Using 4869 Encryption for Authentication in Large Networks of Com- 4870 puters," Communications of the ACM, Vol. 21(12), 4871 pp. 993-999 (December, 1978). 4873 4. Dorothy E. Denning and Giovanni Maria Sacco, "Time- 4874 stamps in Key Distribution Protocols," Communications 4875 of the ACM, Vol. 24(8), pp. 533-536 (August 1981). 4877 5. John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 4878 "The Evolution of the Kerberos Authentication Service," 4879 in an IEEE Computer Society Text soon to be published 4880 (June 1992). 4882 6. Don Davis and Ralph Swick, "Workstation Services and 4883 Kerberos Authentication at Project Athena," Technical 4884 Memorandum TM-424, MIT Laboratory for Computer Science 4885 (February 1990). 4887 7. P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 4888 merfeld, and K. Raeburn, Section E.1: Service Manage- 4889 ment System, M.I.T. Project Athena, Cambridge, Mas- 4890 sachusetts (1987). 4892 8. CCITT, Recommendation X.509: The Directory Authentica- 4893 tion Framework, December 1988. 4895 9. B. Clifford Neuman, "Proxy-Based Authorization and 4896 Accounting for Distributed Systems," in Proceedings of 4897 the 13th International Conference on Distributed Com- 4898 puting Systems, Pittsburgh, PA (May, 1993). 4900 10. J. Pato, Using Pre-Authentication to Avoid Password 4901 Guessing Attacks, Open Software Foundation DCE Request 4902 for Comments 26 (December 1992). 4904 11. National Bureau of Standards, U.S. Department of Com- 4905 merce, "Data Encryption Standard," Federal Information 4906 Processing Standards Publication 46, Washington, DC 4907 (1977). 4909 Section 11. - 88 - Expires 15 October 1993 4911 Version 5 - Revision 5.2 4913 12. National Bureau of Standards, U.S. Department of Com- 4914 merce, "DES Modes of Operation," Federal Information 4915 Processing Standards Publication 81, Springfield, VA 4916 (December 1980). 4918 13. Stuart G. Stubblebine and Virgil D. Gligor, "On Message 4919 Integrity in Cryptographic Protocols," in Proceedings 4920 of the IEEE Symposium on Research in Security and 4921 Privacy, Oakland, California (May 1992). 4923 14. International Organization for Standardization, "ISO 4924 Information Processing Systems - Data Communication - 4925 High-Level Data Link Control Procedure - Frame Struc- 4926 ture," IS 3309 (October 1984). 3rd Edition. 4928 15. R. Rivest, "The MD4 Message Digest Algorithm," RFC 4929 1320, MIT Laboratory for Computer Science (April 4930 1992). 4932 16. R. Rivest, "The MD5 Message Digest Algorithm," RFC 4933 1321, MIT Laboratory for Computer Science (April 4934 1992). 4936 17. S. M. Bellovin and M. Merritt, "Limitations of the Ker- 4937 beros Authentication System," Computer Communications 4938 Review, Vol. 20(5), pp. 119-132 (October 1990). 4940 Section 11. - 89 - Expires 15 October 1993 4942 Version 5 - Revision 5.2 4944 A. Pseudo-code for protocol processing 4946 This appendix provides pseudo-code describing how the 4947 messages are to be constructed and interpreted by clients 4948 and servers. 4950 A.1. KRB_AS_REQ generation 4951 request.pvno := protocol version; /* pvno = 5 */ 4952 request.msg-type := message type; /* type = KRB_AS_REQ */ 4954 if(pa_enc_timestamp_required) then 4955 request.padata.padata-type = PA-ENC-TIMESTAMP; 4956 get system_time; 4957 padata-body.patimestamp,pausec = system_time; 4958 encrypt padata-body into request.padata.padata-value 4959 using client.key; /* derived from password */ 4960 endif 4962 body.kdc-options := users's preferences; 4963 body.cname := user's name; 4964 body.realm := user's realm; 4965 body.sname := service's name; /* usually "krbtgt", "localrealm" */ 4966 if (body.kdc-options.POSTDATED is set) then 4967 body.from := requested starting time; 4968 else 4969 omit body.from; 4970 endif 4971 body.till := requested end time; 4972 if (body.kdc-options.RENEWABLE is set) then 4973 body.rtime := requested final renewal time; 4974 endif 4975 body.nonce := random_nonce(); 4976 body.etype := requested etypes; 4977 if (user supplied addresses) then 4978 body.addresses := user's addresses; 4979 else 4980 omit body.addresses; 4981 endif 4982 omit body.enc-authorization-data; 4983 request.req-body := body; 4985 kerberos := lookup(name of local kerberos server (or servers)); 4986 send(packet,kerberos); 4988 wait(for response); 4989 if (timed_out) then 4990 retry or use alternate server; 4991 endif 4993 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 4994 decode message into req; 4996 client := lookup(req.cname,req.realm); 4997 server := lookup(req.sname,req.realm); 4999 Section A.2. - 90 - Expires 15 October 1993 5001 Version 5 - Revision 5.2 5003 get system_time; 5004 kdc_time := system_time.seconds; 5006 if (!client) then 5007 /* no client in Database */ 5008 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 5009 endif 5010 if (!server) then 5011 /* no server in Database */ 5012 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5013 endif 5015 if(client.pa_enc_timestamp_required and 5016 pa_enc_timestamp not present) then 5017 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 5018 endif 5020 if(pa_enc_timestamp present) then 5021 decrypt req.padata-value into decrypted_enc_timestamp 5022 using client.key; 5023 using auth_hdr.authenticator.subkey; 5024 if (decrypt_error()) then 5025 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5026 if(decrypted_enc_timestamp is not within allowable skew) then 5027 error_out(KDC_ERR_PREAUTH_FAILED); 5028 endif 5029 if(decrypted_enc_timestamp and usec is replay) 5030 error_out(KDC_ERR_PREAUTH_FAILED); 5031 endif 5032 add decrypted_enc_timestamp and usec to replay cache; 5033 endif 5035 use_etype := first supported etype in req.etypes; 5037 if (no support for req.etypes) then 5038 error_out(KDC_ERR_ETYPE_NOSUPP); 5039 endif 5041 new_tkt.vno := ticket version; /* = 5 */ 5042 new_tkt.sname := req.sname; 5043 new_tkt.srealm := req.srealm; 5044 reset all flags in new_tkt.flags; 5046 /* It should be noted that local policy may affect the */ 5047 /* processing of any of these flags. For example, some */ 5048 /* realms may refuse to issue renewable tickets */ 5050 if (req.kdc-options.FORWARDABLE is set) then 5051 set new_tkt.flags.FORWARDABLE; 5052 endif 5053 if (req.kdc-options.PROXIABLE is set) then 5054 set new_tkt.flags.PROXIABLE; 5055 endif 5057 Section A.2. - 91 - Expires 15 October 1993 5059 Version 5 - Revision 5.2 5061 if (req.kdc-options.ALLOW-POSTDATE is set) then 5062 set new_tkt.flags.ALLOW-POSTDATE; 5063 endif 5064 if ((req.kdc-options.RENEW is set) or 5065 (req.kdc-options.VALIDATE is set) or 5066 (req.kdc-options.PROXY is set) or 5067 (req.kdc-options.FORWARDED is set) or 5068 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 5069 error_out(KDC_ERR_BADOPTION); 5070 endif 5072 new_tkt.session := random_session_key(); 5073 new_tkt.cname := req.cname; 5074 new_tkt.crealm := req.crealm; 5075 new_tkt.transited := empty_transited_field(); 5077 new_tkt.authtime := kdc_time; 5079 if (req.kdc-options.POSTDATED is set) then 5080 if (against_postdate_policy(req.from)) then 5081 error_out(KDC_ERR_POLICY); 5082 endif 5083 set new_tkt.flags.INVALID; 5084 new_tkt.starttime := req.from; 5085 else 5086 omit new_tkt.starttime; /* treated as authtime when omitted */ 5087 endif 5088 if (req.till = 0) then 5089 till := infinity; 5090 else 5091 till := req.till; 5092 endif 5094 new_tkt.endtime := min(till, 5095 new_tkt.starttime+client.max_life, 5096 new_tkt.starttime+server.max_life, 5097 new_tkt.starttime+max_life_for_realm); 5099 if ((req.kdc-options.RENEWABLE-OK is set) and 5100 (new_tkt.endtime < req.till)) then 5101 /* we set the RENEWABLE option for later processing */ 5102 set req.kdc-options.RENEWABLE; 5103 req.rtime := req.till; 5104 endif 5106 if (req.rtime = 0) then 5107 rtime := infinity; 5108 else 5109 rtime := req.rtime; 5110 endif 5112 if (req.kdc-options.RENEWABLE is set) then 5113 set new_tkt.flags.RENEWABLE; 5114 new_tkt.renew-till := min(rtime, 5116 Section A.2. - 92 - Expires 15 October 1993 5118 Version 5 - Revision 5.2 5120 new_tkt.starttime+client.max_rlife, 5121 new_tkt.starttime+server.max_rlife, 5122 new_tkt.starttime+max_rlife_for_realm); 5123 else 5124 omit new_tkt.renew-till; /* only present if RENEWABLE */ 5125 endif 5127 if (req.addresses) then 5128 new_tkt.caddr := req.addresses; 5129 else 5130 omit new_tkt.caddr; 5131 endif 5133 new_tkt.authorization_data := empty_authorization_data(); 5135 encode to-be-encrypted part of ticket into OCTET STRING; 5136 new_tkt.enc-part := encrypt OCTET STRING 5137 using etype_for_key(server.key), server.key, server.p_kvno; 5139 /* Start processing the response */ 5141 resp.pvno := 5; 5142 resp.msg-type := KRB_AS_REP; 5143 resp.cname := req.cname; 5144 resp.crealm := req.realm; 5145 resp.ticket := new_tkt; 5147 resp.key := new_tkt.session; 5148 resp.last-req := fetch_last_request_info(client); 5149 resp.nonce := req.nonce; 5150 resp.key-expiration := client.expiration; 5151 resp.flags := new_tkt.flags; 5153 resp.authtime := new_tkt.authtime; 5154 resp.starttime := new_tkt.starttime; 5155 resp.endtime := new_tkt.endtime; 5157 if (new_tkt.flags.RENEWABLE) then 5158 resp.renew-till := new_tkt.renew-till; 5159 endif 5161 resp.realm := new_tkt.realm; 5162 resp.sname := new_tkt.sname; 5164 resp.caddr := new_tkt.caddr; 5166 encode body of reply into OCTET STRING; 5168 resp.enc-part := encrypt OCTET STRING 5169 using use_etype, client.key, client.p_kvno; 5170 send(resp); 5172 Section A.2. - 93 - Expires 15 October 1993 5174 Version 5 - Revision 5.2 5176 A.3. KRB_AS_REP verification 5177 decode response into resp; 5179 if (resp.msg-type = KRB_ERROR) then 5180 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 5181 set pa_enc_timestamp_required; 5182 goto KRB_AS_REQ; 5183 endif 5184 process_error(resp); 5185 return; 5186 endif 5188 /* On error, discard the response, and zero the session key */ 5189 /* from the response immediately */ 5191 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 5192 resp.padata); 5193 unencrypted part of resp := decode of decrypt of resp.enc-part 5194 using resp.enc-part.etype and key; 5195 zero(key); 5197 if (common_as_rep_tgs_rep_checks fail) then 5198 destroy resp.key; 5199 return error; 5200 endif 5202 if near(resp.princ_exp) then 5203 print(warning message); 5204 endif 5205 save_for_later(ticket,session,client,server,times,flags); 5207 A.4. KRB_AS_REP and KRB_TGS_REP common checks 5208 if (decryption_error() or 5209 (req.cname != resp.cname) or 5210 (req.realm != resp.crealm) or 5211 (req.sname != resp.sname) or 5212 (req.realm != resp.realm) or 5213 (req.nonce != resp.nonce) or 5214 (req.addresses != resp.caddr)) then 5215 destroy resp.key; 5216 return KRB_AP_ERR_MODIFIED; 5217 endif 5219 /* make sure no flags are set that shouldn't be, and that all that */ 5220 /* should be are set */ 5221 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 5222 destroy resp.key; 5223 return KRB_AP_ERR_MODIFIED; 5224 endif 5226 if ((req.from = 0) and 5227 (resp.starttime is not within allowable skew)) then 5228 destroy resp.key; 5229 return KRB_AP_ERR_SKEW; 5231 Section A.4. - 94 - Expires 15 October 1993 5233 Version 5 - Revision 5.2 5235 endif 5236 if ((req.from != 0) and (req.from != resp.starttime)) then 5237 destroy resp.key; 5238 return KRB_AP_ERR_MODIFIED; 5239 endif 5240 if ((req.till != 0) and (resp.endtime > req.till)) then 5241 destroy resp.key; 5242 return KRB_AP_ERR_MODIFIED; 5243 endif 5245 if ((req.kdc-options.RENEWABLE is set) and 5246 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 5247 destroy resp.key; 5248 return KRB_AP_ERR_MODIFIED; 5249 endif 5250 if ((req.kdc-options.RENEWABLE-OK is set) and 5251 (resp.flags.RENEWABLE) and 5252 (req.till != 0) and 5253 (resp.renew-till > req.till)) then 5254 destroy resp.key; 5255 return KRB_AP_ERR_MODIFIED; 5256 endif 5258 A.5. KRB_TGS_REQ generation 5259 /* Note that make_application_request might have to recursivly */ 5260 /* call this routine to get the appropriate ticket-granting ticket */ 5262 request.pvno := protocol version; /* pvno = 5 */ 5263 request.msg-type := message type; /* type = KRB_TGS_REQ */ 5265 body.kdc-options := users's preferences; 5266 /* If the TGT is not for the realm of the end-server */ 5267 /* then the sname will be for a TGT for the end-realm */ 5268 /* and the realm of the requested ticket (body.realm) */ 5269 /* will be that of the TGS to which the TGT we are */ 5270 /* sending applies */ 5271 body.sname := service's name; 5272 body.realm := service's realm; 5274 if (body.kdc-options.POSTDATED is set) then 5275 body.from := requested starting time; 5276 else 5277 omit body.from; 5278 endif 5279 body.till := requested end time; 5280 if (body.kdc-options.RENEWABLE is set) then 5281 body.rtime := requested final renewal time; 5282 endif 5283 body.nonce := random_nonce(); 5284 body.etype := requested etypes; 5285 if (user supplied addresses) then 5286 body.addresses := user's addresses; 5287 else 5288 omit body.addresses; 5290 Section A.5. - 95 - Expires 15 October 1993 5292 Version 5 - Revision 5.2 5294 endif 5296 body.enc-authorization-data := user-supplied data; 5297 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5298 body.additional-tickets_ticket := second TGT; 5299 endif 5301 request.req-body := body; 5302 check := generate_checksum (req.body,checksumtype); 5304 request.padata[0].padata-type := PA-TGS-REQ; 5305 request.padata[0].padata-value := create a KRB_AP_REQ using 5306 the TGT and checksum 5308 /* add in any other padata as required/supplied */ 5310 kerberos := lookup(name of local kerberose server (or servers)); 5311 send(packet,kerberos); 5313 wait(for response); 5314 if (timed_out) then 5315 retry or use alternate server; 5316 endif 5318 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5319 /* note that reading the application request requires first 5320 determining the server for which a ticket was issued, and choosing the 5321 correct key for decryption. The name of the server appears in the 5322 plaintext part of the ticket. */ 5324 if (no KRB_AP_REQ in req.padata) then 5325 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5326 endif 5327 verify KRB_AP_REQ in req.padata; 5329 /* Note that the realm in which the Kerberos server is operating is 5330 determined by the instance from the ticket-granting ticket. The realm 5331 in the ticket-granting ticket is the realm under which the ticket 5332 granting ticket was issued. It is possible for a single Kerberos 5333 server to support more than one realm. */ 5335 auth_hdr := KRB_AP_REQ; 5336 tgt := auth_hdr.ticket; 5338 if (tgt.sname is not a TGT for local realm and is not req.sname) then 5339 error_out(KRB_AP_ERR_NOT_US); 5341 realm := realm_tgt_is_for(tgt); 5343 decode remainder of request; 5345 if (auth_hdr.authenticator.cksum is missing) then 5346 error_out(KRB_AP_ERR_INAPP_CKSUM); 5347 endif 5349 Section A.6. - 96 - Expires 15 October 1993 5351 Version 5 - Revision 5.2 5353 if (auth_hdr.authenticator.cksum type is not supported) then 5354 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5355 endif 5356 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 5357 error_out(KRB_AP_ERR_INAPP_CKSUM); 5358 endif 5360 set computed_checksum := checksum(req); 5361 if (computed_checksum != auth_hdr.authenticatory.cksum) then 5362 error_out(KRB_AP_ERR_MODIFIED); 5363 endif 5365 server := lookup(req.sname,realm); 5367 if (!server) then 5368 if (is_foreign_tgt_name(server)) then 5369 server := best_intermediate_tgs(server); 5370 else 5371 /* no server in Database */ 5372 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5373 endif 5374 endif 5376 session := generate_random_session_key(); 5378 use_etype := first supported etype in req.etypes; 5380 if (no support for req.etypes) then 5381 error_out(KDC_ERR_ETYPE_NOSUPP); 5382 endif 5384 new_tkt.vno := ticket version; /* = 5 */ 5385 new_tkt.sname := req.sname; 5386 new_tkt.srealm := realm; 5387 reset all flags in new_tkt.flags; 5389 /* It should be noted that local policy may affect the */ 5390 /* processing of any of these flags. For example, some */ 5391 /* realms may refuse to issue renewable tickets */ 5393 new_tkt.caddr := tgt.caddr; 5394 resp.caddr := NULL; /* We only include this if they change */ 5395 if (req.kdc-options.FORWARDABLE is set) then 5396 if (tgt.flags.FORWARDABLE is reset) then 5397 error_out(KDC_ERR_BADOPTION); 5398 endif 5399 set new_tkt.flags.FORWARDABLE; 5400 endif 5401 if (req.kdc-options.FORWARDED is set) then 5402 if (tgt.flags.FORWARDABLE is reset) then 5403 error_out(KDC_ERR_BADOPTION); 5404 endif 5405 set new_tkt.flags.FORWARDED; 5407 Section A.6. - 97 - Expires 15 October 1993 5409 Version 5 - Revision 5.2 5411 new_tkt.caddr := req.addresses; 5412 resp.caddr := req.addresses; 5413 endif 5414 if (tgt.flags.FORWARDED is set) then 5415 set new_tkt.flags.FORWARDED; 5416 endif 5418 if (req.kdc-options.PROXIABLE is set) then 5419 if (tgt.flags.PROXIABLE is reset) 5420 error_out(KDC_ERR_BADOPTION); 5421 endif 5422 set new_tkt.flags.PROXIABLE; 5423 endif 5424 if (req.kdc-options.PROXY is set) then 5425 if (tgt.flags.PROXIABLE is reset) then 5426 error_out(KDC_ERR_BADOPTION); 5427 endif 5428 set new_tkt.flags.PROXY; 5429 new_tkt.caddr := req.addresses; 5430 resp.caddr := req.addresses; 5431 endif 5433 if (req.kdc-options.POSTDATE is set) then 5434 if (tgt.flags.POSTDATE is reset) 5435 error_out(KDC_ERR_BADOPTION); 5436 endif 5437 set new_tkt.flags.POSTDATE; 5438 endif 5439 if (req.kdc-options.POSTDATED is set) then 5440 if (tgt.flags.POSTDATE is reset) then 5441 error_out(KDC_ERR_BADOPTION); 5442 endif 5443 set new_tkt.flags.POSTDATED; 5444 set new_tkt.flags.INVALID; 5445 if (against_postdate_policy(req.from)) then 5446 error_out(KDC_ERR_POLICY); 5447 endif 5448 new_tkt.starttime := req.from; 5449 endif 5451 if (req.kdc-options.VALIDATE is set) then 5452 if (tgt.flags.INVALID is reset) then 5453 error_out(KDC_ERR_POLICY); 5454 endif 5455 if (tgt.starttime > kdc_time) then 5456 error_out(KRB_AP_ERR_NYV); 5457 endif 5458 if (check_hot_list(tgt)) then 5459 error_out(KRB_AP_ERR_REPEAT); 5460 endif 5461 tkt := tgt; 5462 reset new_tkt.flags.INVALID; 5463 endif 5465 Section A.6. - 98 - Expires 15 October 1993 5467 Version 5 - Revision 5.2 5469 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 5470 and those already processed) is set) then 5471 error_out(KDC_ERR_BADOPTION); 5472 endif 5474 new_tkt.authtime := tgt.authtime; 5476 if (req.kdc-options.RENEW is set) then 5477 /* Note that if the endtime has already passed, the ticket would */ 5478 /* have been rejected in the initial authentication stage, so */ 5479 /* there is no need to check again here */ 5480 if (tgt.flags.RENEWABLE is reset) then 5481 error_out(KDC_ERR_BADOPTION); 5482 endif 5483 if (tgt.renew-till >= kdc_time) then 5484 error_out(KRB_AP_ERR_TKT_EXPIRED); 5485 endif 5486 tkt := tgt; 5487 new_tkt.starttime := kdc_time; 5488 old_life := tgt.endttime - tgt.starttime; 5489 new_tkt.endtime := min(tgt.renew-till, 5490 new_tkt.starttime + old_life); 5491 else 5492 new_tkt.starttime := kdc_time; 5493 if (req.till = 0) then 5494 till := infinity; 5495 else 5496 till := req.till; 5497 endif 5498 new_tkt.endtime := min(till, 5499 new_tkt.starttime+client.max_life, 5500 new_tkt.starttime+server.max_life, 5501 new_tkt.starttime+max_life_for_realm, 5502 tgt.endtime); 5504 if ((req.kdc-options.RENEWABLE-OK is set) and 5505 (new_tkt.endtime < req.till) and 5506 (tgt.flags.RENEWABLE is set) then 5507 /* we set the RENEWABLE option for later processing */ 5508 set req.kdc-options.RENEWABLE; 5509 req.rtime := min(req.till, tgt.renew-till); 5510 endif 5511 endif 5513 if (req.rtime = 0) then 5514 rtime := infinity; 5515 else 5516 rtime := req.rtime; 5517 endif 5519 if ((req.kdc-options.RENEWABLE is set) and 5520 (tgt.flags.RENEWABLE is set)) then 5521 set new_tkt.flags.RENEWABLE; 5522 new_tkt.renew-till := min(rtime, 5524 Section A.6. - 99 - Expires 15 October 1993 5526 Version 5 - Revision 5.2 5528 new_tkt.starttime+client.max_rlife, 5529 new_tkt.starttime+server.max_rlife, 5530 new_tkt.starttime+max_rlife_for_realm, 5531 tgt.renew-till); 5532 else 5533 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 5534 endif 5535 if (req.enc-authorization-data is present) then 5536 decrypt req.enc-authorization-data into decrypted_authorization_data 5537 using auth_hdr.authenticator.subkey; 5538 if (decrypt_error()) then 5539 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5540 endif 5541 endif 5542 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 5543 decrypted_authorization_data; 5545 new_tkt.key := session; 5546 new_tkt.crealm := tgt.crealm; 5547 new_tkt.cname := req.auth_hdr.ticket.cname; 5549 if (realm_tgt_is_for(tgt) := tgt.realm) then 5550 /* tgt issued by local realm */ 5551 new_tkt.transited := tgt.transited; 5552 else 5553 /* was issued for this realm by some other realm */ 5554 if (tgt.transited.tr-type not supported) then 5555 error_out(KDC_ERR_TRTYPE_NOSUPP); 5556 endif 5557 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 5558 endif 5560 encode encrypted part of new_tkt into OCTET STRING; 5561 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 5562 if (server not specified) then 5563 server = req.second_ticket.client; 5564 endif 5565 if ((req.second_ticket is not a TGT) or 5566 (req.second_ticket.client != server)) then 5567 error_out(KDC_ERR_POLICY); 5568 endif 5570 new_tkt.enc-part := encrypt OCTET STRING using 5571 using etype_for_key(second-ticket.key), second-ticket.key; 5572 else 5573 new_tkt.enc-part := encrypt OCTET STRING 5574 using etype_for_key(server.key), server.key, server.p_kvno; 5575 endif 5577 resp.pvno := 5; 5578 resp.msg-type := KRB_TGS_REP; 5579 resp.crealm := tgt.crealm; 5580 resp.cname := tgt.cname; 5582 Section A.6. - 100 - Expires 15 October 1993 5584 Version 5 - Revision 5.2 5586 resp.ticket := new_tkt; 5588 resp.key := session; 5589 resp.nonce := req.nonce; 5590 resp.last-req := fetch_last_request_info(client); 5591 resp.flags := new_tkt.flags; 5593 resp.authtime := new_tkt.authtime; 5594 resp.starttime := new_tkt.starttime; 5595 resp.endtime := new_tkt.endtime; 5597 omit resp.key-expiration; 5599 resp.sname := new_tkt.sname; 5600 resp.realm := new_tkt.realm; 5602 if (new_tkt.flags.RENEWABLE) then 5603 resp.renew-till := new_tkt.renew-till; 5604 endif 5606 encode body of reply into OCTET STRING; 5608 if (req.padata.authenticator.subkey) 5609 resp.enc-part := encrypt OCTET STRING using use_etype, 5610 req.padata.authenticator.subkey; 5611 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 5613 send(resp); 5615 A.7. KRB_TGS_REP verification 5616 decode response into resp; 5618 if (resp.msg-type = KRB_ERROR) then 5619 process_error(resp); 5620 return; 5621 endif 5623 /* On error, discard the response, and zero the session key from 5624 the response immediately */ 5626 if (req.padata.authenticator.subkey) 5627 unencrypted part of resp := decode of decrypt of resp.enc-part 5628 using resp.enc-part.etype and subkey; 5629 else unencrypted part of resp := decode of decrypt of resp.enc-part 5630 using resp.enc-part.etype and tgt's session key; 5631 if (common_as_rep_tgs_rep_checks fail) then 5632 destroy resp.key; 5633 return error; 5634 endif 5636 check authorization_data as necessary; 5637 save_for_later(ticket,session,client,server,times,flags); 5639 Section A.7. - 101 - Expires 15 October 1993 5641 Version 5 - Revision 5.2 5643 A.8. Authenticator generation 5644 body.authenticator-vno := authenticator vno; /* = 5 */ 5645 body.cname, body.crealm := client name; 5646 if (supplying checksum) then 5647 body.cksum := checksum; 5648 endif 5649 get system_time; 5650 body.ctime, body.cusec := system_time; 5651 if (selecting sub-session key) then 5652 select sub-session key; 5653 body.subkey := sub-session key; 5654 endif 5655 if (using sequence numbers) then 5656 select initial sequence number; 5657 body.seq-number := initial sequence; 5658 endif 5660 A.9. KRB_AP_REQ generation 5661 obtain ticket and session_key from cache; 5663 packet.pvno := protocol version; /* 5 */ 5664 packet.msg-type := message type; /* KRB_AP_REQ */ 5666 if (desired(MUTUAL_AUTHENTICATION)) then 5667 set packet.ap-options.MUTUAL-REQUIRED; 5668 else 5669 reset packet.ap-options.MUTUAL-REQUIRED; 5670 endif 5671 if (using session key for ticket) then 5672 set packet.ap-options.USE-SESSION-KEY; 5673 else 5674 reset packet.ap-options.USE-SESSION-KEY; 5675 endif 5676 packet.ticket := ticket; /* ticket */ 5677 generate authenticator; 5678 encode authenticator into OCTET STRING; 5679 encrypt OCTET STRING into packet.authenticator using session_key; 5681 A.10. KRB_AP_REQ verification 5682 receive packet; 5683 if (packet.pvno != 5) then 5684 either process using other protocol spec 5685 or error_out(KRB_AP_ERR_BADVERSION); 5686 endif 5687 if (packet.msg-type != KRB_AP_REQ) then 5688 error_out(KRB_AP_ERR_MSG_TYPE); 5689 endif 5690 if (packet.ticket.tkt_vno != 5) then 5691 either process using other protocol spec 5692 or error_out(KRB_AP_ERR_BADVERSION); 5693 endif 5694 if (packet.ap_options.USE-SESSION-KEY is set) then 5695 retrieve session key from ticket-granting ticket for 5696 packet.ticket.{sname,srealm,enc-part.etype}; 5698 Section A.10. - 102 - Expires 15 October 1993 5700 Version 5 - Revision 5.2 5702 else 5703 retrieve service key for 5704 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 5705 endif 5706 if (no_key_available) then 5707 if (cannot_find_specified_skvno) then 5708 error_out(KRB_AP_ERR_BADKEYVER); 5709 else 5710 error_out(KRB_AP_ERR_NOKEY); 5711 endif 5712 endif 5713 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 5714 if (decryption_error()) then 5715 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5716 endif 5717 decrypt packet.authenticator into decr_authenticator 5718 using decr_ticket.key; 5719 if (decryption_error()) then 5720 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5721 endif 5722 if (decr_authenticator.{cname,crealm} != 5723 decr_ticket.{cname,crealm}) then 5724 error_out(KRB_AP_ERR_BADMATCH); 5725 endif 5726 if (decr_ticket.caddr is present) then 5727 if (sender_address(packet) is not in decr_ticket.caddr) then 5728 error_out(KRB_AP_ERR_BADADDR); 5729 endif 5730 elseif (application requires addresses) then 5731 error_out(KRB_AP_ERR_BADADDR); 5732 endif 5733 if (not in_clock_skew(decr_authenticator.ctime, 5734 decr_authenticator.cusec)) then 5735 error_out(KRB_AP_ERR_SKEW); 5736 endif 5737 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 5738 error_out(KRB_AP_ERR_REPEAT); 5739 endif 5740 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 5741 get system_time; 5742 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 5743 (decr_ticket.flags.INVALID is set)) then 5744 /* it hasn't yet become valid */ 5745 error_out(KRB_AP_ERR_TKT_NYV); 5746 endif 5747 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 5748 error_out(KRB_AP_ERR_TKT_EXPIRED); 5749 endif 5750 /* caller must check decr_ticket.flags for any pertinent details */ 5751 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 5753 A.11. KRB_AP_REP generation 5754 packet.pvno := protocol version; /* 5 */ 5755 packet.msg-type := message type; /* KRB_AP_REP */ 5757 Section A.11. - 103 - Expires 15 October 1993 5759 Version 5 - Revision 5.2 5761 body.ctime := packet.ctime; 5762 body.cusec := packet.cusec; 5763 if (selecting sub-session key) then 5764 select sub-session key; 5765 body.subkey := sub-session key; 5766 endif 5767 if (using sequence numbers) then 5768 select initial sequence number; 5769 body.seq-number := initial sequence; 5770 endif 5772 encode body into OCTET STRING; 5774 select encryption type; 5775 encrypt OCTET STRING into packet.enc-part; 5777 A.12. KRB_AP_REP verification 5778 receive packet; 5779 if (packet.pvno != 5) then 5780 either process using other protocol spec 5781 or error_out(KRB_AP_ERR_BADVERSION); 5782 endif 5783 if (packet.msg-type != KRB_AP_REP) then 5784 error_out(KRB_AP_ERR_MSG_TYPE); 5785 endif 5786 cleartext := decrypt(packet.enc-part) using ticket's session key; 5787 if (decryption_error()) then 5788 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5789 endif 5790 if (cleartext.ctime != authenticator.ctime) then 5791 error_out(KRB_AP_ERR_MUT_FAIL); 5792 endif 5793 if (cleartext.cusec != authenticator.cusec) then 5794 error_out(KRB_AP_ERR_MUT_FAIL); 5795 endif 5796 if (cleartext.subkey is present) then 5797 save cleartext.subkey for future use; 5798 endif 5799 if (cleartext.seq-number is present) then 5800 save cleartext.seq-number for future verifications; 5801 endif 5802 return(AUTHENTICATION_SUCCEEDED); 5804 A.13. KRB_SAFE generation 5805 collect user data in buffer; 5807 /* assemble packet: */ 5808 packet.pvno := protocol version; /* 5 */ 5809 packet.msg-type := message type; /* KRB_SAFE */ 5811 body.user-data := buffer; /* DATA */ 5812 if (using timestamp) then 5813 get system_time; 5814 body.timestamp, body.usec := system_time; 5816 Section A.13. - 104 - Expires 15 October 1993 5818 Version 5 - Revision 5.2 5820 endif 5821 if (using sequence numbers) then 5822 body.seq-number := sequence number; 5823 endif 5824 body.s-address := sender host addresses; 5825 if (only one recipient) then 5826 body.r-address := recipient host address; 5827 endif 5828 checksum.cksumtype := checksum type; 5829 compute checksum over body; 5830 checksum.checksum := checksum value; /* checksum.checksum */ 5831 packet.cksum := checksum; 5832 packet.safe-body := body; 5834 A.14. KRB_SAFE verification 5835 receive packet; 5836 if (packet.pvno != 5) then 5837 either process using other protocol spec 5838 or error_out(KRB_AP_ERR_BADVERSION); 5839 endif 5840 if (packet.msg-type != KRB_SAFE) then 5841 error_out(KRB_AP_ERR_MSG_TYPE); 5842 endif 5843 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 5844 error_out(KRB_AP_ERR_INAPP_CKSUM); 5845 endif 5846 if (safe_priv_common_checks_ok(packet)) then 5847 set computed_checksum := checksum(packet.body); 5848 if (computed_checksum != packet.checksum) then 5849 error_out(KRB_AP_ERR_MODIFIED); 5850 endif 5851 return (packet, PACKET_IS_GENUINE); 5852 else 5853 return common_checks_error; 5854 endif 5856 A.15. KRB_SAFE and KRB_PRIV common checks 5857 if (packet.s-address != O/S_sender(packet)) then 5858 /* O/S report of sender not who claims to have sent it */ 5859 error_out(KRB_AP_ERR_BADADDR); 5860 endif 5861 if ((packet.r-address is present) and 5862 (packet.r-address != local_host_address)) then 5863 /* was not sent to proper place */ 5864 error_out(KRB_AP_ERR_BADADDR); 5865 endif 5866 if (((packet.timestamp is present) and 5867 (not in_clock_skew(packet.timestamp,packet.usec))) or 5868 (packet.timestamp is not present and timestamp expected)) then 5869 error_out(KRB_AP_ERR_SKEW); 5870 endif 5871 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 5872 error_out(KRB_AP_ERR_REPEAT); 5873 endif 5875 Section A.15. - 105 - Expires 15 October 1993 5877 Version 5 - Revision 5.2 5879 if (((packet.seq-number is present) and 5880 ((not in_sequence(packet.seq-number)))) or 5881 (packet.seq-number is not present and sequence expected)) then 5882 error_out(KRB_AP_ERR_BADORDER); 5883 endif 5884 if (packet.timestamp not present and packet.seq-number not present) then 5885 error_out(KRB_AP_ERR_MODIFIED); 5886 endif 5888 save_identifier(packet.{timestamp,usec,s-address}, 5889 sender_principal(packet)); 5891 return PACKET_IS_OK; 5893 A.16. KRB_PRIV generation 5894 collect user data in buffer; 5896 /* assemble packet: */ 5897 packet.pvno := protocol version; /* 5 */ 5898 packet.msg-type := message type; /* KRB_PRIV */ 5900 packet.enc-part.etype := encryption type; 5902 body.user-data := buffer; 5903 if (using timestamp) then 5904 get system_time; 5905 body.timestamp, body.usec := system_time; 5906 endif 5907 if (using sequence numbers) then 5908 body.seq-number := sequence number; 5909 endif 5910 body.s-address := sender host addresses; 5911 if (only one recipient) then 5912 body.r-address := recipient host address; 5913 endif 5915 encode body into OCTET STRING; 5917 select encryption type; 5918 encrypt OCTET STRING into packet.enc-part.cipher; 5920 A.17. KRB_PRIV verification 5921 receive packet; 5922 if (packet.pvno != 5) then 5923 either process using other protocol spec 5924 or error_out(KRB_AP_ERR_BADVERSION); 5925 endif 5926 if (packet.msg-type != KRB_PRIV) then 5927 error_out(KRB_AP_ERR_MSG_TYPE); 5928 endif 5930 cleartext := decrypt(packet.enc-part) using negotiated key; 5931 if (decryption_error()) then 5933 Section A.17. - 106 - Expires 15 October 1993 5935 Version 5 - Revision 5.2 5937 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5938 endif 5940 if (safe_priv_common_checks_ok(cleartext)) then 5941 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 5942 else 5943 return common_checks_error; 5944 endif 5946 A.18. KRB_CRED generation 5947 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 5949 /* assemble packet: */ 5950 packet.pvno := protocol version; /* 5 */ 5951 packet.msg-type := message type; /* KRB_CRED */ 5953 for (tickets[n] in tickets to be forwarded) do 5954 packet.tickets[n] = tickets[n].ticket; 5955 done 5957 packet.enc-part.etype := encryption type; 5959 for (ticket[n] in tickets to be forwarded) do 5960 body.ticket-info[n].key = tickets[n].session; 5961 body.ticket-info[n].prealm = tickets[n].crealm; 5962 body.ticket-info[n].pname = tickets[n].cname; 5963 body.ticket-info[n].flags = tickets[n].flags; 5964 body.ticket-info[n].authtime = tickets[n].authtime; 5965 body.ticket-info[n].starttime = tickets[n].starttime; 5966 body.ticket-info[n].endtime = tickets[n].endtime; 5967 body.ticket-info[n].renew-till = tickets[n].renew-till; 5968 body.ticket-info[n].srealm = tickets[n].srealm; 5969 body.ticket-info[n].sname = tickets[n].sname; 5970 body.ticket-info[n].caddr = tickets[n].caddr; 5971 done 5973 get system_time; 5974 body.timestamp, body.usec := system_time; 5976 if (using nonce) then 5977 body.nonce := nonce; 5978 endif 5980 if (using s-address) then 5981 body.s-address := sender host addresses; 5982 endif 5983 if (limited recipients) then 5984 body.r-address := recipient host address; 5985 endif 5987 encode body into OCTET STRING; 5989 select encryption type; 5990 encrypt OCTET STRING into packet.enc-part.cipher 5992 Section A.18. - 107 - Expires 15 October 1993 5994 Version 5 - Revision 5.2 5996 using negotiated encryption key; 5998 A.19. KRB_CRED verification 5999 receive packet; 6000 if (packet.pvno != 5) then 6001 either process using other protocol spec 6002 or error_out(KRB_AP_ERR_BADVERSION); 6003 endif 6004 if (packet.msg-type != KRB_CRED) then 6005 error_out(KRB_AP_ERR_MSG_TYPE); 6006 endif 6008 cleartext := decrypt(packet.enc-part) using negotiated key; 6009 if (decryption_error()) then 6010 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6011 endif 6012 if ((packet.r-address is present or required) and 6013 (packet.s-address != O/S_sender(packet)) then 6014 /* O/S report of sender not who claims to have sent it */ 6015 error_out(KRB_AP_ERR_BADADDR); 6016 endif 6017 if ((packet.r-address is present) and 6018 (packet.r-address != local_host_address)) then 6019 /* was not sent to proper place */ 6020 error_out(KRB_AP_ERR_BADADDR); 6021 endif 6022 if (not in_clock_skew(packet.timestamp,packet.usec)) then 6023 error_out(KRB_AP_ERR_SKEW); 6024 endif 6025 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6026 error_out(KRB_AP_ERR_REPEAT); 6027 endif 6028 if (packet.nonce is required or present) and 6029 (packet.nonce != expected-nonce) then 6030 error_out(KRB_AP_ERR_MODIFIED); 6031 endif 6033 for (ticket[n] in tickets that were forwarded) do 6034 save_for_later(ticket[n],key[n],principal[n], 6035 server[n],times[n],flags[n]); 6036 return 6038 A.20. KRB_ERROR generation 6040 /* assemble packet: */ 6041 packet.pvno := protocol version; /* 5 */ 6042 packet.msg-type := message type; /* KRB_ERROR */ 6044 get system_time; 6045 packet.stime, packet.susec := system_time; 6046 packet.realm, packet.sname := server name; 6048 if (client time available) then 6050 Section A.20. - 108 - Expires 15 October 1993 6052 Version 5 - Revision 5.2 6054 packet.ctime, packet.cusec := client_time; 6055 endif 6056 packet.error-code := error code; 6057 if (client name available) then 6058 packet.cname, packet.crealm := client name; 6059 endif 6060 if (error text available) then 6061 packet.e-text := error text; 6062 endif 6063 if (error data available) then 6064 packet.e-data := error data; 6065 endif 6067 - 109 - Expires 15 October 1993 6069 Version 5 - Revision 5.2 6071 - cx - Expires 15 October 1993 6073 Table of Contents 6075 Overview .............................................. 1 6077 Background ............................................ 2 6079 1. Introduction ....................................... 2 6081 1.1. Cross-Realm Operation ............................ 4 6083 1.2. Environmental assumptions ........................ 5 6085 1.3. Glossary of terms ................................ 6 6087 2. Ticket flag uses and requests ...................... 9 6089 2.1. Initial and pre-authenticated tickets ............ 9 6091 2.2. Invalid tickets .................................. 9 6093 2.3. Renewable tickets ................................ 10 6095 2.4. Postdated tickets ................................ 10 6097 2.5. Proxiable and proxy tickets ...................... 11 6099 2.6. Forwardable tickets .............................. 12 6101 2.7. Other KDC options ................................ 12 6103 3. Message Exchanges .................................. 13 6105 3.1. The Authentication Service Exchange .............. 13 6107 3.1.1. Generation of KRB_AS_REQ message ............... 15 6109 3.1.2. Receipt of KRB_AS_REQ message .................. 15 6111 3.1.3. Generation of KRB_AS_REP message ............... 15 6113 3.1.4. Generation of KRB_ERROR message ................ 17 6115 3.1.5. Receipt of KRB_AS_REP message .................. 17 6117 3.1.6. Receipt of KRB_ERROR message ................... 18 6119 3.2. The Client/Server Authentication Exchange ........ 18 6121 3.2.1. The KRB_AP_REQ message ......................... 18 6123 3.2.2. Generation of a KRB_AP_REQ message ............. 19 6125 - i - Expires 15 October 1993 6127 Version 5 - Revision 5.2 6129 3.2.3. Receipt of KRB_AP_REQ message .................. 19 6131 3.2.4. Generation of a KRB_AP_REP message ............. 21 6133 3.2.5. Receipt of KRB_AP_REP message .................. 22 6135 3.2.6. Using the encryption key ....................... 22 6137 3.3. The Ticket-Granting Service (TGS) Exchange ....... 23 6139 3.3.1. Generation of KRB_TGS_REQ message .............. 24 6141 3.3.2. Receipt of KRB_TGS_REQ message ................. 25 6143 3.3.3. Generation of KRB_TGS_REP message .............. 26 6145 3.3.3.1. Encoding the transited field ................. 28 6147 3.3.4. Receipt of KRB_TGS_REP message ................. 30 6149 3.4. The KRB_SAFE Exchange ............................ 30 6151 3.4.1. Generation of a KRB_SAFE message ............... 30 6153 3.4.2. Receipt of KRB_SAFE message .................... 31 6155 3.5. The KRB_PRIV Exchange ............................ 31 6157 3.5.1. Generation of a KRB_PRIV message ............... 32 6159 3.5.2. Receipt of KRB_PRIV message .................... 32 6161 3.6. The KRB_CRED Exchange ............................ 33 6163 3.6.1. Generation of a KRB_CRED message ............... 33 6165 3.6.2. Receipt of KRB_CRED message .................... 33 6167 4. The Kerberos Database .............................. 34 6169 4.1. Database contents ................................ 34 6171 4.2. Additional fields ................................ 35 6173 4.3. Frequently Changing Fields ....................... 36 6175 4.4. Site Constants ................................... 36 6177 5. Message Specifications ............................. 37 6179 5.1. ASN.1 Distinguished Encoding Representation ...... 37 6181 5.2. ASN.1 Base Definitions ........................... 37 6183 - ii - Expires 15 October 1993 6185 Version 5 - Revision 5.2 6187 5.3. Tickets and Authenticators ....................... 40 6189 5.3.1. Tickets ........................................ 40 6191 5.3.2. Authenticators ................................. 46 6193 5.4. Specifications for the AS and TGS exchanges ...... 47 6195 5.4.1. KRB_KDC_REQ definition ......................... 47 6197 5.4.2. KRB_KDC_REP definition ......................... 54 6199 5.5. Client/Server (CS) message specifications ........ 57 6201 5.5.1. KRB_AP_REQ definition .......................... 57 6203 5.5.2. KRB_AP_REP definition .......................... 58 6205 5.5.3. Error message reply ............................ 59 6207 5.6. KRB_SAFE message specification ................... 60 6209 5.6.1. KRB_SAFE definition ............................ 60 6211 5.7. KRB_PRIV message specification ................... 61 6213 5.7.1. KRB_PRIV definition ............................ 61 6215 5.8. KRB_CRED message specification ................... 62 6217 5.8.1. KRB_CRED definition ............................ 63 6219 5.9. Error message specification ...................... 65 6221 5.9.1. KRB_ERROR definition ........................... 65 6223 6. Encryption and Checksum Specifications ............. 67 6225 6.1. Encryption Specifications ........................ 68 6227 6.2. Encryption Keys .................................. 70 6229 6.3. Encryption Systems ............................... 71 6231 6.3.1. The NULL Encryption System (null) .............. 71 6233 6.3.2. DES in CBC mode with a CRC-32 checksum (des- 6234 cbc-crc) .............................................. 71 6236 6.3.3. DES in CBC mode with an MD4 checksum (des- 6237 cbc-md4) .............................................. 71 6239 6.3.4. DES in CBC mode with an MD5 checksum (des- 6240 cbc-md5) .............................................. 72 6242 - iii - Expires 15 October 1993 6244 Version 5 - Revision 5.2 6246 6.4. Checksums ........................................ 73 6248 6.4.1. The CRC-32 Checksum (crc32) .................... 74 6250 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 74 6252 6.4.3. RSA MD4 Cryptographic Checksum Using DES 6253 (rsa-md4-des) ......................................... 74 6255 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 75 6257 6.4.5. RSA MD5 Cryptographic Checksum Using DES 6258 (rsa-md5-des) ......................................... 75 6260 6.4.6. DES cipher-block chained checksum (des-mac) 6262 6.4.7. RSA MD4 Cryptographic Checksum Using DES 6263 alternative (rsa-md4-des-k) ........................... 77 6265 6.4.8. DES cipher-block chained checksum alternative 6266 (des-mac-k) ........................................... 77 6268 7. Naming Constraints ................................. 77 6270 7.1. Realm Names ...................................... 77 6272 7.2. Principal Names .................................. 79 6274 7.2.1. Name of server principals ...................... 80 6276 8. Constants and other defined values ................. 80 6278 8.1. Host address types ............................... 80 6280 8.2. KDC messages ..................................... 81 6282 8.2.1. IP transport ................................... 81 6284 8.2.2. OSI transport .................................. 81 6286 8.2.3. Name of the TGS ................................ 82 6288 8.3. Protocol constants and associated values ......... 82 6290 9. Interoperability requirements ...................... 84 6292 9.1. Specification 1 .................................. 85 6294 9.2. Recommended KDC values ........................... 86 6296 10. Acknowledgments ................................... 87 6298 11. REFERENCES ........................................ 88 6300 - iv - Expires 15 October 1993 6302 Version 5 - Revision 5.2 6304 A. Pseudo-code for protocol processing ................ 90 6306 A.1. KRB_AS_REQ generation ............................ 90 6308 A.2. KRB_AS_REQ verification and KRB_AS_REP genera- 6309 tion .................................................. 90 6311 A.3. KRB_AS_REP verification .......................... 94 6313 A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 94 6315 A.5. KRB_TGS_REQ generation ........................... 95 6317 A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen- 6318 eration ............................................... 96 6320 A.7. KRB_TGS_REP verification ......................... 101 6322 A.8. Authenticator generation ......................... 102 6324 A.9. KRB_AP_REQ generation ............................ 102 6326 A.10. KRB_AP_REQ verification ......................... 102 6328 A.11. KRB_AP_REP generation ........................... 103 6330 A.12. KRB_AP_REP verification ......................... 104 6332 A.13. KRB_SAFE generation ............................. 104 6334 A.14. KRB_SAFE verification ........................... 105 6336 A.15. KRB_SAFE and KRB_PRIV common checks ............. 105 6338 A.16. KRB_PRIV generation ............................. 106 6340 A.17. KRB_PRIV verification ........................... 106 6342 A.18. KRB_CRED generation ............................. 107 6344 A.19. KRB_CRED verification ........................... 108 6346 A.20. KRB_ERROR generation ............................ 108 6348 - v - Expires 15 October 1993