idnits 2.17.1 draft-ietf-cat-kerberos-revisions-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 6867 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. ** There are 159 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 1944 instances of too long lines in the document, the longest one being 19 characters in excess of 72. ** The abstract seems to contain references ([DS81], [MNSS87], [NT94], [NS78], [SNS88]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 25 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1833: '... extensions[4] TicketExtensions OPTIONAL...' RFC 2119 keyword, line 1844: '... starttime[6] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 1846: '... renew-till[8] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 1847: '... caddr[9] HostAddresses OPTIONAL,...' RFC 2119 keyword, line 1848: '... authorization-data[10] AuthorizationData OPTIONAL...' (62 more instances...) -- The abstract seems to indicate that this document updates RFC1510, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1908 has weird spacing: '... future expan...' == Line 1912 has weird spacing: '...LE flag is n...' == Line 1913 has weird spacing: '...rpreted by t...' == Line 1915 has weird spacing: '... flag tells...' == Line 1916 has weird spacing: '...s OK to issue...' == (154 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: o the Unspecified Address o the Loopback Address o Link-Local addresses IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2000) is 8628 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'NT94' on line 4580 looks like a reference -- Missing reference section? 'SNS88' on line 4589 looks like a reference -- Missing reference section? 'MNSS87' on line 4584 looks like a reference -- Missing reference section? 'NS78' on line 4594 looks like a reference -- Missing reference section? 'DS81' on line 4599 looks like a reference -- Missing reference section? 'KNT92' on line 4603 looks like a reference -- Missing reference section? '1' on line 6029 looks like a reference -- Missing reference section? '2' on line 6036 looks like a reference -- Missing reference section? '3' on line 6042 looks like a reference -- Missing reference section? 'Neu93' on line 4608 looks like a reference -- Missing reference section? '4' on line 6048 looks like a reference -- Missing reference section? '5' on line 6051 looks like a reference -- Missing reference section? '6' on line 6056 looks like a reference -- Missing reference section? '7' on line 6062 looks like a reference -- Missing reference section? 'DS90' on line 4615 looks like a reference -- Missing reference section? 'LGDSR87' on line 4620 looks like a reference -- Missing reference section? '10' on line 6081 looks like a reference -- Missing reference section? '11' on line 6083 looks like a reference -- Missing reference section? '12' on line 6089 looks like a reference -- Missing reference section? '13' on line 6095 looks like a reference -- Missing reference section? '14' on line 6098 looks like a reference -- Missing reference section? '15' on line 1046 looks like a reference -- Missing reference section? '16' on line 6112 looks like a reference -- Missing reference section? '17' on line 6117 looks like a reference -- Missing reference section? '18' on line 6122 looks like a reference -- Missing reference section? '19' on line 6125 looks like a reference -- Missing reference section? '20' on line 6131 looks like a reference -- Missing reference section? '21' on line 6135 looks like a reference -- Missing reference section? '22' on line 6143 looks like a reference -- Missing reference section? 'X509-88' on line 4625 looks like a reference -- Missing reference section? '0' on line 5929 looks like a reference -- Missing reference section? '23' on line 6146 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 1828 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 1837 looks like a reference -- Missing reference section? '8' on line 6118 looks like a reference -- Missing reference section? '9' on line 6075 looks like a reference -- Missing reference section? '24' on line 6153 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 2194 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 2268 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 2269 looks like a reference -- Missing reference section? 'Pat92' on line 4628 looks like a reference -- Missing reference section? '25' on line 6158 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 2661 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2662 looks like a reference -- Missing reference section? 'APPLICATION 26' on line 2677 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 2763 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 2826 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 2884 looks like a reference -- Missing reference section? 'APPLICATION 21' on line 2956 looks like a reference -- Missing reference section? '32' on line 6172 looks like a reference -- Missing reference section? 'APPLICATION 22' on line 3003 looks like a reference -- Missing reference section? 'APPLICATION 29' on line 3010 looks like a reference -- Missing reference section? 'APPLICATION 30' on line 3102 looks like a reference -- Missing reference section? '33' on line 6180 looks like a reference -- Missing reference section? 'DES77' on line 4632 looks like a reference -- Missing reference section? 'DESM80' on line 4637 looks like a reference -- Missing reference section? 'SG92' on line 4642 looks like a reference -- Missing reference section? '35' on line 6184 looks like a reference -- Missing reference section? '36' on line 6192 looks like a reference -- Missing reference section? 'ISO3309' on line 3788 looks like a reference -- Missing reference section? 'MD492' on line 3398 looks like a reference -- Missing reference section? 'MD5-92' on line 4656 looks like a reference -- Missing reference section? 'Krawczyk96' on line 4673 looks like a reference -- Missing reference section? 'HorowitzB96' on line 4668 looks like a reference -- Missing reference section? 'Horowitz96' on line 4664 looks like a reference -- Missing reference section? 'MD4-92' on line 4652 looks like a reference -- Missing reference section? '39' on line 6210 looks like a reference -- Missing reference section? 'RFC 1779' on line 4016 looks like a reference -- Missing reference section? 'Westerlund' on line 4155 looks like a reference -- Missing reference section? 'RFC1883' on line 4098 looks like a reference -- Missing reference section? 'RFC1884' on line 4099 looks like a reference -- Missing reference section? 'Danielsson' on line 4155 looks like a reference -- Missing reference section? 'RFC 2253' on line 4366 looks like a reference -- Missing reference section? '40' on line 6218 looks like a reference -- Missing reference section? 'IS3309' on line 4647 looks like a reference -- Missing reference section? 'KBC96' on line 4660 looks like a reference -- Missing reference section? 'TM' on line 6025 looks like a reference -- Missing reference section? '27' on line 6163 looks like a reference -- Missing reference section? '29' on line 6166 looks like a reference -- Missing reference section? '31' on line 6169 looks like a reference -- Missing reference section? '37' on line 6202 looks like a reference -- Missing reference section? '38' on line 6206 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 86 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 John Kohl 3 Theodore Ts'o 4 March 10, 2000 5 Expires September 10, 2000 7 The Kerberos Network Authentication Service (V5) 8 draft-ietf-cat-kerberos-revisions-05.txt 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. Internet-Drafts are working documents 14 of the Internet Engineering Task Force (IETF), its areas, and its working 15 groups. Note that other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite them 21 other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 The distribution of this memo is unlimited. It is filed as 35 draft-ietf-cat-kerberos-revisions-05.txt, and expires September 10, 2000. 36 Please send comments to: krb-protocol@MIT.EDU 38 ABSTRACT 40 This document provides an overview and specification of Version 5 of the 41 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 42 and its intended use that require more detailed or clearer explanation than 43 was provided in RFC1510. This document is intended to provide a detailed 44 description of the protocol, suitable for implementation, together with 45 descriptions of the appropriate use of protocol messages and fields within 46 those messages. 48 This document is not intended to describe Kerberos to the end user, system 49 administrator, or application developer. Higher level papers describing 50 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 51 are available elsewhere. 53 OVERVIEW 55 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 56 network authentication system is based. It also specifies Version 5 of the 57 Kerberos protocol. 59 The motivations, goals, assumptions, and rationale behind most design 60 decisions are treated cursorily; they are more fully described in a paper 62 Neuman, Ts'o, Kohl Expires: 10 September, 2000 63 available in IEEE communications [NT94] and earlier in the Kerberos portion 64 of the Athena Technical Plan [MNSS87]. The protocols have been a proposed 65 standard and are being considered for advancement for draft standard through 66 the IETF standard process. Comments are encouraged on the presentation, but 67 only minor refinements to the protocol as implemented or extensions that fit 68 within current protocol framework will be considered at this time. 70 Requests for addition to an electronic mailing list for discussion of 71 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. 72 This mailing list is gatewayed onto the Usenet as the group 73 comp.protocols.kerberos. Requests for further information, including 74 documents and code availability, may be sent to info-kerberos@MIT.EDU. 76 BACKGROUND 78 The Kerberos model is based in part on Needham and Schroeder's trusted 79 third-party authentication protocol [NS78] and on modifications suggested by 80 Denning and Sacco [DS81]. The original design and implementation of Kerberos 81 Versions 1 through 4 was the work of two former Project Athena staff 82 members, Steve Miller of Digital Equipment Corporation and Clifford Neuman 83 (now at the Information Sciences Institute of the University of Southern 84 California), along with Jerome Saltzer, Technical Director of Project 85 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members 86 of Project Athena have also contributed to the work on Kerberos. 88 Version 5 of the Kerberos protocol (described in this document) has evolved 89 from Version 4 based on new requirements and desires for features not 90 available in Version 4. The design of Version 5 of the Kerberos protocol was 91 led by Clifford Neuman and John Kohl with much input from the community. The 92 development of the MIT reference implementation was led at MIT by John Kohl 93 and Theodore T'so, with help and contributed code from many others. Since 94 RFC1510 was issued, extensions and revisions to the protocol have been 95 proposed by many individuals. Some of these proposals are reflected in this 96 document. Where such changes involved significant effort, the document cites 97 the contribution of the proposer. 99 Reference implementations of both version 4 and version 5 of Kerberos are 100 publicly available and commercial implementations have been developed and 101 are widely used. Details on the differences between Kerberos Versions 4 and 102 5 can be found in [KNT92]. 104 1. Introduction 106 Kerberos provides a means of verifying the identities of principals, (e.g. a 107 workstation user or a network server) on an open (unprotected) network. This 108 is accomplished without relying on assertions by the host operating system, 109 without basing trust on host addresses, without requiring physical security 110 of all the hosts on the network, and under the assumption that packets 111 traveling along the network can be read, modified, and inserted at will[1]. 112 Kerberos performs authentication under these conditions as a trusted 113 third-party authentication service by using conventional (shared secret key 114 [2] cryptography. Kerberos extensions have been proposed and implemented 115 that provide for the use of public key cryptography during certain phases of 116 the authentication protocol. These extensions provide for authentication of 117 users registered with public key certification authorities, and allow the 118 system to provide certain benefits of public key cryptography in situations 119 where they are needed. 121 The basic Kerberos authentication process proceeds as follows: A client 123 Neuman, Ts'o, Kohl Expires: 10 September, 2000 124 sends a request to the authentication server (AS) requesting 'credentials' 125 for a given server. The AS responds with these credentials, encrypted in the 126 client's key. The credentials consist of 1) a 'ticket' for the server and 2) 127 a temporary encryption key (often called a "session key"). The client 128 transmits the ticket (which contains the client's identity and a copy of the 129 session key, all encrypted in the server's key) to the server. The session 130 key (now shared by the client and server) is used to authenticate the 131 client, and may optionally be used to authenticate the server. It may also 132 be used to encrypt further communication between the two parties or to 133 exchange a separate sub-session key to be used to encrypt further 134 communication. 136 Implementation of the basic protocol consists of one or more authentication 137 servers running on physically secure hosts. The authentication servers 138 maintain a database of principals (i.e., users and servers) and their secret 139 keys. Code libraries provide encryption and implement the Kerberos protocol. 140 In order to add authentication to its transactions, a typical network 141 application adds one or two calls to the Kerberos library directly or 142 through the Generic Security Services Application Programming Interface, 143 GSSAPI, described in separate document. These calls result in the 144 transmission of the necessary messages to achieve authentication. 146 The Kerberos protocol consists of several sub-protocols (or exchanges). 147 There are two basic methods by which a client can ask a Kerberos server for 148 credentials. In the first approach, the client sends a cleartext request for 149 a ticket for the desired server to the AS. The reply is sent encrypted in 150 the client's secret key. Usually this request is for a ticket-granting 151 ticket (TGT) which can later be used with the ticket-granting server (TGS). 152 In the second method, the client sends a request to the TGS. The client uses 153 the TGT to authenticate itself to the TGS in the same manner as if it were 154 contacting any other application server that requires Kerberos 155 authentication. The reply is encrypted in the session key from the TGT. 156 Though the protocol specification describes the AS and the TGS as separate 157 servers, they are implemented in practice as different protocol entry points 158 within a single Kerberos server. 160 Once obtained, credentials may be used to verify the identity of the 161 principals in a transaction, to ensure the integrity of messages exchanged 162 between them, or to preserve privacy of the messages. The application is 163 free to choose whatever protection may be necessary. 165 To verify the identities of the principals in a transaction, the client 166 transmits the ticket to the application server. Since the ticket is sent "in 167 the clear" (parts of it are encrypted, but this encryption doesn't thwart 168 replay) and might be intercepted and reused by an attacker, additional 169 information is sent to prove that the message originated with the principal 170 to whom the ticket was issued. This information (called the authenticator) 171 is encrypted in the session key, and includes a timestamp. The timestamp 172 proves that the message was recently generated and is not a replay. 173 Encrypting the authenticator in the session key proves that it was generated 174 by a party possessing the session key. Since no one except the requesting 175 principal and the server know the session key (it is never sent over the 176 network in the clear) this guarantees the identity of the client. 178 The integrity of the messages exchanged between principals can also be 179 guaranteed using the session key (passed in the ticket and contained in the 180 credentials). This approach provides detection of both replay attacks and 181 message stream modification attacks. It is accomplished by generating and 182 transmitting a collision-proof checksum (elsewhere called a hash or digest 184 Neuman, Ts'o, Kohl Expires: 10 September, 2000 185 function) of the client's message, keyed with the session key. Privacy and 186 integrity of the messages exchanged between principals can be secured by 187 encrypting the data to be passed using the session key contained in the 188 ticket or the subsession key found in the authenticator. 190 The authentication exchanges mentioned above require read-only access to the 191 Kerberos database. Sometimes, however, the entries in the database must be 192 modified, such as when adding new principals or changing a principal's key. 193 This is done using a protocol between a client and a third Kerberos server, 194 the Kerberos Administration Server (KADM). There is also a protocol for 195 maintaining multiple copies of the Kerberos database. Neither of these 196 protocols are described in this document. 198 1.1. Cross-Realm Operation 200 The Kerberos protocol is designed to operate across organizational 201 boundaries. A client in one organization can be authenticated to a server in 202 another. Each organization wishing to run a Kerberos server establishes its 203 own 'realm'. The name of the realm in which a client is registered is part 204 of the client's name, and can be used by the end-service to decide whether 205 to honor a request. 207 By establishing 'inter-realm' keys, the administrators of two realms can 208 allow a client authenticated in the local realm to prove its identity to 209 servers in other realms[3]. The exchange of inter-realm keys (a separate key 210 may be used for each direction) registers the ticket-granting service of 211 each realm as a principal in the other realm. A client is then able to 212 obtain a ticket-granting ticket for the remote realm's ticket-granting 213 service from its local realm. When that ticket-granting ticket is used, the 214 remote ticket-granting service uses the inter-realm key (which usually 215 differs from its own normal TGS key) to decrypt the ticket-granting ticket, 216 and is thus certain that it was issued by the client's own TGS. Tickets 217 issued by the remote ticket-granting service will indicate to the 218 end-service that the client was authenticated from another realm. 220 A realm is said to communicate with another realm if the two realms share an 221 inter-realm key, or if the local realm shares an inter-realm key with an 222 intermediate realm that communicates with the remote realm. An 223 authentication path is the sequence of intermediate realms that are 224 transited in communicating from one realm to another. 226 Realms are typically organized hierarchically. Each realm shares a key with 227 its parent and a different key with each child. If an inter-realm key is not 228 directly shared by two realms, the hierarchical organization allows an 229 authentication path to be easily constructed. If a hierarchical organization 230 is not used, it may be necessary to consult a database in order to construct 231 an authentication path between realms. 233 Although realms are typically hierarchical, intermediate realms may be 234 bypassed to achieve cross-realm authentication through alternate 235 authentication paths (these might be established to make communication 236 between two realms more efficient). It is important for the end-service to 237 know which realms were transited when deciding how much faith to place in 238 the authentication process. To facilitate this decision, a field in each 239 ticket contains the names of the realms that were involved in authenticating 240 the client. 242 The application server is ultimately responsible for accepting or rejecting 243 authentication and should check the transited field. The application server 245 Neuman, Ts'o, Kohl Expires: 10 September, 2000 246 may choose to rely on the KDC for the application server's realm to check 247 the transited field. The application server's KDC will set the 248 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 249 realms may also check the transited field as they issue 250 ticket-granting-tickets for other realms, but they are encouraged not to do 251 so. A client may request that the KDC's not check the transited field by 252 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 253 required to honor this flag. 255 1.2. Authorization 257 As an authentication service, Kerberos provides a means of verifying the 258 identity of principals on a network. Authentication is usually useful 259 primarily as a first step in the process of authorization, determining 260 whether a client may use a service, which objects the client is allowed to 261 access, and the type of access allowed for each. Kerberos does not, by 262 itself, provide authorization. Possession of a client ticket for a service 263 provides only for authentication of the client to that service, and in the 264 absence of a separate authorization procedure, it should not be considered 265 by an application as authorizing the use of that service. 267 Such separate authorization methods may be implemented as application 268 specific access control functions and may be based on files such as the 269 application server, or on separately issued authorization credentials such 270 as those based on proxies [Neu93], or on other authorization services. 271 Separately authenticated authorization credentials may be embedded in a 272 tickets authorization data when encapsulated by the kdc-issued authorization 273 data element. 275 Applications should not be modified to accept the mere issuance of a service 276 ticket by the Kerberos server (even by a modified Kerberos server) as 277 granting authority to use the service, since such applications may become 278 vulnerable to the bypass of this authorization check in an environment if 279 they interoperate with other KDCs or where other options for application 280 authentication (e.g. the PKTAPP proposal) are provided. 282 1.3. Environmental assumptions 284 Kerberos imposes a few assumptions on the environment in which it can 285 properly function: 287 * 'Denial of service' attacks are not solved with Kerberos. There are 288 places in these protocols where an intruder can prevent an application 289 from participating in the proper authentication steps. Detection and 290 solution of such attacks (some of which can appear to be nnot-uncommon 291 'normal' failure modes for the system) is usually best left to the 292 human administrators and users. 293 * Principals must keep their secret keys secret. If an intruder somehow 294 steals a principal's key, it will be able to masquerade as that 295 principal or impersonate any server to the legitimate principal. 296 * 'Password guessing' attacks are not solved by Kerberos. If a user 297 chooses a poor password, it is possible for an attacker to successfully 298 mount an offline dictionary attack by repeatedly attempting to decrypt, 299 with successive entries from a dictionary, messages obtained which are 300 encrypted under a key derived from the user's password. 301 * Each host on the network must have a clock which is 'loosely 302 synchronized' to the time of the other hosts; this synchronization is 303 used to reduce the bookkeeping needs of application servers when they 304 do replay detection. The degree of "looseness" can be configured on a 306 Neuman, Ts'o, Kohl Expires: 10 September, 2000 307 per-server basis, but is typically on the order of 5 minutes. If the 308 clocks are synchronized over the network, the clock synchronization 309 protocol must itself be secured from network attackers. 310 * Principal identifiers are not recycled on a short-term basis. A typical 311 mode of access control will use access control lists (ACLs) to grant 312 permissions to particular principals. If a stale ACL entry remains for 313 a deleted principal and the principal identifier is reused, the new 314 principal will inherit rights specified in the stale ACL entry. By not 315 re-using principal identifiers, the danger of inadvertent access is 316 removed. 318 1.4. Glossary of terms 320 Below is a list of terms used throughout this document. 322 Authentication 323 Verifying the claimed identity of a principal. 324 Authentication header 325 A record containing a Ticket and an Authenticator to be presented to a 326 server as part of the authentication process. 327 Authentication path 328 A sequence of intermediate realms transited in the authentication 329 process when communicating from one realm to another. 330 Authenticator 331 A record containing information that can be shown to have been recently 332 generated using the session key known only by the client and server. 333 Authorization 334 The process of determining whether a client may use a service, which 335 objects the client is allowed to access, and the type of access allowed 336 for each. 337 Capability 338 A token that grants the bearer permission to access an object or 339 service. In Kerberos, this might be a ticket whose use is restricted by 340 the contents of the authorization data field, but which lists no 341 network addresses, together with the session key necessary to use the 342 ticket. 343 Ciphertext 344 The output of an encryption function. Encryption transforms plaintext 345 into ciphertext. 346 Client 347 A process that makes use of a network service on behalf of a user. Note 348 that in some cases a Server may itself be a client of some other server 349 (e.g. a print server may be a client of a file server). 350 Credentials 351 A ticket plus the secret session key necessary to successfully use that 352 ticket in an authentication exchange. 353 KDC 354 Key Distribution Center, a network service that supplies tickets and 355 temporary session keys; or an instance of that service or the host on 356 which it runs. The KDC services both initial ticket and ticket-granting 357 ticket requests. The initial ticket portion is sometimes referred to as 358 the Authentication Server (or service). The ticket-granting ticket 359 portion is sometimes referred to as the ticket-granting server (or 360 service). 361 Kerberos 362 Aside from the 3-headed dog guarding Hades, the name given to Project 363 Athena's authentication service, the protocol used by that service, or 364 the code used to implement the authentication service. 365 Plaintext 367 Neuman, Ts'o, Kohl Expires: 10 September, 2000 368 The input to an encryption function or the output of a decryption 369 function. Decryption transforms ciphertext into plaintext. 370 Principal 371 A uniquely named client or server instance that participates in a 372 network communication. 373 Principal identifier 374 The name used to uniquely identify each different principal. 375 Seal 376 To encipher a record containing several fields in such a way that the 377 fields cannot be individually replaced without either knowledge of the 378 encryption key or leaving evidence of tampering. 379 Secret key 380 An encryption key shared by a principal and the KDC, distributed 381 outside the bounds of the system, with a long lifetime. In the case of 382 a human user's principal, the secret key is derived from a password. 383 Server 384 A particular Principal which provides a resource to network clients. 385 The server is sometimes refered to as the Application Server. 386 Service 387 A resource provided to network clients; often provided by more than one 388 server (for example, remote file service). 389 Session key 390 A temporary encryption key used between two principals, with a lifetime 391 limited to the duration of a single login "session". 392 Sub-session key 393 A temporary encryption key used between two principals, selected and 394 exchanged by the principals using the session key, and with a lifetime 395 limited to the duration of a single association. 396 Ticket 397 A record that helps a client authenticate itself to a server; it 398 contains the client's identity, a session key, a timestamp, and other 399 information, all sealed using the server's secret key. It only serves 400 to authenticate a client when presented along with a fresh 401 Authenticator. 403 2. Ticket flag uses and requests 405 Each Kerberos ticket contains a set of flags which are used to indicate 406 various attributes of that ticket. Most flags may be requested by a client 407 when the ticket is obtained; some are automatically turned on and off by a 408 Kerberos server as required. The following sections explain what the various 409 flags mean, and gives examples of reasons to use such a flag. 411 2.1. Initial and pre-authenticated tickets 413 The INITIAL flag indicates that a ticket was issued using the AS protocol 414 and not issued based on a ticket-granting ticket. Application servers that 415 want to require the demonstrated knowledge of a client's secret key (e.g. a 416 password-changing program) can insist that this flag be set in any tickets 417 they accept, and thus be assured that the client's key was recently 418 presented to the application client. 420 The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the 421 initial authentication, regardless of whether the current ticket was issued 422 directly (in which case INITIAL will also be set) or issued on the basis of 423 a ticket-granting ticket (in which case the INITIAL flag is clear, but the 424 PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 425 ticket-granting ticket). 427 Neuman, Ts'o, Kohl Expires: 10 September, 2000 428 2.2. Invalid tickets 430 The INVALID flag indicates that a ticket is invalid. Application servers 431 must reject tickets which have this flag set. A postdated ticket will 432 usually be issued in this form. Invalid tickets must be validated by the KDC 433 before use, by presenting them to the KDC in a TGS request with the VALIDATE 434 option specified. The KDC will only validate tickets after their starttime 435 has passed. The validation is required so that postdated tickets which have 436 been stolen before their starttime can be rendered permanently invalid 437 (through a hot-list mechanism) (see section 3.3.3.1). 439 2.3. Renewable tickets 441 Applications may desire to hold tickets which can be valid for long periods 442 of time. However, this can expose their credentials to potential theft for 443 equally long periods, and those stolen credentials would be valid until the 444 expiration time of the ticket(s). Simply using short-lived tickets and 445 obtaining new ones periodically would require the client to have long-term 446 access to its secret key, an even greater risk. Renewable tickets can be 447 used to mitigate the consequences of theft. Renewable tickets have two 448 "expiration times": the first is when the current instance of the ticket 449 expires, and the second is the latest permissible value for an individual 450 expiration time. An application client must periodically (i.e. before it 451 expires) present a renewable ticket to the KDC, with the RENEW option set in 452 the KDC request. The KDC will issue a new ticket with a new session key and 453 a later expiration time. All other fields of the ticket are left unmodified 454 by the renewal process. When the latest permissible expiration time arrives, 455 the ticket expires permanently. At each renewal, the KDC may consult a 456 hot-list to determine if the ticket had been reported stolen since its last 457 renewal; it will refuse to renew such stolen tickets, and thus the usable 458 lifetime of stolen tickets is reduced. 460 The RENEWABLE flag in a ticket is normally only interpreted by the 461 ticket-granting service (discussed below in section 3.3). It can usually be 462 ignored by application servers. However, some particularly careful 463 application servers may wish to disallow renewable tickets. 465 If a renewable ticket is not renewed by its expiration time, the KDC will 466 not renew the ticket. The RENEWABLE flag is reset by default, but a client 467 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 468 message. If it is set, then the renew-till field in the ticket contains the 469 time after which the ticket may not be renewed. 471 2.4. Postdated tickets 473 Applications may occasionally need to obtain tickets for use much later, 474 e.g. a batch submission system would need tickets to be valid at the time 475 the batch job is serviced. However, it is dangerous to hold valid tickets in 476 a batch queue, since they will be on-line longer and more prone to theft. 477 Postdated tickets provide a way to obtain these tickets from the KDC at job 478 submission time, but to leave them "dormant" until they are activated and 479 validated by a further request of the KDC. If a ticket theft were reported 480 in the interim, the KDC would refuse to validate the ticket, and the thief 481 would be foiled. 483 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 484 ticket-granting service. It can be ignored by application servers. This flag 485 must be set in a ticket-granting ticket in order to issue a postdated ticket 486 based on the presented ticket. It is reset by default; it may be requested 488 Neuman, Ts'o, Kohl Expires: 10 September, 2000 489 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 490 This flag does not allow a client to obtain a postdated ticket-granting 491 ticket; postdated ticket-granting tickets can only by obtained by requesting 492 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 493 postdated ticket will be the remaining life of the ticket-granting ticket at 494 the time of the request, unless the RENEWABLE option is also set, in which 495 case it can be the full life (endtime-starttime) of the ticket-granting 496 ticket. The KDC may limit how far in the future a ticket may be postdated. 498 The POSTDATED flag indicates that a ticket has been postdated. The 499 application server can check the authtime field in the ticket to see when 500 the original authentication occurred. Some services may choose to reject 501 postdated tickets, or they may only accept them within a certain period 502 after the original authentication. When the KDC issues a POSTDATED ticket, 503 it will also be marked as INVALID, so that the application client must 504 present the ticket to the KDC to be validated before use. 506 2.5. Proxiable and proxy tickets 508 At times it may be necessary for a principal to allow a service to perform 509 an operation on its behalf. The service must be able to take on the identity 510 of the client, but only for a particular purpose. A principal can allow a 511 service to take on the principal's identity for a particular purpose by 512 granting it a proxy. 514 The process of granting a proxy using the proxy and proxiable flags is used 515 to provide credentials for use with specific services. Though conceptually 516 also a proxy, user's wishing to delegate their identity for ANY purpose must 517 use the ticket forwarding mechanism described in the next section to forward 518 a ticket granting ticket. 520 The PROXIABLE flag in a ticket is normally only interpreted by the 521 ticket-granting service. It can be ignored by application servers. When set, 522 this flag tells the ticket-granting server that it is OK to issue a new 523 ticket (but not a ticket-granting ticket) with a different network address 524 based on this ticket. This flag is set if requested by the client on initial 525 authentication. By default, the client will request that it be set when 526 requesting a ticket granting ticket, and reset when requesting any other 527 ticket. 529 This flag allows a client to pass a proxy to a server to perform a remote 530 request on its behalf, e.g. a print service client can give the print server 531 a proxy to access the client's files on a particular file server in order to 532 satisfy a print request. 534 In order to complicate the use of stolen credentials, Kerberos tickets are 535 usually valid from only those network addresses specifically included in the 536 ticket[4]. When granting a proxy, the client must specify the new network 537 address from which the proxy is to be used, or indicate that the proxy is to 538 be issued for use from any address. 540 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 541 Application servers may check this flag and at their option they may require 542 additional authentication from the agent presenting the proxy in order to 543 provide an audit trail. 545 2.6. Forwardable tickets 547 Authentication forwarding is an instance of a proxy where the service is 549 Neuman, Ts'o, Kohl Expires: 10 September, 2000 550 granted complete use of the client's identity. An example where it might be 551 used is when a user logs in to a remote system and wants authentication to 552 work from that system as if the login were local. 554 The FORWARDABLE flag in a ticket is normally only interpreted by the 555 ticket-granting service. It can be ignored by application servers. The 556 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 557 flag, except ticket-granting tickets may also be issued with different 558 network addresses. This flag is reset by default, but users may request that 559 it be set by setting the FORWARDABLE option in the AS request when they 560 request their initial ticket- granting ticket. 562 This flag allows for authentication forwarding without requiring the user to 563 enter a password again. If the flag is not set, then authentication 564 forwarding is not permitted, but the same result can still be achieved if 565 the user engages in the AS exchange specifying the requested network 566 addresses and supplies a password. 568 The FORWARDED flag is set by the TGS when a client presents a ticket with 569 the FORWARDABLE flag set and requests a forwarded ticket by specifying the 570 FORWARDED KDC option and supplying a set of addresses for the new ticket. It 571 is also set in all tickets issued based on tickets with the FORWARDED flag 572 set. Application servers may choose to process FORWARDED tickets differently 573 than non-FORWARDED tickets. 575 2.7. Other KDC options 577 There are two additional options which may be set in a client's request of 578 the KDC. The RENEWABLE-OK option indicates that the client will accept a 579 renewable ticket if a ticket with the requested life cannot otherwise be 580 provided. If a ticket with the requested life cannot be provided, then the 581 KDC may issue a renewable ticket with a renew-till equal to the the 582 requested endtime. The value of the renew-till field may still be adjusted 583 by site-determined limits or limits imposed by the individual principal or 584 server. 586 The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. 587 It indicates that the ticket to be issued for the end server is to be 588 encrypted in the session key from the a additional second ticket-granting 589 ticket provided with the request. See section 3.3.3 for specific details. 591 3. Message Exchanges 593 The following sections describe the interactions between network clients and 594 servers and the messages involved in those exchanges. 596 3.1. The Authentication Service Exchange 598 Summary 599 Message direction Message type Section 600 1. Client to Kerberos KRB_AS_REQ 5.4.1 601 2. Kerberos to client KRB_AS_REP or 5.4.2 602 KRB_ERROR 5.9.1 604 The Authentication Service (AS) Exchange between the client and the Kerberos 605 Authentication Server is initiated by a client when it wishes to obtain 606 authentication credentials for a given server but currently holds no 607 credentials. In its basic form, the client's secret key is used for 608 encryption and decryption. This exchange is typically used at the initiation 610 Neuman, Ts'o, Kohl Expires: 10 September, 2000 611 of a login session to obtain credentials for a Ticket-Granting Server which 612 will subsequently be used to obtain credentials for other servers (see 613 section 3.3) without requiring further use of the client's secret key. This 614 exchange is also used to request credentials for services which must not be 615 mediated through the Ticket-Granting Service, but rather require a 616 principal's secret key, such as the password-changing service[5]. This 617 exchange does not by itself provide any assurance of the the identity of the 618 user[6]. 620 The exchange consists of two messages: KRB_AS_REQ from the client to 621 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 622 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 624 In the request, the client sends (in cleartext) its own identity and the 625 identity of the server for which it is requesting credentials. The response, 626 KRB_AS_REP, contains a ticket for the client to present to the server, and a 627 session key that will be shared by the client and the server. The session 628 key and additional information are encrypted in the client's secret key. The 629 KRB_AS_REP message contains information which can be used to detect replays, 630 and to associate it with the message to which it replies. Various errors can 631 occur; these are indicated by an error response (KRB_ERROR) instead of the 632 KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR 633 message contains information which can be used to associate it with the 634 message to which it replies. The lack of encryption in the KRB_ERROR message 635 precludes the ability to detect replays, fabrications, or modifications of 636 such messages. 638 Without preautentication, the authentication server does not know whether 639 the client is actually the principal named in the request. It simply sends a 640 reply without knowing or caring whether they are the same. This is 641 acceptable because nobody but the principal whose identity was given in the 642 request will be able to use the reply. Its critical information is encrypted 643 in that principal's key. The initial request supports an optional field that 644 can be used to pass additional information that might be needed for the 645 initial exchange. This field may be used for preauthentication as described 646 in section [hl<>]. 648 3.1.1. Generation of KRB_AS_REQ message 650 The client may specify a number of options in the initial request. Among 651 these options are whether pre-authentication is to be performed; whether the 652 requested ticket is to be renewable, proxiable, or forwardable; whether it 653 should be postdated or allow postdating of derivative tickets; and whether a 654 renewable ticket will be accepted in lieu of a non-renewable ticket if the 655 requested ticket expiration date cannot be satisfied by a non-renewable 656 ticket (due to configuration constraints; see section 4). See section A.1 657 for pseudocode. 659 The client prepares the KRB_AS_REQ message and sends it to the KDC. 661 3.1.2. Receipt of KRB_AS_REQ message 663 If all goes well, processing the KRB_AS_REQ message will result in the 664 creation of a ticket for the client to present to the server. The format for 665 the ticket is described in section 5.3.1. The contents of the ticket are 666 determined as follows. 668 3.1.3. Generation of KRB_AS_REP message 670 Neuman, Ts'o, Kohl Expires: 10 September, 2000 671 The authentication server looks up the client and server principals named in 672 the KRB_AS_REQ in its database, extracting their respective keys. If 673 required, the server pre-authenticates the request, and if the 674 pre-authentication check fails, an error message with the code 675 KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the 676 requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP 677 is returned. Otherwise it generates a 'random' session key[7]. 679 If there are multiple encryption keys registered for a client in the 680 Kerberos database (or if the key registered supports multiple encryption 681 types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS 682 request is used by the KDC to select the encryption method to be used for 683 encrypting the response to the client. If there is more than one supported, 684 strong encryption type in the etype list, the first valid etype for which an 685 encryption key is available is used. The encryption method used to respond 686 to a TGS request is taken from the keytype of the session key found in the 687 ticket granting ticket. [***I will change the example keytypes to be 3DES 688 based examples 7/14***] 690 When the etype field is present in a KDC request, whether an AS or TGS 691 request, the KDC will attempt to assign the type of the random session key 692 from the list of methods in the etype field. The KDC will select the 693 appropriate type using the list of methods provided together with 694 information from the Kerberos database indicating acceptable encryption 695 methods for the application server. The KDC will not issue tickets with a 696 weak session key encryption type. 698 If the requested start time is absent, indicates a time in the past, or is 699 within the window of acceptable clock skew for the KDC and the POSTDATE 700 option has not been specified, then the start time of the ticket is set to 701 the authentication server's current time. If it indicates a time in the 702 future beyond the acceptable clock skew, but the POSTDATED option has not 703 been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise 704 the requested start time is checked against the policy of the local realm 705 (the administrator might decide to prohibit certain types or ranges of 706 postdated tickets), and if acceptable, the ticket's start time is set as 707 requested and the INVALID flag is set in the new ticket. The postdated 708 ticket must be validated before use by presenting it to the KDC after the 709 start time has been reached. 711 The expiration time of the ticket will be set to the minimum of the 712 following: 714 * The expiration time (endtime) requested in the KRB_AS_REQ message. 715 * The ticket's start time plus the maximum allowable lifetime associated 716 with the client principal (the authentication server's database 717 includes a maximum ticket lifetime field in each principal's record; 718 see section 4). 719 * The ticket's start time plus the maximum allowable lifetime associated 720 with the server principal. 721 * The ticket's start time plus the maximum lifetime set by the policy of 722 the local realm. 724 If the requested expiration time minus the start time (as determined above) 725 is less than a site-determined minimum lifetime, an error message with code 726 KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the 727 ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' 728 option was requested, then the 'RENEWABLE' flag is set in the new ticket, 729 and the renew-till value is set as if the 'RENEWABLE' option were requested 731 Neuman, Ts'o, Kohl Expires: 10 September, 2000 732 (the field and option names are described fully in section 5.4.1). 734 If the RENEWABLE option has been requested or if the RENEWABLE-OK option has 735 been set and a renewable ticket is to be issued, then the renew-till field 736 is set to the minimum of: 738 * Its requested value. 739 * The start time of the ticket plus the minimum of the two maximum 740 renewable lifetimes associated with the principals' database entries. 741 * The start time of the ticket plus the maximum renewable lifetime set by 742 the policy of the local realm. 744 The flags field of the new ticket will have the following options set if 745 they have been requested and if the policy of the local realm allows: 746 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new 747 ticket is post-dated (the start time is in the future), its INVALID flag 748 will also be set. 750 If all of the above succeed, the server formats a KRB_AS_REP message (see 751 section 5.4.2), copying the addresses in the request into the caddr of the 752 response, placing any required pre-authentication data into the padata of 753 the response, and encrypts the ciphertext part in the client's key using the 754 requested encryption method, and sends it to the client. See section A.2 for 755 pseudocode. 757 3.1.4. Generation of KRB_ERROR message 759 Several errors can occur, and the Authentication Server responds by 760 returning an error message, KRB_ERROR, to the client, with the error-code 761 and e-text fields set to appropriate values. The error message contents and 762 details are described in Section 5.9.1. 764 3.1.5. Receipt of KRB_AS_REP message 766 If the reply message type is KRB_AS_REP, then the client verifies that the 767 cname and crealm fields in the cleartext portion of the reply match what it 768 requested. If any padata fields are present, they may be used to derive the 769 proper secret key to decrypt the message. The client decrypts the encrypted 770 part of the response using its secret key, verifies that the nonce in the 771 encrypted part matches the nonce it supplied in its request (to detect 772 replays). It also verifies that the sname and srealm in the response match 773 those in the request (or are otherwise expected values), and that the host 774 address field is also correct. It then stores the ticket, session key, start 775 and expiration times, and other information for later use. The 776 key-expiration field from the encrypted part of the response may be checked 777 to notify the user of impending key expiration (the client program could 778 then suggest remedial action, such as a password change). See section A.3 779 for pseudocode. 781 Proper decryption of the KRB_AS_REP message is not sufficient to verify the 782 identity of the user; the user and an attacker could cooperate to generate a 783 KRB_AS_REP format message which decrypts properly but is not from the proper 784 KDC. If the host wishes to verify the identity of the user, it must require 785 the user to present application credentials which can be verified using a 786 securely-stored secret key for the host. If those credentials can be 787 verified, then the identity of the user can be assured. 789 3.1.6. Receipt of KRB_ERROR message 791 Neuman, Ts'o, Kohl Expires: 10 September, 2000 792 If the reply message type is KRB_ERROR, then the client interprets it as an 793 error and performs whatever application-specific tasks are necessary to 794 recover. 796 3.2. The Client/Server Authentication Exchange 798 Summary 799 Message direction Message type Section 800 Client to Application server KRB_AP_REQ 5.5.1 801 [optional] Application server to client KRB_AP_REP or 5.5.2 802 KRB_ERROR 5.9.1 804 The client/server authentication (CS) exchange is used by network 805 applications to authenticate the client to the server and vice versa. The 806 client must have already acquired credentials for the server using the AS or 807 TGS exchange. 809 3.2.1. The KRB_AP_REQ message 811 The KRB_AP_REQ contains authentication information which should be part of 812 the first message in an authenticated transaction. It contains a ticket, an 813 authenticator, and some additional bookkeeping information (see section 814 5.5.1 for the exact format). The ticket by itself is insufficient to 815 authenticate a client, since tickets are passed across the network in 816 cleartext[DS90], so the authenticator is used to prevent invalid replay of 817 tickets by proving to the server that the client knows the session key of 818 the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is 819 referred to elsewhere as the 'authentication header.' 821 3.2.2. Generation of a KRB_AP_REQ message 823 When a client wishes to initiate authentication to a server, it obtains 824 (either through a credentials cache, the AS exchange, or the TGS exchange) a 825 ticket and session key for the desired service. The client may re-use any 826 tickets it holds until they expire. To use a ticket the client constructs a 827 new Authenticator from the the system time, its name, and optionally an 828 application specific checksum, an initial sequence number to be used in 829 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in 830 negotiations for a session key unique to this particular session. 831 Authenticators may not be re-used and will be rejected if replayed to a 832 server[LGDSR87]. If a sequence number is to be included, it should be 833 randomly chosen so that even after many messages have been exchanged it is 834 not likely to collide with other sequence numbers in use. 836 The client may indicate a requirement of mutual authentication or the use of 837 a session-key based ticket by setting the appropriate flag(s) in the 838 ap-options field of the message. 840 The Authenticator is encrypted in the session key and combined with the 841 ticket to form the KRB_AP_REQ message which is then sent to the end server 842 along with any additional application-specific information. See section A.9 843 for pseudocode. 845 3.2.3. Receipt of KRB_AP_REQ message 847 Authentication is based on the server's current time of day (clocks must be 848 loosely synchronized), the authenticator, and the ticket. Several errors are 849 possible. If an error occurs, the server is expected to reply to the client 850 with a KRB_ERROR message. This message may be encapsulated in the 852 Neuman, Ts'o, Kohl Expires: 10 September, 2000 853 application protocol if its 'raw' form is not acceptable to the protocol. 854 The format of error messages is described in section 5.9.1. 856 The algorithm for verifying authentication information is as follows. If the 857 message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE 858 error. If the key version indicated by the Ticket in the KRB_AP_REQ is not 859 one the server can use (e.g., it indicates an old key, and the server no 860 longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is 861 returned. If the USE-SESSION-KEY flag is set in the ap-options field, it 862 indicates to the server that the ticket is encrypted in the session key from 863 the server's ticket-granting ticket rather than its secret key[10]. Since it 864 is possible for the server to be registered in multiple realms, with 865 different keys in each, the srealm field in the unencrypted portion of the 866 ticket in the KRB_AP_REQ is used to specify which secret key the server 867 should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is 868 returned if the server doesn't have the proper key to decipher the ticket. 870 The ticket is decrypted using the version of the server's key specified by 871 the ticket. If the decryption routines detect a modification of the ticket 872 (each encryption system must provide safeguards to detect modified 873 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned 874 (chances are good that different keys were used to encrypt and decrypt). 876 The authenticator is decrypted using the session key extracted from the 877 decrypted ticket. If decryption shows it to have been modified, the 878 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client 879 from the ticket are compared against the same fields in the authenticator. 880 If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might 881 not match, for example, if the wrong session key was used to encrypt the 882 authenticator). The addresses in the ticket (if any) are then searched for 883 an address matching the operating-system reported address of the client. If 884 no match is found or the server insists on ticket addresses but none are 885 present in the ticket, the KRB_AP_ERR_BADADDR error is returned. 887 If the local (server) time and the client time in the authenticator differ 888 by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW 889 error is returned. If the server name, along with the client name, time and 890 microsecond fields from the Authenticator match any recently-seen such 891 tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must 892 remember any authenticator presented within the allowable clock skew, so 893 that a replay attempt is guaranteed to fail. If a server loses track of any 894 authenticator presented within the allowable clock skew, it must reject all 895 requests until the clock skew interval has passed. This assures that any 896 lost or re-played authenticators will fall outside the allowable clock skew 897 and can no longer be successfully replayed (If this is not done, an attacker 898 could conceivably record the ticket and authenticator sent over the network 899 to a server, then disable the client's host, pose as the disabled host, and 900 replay the ticket and authenticator to subvert the authentication.). If a 901 sequence number is provided in the authenticator, the server saves it for 902 later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is 903 present, the server either saves it for later use or uses it to help 904 generate its own choice for a subkey to be returned in a KRB_AP_REP message. 906 The server computes the age of the ticket: local (server) time minus the 907 start time inside the Ticket. If the start time is later than the current 908 time by more than the allowable clock skew or if the INVALID flag is set in 909 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the 910 current time is later than end time by more than the allowable clock skew, 911 the KRB_AP_ERR_TKT_EXPIRED error is returned. 913 Neuman, Ts'o, Kohl Expires: 10 September, 2000 914 If all these checks succeed without an error, the server is assured that the 915 client possesses the credentials of the principal named in the ticket and 916 thus, the client has been authenticated to the server. See section A.10 for 917 pseudocode. 919 Passing these checks provides only authentication of the named principal; it 920 does not imply authorization to use the named service. Applications must 921 make a separate authorization decisions based upon the authenticated name of 922 the user, the requested operation, local acces control information such as 923 that contained in a .k5login or .k5users file, and possibly a separate 924 distributed authorization service. 926 3.2.4. Generation of a KRB_AP_REP message 928 Typically, a client's request will include both the authentication 929 information and its initial request in the same message, and the server need 930 not explicitly reply to the KRB_AP_REQ. However, if mutual authentication 931 (not only authenticating the client to the server, but also the server to 932 the client) is being performed, the KRB_AP_REQ message will have 933 MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is 934 required in response. As with the error message, this message may be 935 encapsulated in the application protocol if its "raw" form is not acceptable 936 to the application's protocol. The timestamp and microsecond field used in 937 the reply must be the client's timestamp and microsecond field (as provided 938 in the authenticator)[12]. If a sequence number is to be included, it should 939 be randomly chosen as described above for the authenticator. A subkey may be 940 included if the server desires to negotiate a different subkey. The 941 KRB_AP_REP message is encrypted in the session key extracted from the 942 ticket. See section A.11 for pseudocode. 944 3.2.5. Receipt of KRB_AP_REP message 946 If a KRB_AP_REP message is returned, the client uses the session key from 947 the credentials obtained for the server[13] to decrypt the message, and 948 verifies that the timestamp and microsecond fields match those in the 949 Authenticator it sent to the server. If they match, then the client is 950 assured that the server is genuine. The sequence number and subkey (if 951 present) are retained for later use. See section A.12 for pseudocode. 953 3.2.6. Using the encryption key 955 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server 956 share an encryption key which can be used by the application. The 'true 957 session key' to be used for KRB_PRIV, KRB_SAFE, or other 958 application-specific uses may be chosen by the application based on the 959 subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, 960 the use of this session key will be implicit in the protocol; in others the 961 method of use must be chosen from several alternatives. We leave the 962 protocol negotiations of how to use the key (e.g. selecting an encryption or 963 checksum type) to the application programmer; the Kerberos protocol does not 964 constrain the implementation options, but an example of how this might be 965 done follows. 967 One way that an application may choose to negotiate a key to be used for 968 subequent integrity and privacy protection is for the client to propose a 969 key in the subkey field of the authenticator. The server can then choose a 970 key using the proposed key from the client as input, returning the new 971 subkey in the subkey field of the application reply. This key could then be 973 Neuman, Ts'o, Kohl Expires: 10 September, 2000 974 used for subsequent communication. To make this example more concrete, if 975 the encryption method in use required a 56 bit key, and for whatever reason, 976 one of the parties was prevented from using a key with more than 40 unknown 977 bits, this method would allow the the party which is prevented from using 978 more than 40 bits to either propose (if the client) an initial key with a 979 known quantity for 16 of those bits, or to mask 16 of the bits (if the 980 server) with the known quantity. The application implementor is warned, 981 however, that this is only an example, and that an analysis of the 982 particular crytosystem to be used, and the reasons for limiting the key 983 length, must be made before deciding whether it is acceptable to mask bits 984 of the key. 986 With both the one-way and mutual authentication exchanges, the peers should 987 take care not to send sensitive information to each other without proper 988 assurances. In particular, applications that require privacy or integrity 989 should use the KRB_AP_REP response from the server to client to assure both 990 client and server of their peer's identity. If an application protocol 991 requires privacy of its messages, it can use the KRB_PRIV message (section 992 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 994 3.3. The Ticket-Granting Service (TGS) Exchange 996 Summary 997 Message direction Message type Section 998 1. Client to Kerberos KRB_TGS_REQ 5.4.1 999 2. Kerberos to client KRB_TGS_REP or 5.4.2 1000 KRB_ERROR 5.9.1 1002 The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1003 initiated by a client when it wishes to obtain authentication credentials 1004 for a given server (which might be registered in a remote realm), when it 1005 wishes to renew or validate an existing ticket, or when it wishes to obtain 1006 a proxy ticket. In the first case, the client must already have acquired a 1007 ticket for the Ticket-Granting Service using the AS exchange (the 1008 ticket-granting ticket is usually obtained when a client initially 1009 authenticates to the system, such as when a user logs in). The message 1010 format for the TGS exchange is almost identical to that for the AS exchange. 1011 The primary difference is that encryption and decryption in the TGS exchange 1012 does not take place under the client's key. Instead, the session key from 1013 the ticket-granting ticket or renewable ticket, or sub-session key from an 1014 Authenticator is used. As is the case for all application servers, expired 1015 tickets are not accepted by the TGS, so once a renewable or ticket-granting 1016 ticket expires, the client must use a separate exchange to obtain valid 1017 tickets. 1019 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1020 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1021 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1022 client plus a request for credentials. The authentication information 1023 consists of the authentication header (KRB_AP_REQ) which includes the 1024 client's previously obtained ticket-granting, renewable, or invalid ticket. 1025 In the ticket-granting ticket and proxy cases, the request may include one 1026 or more of: a list of network addresses, a collection of typed authorization 1027 data to be sealed in the ticket for authorization use by the application 1028 server, or additional tickets (the use of which are described later). The 1029 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1030 session key from the ticket-granting ticket or renewable ticket, or if 1031 present, in the sub-session key from the Authenticator (part of the 1032 authentication header). The KRB_ERROR message contains an error code and 1034 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1035 text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1036 KRB_TGS_REP message contains information which can be used to detect 1037 replays, and to associate it with the message to which it replies. The 1038 KRB_ERROR message also contains information which can be used to associate 1039 it with the message to which it replies, but the lack of encryption in the 1040 KRB_ERROR message precludes the ability to detect replays or fabrications of 1041 such messages. 1043 3.3.1. Generation of KRB_TGS_REQ message 1045 Before sending a request to the ticket-granting service, the client must 1046 determine in which realm the application server is registered[15]. If the 1047 client does not already possess a ticket-granting ticket for the appropriate 1048 realm, then one must be obtained. This is first attempted by requesting a 1049 ticket-granting ticket for the destination realm from a Kerberos server for 1050 which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ 1051 message recursively). The Kerberos server may return a TGT for the desired 1052 realm in which case one can proceed. Alternatively, the Kerberos server may 1053 return a TGT for a realm which is 'closer' to the desired realm (further 1054 along the standard hierarchical path), in which case this step must be 1055 repeated with a Kerberos server in the realm specified in the returned TGT. 1056 If neither are returned, then the request must be retried with a Kerberos 1057 server for a realm higher in the hierarchy. This request will itself require 1058 a ticket-granting ticket for the higher realm which must be obtained by 1059 recursively applying these directions. 1061 Once the client obtains a ticket-granting ticket for the appropriate realm, 1062 it determines which Kerberos servers serve that realm, and contacts one. The 1063 list might be obtained through a configuration file or network service or it 1064 may be generated from the name of the realm; as long as the secret keys 1065 exchanged by realms are kept secret, only denial of service results from 1066 using a false Kerberos server. 1068 As in the AS exchange, the client may specify a number of options in the 1069 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing 1070 an authentication header as an element of the padata field, and including 1071 the same fields as used in the KRB_AS_REQ message along with several 1072 optional fields: the enc-authorization-data field for application server use 1073 and additional tickets required by some options. 1075 In preparing the authentication header, the client can select a sub-session 1076 key under which the response from the Kerberos server will be encrypted[16]. 1077 If the sub-session key is not specified, the session key from the 1078 ticket-granting ticket will be used. If the enc-authorization-data is 1079 present, it must be encrypted in the sub-session key, if present, from the 1080 authenticator portion of the authentication header, or if not present, using 1081 the session key from the ticket-granting ticket. 1083 Once prepared, the message is sent to a Kerberos server for the destination 1084 realm. See section A.5 for pseudocode. 1086 3.3.2. Receipt of KRB_TGS_REQ message 1088 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1089 message, but there are many additional checks to be performed. First, the 1090 Kerberos server must determine which server the accompanying ticket is for 1091 and it must select the appropriate key to decrypt it. For a normal 1092 KRB_TGS_REQ message, it will be for the ticket granting service, and the 1093 TGS's key will be used. If the TGT was issued by another realm, then the 1095 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1096 appropriate inter-realm key must be used. If the accompanying ticket is not 1097 a ticket granting ticket for the current realm, but is for an application 1098 server in the current realm, the RENEW, VALIDATE, or PROXY options are 1099 specified in the request, and the server for which a ticket is requested is 1100 the server named in the accompanying ticket, then the KDC will decrypt the 1101 ticket in the authentication header using the key of the server for which it 1102 was issued. If no ticket can be found in the padata field, the 1103 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1105 Once the accompanying ticket has been decrypted, the user-supplied checksum 1106 in the Authenticator must be verified against the contents of the request, 1107 and the message rejected if the checksums do not match (with an error code 1108 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1109 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1110 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1111 returned. If the authorization-data are present, they are decrypted using 1112 the sub-session key from the Authenticator. 1114 If any of the decryptions indicate failed integrity checks, the 1115 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1117 3.3.3. Generation of KRB_TGS_REP message 1119 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1120 but with its type field set to KRB_TGS_REP. The detailed specification is in 1121 section 5.4.2. 1123 The response will include a ticket for the requested server. The Kerberos 1124 database is queried to retrieve the record for the requested server 1125 (including the key with which the ticket will be encrypted). If the request 1126 is for a ticket granting ticket for a remote realm, and if no key is shared 1127 with the requested realm, then the Kerberos server will select the realm 1128 "closest" to the requested realm with which it does share a key, and use 1129 that realm instead. This is the only case where the response from the KDC 1130 will be for a different server than that requested by the client. 1132 By default, the address field, the client's name and realm, the list of 1133 transited realms, the time of initial authentication, the expiration time, 1134 and the authorization data of the newly-issued ticket will be copied from 1135 the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1136 needs to be updated, but the transited type is not supported, the 1137 KDC_ERR_TRTYPE_NOSUPP error is returned. 1139 If the request specifies an endtime, then the endtime of the new ticket is 1140 set to the minimum of (a) that request, (b) the endtime from the TGT, and 1141 (c) the starttime of the TGT plus the minimum of the maximum life for the 1142 application server and the maximum life for the local realm (the maximum 1143 life for the requesting principal was already applied when the TGT was 1144 issued). If the new ticket is to be a renewal, then the endtime above is 1145 replaced by the minimum of (a) the value of the renew_till field of the 1146 ticket and (b) the starttime for the new ticket plus the life 1147 (endtime-starttime) of the old ticket. 1149 If the FORWARDED option has been requested, then the resulting ticket will 1150 contain the addresses specified by the client. This option will only be 1151 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1152 similar; the resulting ticket will contain the addresses specified by the 1153 client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1154 PROXY option will not be honored on requests for additional ticket-granting 1156 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1157 tickets. 1159 If the requested start time is absent, indicates a time in the past, or is 1160 within the window of acceptable clock skew for the KDC and the POSTDATE 1161 option has not been specified, then the start time of the ticket is set to 1162 the authentication server's current time. If it indicates a time in the 1163 future beyond the acceptable clock skew, but the POSTDATED option has not 1164 been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1165 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1166 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1167 postdated and the requested starttime is checked against the policy of the 1168 local realm. If acceptable, the ticket's start time is set as requested, and 1169 the INVALID flag is set. The postdated ticket must be validated before use 1170 by presenting it to the KDC after the starttime has been reached. However, 1171 in no case may the starttime, endtime, or renew-till time of a newly-issued 1172 postdated ticket extend beyond the renew-till time of the ticket-granting 1173 ticket. 1175 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1176 has been included in the request, the KDC will decrypt the additional ticket 1177 using the key for the server to which the additional ticket was issued and 1178 verify that it is a ticket-granting ticket. If the name of the requested 1179 server is missing from the request, the name of the client in the additional 1180 ticket will be used. Otherwise the name of the requested server will be 1181 compared to the name of the client in the additional ticket and if 1182 different, the request will be rejected. If the request succeeds, the 1183 session key from the additional ticket will be used to encrypt the new 1184 ticket that is issued instead of using the key of the server for which the 1185 new ticket will be used[17]. 1187 If the name of the server in the ticket that is presented to the KDC as part 1188 of the authentication header is not that of the ticket-granting server 1189 itself, the server is registered in the realm of the KDC, and the RENEW 1190 option is requested, then the KDC will verify that the RENEWABLE flag is set 1191 in the ticket, that the INVALID flag is not set in the ticket, and that the 1192 renew_till time is still in the future. If the VALIDATE option is rqeuested, 1193 the KDC will check that the starttime has passed and the INVALID flag is 1194 set. If the PROXY option is requested, then the KDC will check that the 1195 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1196 passes the hotlist check described in the next paragraph, the KDC will issue 1197 the appropriate new ticket. 1199 3.3.3.1. Checking for revoked tickets 1201 Whenever a request is made to the ticket-granting server, the presented 1202 ticket(s) is(are) checked against a hot-list of tickets which have been 1203 canceled. This hot-list might be implemented by storing a range of issue 1204 timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1205 that range, it would be rejected. In this way, a stolen ticket-granting 1206 ticket or renewable ticket cannot be used to gain additional tickets 1207 (renewals or otherwise) once the theft has been reported. Any normal ticket 1208 obtained before it was reported stolen will still be valid (because they 1209 require no interaction with the KDC), but only until their normal expiration 1210 time. 1212 The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1213 in the sub-session key from the Authenticator, if present, or the session 1214 key key from the ticket-granting ticket. It is not encrypted using the 1215 client's secret key. Furthermore, the client's key's expiration date and the 1217 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1218 key version number fields are left out since these values are stored along 1219 with the client's database record, and that record is not needed to satisfy 1220 a request based on a ticket-granting ticket. See section A.6 for pseudocode. 1222 3.3.3.2. Encoding the transited field 1224 If the identity of the server in the TGT that is presented to the KDC as 1225 part of the authentication header is that of the ticket-granting service, 1226 but the TGT was issued from another realm, the KDC will look up the 1227 inter-realm key shared with that realm and use that key to decrypt the 1228 ticket. If the ticket is valid, then the KDC will honor the request, subject 1229 to the constraints outlined above in the section describing the AS exchange. 1230 The realm part of the client's identity will be taken from the 1231 ticket-granting ticket. The name of the realm that issued the 1232 ticket-granting ticket will be added to the transited field of the ticket to 1233 be issued. This is accomplished by reading the transited field from the 1234 ticket-granting ticket (which is treated as an unordered set of realm 1235 names), adding the new realm to the set, then constructing and writing out 1236 its encoded (shorthand) form (this may involve a rearrangement of the 1237 existing encoding). 1239 Note that the ticket-granting service does not add the name of its own 1240 realm. Instead, its responsibility is to add the name of the previous realm. 1241 This prevents a malicious Kerberos server from intentionally leaving out its 1242 own name (it could, however, omit other realms' names). 1244 The names of neither the local realm nor the principal's realm are to be 1245 included in the transited field. They appear elsewhere in the ticket and 1246 both are known to have taken part in authenticating the principal. Since the 1247 endpoints are not included, both local and single-hop inter-realm 1248 authentication result in a transited field that is empty. 1250 Because the name of each realm transited is added to this field, it might 1251 potentially be very long. To decrease the length of this field, its contents 1252 are encoded. The initially supported encoding is optimized for the normal 1253 case of inter-realm communication: a hierarchical arrangement of realms 1254 using either domain or X.500 style realm names. This encoding (called 1255 DOMAIN-X500-COMPRESS) is now described. 1257 Realm names in the transited field are separated by a ",". The ",", "\", 1258 trailing "."s, and leading spaces (" ") are special characters, and if they 1259 are part of a realm name, they must be quoted in the transited field by 1260 preced- ing them with a "\". 1262 A realm name ending with a "." is interpreted as being prepended to the 1263 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1264 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1266 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1268 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1269 would not be included in this field, and we would have: 1271 "EDU,MIT.,WASHINGTON.EDU" 1273 A realm name beginning with a "/" is interpreted as being appended to the 1274 previous realm[18]. If it is to stand by itself, then it should be preceded 1275 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1276 /COM/HP, /COM, and /COM/DEC as: 1278 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1279 "/COM,/HP,/APOLLO, /COM/DEC". 1281 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1282 they would not be included in this field, and we would have: 1284 "/COM,/HP" 1286 A null subfield preceding or following a "," indicates that all realms 1287 between the previous realm and the next realm have been traversed[19]. Thus, 1288 "," means that all realms along the path between the client and the server 1289 have been traversed. ",EDU, /COM," means that that all realms from the 1290 client's realm up to EDU (in a domain style hierarchy) have been traversed, 1291 and that everything from /COM down to the server's realm in an X.500 style 1292 has also been traversed. This could occur if the EDU realm in one hierarchy 1293 shares an inter-realm key directly with the /COM realm in another hierarchy. 1295 3.3.4. Receipt of KRB_TGS_REP message 1297 When the KRB_TGS_REP is received by the client, it is processed in the same 1298 manner as the KRB_AS_REP processing described above. The primary difference 1299 is that the ciphertext part of the response must be decrypted using the 1300 session key from the ticket-granting ticket rather than the client's secret 1301 key. See section A.7 for pseudocode. 1303 3.4. The KRB_SAFE Exchange 1305 The KRB_SAFE message may be used by clients requiring the ability to detect 1306 modifications of messages they exchange. It achieves this by including a 1307 keyed collision-proof checksum of the user data and some control 1308 information. The checksum is keyed with an encryption key (usually the last 1309 key negotiated via subkeys, or the session key if no negotiation has 1310 occured). 1312 3.4.1. Generation of a KRB_SAFE message 1314 When an application wishes to send a KRB_SAFE message, it collects its data 1315 and the appropriate control information and computes a checksum over them. 1316 The checksum algorithm should be a keyed one-way hash function (such as the 1317 RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), 1318 generated using the sub-session key if present, or the session key. 1319 Different algorithms may be selected by changing the checksum type in the 1320 message. Unkeyed or non-collision-proof checksums are not suitable for this 1321 use. 1323 The control information for the KRB_SAFE message includes both a timestamp 1324 and a sequence number. The designer of an application using the KRB_SAFE 1325 message must choose at least one of the two mechanisms. This choice should 1326 be based on the needs of the application protocol. 1328 Sequence numbers are useful when all messages sent will be received by one's 1329 peer. Connection state is presently required to maintain the session key, so 1330 maintaining the next sequence number should not present an additional 1331 problem. 1333 If the application protocol is expected to tolerate lost messages without 1334 them being resent, the use of the timestamp is the appropriate replay 1335 detection mechanism. Using timestamps is also the appropriate mechanism for 1336 multi-cast protocols where all of one's peers share a common sub-session 1338 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1339 key, but some messages will be sent to a subset of one's peers. 1341 After computing the checksum, the client then transmits the information and 1342 checksum to the recipient in the message format specified in section 5.6.1. 1344 3.4.2. Receipt of KRB_SAFE message 1346 When an application receives a KRB_SAFE message, it verifies it as follows. 1347 If any error occurs, an error code is reported for use by the application. 1349 The message is first checked by verifying that the protocol version and type 1350 fields match the current version and KRB_SAFE, respectively. A mismatch 1351 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1352 application verifies that the checksum used is a collision-proof keyed 1353 checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If 1354 the sender's address was included in the control information, the recipient 1355 verifies that the operating system's report of the sender's address matches 1356 the sender's address in the message, and (if a recipient address is 1357 specified or the recipient requires an address) that one of the recipient's 1358 addresses appears as the recipient's address in the message. A failed match 1359 for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and 1360 usec and/or the sequence number fields are checked. If timestamp and usec 1361 are expected and not present, or they are present but not current, the 1362 KRB_AP_ERR_SKEW error is generated. If the server name, along with the 1363 client name, time and microsecond fields from the Authenticator match any 1364 recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT 1365 error is generated. If an incorrect sequence number is included, or a 1366 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error 1367 is generated. If neither a time-stamp and usec or a sequence number is 1368 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is 1369 computed over the data and control information, and if it doesn't match the 1370 received checksum, a KRB_AP_ERR_MODIFIED error is generated. 1372 If all the checks succeed, the application is assured that the message was 1373 generated by its peer and was not modi- fied in transit. 1375 3.5. The KRB_PRIV Exchange 1377 The KRB_PRIV message may be used by clients requiring confidentiality and 1378 the ability to detect modifications of exchanged messages. It achieves this 1379 by encrypting the messages and adding control information. 1381 3.5.1. Generation of a KRB_PRIV message 1383 When an application wishes to send a KRB_PRIV message, it collects its data 1384 and the appropriate control information (specified in section 5.7.1) and 1385 encrypts them under an encryption key (usually the last key negotiated via 1386 subkeys, or the session key if no negotiation has occured). As part of the 1387 control information, the client must choose to use either a timestamp or a 1388 sequence number (or both); see the discussion in section 3.4.1 for 1389 guidelines on which to use. After the user data and control information are 1390 encrypted, the client transmits the ciphertext and some 'envelope' 1391 information to the recipient. 1393 3.5.2. Receipt of KRB_PRIV message 1395 When an application receives a KRB_PRIV message, it verifies it as follows. 1396 If any error occurs, an error code is reported for use by the application. 1398 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1399 The message is first checked by verifying that the protocol version and type 1400 fields match the current version and KRB_PRIV, respectively. A mismatch 1401 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1402 application then decrypts the ciphertext and processes the resultant 1403 plaintext. If decryption shows the data to have been modified, a 1404 KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was 1405 included in the control information, the recipient verifies that the 1406 operating system's report of the sender's address matches the sender's 1407 address in the message, and (if a recipient address is specified or the 1408 recipient requires an address) that one of the recipient's addresses appears 1409 as the recipient's address in the message. A failed match for either case 1410 generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1411 sequence number fields are checked. If timestamp and usec are expected and 1412 not present, or they are present but not current, the KRB_AP_ERR_SKEW error 1413 is generated. If the server name, along with the client name, time and 1414 microsecond fields from the Authenticator match any recently-seen such 1415 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 1416 number is included, or a sequence number is expected but not present, the 1417 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1418 a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1420 If all the checks succeed, the application can assume the message was 1421 generated by its peer, and was securely transmitted (without intruders able 1422 to see the unencrypted contents). 1424 3.6. The KRB_CRED Exchange 1426 The KRB_CRED message may be used by clients requiring the ability to send 1427 Kerberos credentials from one host to another. It achieves this by sending 1428 the tickets together with encrypted data containing the session keys and 1429 other information associated with the tickets. 1431 3.6.1. Generation of a KRB_CRED message 1433 When an application wishes to send a KRB_CRED message it first (using the 1434 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1435 constructs a KRB_CRED message using the ticket or tickets so obtained, 1436 placing the session key needed to use each ticket in the key field of the 1437 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1438 message. 1440 Other information associated with each ticket and obtained during the 1441 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1442 the encrypted part of the KRB_CRED message. The current time and, if 1443 specifically required by the application the nonce, s-address, and r-address 1444 fields, are placed in the encrypted part of the KRB_CRED message which is 1445 then encrypted under an encryption key previosuly exchanged in the KRB_AP 1446 exchange (usually the last key negotiated via subkeys, or the session key if 1447 no negotiation has occured). 1449 3.6.2. Receipt of KRB_CRED message 1451 When an application receives a KRB_CRED message, it verifies it. If any 1452 error occurs, an error code is reported for use by the application. The 1453 message is verified by checking that the protocol version and type fields 1454 match the current version and KRB_CRED, respectively. A mismatch generates a 1455 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1456 decrypts the ciphertext and processes the resultant plaintext. If decryption 1457 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1459 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1460 generated. 1462 If present or required, the recipient verifies that the operating system's 1463 report of the sender's address matches the sender's address in the message, 1464 and that one of the recipient's addresses appears as the recipient's address 1465 in the message. A failed match for either case generates a 1466 KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field 1467 if required) are checked next. If the timestamp and usec are not present, or 1468 they are present but not current, the KRB_AP_ERR_SKEW error is generated. 1470 If all the checks succeed, the application stores each of the new tickets in 1471 its ticket cache together with the session key and other information in the 1472 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1473 message. 1475 4. The Kerberos Database 1477 The Kerberos server must have access to a database containing the principal 1478 identifiers and secret keys of principals to be authenticated[21]. 1480 4.1. Database contents 1482 A database entry should contain at least the following fields: 1484 Field Value 1486 name Principal's identifier 1487 key Principal's secret key 1488 p_kvno Principal's key version 1489 max_life Maximum lifetime for Tickets 1490 max_renewable_life Maximum total lifetime for renewable Tickets 1492 The name field is an encoding of the principal's identifier. The key field 1493 contains an encryption key. This key is the principal's secret key. (The key 1494 can be encrypted before storage under a Kerberos "master key" to protect it 1495 in case the database is compromised but the master key is not. In that case, 1496 an extra field must be added to indicate the master key version used, see 1497 below.) The p_kvno field is the key version number of the principal's secret 1498 key. The max_life field contains the maximum allowable lifetime (endtime - 1499 starttime) for any Ticket issued for this principal. The max_renewable_life 1500 field contains the maximum allowable total lifetime for any renewable Ticket 1501 issued for this principal. (See section 3.1 for a description of how these 1502 lifetimes are used in determining the lifetime of a given Ticket.) 1504 A server may provide KDC service to several realms, as long as the database 1505 representation provides a mechanism to distinguish between principal records 1506 with identifiers which differ only in the realm name. 1508 When an application server's key changes, if the change is routine (i.e. not 1509 the result of disclosure of the old key), the old key should be retained by 1510 the server until all tickets that had been issued using that key have 1511 expired. Because of this, it is possible for several keys to be active for a 1512 single principal. Ciphertext encrypted in a principal's key is always tagged 1513 with the version of the key that was used for encryption, to help the 1514 recipient find the proper key for decryption. 1516 When more than one key is active for a particular principal, the principal 1517 will have more than one record in the Kerberos database. The keys and key 1518 version numbers will differ between the records (the rest of the fields may 1520 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1521 or may not be the same). Whenever Kerberos issues a ticket, or responds to a 1522 request for initial authentication, the most recent key (known by the 1523 Kerberos server) will be used for encryption. This is the key with the 1524 highest key version number. 1526 4.2. Additional fields 1528 Project Athena's KDC implementation uses additional fields in its database: 1530 Field Value 1532 K_kvno Kerberos' key version 1533 expiration Expiration date for entry 1534 attributes Bit field of attributes 1535 mod_date Timestamp of last modification 1536 mod_name Modifying principal's identifier 1538 The K_kvno field indicates the key version of the Kerberos master key under 1539 which the principal's secret key is encrypted. 1541 After an entry's expiration date has passed, the KDC will return an error to 1542 any client attempting to gain tickets as or for the principal. (A database 1543 may want to maintain two expiration dates: one for the principal, and one 1544 for the principal's current key. This allows password aging to work 1545 independently of the principal's expiration date. However, due to the 1546 limited space in the responses, the KDC must combine the key expiration and 1547 principal expiration date into a single value called 'key_exp', which is 1548 used as a hint to the user to take administrative action.) 1550 The attributes field is a bitfield used to govern the operations involving 1551 the principal. This field might be useful in conjunction with user 1552 registration procedures, for site-specific policy implementations (Project 1553 Athena currently uses it for their user registration process controlled by 1554 the system-wide database service, Moira [LGDSR87]), to identify whether a 1555 principal can play the role of a client or server or both, to note whether a 1556 server is appropriate trusted to recieve credentials delegated by a client, 1557 or to identify the 'string to key' conversion algorithm used for a 1558 principal's key[22]. Other bits are used to indicate that certain ticket 1559 options should not be allowed in tickets encrypted under a principal's key 1560 (one bit each): Disallow issuing postdated tickets, disallow issuing 1561 forwardable tickets, disallow issuing tickets based on TGT authentication, 1562 disallow issuing renewable tickets, disallow issuing proxiable tickets, and 1563 disallow issuing tickets for which the principal is the server. 1565 The mod_date field contains the time of last modification of the entry, and 1566 the mod_name field contains the name of the principal which last modified 1567 the entry. 1569 4.3. Frequently Changing Fields 1571 Some KDC implementations may wish to maintain the last time that a request 1572 was made by a particular principal. Information that might be maintained 1573 includes the time of the last request, the time of the last request for a 1574 ticket-granting ticket, the time of the last use of a ticket-granting 1575 ticket, or other times. This information can then be returned to the user in 1576 the last-req field (see section 5.2). 1578 Other frequently changing information that can be maintained is the latest 1579 expiration time for any tickets that have been issued using each key. This 1581 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1582 field would be used to indicate how long old keys must remain valid to allow 1583 the continued use of outstanding tickets. 1585 4.4. Site Constants 1587 The KDC implementation should have the following configurable constants or 1588 options, to allow an administrator to make and enforce policy decisions: 1590 * The minimum supported lifetime (used to determine whether the 1591 KDC_ERR_NEVER_VALID error should be returned). This constant should 1592 reflect reasonable expectations of round-trip time to the KDC, 1593 encryption/decryption time, and processing time by the client and 1594 target server, and it should allow for a minimum 'useful' lifetime. 1595 * The maximum allowable total (renewable) lifetime of a ticket 1596 (renew_till - starttime). 1597 * The maximum allowable lifetime of a ticket (endtime - starttime). 1598 * Whether to allow the issue of tickets with empty address fields 1599 (including the ability to specify that such tickets may only be issued 1600 if the request specifies some authorization_data). 1601 * Whether proxiable, forwardable, renewable or post-datable tickets are 1602 to be issued. 1604 5. Message Specifications 1606 The following sections describe the exact contents and encoding of protocol 1607 messages and objects. The ASN.1 base definitions are presented in the first 1608 subsection. The remaining subsections specify the protocol objects (tickets 1609 and authenticators) and messages. Specification of encryption and checksum 1610 techniques, and the fields related to them, appear in section 6. 1612 Optional field in ASN.1 sequences 1614 For optional integer value and date fields in ASN.1 sequences where a 1615 default value has been specified, certain default values will not be allowed 1616 in the encoding because these values will always be represented through 1617 defaulting by the absence of the optional field. For example, one will not 1618 send a microsecond zero value because one must make sure that there is only 1619 one way to encode this value. 1621 Additional fields in ASN.1 sequences 1623 Implementations receiving Kerberos messages with additional fields present 1624 in ASN.1 sequences should carry the those fields through, unmodified, when 1625 the message is forwarded. Implementations should not drop such fields if the 1626 sequence is reencoded. 1628 5.1. ASN.1 Distinguished Encoding Representation 1630 All uses of ASN.1 in Kerberos shall use the Distinguished Encoding 1631 Representation of the data elements as described in the X.509 specification, 1632 section 8.7 [X509-88]. 1634 5.3. ASN.1 Base Definitions 1636 The following ASN.1 base definitions are used in the rest of this section. 1637 Note that since the underscore character (_) is not permitted in ASN.1 1638 names, the hyphen (-) is used in its place for the purposes of ASN.1 names. 1640 Realm ::= GeneralString 1642 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1643 PrincipalName ::= SEQUENCE { 1644 name-type[0] INTEGER, 1645 name-string[1] SEQUENCE OF GeneralString 1646 } 1648 Kerberos realms are encoded as GeneralStrings. Realms shall not contain a 1649 character with the code 0 (the ASCII NUL). Most realms will usually consist 1650 of several components separated by periods (.), in the style of Internet 1651 Domain Names, or separated by slashes (/) in the style of X.500 names. 1652 Acceptable forms for realm names are specified in section 7. A PrincipalName 1653 is a typed sequence of components consisting of the following sub-fields: 1655 name-type 1656 This field specifies the type of name that follows. Pre-defined values 1657 for this field are specified in section 7.2. The name-type should be 1658 treated as a hint. Ignoring the name type, no two names can be the same 1659 (i.e. at least one of the components, or the realm, must be different). 1660 This constraint may be eliminated in the future. 1661 name-string 1662 This field encodes a sequence of components that form a name, each 1663 component encoded as a GeneralString. Taken together, a PrincipalName 1664 and a Realm form a principal identifier. Most PrincipalNames will have 1665 only a few components (typically one or two). 1667 KerberosTime ::= GeneralizedTime 1668 -- Specifying UTC time zone (Z) 1670 The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding 1671 shall specify the UTC time zone (Z) and shall not include any fractional 1672 portions of the seconds. It further shall not include any separators. 1673 Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm 1674 on 6 November 1985 is 19851106210627Z. 1676 HostAddress ::= SEQUENCE { 1677 addr-type[0] INTEGER, 1678 address[1] OCTET STRING 1679 } 1681 HostAddresses ::= SEQUENCE OF HostAddress 1683 The host adddress encodings consists of two fields: 1685 addr-type 1686 This field specifies the type of address that follows. Pre-defined 1687 values for this field are specified in section 8.1. 1688 address 1689 This field encodes a single address of type addr-type. 1691 The two forms differ slightly. HostAddress contains exactly one address; 1692 HostAddresses contains a sequence of possibly many addresses. 1694 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1695 ad-type[0] INTEGER, 1696 ad-data[1] OCTET STRING 1697 } 1699 ad-data 1700 This field contains authorization data to be interpreted according to 1701 the value of the corresponding ad-type field. 1703 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1704 ad-type 1705 This field specifies the format for the ad-data subfield. All negative 1706 values are reserved for local use. Non-negative values are reserved for 1707 registered use. 1709 Each sequence of type and data is refered to as an authorization element. 1710 Elements may be application specific, however, there is a common set of 1711 recursive elements that should be understood by all implementations. These 1712 elements contain other elements embedded within them, and the interpretation 1713 of the encapsulating element determines which of the embedded elements must 1714 be interpreted, and which may be ignored. Definitions for these common 1715 elements may be found in Appendix B. 1717 TicketExtensions ::= SEQUENCE OF SEQUENCE { 1718 te-type[0] INTEGER, 1719 te-data[1] OCTET STRING 1720 } 1722 te-data 1723 This field contains opaque data that must be caried with the ticket to 1724 support extensions to the Kerberos protocol including but not limited 1725 to some forms of inter-realm key exchange and plaintext authorization 1726 data. See appendix C for some common uses of this field. 1727 te-type 1728 This field specifies the format for the te-data subfield. All negative 1729 values are reserved for local use. Non-negative values are reserved for 1730 registered use. 1732 APOptions ::= BIT STRING 1733 -- reserved(0), 1734 -- use-session-key(1), 1735 -- mutual-required(2) 1737 TicketFlags ::= BIT STRING 1738 -- reserved(0), 1739 -- forwardable(1), 1740 -- forwarded(2), 1741 -- proxiable(3), 1742 -- proxy(4), 1743 -- may-postdate(5), 1744 -- postdated(6), 1745 -- invalid(7), 1746 -- renewable(8), 1747 -- initial(9), 1748 -- pre-authent(10), 1749 -- hw-authent(11), 1750 -- transited-policy-checked(12), 1751 -- ok-as-delegate(13) 1753 KDCOptions ::= BIT STRING 1754 -- reserved(0), 1755 -- forwardable(1), 1756 -- forwarded(2), 1757 -- proxiable(3), 1758 -- proxy(4), 1759 -- allow-postdate(5), 1760 -- postdated(6), 1762 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1763 -- unused7(7), 1764 -- renewable(8), 1765 -- unused9(9), 1766 -- unused10(10), 1767 -- unused11(11), 1768 -- unused12(12), 1769 -- unused13(13), 1770 -- disable-transited-check(26), 1771 -- renewable-ok(27), 1772 -- enc-tkt-in-skey(28), 1773 -- renew(30), 1774 -- validate(31) 1776 ASN.1 Bit strings have a length and a value. When used in Kerberos for the 1777 APOptions, TicketFlags, and KDCOptions, the length of the bit string on 1778 generated values should be the smallest number of bits needed to include the 1779 highest order bit that is set (1), but in no case less than 32 bits. The 1780 ASN.1 representation of the bit strings uses unnamed bits, with the meaning 1781 of the individual bits defined by the comments in the specification above. 1782 Implementations should accept values of bit strings of any length and treat 1783 the value of flags corresponding to bits beyond the end of the bit string as 1784 if the bit were reset (0). Comparison of bit strings of different length 1785 should treat the smaller string as if it were padded with zeros beyond the 1786 high order bits to the length of the longer string[23]. 1788 LastReq ::= SEQUENCE OF SEQUENCE { 1789 lr-type[0] INTEGER, 1790 lr-value[1] KerberosTime 1791 } 1793 lr-type 1794 This field indicates how the following lr-value field is to be 1795 interpreted. Negative values indicate that the information pertains 1796 only to the responding server. Non-negative values pertain to all 1797 servers for the realm. If the lr-type field is zero (0), then no 1798 information is conveyed by the lr-value subfield. If the absolute value 1799 of the lr-type field is one (1), then the lr-value subfield is the time 1800 of last initial request for a TGT. If it is two (2), then the lr-value 1801 subfield is the time of last initial request. If it is three (3), then 1802 the lr-value subfield is the time of issue for the newest 1803 ticket-granting ticket used. If it is four (4), then the lr-value 1804 subfield is the time of the last renewal. If it is five (5), then the 1805 lr-value subfield is the time of last request (of any type). If it is 1806 (6), then the lr-value subfield is the time when the password will 1807 expire. 1808 lr-value 1809 This field contains the time of the last request. the time must be 1810 interpreted according to the contents of the accompanying lr-type 1811 subfield. 1813 See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, 1814 EncryptionKey, EncryptionType, and KeyType. 1816 5.3. Tickets and Authenticators 1818 This section describes the format and encryption parameters for tickets and 1819 authenticators. When a ticket or authenticator is included in a protocol 1820 message it is treated as an opaque object. 1822 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1823 5.3.1. Tickets 1825 A ticket is a record that helps a client authenticate to a service. A Ticket 1826 contains the following information: 1828 Ticket ::= [APPLICATION 1] SEQUENCE { 1829 tkt-vno[0] INTEGER, 1830 realm[1] Realm, 1831 sname[2] PrincipalName, 1832 enc-part[3] EncryptedData, 1833 extensions[4] TicketExtensions OPTIONAL 1834 } 1836 -- Encrypted part of ticket 1837 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 1838 flags[0] TicketFlags, 1839 key[1] EncryptionKey, 1840 crealm[2] Realm, 1841 cname[3] PrincipalName, 1842 transited[4] TransitedEncoding, 1843 authtime[5] KerberosTime, 1844 starttime[6] KerberosTime OPTIONAL, 1845 endtime[7] KerberosTime, 1846 renew-till[8] KerberosTime OPTIONAL, 1847 caddr[9] HostAddresses OPTIONAL, 1848 authorization-data[10] AuthorizationData OPTIONAL 1849 } 1850 -- encoded Transited field 1851 TransitedEncoding ::= SEQUENCE { 1852 tr-type[0] INTEGER, -- must be registered 1853 contents[1] OCTET STRING 1854 } 1856 The encoding of EncTicketPart is encrypted in the key shared by Kerberos and 1857 the end server (the server's secret key). See section 6 for the format of 1858 the ciphertext. 1860 tkt-vno 1861 This field specifies the version number for the ticket format. This 1862 document describes version number 5. 1863 realm 1864 This field specifies the realm that issued a ticket. It also serves to 1865 identify the realm part of the server's principal identifier. Since a 1866 Kerberos server can only issue tickets for servers within its realm, 1867 the two will always be identical. 1868 sname 1869 This field specifies all components of the name part of the server's 1870 identity, including those parts that identify a specific instance of a 1871 service. 1872 enc-part 1873 This field holds the encrypted encoding of the EncTicketPart sequence. 1874 extensions 1875 This optional field contains a sequence of extentions that may be used 1876 to carry information that must be carried with the ticket to support 1877 several extensions, including but not limited to plaintext 1878 authorization data, tokens for exchanging inter-realm keys, and other 1879 information that must be associated with a ticket for use by the 1880 application server. See Appendix C for definitions of some common 1881 extensions. 1883 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1884 Note that some older versions of Kerberos did not support this field. 1885 Because this is an optional field it will not break older clients, but 1886 older clients might strip this field from the ticket before sending it 1887 to the application server. This limits the usefulness of this ticket 1888 field to environments where the ticket will not be parsed and 1889 reconstructed by these older Kerberos clients. 1891 If it is known that the client will strip this field from the ticket, 1892 as an interim measure the KDC may append this field to the end of the 1893 enc-part of the ticket and append a traler indicating the lenght of the 1894 appended extensions field. (this paragraph is open for discussion, 1895 including the form of the traler). 1896 flags 1897 This field indicates which of various options were used or requested 1898 when the ticket was issued. It is a bit-field, where the selected 1899 options are indicated by the bit being set (1), and the unselected 1900 options and reserved fields being reset (0). Bit 0 is the most 1901 significant bit. The encoding of the bits is specified in section 5.2. 1902 The flags are described in more detail above in section 2. The meanings 1903 of the flags are: 1905 Bit(s) Name Description 1907 0 RESERVED 1908 Reserved for future expansion of this 1909 field. 1911 1 FORWARDABLE 1912 The FORWARDABLE flag is normally only 1913 interpreted by the TGS, and can be 1914 ignored by end servers. When set, this 1915 flag tells the ticket-granting server 1916 that it is OK to issue a new ticket- 1917 granting ticket with a different network 1918 address based on the presented ticket. 1920 2 FORWARDED 1921 When set, this flag indicates that the 1922 ticket has either been forwarded or was 1923 issued based on authentication involving 1924 a forwarded ticket-granting ticket. 1926 3 PROXIABLE 1927 The PROXIABLE flag is normally only 1928 interpreted by the TGS, and can be 1929 ignored by end servers. The PROXIABLE 1930 flag has an interpretation identical to 1931 that of the FORWARDABLE flag, except 1932 that the PROXIABLE flag tells the 1933 ticket-granting server that only non- 1934 ticket-granting tickets may be issued 1935 with different network addresses. 1937 4 PROXY 1938 When set, this flag indicates that a 1939 ticket is a proxy. 1941 5 MAY-POSTDATE 1943 Neuman, Ts'o, Kohl Expires: 10 September, 2000 1944 The MAY-POSTDATE flag is normally only 1945 interpreted by the TGS, and can be 1946 ignored by end servers. This flag tells 1947 the ticket-granting server that a post- 1948 dated ticket may be issued based on this 1949 ticket-granting ticket. 1951 6 POSTDATED 1952 This flag indicates that this ticket has 1953 been postdated. The end-service can 1954 check the authtime field to see when the 1955 original authentication occurred. 1957 7 INVALID 1958 This flag indicates that a ticket is 1959 invalid, and it must be validated by the 1960 KDC before use. Application servers 1961 must reject tickets which have this flag 1962 set. 1964 8 RENEWABLE 1965 The RENEWABLE flag is normally only 1966 interpreted by the TGS, and can usually 1967 be ignored by end servers (some particu- 1968 larly careful servers may wish to disal- 1969 low renewable tickets). A renewable 1970 ticket can be used to obtain a replace- 1971 ment ticket that expires at a later 1972 date. 1974 9 INITIAL 1975 This flag indicates that this ticket was 1976 issued using the AS protocol, and not 1977 issued based on a ticket-granting 1978 ticket. 1980 10 PRE-AUTHENT 1981 This flag indicates that during initial 1982 authentication, the client was authenti- 1983 cated by the KDC before a ticket was 1984 issued. The strength of the pre- 1985 authentication method is not indicated, 1986 but is acceptable to the KDC. 1988 11 HW-AUTHENT 1989 This flag indicates that the protocol 1990 employed for initial authentication 1991 required the use of hardware expected to 1992 be possessed solely by the named client. 1993 The hardware authentication method is 1994 selected by the KDC and the strength of 1995 the method is not indicated. 1997 12 TRANSITED This flag indicates that the KDC for the 1998 POLICY-CHECKED realm has checked the transited field 1999 against a realm defined policy for 2000 trusted certifiers. If this flag is 2001 reset (0), then the application server 2002 must check the transited field itself, 2004 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2005 and if unable to do so it must reject 2006 the authentication. If the flag is set 2007 (1) then the application server may skip 2008 its own validation of the transited 2009 field, relying on the validation 2010 performed by the KDC. At its option the 2011 application server may still apply its 2012 own validation based on a separate 2013 policy for acceptance. 2015 13 OK-AS-DELEGATE This flag indicates that the server (not 2016 the client) specified in the ticket has 2017 been determined by policy of the realm 2018 to be a suitable recipient of 2019 delegation. A client can use the 2020 presence of this flag to help it make a 2021 decision whether to delegate credentials 2022 (either grant a proxy or a forwarded 2023 ticket granting ticket) to this server. 2024 The client is free to ignore the value 2025 of this flag. When setting this flag, 2026 an administrator should consider the 2027 Security and placement of the server on 2028 which the service will run, as well as 2029 whether the service requires the use of 2030 delegated credentials. 2032 14 ANONYMOUS 2033 This flag indicates that the principal 2034 named in the ticket is a generic princi- 2035 pal for the realm and does not identify 2036 the individual using the ticket. The 2037 purpose of the ticket is only to 2038 securely distribute a session key, and 2039 not to identify the user. Subsequent 2040 requests using the same ticket and ses- 2041 sion may be considered as originating 2042 from the same user, but requests with 2043 the same username but a different ticket 2044 are likely to originate from different 2045 users. 2047 15-31 RESERVED 2048 Reserved for future use. 2050 key 2051 This field exists in the ticket and the KDC response and is used to 2052 pass the session key from Kerberos to the application server and the 2053 client. The field's encoding is described in section 6.2. 2054 crealm 2055 This field contains the name of the realm in which the client is 2056 registered and in which initial authentication took place. 2057 cname 2058 This field contains the name part of the client's principal identifier. 2059 transited 2060 This field lists the names of the Kerberos realms that took part in 2061 authenticating the user to whom this ticket was issued. It does not 2062 specify the order in which the realms were transited. See section 2063 3.3.3.2 for details on how this field encodes the traversed realms. 2065 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2066 When the names of CA's are to be embedded inthe transited field (as 2067 specified for some extentions to the protocol), the X.500 names of the 2068 CA's should be mapped into items in the transited field using the 2069 mapping defined by RFC2253. 2070 authtime 2071 This field indicates the time of initial authentication for the named 2072 principal. It is the time of issue for the original ticket on which 2073 this ticket is based. It is included in the ticket to provide 2074 additional information to the end service, and to provide the necessary 2075 information for implementation of a `hot list' service at the KDC. An 2076 end service that is particularly paranoid could refuse to accept 2077 tickets for which the initial authentication occurred "too far" in the 2078 past. This field is also returned as part of the response from the KDC. 2079 When returned as part of the response to initial authentication 2080 (KRB_AS_REP), this is the current time on the Kerberos server[24]. 2081 starttime 2082 This field in the ticket specifies the time after which the ticket is 2083 valid. Together with endtime, this field specifies the life of the 2084 ticket. If it is absent from the ticket, its value should be treated as 2085 that of the authtime field. 2086 endtime 2087 This field contains the time after which the ticket will not be honored 2088 (its expiration time). Note that individual services may place their 2089 own limits on the life of a ticket and may reject tickets which have 2090 not yet expired. As such, this is really an upper bound on the 2091 expiration time for the ticket. 2092 renew-till 2093 This field is only present in tickets that have the RENEWABLE flag set 2094 in the flags field. It indicates the maximum endtime that may be 2095 included in a renewal. It can be thought of as the absolute expiration 2096 time for the ticket, including all renewals. 2097 caddr 2098 This field in a ticket contains zero (if omitted) or more (if present) 2099 host addresses. These are the addresses from which the ticket can be 2100 used. If there are no addresses, the ticket can be used from any 2101 location. The decision by the KDC to issue or by the end server to 2102 accept zero-address tickets is a policy decision and is left to the 2103 Kerberos and end-service administrators; they may refuse to issue or 2104 accept such tickets. The suggested and default policy, however, is that 2105 such tickets will only be issued or accepted when additional 2106 information that can be used to restrict the use of the ticket is 2107 included in the authorization_data field. Such a ticket is a 2108 capability. 2110 Network addresses are included in the ticket to make it harder for an 2111 attacker to use stolen credentials. Because the session key is not sent 2112 over the network in cleartext, credentials can't be stolen simply by 2113 listening to the network; an attacker has to gain access to the session 2114 key (perhaps through operating system security breaches or a careless 2115 user's unattended session) to make use of stolen tickets. 2117 It is important to note that the network address from which a 2118 connection is received cannot be reliably determined. Even if it could 2119 be, an attacker who has compromised the client's workstation could use 2120 the credentials from there. Including the network addresses only makes 2121 it more difficult, not impossible, for an attacker to walk off with 2122 stolen credentials and then use them from a "safe" location. 2123 authorization-data 2124 The authorization-data field is used to pass authorization data from 2126 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2127 the principal on whose behalf a ticket was issued to the application 2128 service. If no authorization data is included, this field will be left 2129 out. Experience has shown that the name of this field is confusing, and 2130 that a better name for this field would be restrictions. Unfortunately, 2131 it is not possible to change the name of this field at this time. 2133 This field contains restrictions on any authority obtained on the basis 2134 of authentication using the ticket. It is possible for any principal in 2135 posession of credentials to add entries to the authorization data field 2136 since these entries further restrict what can be done with the ticket. 2137 Such additions can be made by specifying the additional entries when a 2138 new ticket is obtained during the TGS exchange, or they may be added 2139 during chained delegation using the authorization data field of the 2140 authenticator. 2142 Because entries may be added to this field by the holder of 2143 credentials, except when an entry is separately authenticated by 2144 encapulation in the kdc-issued element, it is not allowable for the 2145 presence of an entry in the authorization data field of a ticket to 2146 amplify the priveleges one would obtain from using a ticket. 2148 The data in this field may be specific to the end service; the field 2149 will contain the names of service specific objects, and the rights to 2150 those objects. The format for this field is described in section 5.2. 2151 Although Kerberos is not concerned with the format of the contents of 2152 the sub-fields, it does carry type information (ad-type). 2154 By using the authorization_data field, a principal is able to issue a 2155 proxy that is valid for a specific purpose. For example, a client 2156 wishing to print a file can obtain a file server proxy to be passed to 2157 the print server. By specifying the name of the file in the 2158 authorization_data field, the file server knows that the print server 2159 can only use the client's rights when accessing the particular file to 2160 be printed. 2162 A separate service providing authorization or certifying group 2163 membership may be built using the authorization-data field. In this 2164 case, the entity granting authorization (not the authorized entity), 2165 may obtain a ticket in its own name (e.g. the ticket is issued in the 2166 name of a privelege server), and this entity adds restrictions on its 2167 own authority and delegates the restricted authority through a proxy to 2168 the client. The client would then present this authorization credential 2169 to the application server separately from the authentication exchange. 2170 Alternatively, such authorization credentials may be embedded in the 2171 ticket authenticating the authorized entity, when the authorization is 2172 separately authenticated using the kdc-issued authorization data 2173 element (see B.4). 2175 Similarly, if one specifies the authorization-data field of a proxy and 2176 leaves the host addresses blank, the resulting ticket and session key 2177 can be treated as a capability. See [Neu93] for some suggested uses of 2178 this field. 2180 The authorization-data field is optional and does not have to be 2181 included in a ticket. 2183 5.3.2. Authenticators 2185 An authenticator is a record sent with a ticket to a server to certify the 2187 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2188 client's knowledge of the encryption key in the ticket, to help the server 2189 detect replays, and to help choose a "true session key" to use with the 2190 particular session. The encoding is encrypted in the ticket's session key 2191 shared by the client and the server: 2193 -- Unencrypted authenticator 2194 Authenticator ::= [APPLICATION 2] SEQUENCE { 2195 authenticator-vno[0] INTEGER, 2196 crealm[1] Realm, 2197 cname[2] PrincipalName, 2198 cksum[3] Checksum OPTIONAL, 2199 cusec[4] INTEGER, 2200 ctime[5] KerberosTime, 2201 subkey[6] EncryptionKey OPTIONAL, 2202 seq-number[7] INTEGER OPTIONAL, 2203 authorization-data[8] AuthorizationData OPTIONAL 2204 } 2206 authenticator-vno 2207 This field specifies the version number for the format of the 2208 authenticator. This document specifies version 5. 2209 crealm and cname 2210 These fields are the same as those described for the ticket in section 2211 5.3.1. 2212 cksum 2213 This field contains a checksum of the the applica- tion data that 2214 accompanies the KRB_AP_REQ. 2215 cusec 2216 This field contains the microsecond part of the client's timestamp. Its 2217 value (before encryption) ranges from 0 to 999999. It often appears 2218 along with ctime. The two fields are used together to specify a 2219 reasonably accurate timestamp. 2220 ctime 2221 This field contains the current time on the client's host. 2222 subkey 2223 This field contains the client's choice for an encryption key which is 2224 to be used to protect this specific application session. Unless an 2225 application specifies otherwise, if this field is left out the session 2226 key from the ticket will be used. 2227 seq-number 2228 This optional field includes the initial sequence number to be used by 2229 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 2230 detect replays (It may also be used by application specific messages). 2231 When included in the authenticator this field specifies the initial 2232 sequence number for messages from the client to the server. When 2233 included in the AP-REP message, the initial sequence number is that for 2234 messages from the server to the client. When used in KRB_PRIV or 2235 KRB_SAFE messages, it is incremented by one after each message is sent. 2236 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to 2237 zero following the value 2^32 - 1. 2239 For sequence numbers to adequately support the detection of replays 2240 they should be non-repeating, even across connection boundaries. The 2241 initial sequence number should be random and uniformly distributed 2242 across the full space of possible sequence numbers, so that it cannot 2243 be guessed by an attacker and so that it and the successive sequence 2244 numbers do not repeat other sequences. 2245 authorization-data 2247 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2248 This field is the same as described for the ticket in section 5.3.1. It 2249 is optional and will only appear when additional restrictions are to be 2250 placed on the use of a ticket, beyond those carried in the ticket 2251 itself. 2253 5.4. Specifications for the AS and TGS exchanges 2255 This section specifies the format of the messages used in the exchange 2256 between the client and the Kerberos server. The format of possible error 2257 messages appears in section 5.9.1. 2259 5.4.1. KRB_KDC_REQ definition 2261 The KRB_KDC_REQ message has no type of its own. Instead, its type is one of 2262 KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial 2263 ticket or an additional ticket. In either case, the message is sent from the 2264 client to the Authentication Server to request credentials for a service. 2266 The message fields are: 2268 AS-REQ ::= [APPLICATION 10] KDC-REQ 2269 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2271 KDC-REQ ::= SEQUENCE { 2272 pvno[1] INTEGER, 2273 msg-type[2] INTEGER, 2274 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2275 req-body[4] KDC-REQ-BODY 2276 } 2278 PA-DATA ::= SEQUENCE { 2279 padata-type[1] INTEGER, 2280 padata-value[2] OCTET STRING, 2281 -- might be encoded AP-REQ 2282 } 2284 KDC-REQ-BODY ::= SEQUENCE { 2285 kdc-options[0] KDCOptions, 2286 cname[1] PrincipalName OPTIONAL, 2287 -- Used only in AS-REQ 2288 realm[2] Realm, -- Server's realm 2289 -- Also client's in AS-REQ 2290 sname[3] PrincipalName OPTIONAL, 2291 from[4] KerberosTime OPTIONAL, 2292 till[5] KerberosTime OPTIONAL, 2293 rtime[6] KerberosTime OPTIONAL, 2294 nonce[7] INTEGER, 2295 etype[8] SEQUENCE OF INTEGER, 2296 -- EncryptionType, 2297 -- in preference order 2298 addresses[9] HostAddresses OPTIONAL, 2299 enc-authorization-data[10] EncryptedData OPTIONAL, 2300 -- Encrypted AuthorizationData 2301 -- encoding 2302 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2303 } 2305 The fields in this message are: 2307 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2308 pvno 2309 This field is included in each message, and specifies the protocol 2310 version number. This document specifies protocol version 5. 2311 msg-type 2312 This field indicates the type of a protocol message. It will almost 2313 always be the same as the application identifier associated with a 2314 message. It is included to make the identifier more readily accessible 2315 to the application. For the KDC-REQ message, this type will be 2316 KRB_AS_REQ or KRB_TGS_REQ. 2317 padata 2318 The padata (pre-authentication data) field contains a sequence of 2319 authentication information which may be needed before credentials can 2320 be issued or decrypted. In the case of requests for additional tickets 2321 (KRB_TGS_REQ), this field will include an element with padata-type of 2322 PA-TGS-REQ and data of an authentication header (ticket-granting ticket 2323 and authenticator). The checksum in the authenticator (which must be 2324 collision-proof) is to be computed over the KDC-REQ-BODY encoding. In 2325 most requests for initial authentication (KRB_AS_REQ) and most replies 2326 (KDC-REP), the padata field will be left out. 2328 This field may also contain information needed by certain extensions to 2329 the Kerberos protocol. For example, it might be used to initially 2330 verify the identity of a client before any response is returned. This 2331 is accomplished with a padata field with padata-type equal to 2332 PA-ENC-TIMESTAMP and padata-value defined as follows: 2334 padata-type ::= PA-ENC-TIMESTAMP 2335 padata-value ::= EncryptedData -- PA-ENC-TS-ENC 2337 PA-ENC-TS-ENC ::= SEQUENCE { 2338 patimestamp[0] KerberosTime, -- client's time 2339 pausec[1] INTEGER OPTIONAL 2340 } 2342 with patimestamp containing the client's time and pausec containing the 2343 microseconds which may be omitted if a client will not generate more 2344 than one request per second. The ciphertext (padata-value) consists of 2345 the PA-ENC-TS-ENC sequence, encrypted using the client's secret key. 2347 [use-specified-kvno item is here for discussion and may be removed] It 2348 may also be used by the client to specify the version of a key that is 2349 being used for accompanying preauthentication, and/or which should be 2350 used to encrypt the reply from the KDC. 2352 PA-USE-SPECIFIED-KVNO ::= Integer 2354 The KDC should only accept and abide by the value of the 2355 use-specified-kvno preauthentication data field when the specified key 2356 is still valid and until use of a new key is confirmed. This situation 2357 is likely to occur primarily during the period during which an updated 2358 key is propagating to other KDC's in a realm. 2360 The padata field can also contain information needed to help the KDC or 2361 the client select the key needed for generating or decrypting the 2362 response. This form of the padata is useful for supporting the use of 2363 certain token cards with Kerberos. The details of such extensions are 2364 specified in separate documents. See [Pat92] for additional uses of 2365 this field. 2366 padata-type 2368 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2369 The padata-type element of the padata field indicates the way that the 2370 padata-value element is to be interpreted. Negative values of 2371 padata-type are reserved for unregistered use; non-negative values are 2372 used for a registered interpretation of the element type. 2373 req-body 2374 This field is a placeholder delimiting the extent of the remaining 2375 fields. If a checksum is to be calculated over the request, it is 2376 calculated over an encoding of the KDC-REQ-BODY sequence which is 2377 enclosed within the req-body field. 2378 kdc-options 2379 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2380 KDC and indicates the flags that the client wants set on the tickets as 2381 well as other information that is to modify the behavior of the KDC. 2382 Where appropriate, the name of an option may be the same as the flag 2383 that is set by that option. Although in most case, the bit in the 2384 options field will be the same as that in the flags field, this is not 2385 guaranteed, so it is not acceptable to simply copy the options field to 2386 the flags field. There are various checks that must be made before 2387 honoring an option anyway. 2389 The kdc_options field is a bit-field, where the selected options are 2390 indicated by the bit being set (1), and the unselected options and 2391 reserved fields being reset (0). The encoding of the bits is specified 2392 in section 5.2. The options are described in more detail above in 2393 section 2. The meanings of the options are: 2395 Bit(s) Name Description 2396 0 RESERVED 2397 Reserved for future expansion of this 2398 field. 2400 1 FORWARDABLE 2401 The FORWARDABLE option indicates that 2402 the ticket to be issued is to have its 2403 forwardable flag set. It may only be 2404 set on the initial request, or in a sub- 2405 sequent request if the ticket-granting 2406 ticket on which it is based is also for- 2407 wardable. 2409 2 FORWARDED 2410 The FORWARDED option is only specified 2411 in a request to the ticket-granting 2412 server and will only be honored if the 2413 ticket-granting ticket in the request 2414 has its FORWARDABLE bit set. This 2415 option indicates that this is a request 2416 for forwarding. The address(es) of the 2417 host from which the resulting ticket is 2418 to be valid are included in the 2419 addresses field of the request. 2421 3 PROXIABLE 2422 The PROXIABLE option indicates that the 2423 ticket to be issued is to have its prox- 2424 iable flag set. It may only be set on 2425 the initial request, or in a subsequent 2426 request if the ticket-granting ticket on 2427 which it is based is also proxiable. 2429 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2430 4 PROXY 2431 The PROXY option indicates that this is 2432 a request for a proxy. This option will 2433 only be honored if the ticket-granting 2434 ticket in the request has its PROXIABLE 2435 bit set. The address(es) of the host 2436 from which the resulting ticket is to be 2437 valid are included in the addresses 2438 field of the request. 2440 5 ALLOW-POSTDATE 2441 The ALLOW-POSTDATE option indicates that 2442 the ticket to be issued is to have its 2443 MAY-POSTDATE flag set. It may only be 2444 set on the initial request, or in a sub- 2445 sequent request if the ticket-granting 2446 ticket on which it is based also has its 2447 MAY-POSTDATE flag set. 2449 6 POSTDATED 2450 The POSTDATED option indicates that this 2451 is a request for a postdated ticket. 2452 This option will only be honored if the 2453 ticket-granting ticket on which it is 2454 based has its MAY-POSTDATE flag set. 2455 The resulting ticket will also have its 2456 INVALID flag set, and that flag may be 2457 reset by a subsequent request to the KDC 2458 after the starttime in the ticket has 2459 been reached. 2461 7 UNUSED 2462 This option is presently unused. 2464 8 RENEWABLE 2465 The RENEWABLE option indicates that the 2466 ticket to be issued is to have its 2467 RENEWABLE flag set. It may only be set 2468 on the initial request, or when the 2469 ticket-granting ticket on which the 2470 request is based is also renewable. If 2471 this option is requested, then the rtime 2472 field in the request contains the 2473 desired absolute expiration time for the 2474 ticket. 2476 9-13 UNUSED 2477 These options are presently unused. 2479 14 REQUEST-ANONYMOUS 2480 The REQUEST-ANONYMOUS option indicates 2481 that the ticket to be issued is not to 2482 identify the user to which it was 2483 issued. Instead, the principal identif- 2484 ier is to be generic, as specified by 2485 the policy of the realm (e.g. usually 2486 anonymous@realm). The purpose of the 2487 ticket is only to securely distribute a 2489 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2490 session key, and not to identify the 2491 user. The ANONYMOUS flag on the ticket 2492 to be returned should be set. If the 2493 local realms policy does not permit 2494 anonymous credentials, the request is to 2495 be rejected. 2497 15-25 RESERVED 2498 Reserved for future use. 2500 26 DISABLE-TRANSITED-CHECK 2501 By default the KDC will check the 2502 transited field of a ticket-granting- 2503 ticket against the policy of the local 2504 realm before it will issue derivative 2505 tickets based on the ticket granting 2506 ticket. If this flag is set in the 2507 request, checking of the transited field 2508 is disabled. Tickets issued without the 2509 performance of this check will be noted 2510 by the reset (0) value of the 2511 TRANSITED-POLICY-CHECKED flag, 2512 indicating to the application server 2513 that the tranisted field must be checked 2514 locally. KDC's are encouraged but not 2515 required to honor the 2516 DISABLE-TRANSITED-CHECK option. 2518 27 RENEWABLE-OK 2519 The RENEWABLE-OK option indicates that a 2520 renewable ticket will be acceptable if a 2521 ticket with the requested life cannot 2522 otherwise be provided. If a ticket with 2523 the requested life cannot be provided, 2524 then a renewable ticket may be issued 2525 with a renew-till equal to the the 2526 requested endtime. The value of the 2527 renew-till field may still be limited by 2528 local limits, or limits selected by the 2529 individual principal or server. 2531 28 ENC-TKT-IN-SKEY 2532 This option is used only by the ticket- 2533 granting service. The ENC-TKT-IN-SKEY 2534 option indicates that the ticket for the 2535 end server is to be encrypted in the 2536 session key from the additional ticket- 2537 granting ticket provided. 2539 29 RESERVED 2540 Reserved for future use. 2542 30 RENEW 2543 This option is used only by the ticket- 2544 granting service. The RENEW option 2545 indicates that the present request is 2546 for a renewal. The ticket provided is 2547 encrypted in the secret key for the 2548 server on which it is valid. This 2550 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2551 option will only be honored if the 2552 ticket to be renewed has its RENEWABLE 2553 flag set and if the time in its renew- 2554 till field has not passed. The ticket 2555 to be renewed is passed in the padata 2556 field as part of the authentication 2557 header. 2559 31 VALIDATE 2560 This option is used only by the ticket- 2561 granting service. The VALIDATE option 2562 indicates that the request is to vali- 2563 date a postdated ticket. It will only 2564 be honored if the ticket presented is 2565 postdated, presently has its INVALID 2566 flag set, and would be otherwise usable 2567 at this time. A ticket cannot be vali- 2568 dated before its starttime. The ticket 2569 presented for validation is encrypted in 2570 the key of the server for which it is 2571 valid and is passed in the padata field 2572 as part of the authentication header. 2574 cname and sname 2575 These fields are the same as those described for the ticket in section 2576 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is 2577 specified. If absent, the name of the server is taken from the name of 2578 the client in the ticket passed as additional-tickets. 2579 enc-authorization-data 2580 The enc-authorization-data, if present (and it can only be present in 2581 the TGS_REQ form), is an encoding of the desired authorization-data 2582 encrypted under the sub-session key if present in the Authenticator, or 2583 alternatively from the session key in the ticket-granting ticket, both 2584 from the padata field in the KRB_AP_REQ. 2585 realm 2586 This field specifies the realm part of the server's principal 2587 identifier. In the AS exchange, this is also the realm part of the 2588 client's principal identifier. 2589 from 2590 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 2591 requests when the requested ticket is to be postdated. It specifies the 2592 desired start time for the requested ticket. If this field is omitted 2593 then the KDC should use the current time instead. 2594 till 2595 This field contains the expiration date requested by the client in a 2596 ticket request. It is optional and if omitted the requested ticket is 2597 to have the maximum endtime permitted according to KDC policy for the 2598 parties to the authentication exchange as limited by expiration date of 2599 the ticket granting ticket or other preauthentication credentials. 2600 rtime 2601 This field is the requested renew-till time sent from a client to the 2602 KDC in a ticket request. It is optional. 2603 nonce 2604 This field is part of the KDC request and response. It it intended to 2605 hold a random number generated by the client. If the same number is 2606 included in the encrypted response from the KDC, it provides evidence 2607 that the response is fresh and has not been replayed by an attacker. 2608 Nonces must never be re-used. Ideally, it should be generated randomly, 2609 but if the correct time is known, it may suffice[25]. 2611 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2612 etype 2613 This field specifies the desired encryption algorithm to be used in the 2614 response. 2615 addresses 2616 This field is included in the initial request for tickets, and 2617 optionally included in requests for additional tickets from the 2618 ticket-granting server. It specifies the addresses from which the 2619 requested ticket is to be valid. Normally it includes the addresses for 2620 the client's host. If a proxy is requested, this field will contain 2621 other addresses. The contents of this field are usually copied by the 2622 KDC into the caddr field of the resulting ticket. 2623 additional-tickets 2624 Additional tickets may be optionally included in a request to the 2625 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 2626 specified, then the session key from the additional ticket will be used 2627 in place of the server's key to encrypt the new ticket. If more than 2628 one option which requires additional tickets has been specified, then 2629 the additional tickets are used in the order specified by the ordering 2630 of the options bits (see kdc-options, above). 2632 The application code will be either ten (10) or twelve (12) depending on 2633 whether the request is for an initial ticket (AS-REQ) or for an additional 2634 ticket (TGS-REQ). 2636 The optional fields (addresses, authorization-data and additional-tickets) 2637 are only included if necessary to perform the operation specified in the 2638 kdc-options field. 2640 It should be noted that in KRB_TGS_REQ, the protocol version number appears 2641 twice and two different message types appear: the KRB_TGS_REQ message 2642 contains these fields as does the authentication header (KRB_AP_REQ) that is 2643 passed in the padata field. 2645 5.4.2. KRB_KDC_REP definition 2647 The KRB_KDC_REP message format is used for the reply from the KDC for either 2648 an initial (AS) request or a subsequent (TGS) request. There is no message 2649 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 2650 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 2651 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 2652 the client's secret key, and the client's key version number is included in 2653 the key version number for the encrypted data. For KRB_TGS_REP, the 2654 ciphertext is encrypted in the sub-session key from the Authenticator, or if 2655 absent, the session key from the ticket-granting ticket used in the request. 2656 In that case, no version number will be present in the EncryptedData 2657 sequence. 2659 The KRB_KDC_REP message contains the following fields: 2661 AS-REP ::= [APPLICATION 11] KDC-REP 2662 TGS-REP ::= [APPLICATION 13] KDC-REP 2664 KDC-REP ::= SEQUENCE { 2665 pvno[0] INTEGER, 2666 msg-type[1] INTEGER, 2667 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 2668 crealm[3] Realm, 2669 cname[4] PrincipalName, 2670 ticket[5] Ticket, 2672 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2673 enc-part[6] EncryptedData 2674 } 2676 EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart 2677 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 2679 EncKDCRepPart ::= SEQUENCE { 2680 key[0] EncryptionKey, 2681 last-req[1] LastReq, 2682 nonce[2] INTEGER, 2683 key-expiration[3] KerberosTime OPTIONAL, 2684 flags[4] TicketFlags, 2685 authtime[5] KerberosTime, 2686 starttime[6] KerberosTime OPTIONAL, 2687 endtime[7] KerberosTime, 2688 renew-till[8] KerberosTime OPTIONAL, 2689 srealm[9] Realm, 2690 sname[10] PrincipalName, 2691 caddr[11] HostAddresses OPTIONAL 2692 } 2694 pvno and msg-type 2695 These fields are described above in section 5.4.1. msg-type is either 2696 KRB_AS_REP or KRB_TGS_REP. 2697 padata 2698 This field is described in detail in section 5.4.1. One possible use 2699 for this field is to encode an alternate "mix-in" string to be used 2700 with a string-to-key algorithm (such as is described in section 6.3.2). 2701 This ability is useful to ease transitions if a realm name needs to 2702 change (e.g. when a company is acquired); in such a case all existing 2703 password-derived entries in the KDC database would be flagged as 2704 needing a special mix-in string until the next password change. 2705 crealm, cname, srealm and sname 2706 These fields are the same as those described for the ticket in section 2707 5.3.1. 2708 ticket 2709 The newly-issued ticket, from section 5.3.1. 2710 enc-part 2711 This field is a place holder for the ciphertext and related information 2712 that forms the encrypted part of a message. The description of the 2713 encrypted part of the message follows each appearance of this field. 2714 The encrypted part is encoded as described in section 6.1. 2715 key 2716 This field is the same as described for the ticket in section 5.3.1. 2717 last-req 2718 This field is returned by the KDC and specifies the time(s) of the last 2719 request by a principal. Depending on what information is available, 2720 this might be the last time that a request for a ticket-granting ticket 2721 was made, or the last time that a request based on a ticket-granting 2722 ticket was successful. It also might cover all servers for a realm, or 2723 just the particular server. Some implementations may display this 2724 information to the user to aid in discovering unauthorized use of one's 2725 identity. It is similar in spirit to the last login time displayed when 2726 logging into timesharing systems. 2727 nonce 2728 This field is described above in section 5.4.1. 2729 key-expiration 2730 The key-expiration field is part of the response from the KDC and 2731 specifies the time that the client's secret key is due to expire. The 2733 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2734 expiration might be the result of password aging or an account 2735 expiration. This field will usually be left out of the TGS reply since 2736 the response to the TGS request is encrypted in a session key and no 2737 client information need be retrieved from the KDC database. It is up to 2738 the application client (usually the login program) to take appropriate 2739 action (such as notifying the user) if the expiration time is imminent. 2740 flags, authtime, starttime, endtime, renew-till and caddr 2741 These fields are duplicates of those found in the encrypted portion of 2742 the attached ticket (see section 5.3.1), provided so the client may 2743 verify they match the intended request and to assist in proper ticket 2744 caching. If the message is of type KRB_TGS_REP, the caddr field will 2745 only be filled in if the request was for a proxy or forwarded ticket, 2746 or if the user is substituting a subset of the addresses from the 2747 ticket granting ticket. If the client-requested addresses are not 2748 present or not used, then the addresses contained in the ticket will be 2749 the same as those included in the ticket-granting ticket. 2751 5.5. Client/Server (CS) message specifications 2753 This section specifies the format of the messages used for the 2754 authentication of the client to the application server. 2756 5.5.1. KRB_AP_REQ definition 2758 The KRB_AP_REQ message contains the Kerberos protocol version number, the 2759 message type KRB_AP_REQ, an options field to indicate any options in use, 2760 and the ticket and authenticator themselves. The KRB_AP_REQ message is often 2761 referred to as the 'authentication header'. 2763 AP-REQ ::= [APPLICATION 14] SEQUENCE { 2764 pvno[0] INTEGER, 2765 msg-type[1] INTEGER, 2766 ap-options[2] APOptions, 2767 ticket[3] Ticket, 2768 authenticator[4] EncryptedData 2769 } 2771 APOptions ::= BIT STRING { 2772 reserved(0), 2773 use-session-key(1), 2774 mutual-required(2) 2775 } 2777 pvno and msg-type 2778 These fields are described above in section 5.4.1. msg-type is 2779 KRB_AP_REQ. 2780 ap-options 2781 This field appears in the application request (KRB_AP_REQ) and affects 2782 the way the request is processed. It is a bit-field, where the selected 2783 options are indicated by the bit being set (1), and the unselected 2784 options and reserved fields being reset (0). The encoding of the bits 2785 is specified in section 5.2. The meanings of the options are: 2787 Bit(s) Name Description 2789 0 RESERVED 2790 Reserved for future expansion of this 2792 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2793 field. 2795 1 USE-SESSION-KEY 2796 The USE-SESSION-KEY option indicates 2797 that the ticket the client is presenting 2798 to a server is encrypted in the session 2799 key from the server's ticket-granting 2800 ticket. When this option is not speci- 2801 fied, the ticket is encrypted in the 2802 server's secret key. 2804 2 MUTUAL-REQUIRED 2805 The MUTUAL-REQUIRED option tells the 2806 server that the client requires mutual 2807 authentication, and that it must respond 2808 with a KRB_AP_REP message. 2810 3-31 RESERVED 2811 Reserved for future use. 2813 ticket 2814 This field is a ticket authenticating the client to the server. 2815 authenticator 2816 This contains the authenticator, which includes the client's choice of 2817 a subkey. Its encoding is described in section 5.3.2. 2819 5.5.2. KRB_AP_REP definition 2821 The KRB_AP_REP message contains the Kerberos protocol version number, the 2822 message type, and an encrypted time- stamp. The message is sent in in 2823 response to an application request (KRB_AP_REQ) where the mutual 2824 authentication option has been selected in the ap-options field. 2826 AP-REP ::= [APPLICATION 15] SEQUENCE { 2827 pvno[0] INTEGER, 2828 msg-type[1] INTEGER, 2829 enc-part[2] EncryptedData 2830 } 2832 EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { 2833 ctime[0] KerberosTime, 2834 cusec[1] INTEGER, 2835 subkey[2] EncryptionKey OPTIONAL, 2836 seq-number[3] INTEGER OPTIONAL 2837 } 2839 The encoded EncAPRepPart is encrypted in the shared session key of the 2840 ticket. The optional subkey field can be used in an application-arranged 2841 negotiation to choose a per association session key. 2843 pvno and msg-type 2844 These fields are described above in section 5.4.1. msg-type is 2845 KRB_AP_REP. 2846 enc-part 2847 This field is described above in section 5.4.2. 2848 ctime 2849 This field contains the current time on the client's host. 2850 cusec 2851 This field contains the microsecond part of the client's timestamp. 2853 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2854 subkey 2855 This field contains an encryption key which is to be used to protect 2856 this specific application session. See section 3.2.6 for specifics on 2857 how this field is used to negotiate a key. Unless an application 2858 specifies otherwise, if this field is left out, the sub-session key 2859 from the authenticator, or if also left out, the session key from the 2860 ticket will be used. 2862 5.5.3. Error message reply 2864 If an error occurs while processing the application request, the KRB_ERROR 2865 message will be sent in response. See section 5.9.1 for the format of the 2866 error message. The cname and crealm fields may be left out if the server 2867 cannot determine their appropriate values from the corresponding KRB_AP_REQ 2868 message. If the authenticator was decipherable, the ctime and cusec fields 2869 will contain the values from it. 2871 5.6. KRB_SAFE message specification 2873 This section specifies the format of a message that can be used by either 2874 side (client or server) of an application to send a tamper-proof message to 2875 its peer. It presumes that a session key has previously been exchanged (for 2876 example, by using the KRB_AP_REQ/KRB_AP_REP messages). 2878 5.6.1. KRB_SAFE definition 2880 The KRB_SAFE message contains user data along with a collision-proof 2881 checksum keyed with the last encryption key negotiated via subkeys, or the 2882 session key if no negotiation has occured. The message fields are: 2884 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 2885 pvno[0] INTEGER, 2886 msg-type[1] INTEGER, 2887 safe-body[2] KRB-SAFE-BODY, 2888 cksum[3] Checksum 2889 } 2891 KRB-SAFE-BODY ::= SEQUENCE { 2892 user-data[0] OCTET STRING, 2893 timestamp[1] KerberosTime OPTIONAL, 2894 usec[2] INTEGER OPTIONAL, 2895 seq-number[3] INTEGER OPTIONAL, 2896 s-address[4] HostAddress OPTIONAL, 2897 r-address[5] HostAddress OPTIONAL 2898 } 2900 pvno and msg-type 2901 These fields are described above in section 5.4.1. msg-type is 2902 KRB_SAFE. 2903 safe-body 2904 This field is a placeholder for the body of the KRB-SAFE message. 2905 cksum 2906 This field contains the checksum of the application data. Checksum 2907 details are described in section 6.4. The checksum is computed over the 2908 encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the 2909 checksum is computed over the encoding of the KRB-SAFE sequence, then 2910 the checksum is set to the result of that computation, and finally the 2911 KRB-SAFE sequence is encoded again. 2912 user-data 2914 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2915 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 2916 the application specific data that is being passed from the sender to 2917 the recipient. 2918 timestamp 2919 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 2920 are the current time as known by the sender of the message. By checking 2921 the timestamp, the recipient of the message is able to make sure that 2922 it was recently generated, and is not a replay. 2923 usec 2924 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 2925 the microsecond part of the timestamp. 2926 seq-number 2927 This field is described above in section 5.3.2. 2928 s-address 2929 This field specifies the address in use by the sender of the message. 2930 It may be omitted if not required by the application protocol. The 2931 application designer considering omission of this field is warned, that 2932 the inclusion of this address prevents some kinds of replay attacks 2933 (e.g., reflection attacks) and that it is only acceptable to omit this 2934 address if there is sufficient information in the integrity protected 2935 part of the application message for the recipient to unambiguously 2936 determine if it was the intended recipient. 2937 r-address 2938 This field specifies the address in use by the recipient of the 2939 message. It may be omitted for some uses (such as broadcast protocols), 2940 but the recipient may arbitrarily reject such messages. This field 2941 along with s-address can be used to help detect messages which have 2942 been incorrectly or maliciously delivered to the wrong recipient. 2944 5.7. KRB_PRIV message specification 2946 This section specifies the format of a message that can be used by either 2947 side (client or server) of an application to securely and privately send a 2948 message to its peer. It presumes that a session key has previously been 2949 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 2951 5.7.1. KRB_PRIV definition 2953 The KRB_PRIV message contains user data encrypted in the Session Key. The 2954 message fields are: 2956 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 2957 pvno[0] INTEGER, 2958 msg-type[1] INTEGER, 2959 enc-part[3] EncryptedData 2960 } 2962 EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { 2963 user-data[0] OCTET STRING, 2964 timestamp[1] KerberosTime OPTIONAL, 2965 usec[2] INTEGER OPTIONAL, 2966 seq-number[3] INTEGER OPTIONAL, 2967 s-address[4] HostAddress OPTIONAL, -- sender's addr 2968 r-address[5] HostAddress OPTIONAL -- recip's addr 2969 } 2971 pvno and msg-type 2972 These fields are described above in section 5.4.1. msg-type is 2973 KRB_PRIV. 2975 Neuman, Ts'o, Kohl Expires: 10 September, 2000 2976 enc-part 2977 This field holds an encoding of the EncKrbPrivPart sequence encrypted 2978 under the session key[32]. This encrypted encoding is used for the 2979 enc-part field of the KRB-PRIV message. See section 6 for the format of 2980 the ciphertext. 2981 user-data, timestamp, usec, s-address and r-address 2982 These fields are described above in section 5.6.1. 2983 seq-number 2984 This field is described above in section 5.3.2. 2986 5.8. KRB_CRED message specification 2988 This section specifies the format of a message that can be used to send 2989 Kerberos credentials from one principal to another. It is presented here to 2990 encourage a common mechanism to be used by applications when forwarding 2991 tickets or providing proxies to subordinate servers. It presumes that a 2992 session key has already been exchanged perhaps by using the 2993 KRB_AP_REQ/KRB_AP_REP messages. 2995 5.8.1. KRB_CRED definition 2997 The KRB_CRED message contains a sequence of tickets to be sent and 2998 information needed to use the tickets, including the session key from each. 2999 The information needed to use the tickets is encrypted under an encryption 3000 key previously exchanged or transferred alongside the KRB_CRED message. The 3001 message fields are: 3003 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3004 pvno[0] INTEGER, 3005 msg-type[1] INTEGER, -- KRB_CRED 3006 tickets[2] SEQUENCE OF Ticket, 3007 enc-part[3] EncryptedData 3008 } 3010 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3011 ticket-info[0] SEQUENCE OF KrbCredInfo, 3012 nonce[1] INTEGER OPTIONAL, 3013 timestamp[2] KerberosTime OPTIONAL, 3014 usec[3] INTEGER OPTIONAL, 3015 s-address[4] HostAddress OPTIONAL, 3016 r-address[5] HostAddress OPTIONAL 3017 } 3019 KrbCredInfo ::= SEQUENCE { 3020 key[0] EncryptionKey, 3021 prealm[1] Realm OPTIONAL, 3022 pname[2] PrincipalName OPTIONAL, 3023 flags[3] TicketFlags OPTIONAL, 3024 authtime[4] KerberosTime OPTIONAL, 3025 starttime[5] KerberosTime OPTIONAL, 3026 endtime[6] KerberosTime OPTIONAL 3027 renew-till[7] KerberosTime OPTIONAL, 3028 srealm[8] Realm OPTIONAL, 3029 sname[9] PrincipalName OPTIONAL, 3030 caddr[10] HostAddresses OPTIONAL 3031 } 3033 pvno and msg-type 3034 These fields are described above in section 5.4.1. msg-type is 3036 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3037 KRB_CRED. 3038 tickets 3039 These are the tickets obtained from the KDC specifically for use by the 3040 intended recipient. Successive tickets are paired with the 3041 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3042 message. 3043 enc-part 3044 This field holds an encoding of the EncKrbCredPart sequence encrypted 3045 under the session key shared between the sender and the intended 3046 recipient. This encrypted encoding is used for the enc-part field of 3047 the KRB-CRED message. See section 6 for the format of the ciphertext. 3048 nonce 3049 If practical, an application may require the inclusion of a nonce 3050 generated by the recipient of the message. If the same value is 3051 included as the nonce in the message, it provides evidence that the 3052 message is fresh and has not been replayed by an attacker. A nonce must 3053 never be re-used; it should be generated randomly by the recipient of 3054 the message and provided to the sender of the message in an application 3055 specific manner. 3056 timestamp and usec 3057 These fields specify the time that the KRB-CRED message was generated. 3058 The time is used to provide assurance that the message is fresh. 3059 s-address and r-address 3060 These fields are described above in section 5.6.1. They are used 3061 optionally to provide additional assurance of the integrity of the 3062 KRB-CRED message. 3063 key 3064 This field exists in the corresponding ticket passed by the KRB-CRED 3065 message and is used to pass the session key from the sender to the 3066 intended recipient. The field's encoding is described in section 6.2. 3068 The following fields are optional. If present, they can be associated with 3069 the credentials in the remote ticket file. If left out, then it is assumed 3070 that the recipient of the credentials already knows their value. 3072 prealm and pname 3073 The name and realm of the delegated principal identity. 3074 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3075 These fields contain the values of the correspond- ing fields from the 3076 ticket found in the ticket field. Descriptions of the fields are 3077 identical to the descriptions in the KDC-REP message. 3079 5.9. Error message specification 3081 This section specifies the format for the KRB_ERROR message. The fields 3082 included in the message are intended to return as much information as 3083 possible about an error. It is not expected that all the information 3084 required by the fields will be available for all types of errors. If the 3085 appropriate information is not available when the message is composed, the 3086 corresponding field will be left out of the message. 3088 Note that since the KRB_ERROR message is only optionally integrity 3089 protected, it is quite possible for an intruder to synthesize or modify such 3090 a message. In particular, this means that unless appropriate integrity 3091 protection mechanisms have been applied to the KRB_ERROR message, the client 3092 should not use any fields in this message for security-critical purposes, 3093 such as setting a system clock or generating a fresh authenticator. The 3094 message can be useful, however, for advising a user on the reason for some 3095 failure. 3097 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3098 5.9.1. KRB_ERROR definition 3100 The KRB_ERROR message consists of the following fields: 3102 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3103 pvno[0] INTEGER, 3104 msg-type[1] INTEGER, 3105 ctime[2] KerberosTime OPTIONAL, 3106 cusec[3] INTEGER OPTIONAL, 3107 stime[4] KerberosTime, 3108 susec[5] INTEGER, 3109 error-code[6] INTEGER, 3110 crealm[7] Realm OPTIONAL, 3111 cname[8] PrincipalName OPTIONAL, 3112 realm[9] Realm, -- Correct realm 3113 sname[10] PrincipalName, -- Correct name 3114 e-text[11] GeneralString OPTIONAL, 3115 e-data[12] OCTET STRING OPTIONAL, 3116 e-cksum[13] Checksum OPTIONAL, 3117 } 3119 pvno and msg-type 3120 These fields are described above in section 5.4.1. msg-type is 3121 KRB_ERROR. 3122 ctime 3123 This field is described above in section 5.4.1. 3124 cusec 3125 This field is described above in section 5.5.2. 3126 stime 3127 This field contains the current time on the server. It is of type 3128 KerberosTime. 3129 susec 3130 This field contains the microsecond part of the server's timestamp. Its 3131 value ranges from 0 to 999999. It appears along with stime. The two 3132 fields are used in conjunction to specify a reasonably accurate 3133 timestamp. 3134 error-code 3135 This field contains the error code returned by Kerberos or the server 3136 when a request fails. To interpret the value of this field see the list 3137 of error codes in section 8. Implementations are encouraged to provide 3138 for national language support in the display of error messages. 3139 crealm, cname, srealm and sname 3140 These fields are described above in section 5.3.1. 3141 e-text 3142 This field contains additional text to help explain the error code 3143 associated with the failed request (for example, it might include a 3144 principal name which was unknown). 3145 e-data 3146 This field contains additional data about the error for use by the 3147 application to help it recover from or handle the error. If present, 3148 this field will contain the encoding of a sequence of TypedData 3149 (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, 3150 in which case it will contain the encoding of a sequence of of padata 3151 fields (METHOD-DATA below), each corresponding to an acceptable 3152 pre-authentication method and optionally containing data for the 3153 method: 3155 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3156 TYPED-DATA ::= SEQUENCE of TypeData 3157 METHOD-DATA ::= SEQUENCE of PA-DATA 3159 TypedData ::= SEQUENCE { 3160 data-type[0] INTEGER, 3161 data-value[1] OCTET STRING OPTIONAL 3162 } 3164 Note that e-data-types have been reserved for all PA data types defined 3165 prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when 3166 using new PA data types defined in July 1999 or later, the METHOD-DATA 3167 sequence must itself be encapsulated in an TypedData element of type 3168 TD-PADATA. All new implementations interpreting the METHOD-DATA field 3169 for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of 3170 TD-PADATA, extract the typed data field and interpret the use any 3171 elements encapsulated in the TD-PADATA elements as if they were present 3172 in the METHOD-DATA sequence. 3173 e-cksum 3174 This field contains an optional checksum for the KRB-ERROR message. The 3175 checksum is calculated over the Kerberos ASN.1 encoding of the 3176 KRB-ERROR message with the checksum absent. The checksum is then added 3177 to the KRB-ERROR structure and the message is re-encoded. The Checksum 3178 should be calculated using the session key from the ticket granting 3179 ticket or service ticket, where available. If the error is in response 3180 to a TGS or AP request, the checksum should be calculated uing the the 3181 session key from the client's ticket. If the error is in response to an 3182 AS request, then the checksum should be calulated using the client's 3183 secret key ONLY if there has been suitable preauthentication to prove 3184 knowledge of the secret key by the client[33]. If a checksum can not be 3185 computed because the key to be used is not available, no checksum will 3186 be included. 3188 6. Encryption and Checksum Specifications 3190 The Kerberos protocols described in this document are designed to use 3191 stream encryption ciphers, which can be simulated using commonly 3192 available block encryption ciphers, such as the Data Encryption 3193 Standard [DES77], and triple DES variants, in conjunction with block 3194 chaining and checksum methods [DESM80]. Encryption is used to prove the 3195 identities of the network entities participating in message exchanges. 3196 The Key Distribution Center for each realm is trusted by all principals 3197 registered in that realm to store a secret key in confidence. Proof of 3198 knowledge of this secret key is used to verify the authenticity of a 3199 principal. 3201 The KDC uses the principal's secret key (in the AS exchange) or a 3202 shared session key (in the TGS exchange) to encrypt responses to ticket 3203 requests; the ability to obtain the secret key or session key implies 3204 the knowledge of the appropriate keys and the identity of the KDC. The 3205 ability of a principal to decrypt the KDC response and present a Ticket 3206 and a properly formed Authenticator (generated with the session key 3207 from the KDC response) to a service verifies the identity of the 3208 principal; likewise the ability of the service to extract the session 3209 key from the Ticket and prove its knowledge thereof in a response 3210 verifies the identity of the service. 3212 The Kerberos protocols generally assume that the encryption used is 3213 secure from cryptanalysis; however, in some cases, the order of fields 3215 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3216 in the encrypted portions of messages are arranged to minimize the 3217 effects of poorly chosen keys. It is still important to choose good 3218 keys. If keys are derived from user-typed passwords, those passwords 3219 need to be well chosen to make brute force attacks more difficult. 3220 Poorly chosen keys still make easy targets for intruders. 3222 The following sections specify the encryption and checksum mechanisms 3223 currently defined for Kerberos. The encodings, chaining, and padding 3224 requirements for each are described. For encryption methods, it is 3225 often desirable to place random information (often referred to as a 3226 confounder) at the start of the message. The requirements for a 3227 confounder are specified with each encryption mechanism. 3229 Some encryption systems use a block-chaining method to improve the the 3230 security characteristics of the ciphertext. However, these chaining 3231 methods often don't provide an integrity check upon decryption. Such 3232 systems (such as DES in CBC mode) must be augmented with a checksum of 3233 the plain-text which can be verified at decryption and used to detect 3234 any tampering or damage. Such checksums should be good at detecting 3235 burst errors in the input. If any damage is detected, the decryption 3236 routine is expected to return an error indicating the failure of an 3237 integrity check. Each encryption type is expected to provide and verify 3238 an appropriate checksum. The specification of each encryption method 3239 sets out its checksum requirements. 3241 Finally, where a key is to be derived from a user's password, an 3242 algorithm for converting the password to a key of the appropriate type 3243 is included. It is desirable for the string to key function to be 3244 one-way, and for the mapping to be different in different realms. This 3245 is important because users who are registered in more than one realm 3246 will often use the same password in each, and it is desirable that an 3247 attacker compromising the Kerberos server in one realm not obtain or 3248 derive the user's key in another. 3250 For an discussion of the integrity characteristics of the candidate 3251 encryption and checksum methods considered for Kerberos, the reader is 3252 referred to [SG92]. 3254 6.1. Encryption Specifications 3256 The following ASN.1 definition describes all encrypted messages. The 3257 enc-part field which appears in the unencrypted part of messages in 3258 section 5 is a sequence consisting of an encryption type, an optional 3259 key version number, and the ciphertext. 3261 EncryptedData ::= SEQUENCE { 3262 etype[0] INTEGER, -- EncryptionType 3263 kvno[1] INTEGER OPTIONAL, 3264 cipher[2] OCTET STRING -- ciphertext 3265 } 3267 etype 3268 This field identifies which encryption algorithm was used to 3269 encipher the cipher. Detailed specifications for selected 3270 encryption types appear later in this section. 3271 kvno 3272 This field contains the version number of the key under which data 3274 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3275 is encrypted. It is only present in messages encrypted under long 3276 lasting keys, such as principals' secret keys. 3277 cipher 3278 This field contains the enciphered text, encoded as an OCTET 3279 STRING. 3280 The cipher field is generated by applying the specified encryption 3281 algorithm to data composed of the message and algorithm-specific 3282 inputs. Encryption mechanisms defined for use with Kerberos must take 3283 sufficient measures to guarantee the integrity of the plaintext, and we 3284 recommend they also take measures to protect against precomputed 3285 dictionary attacks. If the encryption algorithm is not itself capable 3286 of doing so, the protections can often be enhanced by adding a checksum 3287 and a confounder. 3289 The suggested format for the data to be encrypted includes a 3290 confounder, a checksum, the encoded plaintext, and any necessary 3291 padding. The msg-seq field contains the part of the protocol message 3292 described in section 5 which is to be encrypted. The confounder, 3293 checksum, and padding are all untagged and untyped, and their length is 3294 exactly sufficient to hold the appropriate item. The type and length is 3295 implicit and specified by the particular encryption type being used 3296 (etype). The format for the data to be encrypted for some methods is 3297 described in the following diagram, but other methods may deviate from 3298 this layour - so long as the definition of the method defines the 3299 layout actually in use. 3301 +-----------+----------+-------------+-----+ 3302 |confounder | check | msg-seq | pad | 3303 +-----------+----------+-------------+-----+ 3305 The format cannot be described in ASN.1, but for those who prefer an 3306 ASN.1-like notation: 3308 CipherText ::= ENCRYPTED SEQUENCE { 3309 confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, 3310 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 3311 msg-seq[2] MsgSequence, 3312 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 3313 } 3315 One generates a random confounder of the appropriate length, placing it 3316 in confounder; zeroes out check; calculates the appropriate checksum 3317 over confounder, check, and msg-seq, placing the result in check; adds 3318 the necessary padding; then encrypts using the specified encryption 3319 type and the appropriate key. 3321 Unless otherwise specified, a definition of an encryption algorithm 3322 that specifies a checksum, a length for the confounder field, or an 3323 octet boundary for padding uses this ciphertext format[36]. Those 3324 fields which are not specified will be omitted. 3326 In the interest of allowing all implementations using a particular 3327 encryption type to communicate with all others using that type, the 3328 specification of an encryption type defines any checksum that is needed 3329 as part of the encryption process. If an alternative checksum is to be 3330 used, a new encryption type must be defined. 3332 Some cryptosystems require additional information beyond the key and 3333 the data to be encrypted. For example, DES, when used in 3335 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3336 cipher-block-chaining mode, requires an initialization vector. If 3337 required, the description for each encryption type must specify the 3338 source of such additional information. 6.2. Encryption Keys 3340 The sequence below shows the encoding of an encryption key: 3342 EncryptionKey ::= SEQUENCE { 3343 keytype[0] INTEGER, 3344 keyvalue[1] OCTET STRING 3345 } 3347 keytype 3348 This field specifies the type of encryption that is to be 3349 performed using the key that follows in the keyvalue field. It 3350 will always correspond to the etype to be used to generate or 3351 decode the EncryptedData. In cases when multiple algorithms use a 3352 common kind of key (e.g., if the encryption algorithm uses an 3353 alternate checksum algorithm for an integrity check, or a 3354 different chaining mechanism), the keytype provides information 3355 needed to determine which algorithm is to be used. 3356 keyvalue 3357 This field contains the key itself, encoded as an octet string. 3358 All negative values for the encryption key type are reserved for local 3359 use. All non-negative values are reserved for officially assigned type 3360 fields and interpreta- tions. 3362 6.3. Encryption Systems 3364 6.3.1. The NULL Encryption System (null) 3366 If no encryption is in use, the encryption system is said to be the 3367 NULL encryption system. In the NULL encryption system there is no 3368 checksum, confounder or padding. The ciphertext is simply the 3369 plaintext. The NULL Key is used by the null encryption system and is 3370 zero octets in length, with keytype zero (0). 3372 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) 3374 The des-cbc-crc encryption mode encrypts information under the Data 3375 Encryption Standard [DES77] using the cipher block chaining mode 3376 [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is 3377 applied to the confounder and message sequence (msg-seq) and placed in 3378 the cksum field. DES blocks are 8 bytes. As a result, the data to be 3379 encrypted (the concatenation of confounder, checksum, and message) must 3380 be padded to an 8 byte boundary before encryption. The details of the 3381 encryption of this data are identical to those for the des-cbc-md5 3382 encryption mode. 3384 Note that, since the CRC-32 checksum is not collision-proof, an 3385 attacker could use a probabilistic chosen-plaintext attack to generate 3386 a valid message even if a confounder is used [SG92]. The use of 3387 collision-proof checksums is recommended for environments where such 3388 attacks represent a significant threat. The use of the CRC-32 as the 3389 checksum for ticket or authenticator is no longer mandated as an 3390 interoperability requirement for Kerberos Version 5 Specification 1 3391 (See section 9.1 for specific details). 3393 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) 3395 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3396 The des-cbc-md4 encryption mode encrypts information under the Data 3397 Encryption Standard [DES77] using the cipher block chaining mode 3398 [DESM80]. An MD4 checksum (described in [MD492]) is applied to the 3399 confounder and message sequence (msg-seq) and placed in the cksum 3400 field. DES blocks are 8 bytes. As a result, the data to be encrypted 3401 (the concatenation of confounder, checksum, and message) must be padded 3402 to an 8 byte boundary before encryption. The details of the encryption 3403 of this data are identical to those for the des-cbc-md5 encryption 3404 mode. 3406 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) 3408 The des-cbc-md5 encryption mode encrypts information under the Data 3409 Encryption Standard [DES77] using the cipher block chaining mode 3410 [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the 3411 confounder and message sequence (msg-seq) and placed in the cksum 3412 field. DES blocks are 8 bytes. As a result, the data to be encrypted 3413 (the concatenation of confounder, checksum, and message) must be padded 3414 to an 8 byte boundary before encryption. 3416 Plaintext and DES ciphtertext are encoded as blocks of 8 octets which 3417 are concatenated to make the 64-bit inputs for the DES algorithms. The 3418 first octet supplies the 8 most significant bits (with the octet's 3419 MSbit used as the DES input block's MSbit, etc.), the second octet the 3420 next 8 bits, ..., and the eighth octet supplies the 8 least significant 3421 bits. 3423 Encryption under DES using cipher block chaining requires an additional 3424 input in the form of an initialization vector. Unless otherwise 3425 specified, zero should be used as the initialization vector. Kerberos' 3426 use of DES requires an 8 octet confounder. 3428 The DES specifications identify some 'weak' and 'semi-weak' keys; those 3429 keys shall not be used for encrypting messages for use in Kerberos. 3430 Additionally, because of the way that keys are derived for the 3431 encryption of checksums, keys shall not be used that yield 'weak' or 3432 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant 3433 F0F0F0F0F0F0F0F0. 3435 A DES key is 8 octets of data, with keytype one (1). This consists of 3436 56 bits of key, and 8 parity bits (one per octet). The key is encoded 3437 as a series of 8 octets written in MSB-first order. The bits within the 3438 key are also encoded in MSB order. For example, if the encryption key 3439 is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where 3440 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the 3441 parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with 3442 B1 as the MSbit). [See the FIPS 81 introduction for reference.] 3444 String to key transformation 3446 To generate a DES key from a text string (password), a "salt" is 3447 concatenated to the text string, and then padded with ASCII nulls to an 3448 8 byte boundary. This "salt" is normally the realm and each component 3449 of the principal's name appended. However, sometimes different salts 3450 are used --- for example, when a realm is renamed, or if a user changes 3451 her username, or for compatibility with Kerberos V4 (whose 3452 string-to-key algorithm uses a null string for the salt). This string 3453 is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES 3454 key. Before eXclusive-ORing a block, every byte is shifted one bit to 3456 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3457 the left to leave the lowest bit zero. The key is the "corrected" by 3458 correcting the parity on the key, and if the key matches a 'weak' or 3459 'semi-weak' key as described in the DES specification, it is 3460 eXclusive-ORed with the constant 00000000000000F0. This key is then 3461 used to generate a DES CBC checksum on the initial string (with the 3462 salt appended). The result of the CBC checksum is the "corrected" as 3463 described above to form the result which is return as the key. 3464 Pseudocode follows: 3466 name_to_default_salt(realm, name) { 3467 s = realm 3468 for(each component in name) { 3469 s = s + component; 3470 } 3471 return s; 3472 } 3474 key_correction(key) { 3475 fixparity(key); 3476 if (is_weak_key_key(key)) 3477 key = key XOR 0xF0; 3478 return(key); 3479 } 3481 string_to_key(string,salt) { 3483 odd = 1; 3484 s = string + salt; 3485 tempkey = NULL; 3486 pad(s); /* with nulls to 8 byte boundary */ 3487 for(8byteblock in s) { 3488 if(odd == 0) { 3489 odd = 1; 3490 reverse(8byteblock) 3491 } 3492 else odd = 0; 3493 left shift every byte in 8byteblock one bit; 3494 tempkey = tempkey XOR 8byteblock; 3495 } 3496 tempkey = key_correction(tempkey); 3497 key = key_correction(DES-CBC-check(s,tempkey)); 3498 return(key); 3499 } 3501 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and 3502 without Key Derivation [Original draft by Marc Horowitz, revisions by 3503 David Miller] 3505 This encryption type is based on the Triple DES cryptosystem, the 3506 HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key 3507 derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not 3508 be used in conjunction with the use of Triple DES keys. 3510 Algorithm Identifiers 3512 The des3-cbc-hmac-sha1 encryption type has been assigned the value 7. 3513 The des3-cbc-hmac-sha1-kd encryption type, specifying the key 3514 derivation variant of the encryption type, has been assigned the value 3515 16. The hmac-sha1-des3 checksum type has been assigned the value 13. 3517 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3518 The hmac-sha1-des3-kd checksum type, specifying the key derivation 3519 variant of the checksum, has been assigned the value 12. 3521 Triple DES Key Production 3523 The EncryptionKey value is 24 octets long. The 7 most significant bits 3524 of each octet contain key bits, and the least significant bit is the 3525 inverse of the xor of the key bits. 3527 For the purposes of key derivation, the block size is 64 bits, and the 3528 key size is 168 bits. The 168 bits output by key derivation are 3529 converted to an EncryptionKey value as follows. First, the 168 bits are 3530 divided into three groups of 56 bits, which are expanded individually 3531 into 64 bits as follows: 3533 1 2 3 4 5 6 7 p 3534 9 10 11 12 13 14 15 p 3535 17 18 19 20 21 22 23 p 3536 25 26 27 28 29 30 31 p 3537 33 34 35 36 37 38 39 p 3538 41 42 43 44 45 46 47 p 3539 49 50 51 52 53 54 55 p 3540 56 48 40 32 24 16 8 p 3542 The "p" bits are parity bits computed over the data bits. The output of 3543 the three expansions are concatenated to form the EncryptionKey value. 3545 When the HMAC-SHA1 of a string is computed, the key is used in the 3546 EncryptedKey form. 3548 The string-to-key function is used to tranform UNICODE passwords into 3549 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 3550 algorithm, which is detailed in [9]. The description of the N-fold 3551 algorithm in that document is as follows: 3552 o To n-fold a number X, replicate the input value to a length that 3553 is the least common multiple of n and the length of X. Before each 3554 repetition, the input is rotated to the right by 13 bit positions. 3555 The successive n-bit chunks are added together using 3556 1's-complement addition (that is, addition with end-around carry) 3557 to yield an n-bit result" 3558 o The n-fold algorithm, as with DES string-to-key, is applied to the 3559 password string concatenated with a salt value. The salt value is 3560 derived in the same was as for the DES string-to-key algorithm. 3561 For 3-key triple DES then, the operation will involve a 168-fold 3562 of the input password string. The remainder of the string-to-key 3563 function for DES3 is shown here in pseudocode: 3565 DES3string-to-key(passwordString, key) 3567 salt = name_to_default_salt(realm, name) 3568 s = passwordString + salt 3569 tmpKey1 = 168-fold(s) 3570 parityFix(tmpKey1); 3571 if not weakKey(tmpKey1) 3572 /* 3573 * Encrypt temp key in itself with a 3574 * zero initialization vector 3575 * 3576 * Function signature is DES3encrypt(plain, key, iv) 3578 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3579 * with cipher as the return value 3580 */ 3581 tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec) 3582 /* 3583 * Encrypt resultant temp key in itself with third component 3584 * of first temp key as initialization vector 3585 */ 3586 key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2]) 3587 parityFix(key) 3588 if not weakKey(key) 3589 return SUCCESS 3590 else 3591 return FAILURE 3592 else 3593 return FAILURE 3595 The weakKey function above is the same weakKey function used with DES 3596 keys, but applied to each of the three single DES keys that comprise 3597 the triple DES key. 3599 The lengths of UNICODE encoded character strings include the trailing 3600 terminator character (0). 3602 Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd 3604 EncryptedData using this type must be generated as described in 3605 [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. 3606 The checksum algorithm is HMAC-SHA1. If the key derivation variant of 3607 the encryption type is used, encryption key values are modified 3608 according to the method under the Key Derivation section below. 3610 Unless otherwise specified, a zero IV must be used. 3612 If the length of the input data is not a multiple of the block size, 3613 zero octets must be used to pad the plaintext to the next eight-octet 3614 boundary. The counfounder must be eight random octets (one block). 3616 Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd 3618 Checksums using this type must be generated as described in 3619 [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key 3620 derivation variant of the checksum type is used, checksum key values 3621 are modified according to the method under the Key Derivation section 3622 below. 3624 Key Derivation 3626 In the Kerberos protocol, cryptographic keys are used in a number of 3627 places. In order to minimize the effect of compromising a key, it is 3628 desirable to use a different key for each of these places. Key 3629 derivation [Horowitz96] can be used to construct different keys for 3630 each operation from the keys transported on the network. For this to be 3631 possible, a small change to the specification is necessary. 3633 This section specifies a profile for the use of key derivation 3634 [Horowitz96] with Kerberos. For each place where a key is used, a ``key 3635 usage'' must is specified for that purpose. The key, key usage, and 3636 encryption/checksum type together describe the transformation from 3637 plaintext to ciphertext, or plaintext to checksum. 3639 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3640 Key Usage Values 3642 This is a complete list of places keys are used in the kerberos 3643 protocol, with key usage values and RFC 1510 section numbers: 3645 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 3646 client key (section 5.4.1) 3647 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or 3648 application session key), encrypted with the service key 3649 (section 5.4.2) 3650 3. AS-REP encrypted part (includes tgs session key or application 3651 session key), encrypted with the client key (section 5.4.2) 3652 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 3653 session key (section 5.4.1) 3654 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 3655 authenticator subkey (section 5.4.1) 3656 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 3657 with the tgs session key (sections 5.3.2, 5.4.1) 3658 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs 3659 authenticator subkey), encrypted with the tgs session key 3660 (section 5.3.2) 3661 8. TGS-REP encrypted part (includes application session key), 3662 encrypted with the tgs session key (section 5.4.2) 3663 9. TGS-REP encrypted part (includes application session key), 3664 encrypted with the tgs authenticator subkey (section 5.4.2) 3665 10. AP-REQ Authenticator cksum, keyed with the application session 3666 key (section 5.3.2) 3667 11. AP-REQ Authenticator (includes application authenticator 3668 subkey), encrypted with the application session key (section 3669 5.3.2) 3670 12. AP-REP encrypted part (includes application session subkey), 3671 encrypted with the application session key (section 5.5.2) 3672 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 3673 application (section 5.7.1) 3674 14. KRB-CRED encrypted part, encrypted with a key chosen by the 3675 application (section 5.6.1) 3676 15. KRB-SAVE cksum, keyed with a key chosen by the application 3677 (section 5.8.1) 3678 18. KRB-ERROR checksum (e-cksum in section 5.9.1) 3679 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) 3680 20. Checksum for Mandatory Ticket Extensions (appendix B.6) 3681 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) 3683 Key usage values between 1024 and 2047 (inclusive) are reserved for 3684 application use. Applications should use even values for encryption and 3685 odd values for checksums within this range. 3687 A few of these key usages need a little clarification. A service which 3688 receives an AP-REQ has no way to know if the enclosed Ticket was part 3689 of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for 3690 generating a Ticket, whether it is in response to an AS- REQ or 3691 TGS-REQ. 3693 There might exist other documents which define protocols in terms of 3694 the RFC1510 encryption types or checksum types. Such documents would 3695 not know about key usages. In order that these documents continue to be 3696 meaningful until they are updated, key usages 1024 and 1025 must be 3697 used to derive keys for encryption and checksums, respectively. New 3699 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3700 protocols defined in terms of the Kerberos encryption and checksum 3701 types should use their own key usages. Key usages may be registered 3702 with IANA to avoid conflicts. Key usages must be unsigned 32 bit 3703 integers. Zero is not permitted. 3705 Defining Cryptosystems Using Key Derivation 3707 Kerberos requires that the ciphertext component of EncryptedData be 3708 tamper-resistant as well as confidential. This implies encryption and 3709 integrity functions, which must each use their own separate keys. So, 3710 for each key usage, two keys must be generated, one for encryption 3711 (Ke), and one for integrity (Ki): 3713 Ke = DK(protocol key, key usage | 0xAA) 3714 Ki = DK(protocol key, key usage | 0x55) 3716 where the protocol key is from the EncryptionKey from the wire 3717 protocol, and the key usage is represented as a 32 bit integer in 3718 network byte order. The ciphertest must be generated from the plaintext 3719 as follows: 3721 ciphertext = E(Ke, confounder | plaintext | padding) | 3722 H(Ki, confounder | plaintext | padding) 3724 The confounder and padding are specific to the encryption algorithm E. 3726 When generating a checksum only, there is no need for a confounder or 3727 padding. Again, a new key (Kc) must be used. Checksums must be 3728 generated from the plaintext as follows: 3730 Kc = DK(protocol key, key usage | 0x99) 3731 MAC = H(Kc, plaintext) 3733 Note that each enctype is described by an encryption algorithm E and a 3734 keyed hash algorithm H, and each checksum type is described by a keyed 3735 hash algorithm H. HMAC, with an appropriate hash, is required for use 3736 as H. 3738 Key Derivation from Passwords 3740 The well-known constant for password key derivation must be the byte 3741 string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values 3742 correspond to the ASCII encoding for the string "kerberos". 3744 6.4. Checksums 3746 The following is the ASN.1 definition used for a checksum: 3748 Checksum ::= SEQUENCE { 3749 cksumtype[0] INTEGER, 3750 checksum[1] OCTET STRING 3751 } 3753 cksumtype 3754 This field indicates the algorithm used to generate the 3755 accompanying checksum. 3756 checksum 3757 This field contains the checksum itself, encoded as an octet 3758 string. 3760 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3761 Detailed specification of selected checksum types appear later in this 3762 section. Negative values for the checksum type are reserved for local 3763 use. All non-negative values are reserved for officially assigned type 3764 fields and interpretations. 3766 Checksums used by Kerberos can be classified by two properties: whether 3767 they are collision-proof, and whether they are keyed. It is infeasible 3768 to find two plaintexts which generate the same checksum value for a 3769 collision-proof checksum. A key is required to perturb or initialize 3770 the algorithm in a keyed checksum. To prevent message-stream 3771 modification by an active attacker, unkeyed checksums should only be 3772 used when the checksum and message will be subsequently encrypted (e.g. 3773 the checksums defined as part of the encryption algorithms covered 3774 earlier in this section). 3776 Collision-proof checksums can be made tamper-proof if the checksum 3777 value is encrypted before inclusion in a message. In such cases, the 3778 composition of the checksum and the encryption algorithm must be 3779 considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using 3780 DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed 3781 checksums, as well as for the encrypted forms of unkeyed 3782 collision-proof checksums, Kerberos prepends a confounder before the 3783 checksum is calculated. 3785 6.4.1. The CRC-32 Checksum (crc32) 3787 The CRC-32 checksum calculates a checksum based on a cyclic redundancy 3788 check as described in ISO 3309 [ISO3309]. The resulting checksum is 3789 four (4) octets in length. The CRC-32 is neither keyed nor 3790 collision-proof. The use of this checksum is not recommended. An 3791 attacker using a probabilistic chosen-plaintext attack as described in 3792 [SG92] might be able to generate an alternative message that satisfies 3793 the checksum. The use of collision-proof checksums is recommended for 3794 environments where such attacks represent a significant threat. 3796 6.4.2. The RSA MD4 Checksum (rsa-md4) 3798 The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm 3799 [MD4-92]. The algorithm takes as input an input message of arbitrary 3800 length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is 3801 believed to be collision-proof. 3803 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) 3805 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by 3806 prepending an 8 octet confounder before the text, applying the RSA MD4 3807 checksum algorithm, and encrypting the confounder and the checksum 3808 using DES in cipher-block-chaining (CBC) mode using a variant of the 3809 key, where the variant is computed by eXclusive-ORing the key with the 3810 constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be 3811 zero. The resulting checksum is 24 octets long (8 octets of which are 3812 redundant). This checksum is tamper-proof and believed to be 3813 collision-proof. 3815 The DES specifications identify some weak keys' and 'semi-weak keys'; 3816 those keys shall not be used for generating RSA-MD4 checksums for use 3817 in Kerberos. 3819 The format for the checksum is described in the follow- ing diagram: 3821 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3822 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3823 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 3824 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3826 The format cannot be described in ASN.1, but for those who prefer an 3827 ASN.1-like notation: 3829 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3830 confounder[0] UNTAGGED OCTET STRING(8), 3831 check[1] UNTAGGED OCTET STRING(16) 3832 } 3834 6.4.4. The RSA MD5 Checksum (rsa-md5) 3836 The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm. 3837 [MD5-92]. The algorithm takes as input an input message of arbitrary 3838 length and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is 3839 believed to be collision-proof. 3841 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) 3843 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by 3844 prepending an 8 octet confounder before the text, applying the RSA MD5 3845 checksum algorithm, and encrypting the confounder and the checksum 3846 using DES in cipher-block-chaining (CBC) mode using a variant of the 3847 key, where the variant is computed by eXclusive-ORing the key with the 3848 hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should 3849 be zero. The resulting checksum is 24 octets long (8 octets of which 3850 are redundant). This checksum is tamper-proof and believed to be 3851 collision-proof. 3853 The DES specifications identify some 'weak keys' and 'semi-weak keys'; 3854 those keys shall not be used for encrypting RSA-MD5 checksums for use 3855 in Kerberos. 3857 The format for the checksum is described in the following diagram: 3859 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3860 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 3861 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3863 The format cannot be described in ASN.1, but for those who prefer an 3864 ASN.1-like notation: 3866 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3867 confounder[0] UNTAGGED OCTET STRING(8), 3868 check[1] UNTAGGED OCTET STRING(16) 3869 } 3871 6.4.6. DES cipher-block chained checksum (des-mac) 3873 The DES-MAC checksum is computed by prepending an 8 octet confounder to 3874 the plaintext, performing a DES CBC-mode encryption on the result using 3875 the key and an initialization vector of zero, taking the last block of 3876 the ciphertext, prepending the same confounder and encrypting the pair 3877 using DES in cipher-block-chaining (CBC) mode using a a variant of the 3878 key, where the variant is computed by eXclusive-ORing the key with the 3879 hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should 3881 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3882 be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits 3883 of which are redundant. This checksum is tamper-proof and 3884 collision-proof. 3886 The format for the checksum is described in the following diagram: 3888 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 3889 | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | 3890 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 3892 The format cannot be described in ASN.1, but for those who prefer an 3893 ASN.1-like notation: 3895 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 3896 confounder[0] UNTAGGED OCTET STRING(8), 3897 check[1] UNTAGGED OCTET STRING(8) 3898 } 3900 The DES specifications identify some 'weak' and 'semi-weak' keys; those 3901 keys shall not be used for generating DES-MAC checksums for use in 3902 Kerberos, nor shall a key be used whose variant is 'weak' or 3903 'semi-weak'. 3905 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative 3906 (rsa-md4-des-k) 3908 The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum 3909 by applying the RSA MD4 checksum algorithm and encrypting the results 3910 using DES in cipher-block-chaining (CBC) mode using a DES key as both 3911 key and initialization vector. The resulting checksum is 16 octets 3912 long. This checksum is tamper-proof and believed to be collision-proof. 3913 Note that this checksum type is the old method for encoding the 3914 RSA-MD4-DES checksum and it is no longer recommended. 3916 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) 3918 The DES-MAC-K checksum is computed by performing a DES CBC-mode 3919 encryption of the plaintext, and using the last block of the ciphertext 3920 as the checksum value. It is keyed with an encryption key and an 3921 initialization vector; any uses which do not specify an additional 3922 initialization vector will use the key as both key and initialization 3923 vector. The resulting checksum is 64 bits (8 octets) long. This 3924 checksum is tamper-proof and collision-proof. Note that this checksum 3925 type is the old method for encoding the DES-MAC checksum and it is no 3926 longer recommended. The DES specifications identify some 'weak keys' 3927 and 'semi-weak keys'; those keys shall not be used for generating 3928 DES-MAC checksums for use in Kerberos. 3930 7. Naming Constraints 3932 7.1. Realm Names 3934 Although realm names are encoded as GeneralStrings and although a realm 3935 can technically select any name it chooses, interoperability across 3936 realm boundaries requires agreement on how realm names are to be 3937 assigned, and what information they imply. 3939 To enforce these conventions, each realm must conform to the 3940 conventions itself, and it must require that any realms with which 3942 Neuman, Ts'o, Kohl Expires: 10 September, 2000 3943 inter-realm keys are shared also conform to the conventions and require 3944 the same from its neighbors. 3946 Kerberos realm names are case sensitive. Realm names that differ only 3947 in the case of the characters are not equivalent. There are presently 3948 four styles of realm names: domain, X500, other, and reserved. Examples 3949 of each style follow: 3951 domain: ATHENA.MIT.EDU (example) 3952 X500: C=US/O=OSF (example) 3953 other: NAMETYPE:rest/of.name=without-restrictions (example) 3954 reserved: reserved, but will not conflict with above 3956 Domain names must look like domain names: they consist of components 3957 separated by periods (.) and they contain neither colons (:) nor 3958 slashes (/). Domain names must be converted to upper case when used as 3959 realm names. 3961 X.500 names contain an equal (=) and cannot contain a colon (:) before 3962 the equal. The realm names for X.500 names will be string 3963 representations of the names with components separated by slashes. 3964 Leading and trailing slashes will not be included. 3966 Names that fall into the other category must begin with a prefix that 3967 contains no equal (=) or period (.) and the prefix must be followed by 3968 a colon (:) and the rest of the name. All prefixes must be assigned 3969 before they may be used. Presently none are assigned. 3971 The reserved category includes strings which do not fall into the first 3972 three categories. All names in this category are reserved. It is 3973 unlikely that names will be assigned to this category unless there is a 3974 very strong argument for not using the 'other' category. 3976 These rules guarantee that there will be no conflicts between the 3977 various name styles. The following additional constraints apply to the 3978 assignment of realm names in the domain and X.500 categories: the name 3979 of a realm for the domain or X.500 formats must either be used by the 3980 organization owning (to whom it was assigned) an Internet domain name 3981 or X.500 name, or in the case that no such names are registered, 3982 authority to use a realm name may be derived from the authority of the 3983 parent realm. For example, if there is no domain name for E40.MIT.EDU, 3984 then the administrator of the MIT.EDU realm can authorize the creation 3985 of a realm with that name. 3987 This is acceptable because the organization to which the parent is 3988 assigned is presumably the organization authorized to assign names to 3989 its children in the X.500 and domain name systems as well. If the 3990 parent assigns a realm name without also registering it in the domain 3991 name or X.500 hierarchy, it is the parent's responsibility to make sure 3992 that there will not in the future exists a name identical to the realm 3993 name of the child unless it is assigned to the same entity as the realm 3994 name. 3996 7.2. Principal Names 3998 As was the case for realm names, conventions are needed to ensure that 3999 all agree on what information is implied by a principal name. The 4000 name-type field that is part of the principal name indicates the kind 4001 of information implied by the name. The name-type should be treated as 4003 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4004 a hint. Ignoring the name type, no two names can be the same (i.e. at 4005 least one of the components, or the realm, must be different). The 4006 following name types are defined: 4008 name-type value meaning 4010 NT-UNKNOWN 0 Name type not known 4011 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) 4012 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4013 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4014 NT-SRV-XHST 4 Service with slash-separated host name components 4015 NT-UID 5 Unique ID 4016 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4018 When a name implies no information other than its uniqueness at a 4019 particular time the name type PRINCIPAL should be used. The principal 4020 name type should be used for users, and it might also be used for a 4021 unique server. If the name is a unique machine generated ID that is 4022 guaranteed never to be reassigned then the name type of UID should be 4023 used (note that it is generally a bad idea to reassign names of any 4024 type since stale entries might remain in access control lists). 4026 If the first component of a name identifies a service and the remaining 4027 components identify an instance of the service in a server specified 4028 manner, then the name type of SRV-INST should be used. An example of 4029 this name type is the Kerberos ticket-granting service whose name has a 4030 first component of krbtgt and a second component identifying the realm 4031 for which the ticket is valid. 4033 If instance is a single component following the service name and the 4034 instance identifies the host on which the server is running, then the 4035 name type SRV-HST should be used. This type is typically used for 4036 Internet services such as telnet and the Berkeley R commands. If the 4037 separate components of the host name appear as successive components 4038 following the name of the service, then the name type SRV-XHST should 4039 be used. This type might be used to identify servers on hosts with 4040 X.500 names where the slash (/) might otherwise be ambiguous. 4042 A name type of NT-X500-PRINCIPAL should be used when a name from an 4043 X.509 certificiate is translated into a Kerberos name. The encoding of 4044 the X.509 name as a Kerberos principal shall conform to the encoding 4045 rules specified in RFC 2253. 4047 A name type of UNKNOWN should be used when the form of the name is not 4048 known. When comparing names, a name of type UNKNOWN will match 4049 principals authenticated with names of any type. A principal 4050 authenticated with a name of type UNKNOWN, however, will only match 4051 other names of type UNKNOWN. 4053 Names of any type with an initial component of 'krbtgt' are reserved 4054 for the Kerberos ticket granting service. See section 8.2.3 for the 4055 form of such names. 4057 7.2.1. Name of server principals 4059 The principal identifier for a server on a host will generally be 4060 composed of two parts: (1) the realm of the KDC with which the server 4061 is registered, and (2) a two-component name of type NT-SRV-HST if the 4062 host name is an Internet domain name or a multi-component name of type 4064 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4065 NT-SRV-XHST if the name of the host is of a form such as X.500 that 4066 allows slash (/) separators. The first component of the two- or 4067 multi-component name will identify the service and the latter 4068 components will identify the host. Where the name of the host is not 4069 case sensitive (for example, with Internet domain names) the name of 4070 the host must be lower case. If specified by the application protocol 4071 for services such as telnet and the Berkeley R commands which run with 4072 system privileges, the first component may be the string 'host' instead 4073 of a service specific identifier. When a host has an official name and 4074 one or more aliases, the official name of the host must be used when 4075 constructing the name of the server principal. 4077 8. Constants and other defined values 4079 8.1. Host address types 4081 All negative values for the host address type are reserved for local 4082 use. All non-negative values are reserved for officially assigned type 4083 fields and interpretations. 4085 The values of the types for the following addresses are chosen to match 4086 the defined address family constants in the Berkeley Standard 4087 Distributions of Unix. They can be found in with symbolic names AF_xxx 4088 (where xxx is an abbreviation of the address family name). 4090 Internet (IPv4) Addresses 4092 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in 4093 MSB order. The type of IPv4 addresses is two (2). 4095 Internet (IPv6) Addresses [Westerlund] 4097 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. 4098 The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. 4099 The following addresses (see [RFC1884]) MUST not appear in any Kerberos 4100 packet: 4101 o the Unspecified Address 4102 o the Loopback Address 4103 o Link-Local addresses 4104 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 4106 CHAOSnet addresses 4108 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB 4109 order. The type of CHAOSnet addresses is five (5). 4111 ISO addresses 4113 ISO addresses are variable-length. The type of ISO addresses is seven 4114 (7). 4116 Xerox Network Services (XNS) addresses 4118 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. 4119 The type of XNS addresses is six (6). 4121 AppleTalk Datagram Delivery Protocol (DDP) addresses 4123 AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit 4125 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4126 network number. The first octet of the address is the node number; the 4127 remaining two octets encode the network number in MSB order. The type 4128 of AppleTalk DDP addresses is sixteen (16). 4130 DECnet Phase IV addresses 4132 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. 4133 The type of DECnet Phase IV addresses is twelve (12). 4135 Netbios addresses 4137 Netbios addresses are 16-octet addresses typically composed of 1 to 15 4138 characters, trailing blank (ascii char 20) filled, with a 16th octet of 4139 0x0. The type of Netbios addresses is 20 (0x14). 4141 8.2. KDC messages 4143 8.2.1. UDP/IP transport 4145 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using 4146 UDP IP transport, the client shall send a UDP datagram containing only 4147 an encoding of the request to port 88 (decimal) at the KDC's IP 4148 address; the KDC will respond with a reply datagram containing only an 4149 encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to 4150 the sending port at the sender's IP address. Kerberos servers 4151 supporting IP transport must accept UDP requests on port 88 (decimal). 4152 The response to a request made through UDP/IP transport must also use 4153 UDP/IP transport. 4155 8.2.2. TCP/IP transport [Westerlund,Danielsson] 4157 Kerberos servers (KDC's) should accept TCP requests on port 88 4158 (decimal) and clients should support the sending of TCP requests on 4159 port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC over 4160 a TCP stream, a new connection will be established for each 4161 authentication exchange (request and response). The KRB_KDC_REP or 4162 KRB_ERROR message will be returned to the client on the same TCP stream 4163 that was established for the request. The response to a request made 4164 through TCP/IP transport must also use TCP/IP transport. Implementors 4165 should note that some extentions to the Kerberos protocol will not work 4166 if any implementation not supporting the TCP transport is involved 4167 (client or KDC). Implementors are strongly urged to support the TCP 4168 transport on both the client and server and are advised that the 4169 current notation of "should" support will likely change in the future 4170 to must support. The KDC may close the TCP stream after sending a 4171 response, but may leave the stream open if it expects a followup - in 4172 which case it may close the stream at any time if resource constratints 4173 or other factors make it desirable to do so. Care must be taken in 4174 managing TCP/IP connections with the KDC to prevent denial of service 4175 attacks based on the number of TCP/IP connections with the KDC that 4176 remain open. If multiple exchanges with the KDC are needed for certain 4177 forms of preauthentication, multiple TCP connections may be required. A 4178 client may close the stream after receiving response, and should close 4179 the stream if it does not expect to send followup messages. The client 4180 must be prepared to have the stream closed by the KDC at anytime, in 4181 which case it must simply connect again when it is ready to send 4182 subsequent messages. 4184 The first four octets of the TCP stream used to transmit the request 4186 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4187 request will encode in network byte order the length of the request 4188 (KRB_KDC_REQ), and the length will be followed by the request itself. 4189 The response will similarly be preceeded by a 4 octet encoding in 4190 network byte order of the length of the KRB_KDC_REP or the KRB_ERROR 4191 message and will be followed by the KRB_KDC_REP or the KRB_ERROR 4192 response. If the sign bit is set on the integer represented by the 4193 first 4 octets, then the next 4 octets will be read, extending the 4194 length of the field by another 4 octets (less the sign bit which is 4195 reserved for future expansion). 4197 8.2.3. OSI transport 4199 During authentication of an OSI client to an OSI server, the mutual 4200 authentication of an OSI server to an OSI client, the transfer of 4201 credentials from an OSI client to an OSI server, or during exchange of 4202 private or integrity checked messages, Kerberos protocol messages may 4203 be treated as opaque objects and the type of the authentication 4204 mechanism will be: 4206 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} 4208 Depending on the situation, the opaque object will be an authentication 4209 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe 4210 message (KRB_SAFE), a private message (KRB_PRIV), or a credentials 4211 message (KRB_CRED). The opaque data contains an application code as 4212 specified in the ASN.1 description for each message. The application 4213 code may be used by Kerberos to determine the message type. 4215 8.2.3. Name of the TGS 4217 The principal identifier of the ticket-granting service shall be 4218 composed of three parts: (1) the realm of the KDC issuing the TGS 4219 ticket (2) a two-part name of type NT-SRV-INST, with the first part 4220 "krbtgt" and the second part the name of the realm which will accept 4221 the ticket-granting ticket. For example, a ticket-granting ticket 4222 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the 4223 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" 4224 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket 4225 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the 4226 MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), 4227 ("krbtgt", "MIT.EDU") (name). 4229 8.3. Protocol constants and associated values 4231 The following tables list constants used in the protocol and defines 4232 their meanings. Ranges are specified in the "specification" section 4233 that limit the values of constants for which values are defined here. 4234 This allows implementations to make assumptions about the maximum 4235 values that will be received for these constants. Implementation 4236 receiving values outside the range specified in the "specification" 4237 section may reject the request, but they must recover cleanly. 4239 Encryption type etype value block size minimum pad size confounder size 4240 NULL 0 1 0 0 4241 des-cbc-crc 1 8 4 8 4242 des-cbc-md4 2 8 0 8 4243 des-cbc-md5 3 8 0 8 4244 4 4245 des3-cbc-md5 5 8 0 8 4247 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4248 6 4249 des3-cbc-sha1 7 8 0 8 4250 dsaWithSHA1-CmsOID 9 (pkinit) 4251 md5WithRSAEncryption-CmsOID 10 (pkinit) 4252 sha1WithRSAEncryption-CmsOID 11 (pkinit) 4253 rc2CBC-EnvOID 12 (pkinit) 4254 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 4255 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 4256 des-ede3-cbc-Env-OID 15 (pkinit) 4257 des3-cbc-sha1-kd 16 (Tom Yu) 4258 rc4-hmac 23 (swift) 4259 rc4-hmac-exp 24 (swift) 4261 ENCTYPE_PK_CROSS 48 (reserved for pkcross) 4262 0x8003 4264 Checksum type sumtype value checksum size 4265 CRC32 1 4 4266 rsa-md4 2 16 4267 rsa-md4-des 3 24 4268 des-mac 4 16 4269 des-mac-k 5 8 4270 rsa-md4-des-k 6 16 (drop rsa ?) 4271 rsa-md5 7 16 (drop rsa ?) 4272 rsa-md5-des 8 24 (drop rsa ?) 4273 rsa-md5-des3 9 24 (drop rsa ?) 4274 hmac-sha1-des3-kd 12 20 4275 hmac-sha1-des3 13 20 4277 padata type padata-type value 4279 PA-TGS-REQ 1 4280 PA-ENC-TIMESTAMP 2 4281 PA-PW-SALT 3 4282 4 4283 PA-ENC-UNIX-TIME 5 (depricated) 4284 PA-SANDIA-SECUREID 6 4285 PA-SESAME 7 4286 PA-OSF-DCE 8 4287 PA-CYBERSAFE-SECUREID 9 4288 PA-AFS3-SALT 10 4289 PA-ETYPE-INFO 11 4290 PA-SAM-CHALLENGE 12 (sam/otp) 4291 PA-SAM-RESPONSE 13 (sam/otp) 4292 PA-PK-AS-REQ 14 (pkinit) 4293 PA-PK-AS-REP 15 (pkinit) 4294 PA-USE-SPECIFIED-KVNO 20 4295 PA-SAM-REDIRECT 21 (sam/otp) 4296 PA-GET-FROM-TYPED-DATA 22 4297 PA-SAM-ETYPE-INFO 23 (sam/otp) 4299 data-type value form of typed-data 4301 1-21 4302 TD-PADATA 22 4303 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 4304 TD-KRB-PRINCIPAL 102 4305 TD-KRB-REALM 103 4306 TD-TRUSTED-CERTIFIERS 104 4308 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4309 TD-CERTIFICATE-INDEX 105 4311 authorization data type ad-type value 4312 AD-IF-RELEVANT 1 4313 AD-INTENDED-FOR-SERVER 2 4314 AD-INTENDED-FOR-APPLICATION-CLASS 3 4315 AD-KDC-ISSUED 4 4316 AD-OR 5 4317 AD-MANDATORY-TICKET-EXTENSIONS 6 4318 AD-IN-TICKET-EXTENSIONS 7 4319 reserved values 8-63 4320 OSF-DCE 64 4321 SESAME 65 4322 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 4324 Ticket Extension Types 4326 TE-TYPE-NULL 0 Null ticket extension 4327 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 4328 2 TE-TYPE-PKCROSS-KDC (I have reservations) 4329 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 4330 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 4331 5 TE-TYPE-DEST-HOST (I have reservations) 4333 alternate authentication type method-type value 4334 reserved values 0-63 4335 ATT-CHALLENGE-RESPONSE 64 4337 transited encoding type tr-type value 4338 DOMAIN-X500-COMPRESS 1 4339 reserved values all others 4341 Label Value Meaning or MIT code 4343 pvno 5 current Kerberos protocol version number 4345 message types 4347 KRB_AS_REQ 10 Request for initial authentication 4348 KRB_AS_REP 11 Response to KRB_AS_REQ request 4349 KRB_TGS_REQ 12 Request for authentication based on TGT 4350 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4351 KRB_AP_REQ 14 application request to server 4352 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4353 KRB_SAFE 20 Safe (checksummed) application message 4354 KRB_PRIV 21 Private (encrypted) application message 4355 KRB_CRED 22 Private (encrypted) message to forward credentials 4356 KRB_ERROR 30 Error response 4358 name types 4360 KRB_NT_UNKNOWN 0 Name type not known 4361 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4362 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4363 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 4364 KRB_NT_SRV_XHST 4 Service with host as remaining components 4365 KRB_NT_UID 5 Unique ID 4366 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4368 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4369 error codes 4371 KDC_ERR_NONE 0 No error 4372 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4373 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4374 KDC_ERR_BAD_PVNO 3 Requested prot vers number not supported 4375 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 4376 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 4377 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4378 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4379 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 4380 KDC_ERR_NULL_KEY 9 The client or server has a null key 4381 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4382 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 4383 KDC_ERR_POLICY 12 KDC policy rejects request 4384 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4385 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4386 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4387 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4388 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4389 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4390 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4391 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4392 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4393 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4394 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password 4395 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 4396 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 4397 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 4398 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 4399 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 4400 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 4401 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 4402 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4403 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4404 KRB_AP_ERR_REPEAT 34 Request is a replay 4405 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4406 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4407 KRB_AP_ERR_SKEW 37 Clock skew too great 4408 KRB_AP_ERR_BADADDR 38 Incorrect net address 4409 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4410 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4411 KRB_AP_ERR_MODIFIED 41 Message stream modified 4412 KRB_AP_ERR_BADORDER 42 Message out of order 4413 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 4414 KRB_AP_ERR_NOKEY 45 Service key not available 4415 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4416 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4417 KRB_AP_ERR_METHOD 48 Alternative authentication method required 4418 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4419 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 4420 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 4421 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 4422 KRB_ERR_GENERIC 60 Generic error (description in e-text) 4423 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 4424 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 4425 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 4426 KDC_ERROR_INVALID_SIG 64 (pkinit) 4427 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 4429 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4430 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 4431 KRB_AP_ERR_NO_TGT 67 (user-to-user) 4432 KDC_ERR_WRONG_REALM 68 (user-to-user) 4433 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 4434 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 4435 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 4436 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 4437 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 4438 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 4439 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 4440 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 4442 9. Interoperability requirements 4444 Version 5 of the Kerberos protocol supports a myriad of options. Among 4445 these are multiple encryption and checksum types, alternative encoding 4446 schemes for the transited field, optional mechanisms for 4447 pre-authentication, the handling of tickets with no addresses, options 4448 for mutual authentication, user to user authentication, support for 4449 proxies, forwarding, postdating, and renewing tickets, the format of 4450 realm names, and the handling of authorization data. 4452 In order to ensure the interoperability of realms, it is necessary to 4453 define a minimal configuration which must be supported by all 4454 implementations. This minimal configuration is subject to change as 4455 technology does. For example, if at some later date it is discovered 4456 that one of the required encryption or checksum algorithms is not 4457 secure, it will be replaced. 4459 9.1. Specification 2 4461 This section defines the second specification of these options. 4462 Implementations which are configured in this way can be said to support 4463 Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) 4464 may be found in RFC1510. 4466 Transport 4468 TCP/IP and UDP/IP transport must be supported by KDCs claiming 4469 conformance to specification 2. Kerberos clients claiming conformance 4470 to specification 2 must support UDP/IP transport for messages with the 4471 KDC and should support TCP/IP transport. 4473 Encryption and checksum methods 4475 The following encryption and checksum mechanisms must be supported. 4476 Implementations may support other mechanisms as well, but the 4477 additional mechanisms may only be used when communicating with 4478 principals known to also support them: This list is to be determined. 4480 Encryption: DES-CBC-MD5, one triple des variant (tbd) 4481 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd) 4483 Realm Names 4485 All implementations must understand hierarchical realms in both the 4486 Internet Domain and the X.500 style. When a ticket granting ticket for 4487 an unknown realm is requested, the KDC must be able to determine the 4488 names of the intermediate realms between the KDCs realm and the 4490 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4491 requested realm. 4493 Transited field encoding 4495 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 4496 Alternative encodings may be supported, but they may be used only when 4497 that encoding is supported by ALL intermediate realms. 4499 Pre-authentication methods 4501 The TGS-REQ method must be supported. The TGS-REQ method is not used on 4502 the initial request. The PA-ENC-TIMESTAMP method must be supported by 4503 clients but whether it is enabled by default may be determined on a 4504 realm by realm basis. If not used in the initial request and the error 4505 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 4506 acceptable method, the client should retry the initial request using 4507 the PA-ENC-TIMESTAMP preauthentication method. Servers need not support 4508 the PA-ENC-TIMESTAMP method, but if not supported the server should 4509 ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a 4510 request. 4512 Mutual authentication 4514 Mutual authentication (via the KRB_AP_REP message) must be supported. 4516 Ticket addresses and flags 4518 All KDC's must pass on tickets that carry no addresses (i.e. if a TGT 4519 contains no addresses, the KDC will return derivative tickets), but 4520 each realm may set its own policy for issuing such tickets, and each 4521 application server will set its own policy with respect to accepting 4522 them. 4524 Proxies and forwarded tickets must be supported. Individual realms and 4525 application servers can set their own policy on when such tickets will 4526 be accepted. 4528 All implementations must recognize renewable and postdated tickets, but 4529 need not actually implement them. If these options are not supported, 4530 the starttime and endtime in the ticket shall specify a ticket's entire 4531 useful life. When a postdated ticket is decoded by a server, all 4532 implementations shall make the presence of the postdated flag visible 4533 to the calling server. 4535 User-to-user authentication 4537 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC 4538 option) must be provided by implementations, but individual realms may 4539 decide as a matter of policy to reject such requests on a per-principal 4540 or realm-wide basis. 4542 Authorization data 4544 Implementations must pass all authorization data subfields from 4545 ticket-granting tickets to any derivative tickets unless directed to 4546 suppress a subfield as part of the definition of that registered 4547 subfield type (it is never incorrect to pass on a subfield, and no 4548 registered subfield types presently specify suppression at the KDC). 4550 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4551 Implementations must make the contents of any authorization data 4552 subfields available to the server when a ticket is used. 4553 Implementations are not required to allow clients to specify the 4554 contents of the authorization data fields. 4556 Constant ranges 4558 All protocol constants are constrained to 32 bit (signed) values unless 4559 further constrained by the protocol definition. This limit is provided 4560 to allow implementations to make assumptions about the maximum values 4561 that will be received for these constants. Implementation receiving 4562 values outside this range may reject the request, but they must recover 4563 cleanly. 4565 9.2. Recommended KDC values 4567 Following is a list of recommended values for a KDC implementation, 4568 based on the list of suggested configuration constants (see section 4569 4.4). 4571 minimum lifetime 5 minutes 4572 maximum renewable lifetime 1 week 4573 maximum ticket lifetime 1 day 4574 empty addresses only when suitable restrictions appear 4575 in authorization data 4576 proxiable, etc. Allowed. 4578 10. REFERENCES 4580 [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- 4581 cation Service for Computer Networks," IEEE Communica- 4582 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). 4584 [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 4585 Saltzer, Section E.2.1: Kerberos Authentication and 4586 Authorization System, M.I.T. Project Athena, Cambridge, 4587 Massachusetts (December 21, 1987). 4589 [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 4590 beros: An Authentication Service for Open Network Sys- 4591 tems," pp. 191-202 in Usenix Conference Proceedings, 4592 Dallas, Texas (February, 1988). 4594 [NS78] Roger M. Needham and Michael D. Schroeder, "Using 4595 Encryption for Authentication in Large Networks of Com- 4596 puters," Communications of the ACM, Vol. 21(12), 4597 pp. 993-999 (December, 1978). 4599 [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- 4600 stamps in Key Distribution Protocols," Communications 4601 of the ACM, Vol. 24(8), pp. 533-536 (August 1981). 4603 [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 4604 "The Evolution of the Kerberos Authentication Service," 4605 in an IEEE Computer Society Text soon to be published 4606 (June 1992). 4608 [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and 4609 Accounting for Distributed Systems," in Proceedings of 4611 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4612 the 13th International Conference on Distributed Com- 4613 puting Systems, Pittsburgh, PA (May, 1993). 4615 [DS90] Don Davis and Ralph Swick, "Workstation Services and 4616 Kerberos Authentication at Project Athena," Technical 4617 Memorandum TM-424, MIT Laboratory for Computer Science 4618 (February 1990). 4620 [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 4621 merfeld, and K. Raeburn, Section E.1: Service Manage- 4622 ment System, M.I.T. Project Athena, Cambridge, Mas- 4623 sachusetts (1987). 4625 [X509-88] CCITT, Recommendation X.509: The Directory Authentica- 4626 tion Framework, December 1988. 4628 [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password 4629 Guessing Attacks, Open Software Foundation DCE Request 4630 for Comments 26 (December 1992). 4632 [DES77] National Bureau of Standards, U.S. Department of Com- 4633 merce, "Data Encryption Standard," Federal Information 4634 Processing Standards Publication 46, Washington, DC 4635 (1977). 4637 [DESM80] National Bureau of Standards, U.S. Department of Com- 4638 merce, "DES Modes of Operation," Federal Information 4639 Processing Standards Publication 81, Springfield, VA 4640 (December 1980). 4642 [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message 4643 Integrity in Cryptographic Protocols," in Proceedings 4644 of the IEEE Symposium on Research in Security and 4645 Privacy, Oakland, California (May 1992). 4647 [IS3309] International Organization for Standardization, "ISO 4648 Information Processing Systems - Data Communication - 4649 High-Level Data Link Control Procedure - Frame Struc- 4650 ture," IS 3309 (October 1984). 3rd Edition. 4652 [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC 4653 1320, MIT Laboratory for Computer Science (April 4654 1992). 4656 [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC 4657 1321, MIT Laboratory for Computer Science (April 4658 1992). 4660 [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- 4661 Hashing for Message Authentication," Working Draft 4662 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 4664 [Horowitz96] Horowitz, M., "Key Derivation for Authentication, 4665 Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, 4666 August 1998. 4668 [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- 4669 horowitz-kerb-key-derivation-01.txt, September 1998. 4671 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4673 [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: 4674 Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- 4675 md5-01.txt, August, 1996. 4677 A. Pseudo-code for protocol processing 4679 This appendix provides pseudo-code describing how the messages are to 4680 be constructed and interpreted by clients and servers. 4682 A.1. KRB_AS_REQ generation 4684 request.pvno := protocol version; /* pvno = 5 */ 4685 request.msg-type := message type; /* type = KRB_AS_REQ */ 4687 if(pa_enc_timestamp_required) then 4688 request.padata.padata-type = PA-ENC-TIMESTAMP; 4689 get system_time; 4690 padata-body.patimestamp,pausec = system_time; 4691 encrypt padata-body into request.padata.padata-value 4692 using client.key; /* derived from password */ 4693 endif 4695 body.kdc-options := users's preferences; 4696 body.cname := user's name; 4697 body.realm := user's realm; 4698 body.sname := service's name; /* usually "krbtgt", 4699 "localrealm" */ 4701 if (body.kdc-options.POSTDATED is set) then 4702 body.from := requested starting time; 4703 else 4704 omit body.from; 4705 endif 4706 body.till := requested end time; 4707 if (body.kdc-options.RENEWABLE is set) then 4708 body.rtime := requested final renewal time; 4709 endif 4710 body.nonce := random_nonce(); 4711 body.etype := requested etypes; 4712 if (user supplied addresses) then 4713 body.addresses := user's addresses; 4714 else 4715 omit body.addresses; 4716 endif 4717 omit body.enc-authorization-data; 4718 request.req-body := body; 4720 kerberos := lookup(name of local kerberos server (or servers)); 4721 send(packet,kerberos); 4723 wait(for response); 4724 if (timed_out) then 4725 retry or use alternate server; 4726 endif 4728 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 4730 decode message into req; 4732 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4733 client := lookup(req.cname,req.realm); 4734 server := lookup(req.sname,req.realm); 4736 get system_time; 4737 kdc_time := system_time.seconds; 4739 if (!client) then 4740 /* no client in Database */ 4741 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 4742 endif 4743 if (!server) then 4744 /* no server in Database */ 4745 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 4746 endif 4748 if(client.pa_enc_timestamp_required and 4749 pa_enc_timestamp not present) then 4750 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 4751 endif 4753 if(pa_enc_timestamp present) then 4754 decrypt req.padata-value into decrypted_enc_timestamp 4755 using client.key; 4756 using auth_hdr.authenticator.subkey; 4757 if (decrypt_error()) then 4758 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4759 if(decrypted_enc_timestamp is not within allowable skew) 4760 then 4761 error_out(KDC_ERR_PREAUTH_FAILED); 4762 endif 4763 if(decrypted_enc_timestamp and usec is replay) 4764 error_out(KDC_ERR_PREAUTH_FAILED); 4765 endif 4766 add decrypted_enc_timestamp and usec to replay cache; 4767 endif 4769 use_etype := first supported etype in req.etypes; 4771 if (no support for req.etypes) then 4772 error_out(KDC_ERR_ETYPE_NOSUPP); 4773 endif 4775 new_tkt.vno := ticket version; /* = 5 */ 4776 new_tkt.sname := req.sname; 4777 new_tkt.srealm := req.srealm; 4778 reset all flags in new_tkt.flags; 4780 /* It should be noted that local policy may affect the */ 4781 /* processing of any of these flags. For example, some */ 4782 /* realms may refuse to issue renewable tickets */ 4784 if (req.kdc-options.FORWARDABLE is set) then 4785 set new_tkt.flags.FORWARDABLE; 4786 endif 4787 if (req.kdc-options.PROXIABLE is set) then 4788 set new_tkt.flags.PROXIABLE; 4789 endif 4791 if (req.kdc-options.ALLOW-POSTDATE is set) then 4793 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4794 set new_tkt.flags.MAY-POSTDATE; 4795 endif 4796 if ((req.kdc-options.RENEW is set) or 4797 (req.kdc-options.VALIDATE is set) or 4798 (req.kdc-options.PROXY is set) or 4799 (req.kdc-options.FORWARDED is set) or 4800 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 4801 error_out(KDC_ERR_BADOPTION); 4802 endif 4804 new_tkt.session := random_session_key(); 4805 new_tkt.cname := req.cname; 4806 new_tkt.crealm := req.crealm; 4807 new_tkt.transited := empty_transited_field(); 4809 new_tkt.authtime := kdc_time; 4811 if (req.kdc-options.POSTDATED is set) then 4812 if (against_postdate_policy(req.from)) then 4813 error_out(KDC_ERR_POLICY); 4814 endif 4815 set new_tkt.flags.POSTDATED; 4816 set new_tkt.flags.INVALID; 4817 new_tkt.starttime := req.from; 4818 else 4819 omit new_tkt.starttime; /* treated as authtime when omitted */ 4820 endif 4821 if (req.till = 0) then 4822 till := infinity; 4823 else 4824 till := req.till; 4825 endif 4827 new_tkt.endtime := min(till, 4828 new_tkt.starttime+client.max_life, 4829 new_tkt.starttime+server.max_life, 4830 new_tkt.starttime+max_life_for_realm); 4832 if ((req.kdc-options.RENEWABLE-OK is set) and 4833 (new_tkt.endtime < req.till)) then 4834 /* we set the RENEWABLE option for later processing */ 4835 set req.kdc-options.RENEWABLE; 4836 req.rtime := req.till; 4837 endif 4839 if (req.rtime = 0) then 4840 rtime := infinity; 4841 else 4842 rtime := req.rtime; 4843 endif 4845 if (req.kdc-options.RENEWABLE is set) then 4846 set new_tkt.flags.RENEWABLE; 4847 new_tkt.renew-till := min(rtime, 4848 new_tkt.starttime+client.max_rlife, 4849 new_tkt.starttime+server.max_rlife, 4850 new_tkt.starttime+max_rlife_for_realm); 4851 else 4852 omit new_tkt.renew-till; /* only present if RENEWABLE */ 4854 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4855 endif 4857 if (req.addresses) then 4858 new_tkt.caddr := req.addresses; 4859 else 4860 omit new_tkt.caddr; 4861 endif 4863 new_tkt.authorization_data := empty_authorization_data(); 4865 encode to-be-encrypted part of ticket into OCTET STRING; 4866 new_tkt.enc-part := encrypt OCTET STRING 4867 using etype_for_key(server.key), server.key, server.p_kvno; 4869 /* Start processing the response */ 4871 resp.pvno := 5; 4872 resp.msg-type := KRB_AS_REP; 4873 resp.cname := req.cname; 4874 resp.crealm := req.realm; 4875 resp.ticket := new_tkt; 4877 resp.key := new_tkt.session; 4878 resp.last-req := fetch_last_request_info(client); 4879 resp.nonce := req.nonce; 4880 resp.key-expiration := client.expiration; 4881 resp.flags := new_tkt.flags; 4883 resp.authtime := new_tkt.authtime; 4884 resp.starttime := new_tkt.starttime; 4885 resp.endtime := new_tkt.endtime; 4887 if (new_tkt.flags.RENEWABLE) then 4888 resp.renew-till := new_tkt.renew-till; 4889 endif 4891 resp.realm := new_tkt.realm; 4892 resp.sname := new_tkt.sname; 4894 resp.caddr := new_tkt.caddr; 4896 encode body of reply into OCTET STRING; 4898 resp.enc-part := encrypt OCTET STRING 4899 using use_etype, client.key, client.p_kvno; 4900 send(resp); 4902 A.3. KRB_AS_REP verification 4904 decode response into resp; 4906 if (resp.msg-type = KRB_ERROR) then 4907 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 4908 set pa_enc_timestamp_required; 4909 goto KRB_AS_REQ; 4910 endif 4911 process_error(resp); 4912 return; 4913 endif 4915 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4916 /* On error, discard the response, and zero the session key */ 4917 /* from the response immediately */ 4919 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 4920 resp.padata); 4921 unencrypted part of resp := decode of decrypt of resp.enc-part 4922 using resp.enc-part.etype and key; 4923 zero(key); 4925 if (common_as_rep_tgs_rep_checks fail) then 4926 destroy resp.key; 4927 return error; 4928 endif 4930 if near(resp.princ_exp) then 4931 print(warning message); 4932 endif 4933 save_for_later(ticket,session,client,server,times,flags); 4935 A.4. KRB_AS_REP and KRB_TGS_REP common checks 4937 if (decryption_error() or 4938 (req.cname != resp.cname) or 4939 (req.realm != resp.crealm) or 4940 (req.sname != resp.sname) or 4941 (req.realm != resp.realm) or 4942 (req.nonce != resp.nonce) or 4943 (req.addresses != resp.caddr)) then 4944 destroy resp.key; 4945 return KRB_AP_ERR_MODIFIED; 4946 endif 4948 /* make sure no flags are set that shouldn't be, and that all that */ 4949 /* should be are set */ 4950 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 4951 destroy resp.key; 4952 return KRB_AP_ERR_MODIFIED; 4953 endif 4955 if ((req.from = 0) and 4956 (resp.starttime is not within allowable skew)) then 4957 destroy resp.key; 4958 return KRB_AP_ERR_SKEW; 4959 endif 4960 if ((req.from != 0) and (req.from != resp.starttime)) then 4961 destroy resp.key; 4962 return KRB_AP_ERR_MODIFIED; 4963 endif 4964 if ((req.till != 0) and (resp.endtime > req.till)) then 4965 destroy resp.key; 4966 return KRB_AP_ERR_MODIFIED; 4967 endif 4969 if ((req.kdc-options.RENEWABLE is set) and 4970 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 4971 destroy resp.key; 4972 return KRB_AP_ERR_MODIFIED; 4973 endif 4975 Neuman, Ts'o, Kohl Expires: 10 September, 2000 4976 if ((req.kdc-options.RENEWABLE-OK is set) and 4977 (resp.flags.RENEWABLE) and 4978 (req.till != 0) and 4979 (resp.renew-till > req.till)) then 4980 destroy resp.key; 4981 return KRB_AP_ERR_MODIFIED; 4982 endif 4984 A.5. KRB_TGS_REQ generation 4986 /* Note that make_application_request might have to recursivly */ 4987 /* call this routine to get the appropriate ticket-granting ticket */ 4989 request.pvno := protocol version; /* pvno = 5 */ 4990 request.msg-type := message type; /* type = KRB_TGS_REQ */ 4992 body.kdc-options := users's preferences; 4993 /* If the TGT is not for the realm of the end-server */ 4994 /* then the sname will be for a TGT for the end-realm */ 4995 /* and the realm of the requested ticket (body.realm) */ 4996 /* will be that of the TGS to which the TGT we are */ 4997 /* sending applies */ 4998 body.sname := service's name; 4999 body.realm := service's realm; 5001 if (body.kdc-options.POSTDATED is set) then 5002 body.from := requested starting time; 5003 else 5004 omit body.from; 5005 endif 5006 body.till := requested end time; 5007 if (body.kdc-options.RENEWABLE is set) then 5008 body.rtime := requested final renewal time; 5009 endif 5010 body.nonce := random_nonce(); 5011 body.etype := requested etypes; 5012 if (user supplied addresses) then 5013 body.addresses := user's addresses; 5014 else 5015 omit body.addresses; 5016 endif 5018 body.enc-authorization-data := user-supplied data; 5019 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5020 body.additional-tickets_ticket := second TGT; 5021 endif 5023 request.req-body := body; 5024 check := generate_checksum (req.body,checksumtype); 5026 request.padata[0].padata-type := PA-TGS-REQ; 5027 request.padata[0].padata-value := create a KRB_AP_REQ using 5028 the TGT and checksum 5030 /* add in any other padata as required/supplied */ 5032 kerberos := lookup(name of local kerberose server (or servers)); 5033 send(packet,kerberos); 5035 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5036 wait(for response); 5037 if (timed_out) then 5038 retry or use alternate server; 5039 endif 5041 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5043 /* note that reading the application request requires first 5044 determining the server for which a ticket was issued, and 5045 choosing the correct key for decryption. The name of the 5046 server appears in the plaintext part of the ticket. */ 5048 if (no KRB_AP_REQ in req.padata) then 5049 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5050 endif 5051 verify KRB_AP_REQ in req.padata; 5053 /* Note that the realm in which the Kerberos server is 5054 operating is determined by the instance from the 5055 ticket-granting ticket. The realm in the ticket-granting 5056 ticket is the realm under which the ticket granting 5057 ticket was issued. It is possible for a single Kerberos 5058 server to support more than one realm. */ 5060 auth_hdr := KRB_AP_REQ; 5061 tgt := auth_hdr.ticket; 5063 if (tgt.sname is not a TGT for local realm and is not req.sname) 5064 then 5065 error_out(KRB_AP_ERR_NOT_US); 5067 realm := realm_tgt_is_for(tgt); 5069 decode remainder of request; 5071 if (auth_hdr.authenticator.cksum is missing) then 5072 error_out(KRB_AP_ERR_INAPP_CKSUM); 5073 endif 5075 if (auth_hdr.authenticator.cksum type is not supported) then 5076 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5077 endif 5078 if (auth_hdr.authenticator.cksum is not both collision-proof 5079 and keyed) then 5080 error_out(KRB_AP_ERR_INAPP_CKSUM); 5081 endif 5083 set computed_checksum := checksum(req); 5084 if (computed_checksum != auth_hdr.authenticatory.cksum) then 5085 error_out(KRB_AP_ERR_MODIFIED); 5086 endif 5088 server := lookup(req.sname,realm); 5090 if (!server) then 5091 if (is_foreign_tgt_name(req.sname)) then 5092 server := best_intermediate_tgs(req.sname); 5093 else 5094 /* no server in Database */ 5096 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5097 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5098 endif 5099 endif 5101 session := generate_random_session_key(); 5103 use_etype := first supported etype in req.etypes; 5105 if (no support for req.etypes) then 5106 error_out(KDC_ERR_ETYPE_NOSUPP); 5107 endif 5109 new_tkt.vno := ticket version; /* = 5 */ 5110 new_tkt.sname := req.sname; 5111 new_tkt.srealm := realm; 5112 reset all flags in new_tkt.flags; 5114 /* It should be noted that local policy may affect the */ 5115 /* processing of any of these flags. For example, some */ 5116 /* realms may refuse to issue renewable tickets */ 5118 new_tkt.caddr := tgt.caddr; 5119 resp.caddr := NULL; /* We only include this if they change */ 5120 if (req.kdc-options.FORWARDABLE is set) then 5121 if (tgt.flags.FORWARDABLE is reset) then 5122 error_out(KDC_ERR_BADOPTION); 5123 endif 5124 set new_tkt.flags.FORWARDABLE; 5125 endif 5126 if (req.kdc-options.FORWARDED is set) then 5127 if (tgt.flags.FORWARDABLE is reset) then 5128 error_out(KDC_ERR_BADOPTION); 5129 endif 5130 set new_tkt.flags.FORWARDED; 5131 new_tkt.caddr := req.addresses; 5132 resp.caddr := req.addresses; 5133 endif 5134 if (tgt.flags.FORWARDED is set) then 5135 set new_tkt.flags.FORWARDED; 5136 endif 5138 if (req.kdc-options.PROXIABLE is set) then 5139 if (tgt.flags.PROXIABLE is reset) 5140 error_out(KDC_ERR_BADOPTION); 5141 endif 5142 set new_tkt.flags.PROXIABLE; 5143 endif 5144 if (req.kdc-options.PROXY is set) then 5145 if (tgt.flags.PROXIABLE is reset) then 5146 error_out(KDC_ERR_BADOPTION); 5147 endif 5148 set new_tkt.flags.PROXY; 5149 new_tkt.caddr := req.addresses; 5150 resp.caddr := req.addresses; 5151 endif 5153 if (req.kdc-options.ALLOW-POSTDATE is set) then 5154 if (tgt.flags.MAY-POSTDATE is reset) 5155 error_out(KDC_ERR_BADOPTION); 5157 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5158 endif 5159 set new_tkt.flags.MAY-POSTDATE; 5160 endif 5161 if (req.kdc-options.POSTDATED is set) then 5162 if (tgt.flags.MAY-POSTDATE is reset) then 5163 error_out(KDC_ERR_BADOPTION); 5164 endif 5165 set new_tkt.flags.POSTDATED; 5166 set new_tkt.flags.INVALID; 5167 if (against_postdate_policy(req.from)) then 5168 error_out(KDC_ERR_POLICY); 5169 endif 5170 new_tkt.starttime := req.from; 5171 endif 5173 if (req.kdc-options.VALIDATE is set) then 5174 if (tgt.flags.INVALID is reset) then 5175 error_out(KDC_ERR_POLICY); 5176 endif 5177 if (tgt.starttime > kdc_time) then 5178 error_out(KRB_AP_ERR_NYV); 5179 endif 5180 if (check_hot_list(tgt)) then 5181 error_out(KRB_AP_ERR_REPEAT); 5182 endif 5183 tkt := tgt; 5184 reset new_tkt.flags.INVALID; 5185 endif 5187 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 5188 and those already processed) is set) then 5189 error_out(KDC_ERR_BADOPTION); 5190 endif 5192 new_tkt.authtime := tgt.authtime; 5194 if (req.kdc-options.RENEW is set) then 5195 /* Note that if the endtime has already passed, the ticket would */ 5196 /* have been rejected in the initial authentication stage, so */ 5197 /* there is no need to check again here */ 5198 if (tgt.flags.RENEWABLE is reset) then 5199 error_out(KDC_ERR_BADOPTION); 5200 endif 5201 if (tgt.renew-till < kdc_time) then 5202 error_out(KRB_AP_ERR_TKT_EXPIRED); 5203 endif 5204 tkt := tgt; 5205 new_tkt.starttime := kdc_time; 5206 old_life := tgt.endttime - tgt.starttime; 5207 new_tkt.endtime := min(tgt.renew-till, 5208 new_tkt.starttime + old_life); 5209 else 5210 new_tkt.starttime := kdc_time; 5211 if (req.till = 0) then 5212 till := infinity; 5213 else 5214 till := req.till; 5215 endif 5216 new_tkt.endtime := min(till, 5218 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5219 new_tkt.starttime+client.max_life, 5220 new_tkt.starttime+server.max_life, 5221 new_tkt.starttime+max_life_for_realm, 5222 tgt.endtime); 5224 if ((req.kdc-options.RENEWABLE-OK is set) and 5225 (new_tkt.endtime < req.till) and 5226 (tgt.flags.RENEWABLE is set) then 5227 /* we set the RENEWABLE option for later processing */ 5228 set req.kdc-options.RENEWABLE; 5229 req.rtime := min(req.till, tgt.renew-till); 5230 endif 5231 endif 5233 if (req.rtime = 0) then 5234 rtime := infinity; 5235 else 5236 rtime := req.rtime; 5237 endif 5239 if ((req.kdc-options.RENEWABLE is set) and 5240 (tgt.flags.RENEWABLE is set)) then 5241 set new_tkt.flags.RENEWABLE; 5242 new_tkt.renew-till := min(rtime, 5243 new_tkt.starttime+client.max_rlife, 5244 new_tkt.starttime+server.max_rlife, 5245 new_tkt.starttime+max_rlife_for_realm, 5246 tgt.renew-till); 5247 else 5248 new_tkt.renew-till := OMIT; /* leave the 5249 renew-till field out */ 5250 endif 5251 if (req.enc-authorization-data is present) then 5252 decrypt req.enc-authorization-data into 5253 decrypted_authorization_data 5254 using auth_hdr.authenticator.subkey; 5255 if (decrypt_error()) then 5256 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5257 endif 5258 endif 5259 new_tkt.authorization_data := 5260 req.auth_hdr.ticket.authorization_data + 5261 decrypted_authorization_data; 5263 new_tkt.key := session; 5264 new_tkt.crealm := tgt.crealm; 5265 new_tkt.cname := req.auth_hdr.ticket.cname; 5267 if (realm_tgt_is_for(tgt) := tgt.realm) then 5268 /* tgt issued by local realm */ 5269 new_tkt.transited := tgt.transited; 5270 else 5271 /* was issued for this realm by some other realm */ 5272 if (tgt.transited.tr-type not supported) then 5273 error_out(KDC_ERR_TRTYPE_NOSUPP); 5274 endif 5275 new_tkt.transited := 5276 compress_transited(tgt.transited + tgt.realm) 5277 /* Don't check tranited field if TGT for foreign realm, 5279 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5280 * or requested not to check */ 5281 if (is_not_foreign_tgt_name(new_tkt.server) 5282 && req.kdc-options.DISABLE-TRANSITED-CHECK not 5283 set) then 5284 /* Check it, so end-server does not have to 5285 * but don't fail, end-server may still accept it */ 5286 if (check_transited_field(new_tkt.transited) == OK) 5287 set new_tkt.flags.TRANSITED-POLICY-CHECKED; 5288 endif 5289 endif 5290 endif 5292 encode encrypted part of new_tkt into OCTET STRING; 5293 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 5294 if (server not specified) then 5295 server = req.second_ticket.client; 5296 endif 5297 if ((req.second_ticket is not a TGT) or 5298 (req.second_ticket.client != server)) then 5299 error_out(KDC_ERR_POLICY); 5300 endif 5302 new_tkt.enc-part := encrypt OCTET STRING using 5303 using etype_for_key(second-ticket.key), 5304 second-ticket.key; 5305 else 5306 new_tkt.enc-part := encrypt OCTET STRING 5307 using etype_for_key(server.key), 5308 server.key, server.p_kvno; 5309 endif 5311 resp.pvno := 5; 5312 resp.msg-type := KRB_TGS_REP; 5313 resp.crealm := tgt.crealm; 5314 resp.cname := tgt.cname; 5315 resp.ticket := new_tkt; 5317 resp.key := session; 5318 resp.nonce := req.nonce; 5319 resp.last-req := fetch_last_request_info(client); 5320 resp.flags := new_tkt.flags; 5322 resp.authtime := new_tkt.authtime; 5323 resp.starttime := new_tkt.starttime; 5324 resp.endtime := new_tkt.endtime; 5326 omit resp.key-expiration; 5328 resp.sname := new_tkt.sname; 5329 resp.realm := new_tkt.realm; 5331 if (new_tkt.flags.RENEWABLE) then 5332 resp.renew-till := new_tkt.renew-till; 5333 endif 5335 encode body of reply into OCTET STRING; 5337 if (req.padata.authenticator.subkey) 5338 resp.enc-part := encrypt OCTET STRING using use_etype, 5340 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5341 req.padata.authenticator.subkey; 5342 else resp.enc-part := encrypt OCTET STRING using 5343 use_etype, tgt.key; 5345 send(resp); 5347 A.7. KRB_TGS_REP verification 5349 decode response into resp; 5351 if (resp.msg-type = KRB_ERROR) then 5352 process_error(resp); 5353 return; 5354 endif 5356 /* On error, discard the response, and zero the session key from 5357 the response immediately */ 5359 if (req.padata.authenticator.subkey) 5360 unencrypted part of resp := decode of decrypt of 5361 resp.enc-part 5362 using resp.enc-part.etype and subkey; 5363 else unencrypted part of resp := decode of decrypt of 5364 resp.enc-part 5365 using resp.enc-part.etype and 5366 tgt's session key; 5367 if (common_as_rep_tgs_rep_checks fail) then 5368 destroy resp.key; 5369 return error; 5370 endif 5372 check authorization_data as necessary; 5373 save_for_later(ticket,session,client,server,times,flags); 5375 A.8. Authenticator generation 5377 body.authenticator-vno := authenticator vno; /* = 5 */ 5378 body.cname, body.crealm := client name; 5379 if (supplying checksum) then 5380 body.cksum := checksum; 5381 endif 5382 get system_time; 5383 body.ctime, body.cusec := system_time; 5384 if (selecting sub-session key) then 5385 select sub-session key; 5386 body.subkey := sub-session key; 5387 endif 5388 if (using sequence numbers) then 5389 select initial sequence number; 5390 body.seq-number := initial sequence; 5391 endif 5393 A.9. KRB_AP_REQ generation 5395 obtain ticket and session_key from cache; 5397 packet.pvno := protocol version; /* 5 */ 5398 packet.msg-type := message type; /* KRB_AP_REQ */ 5400 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5401 if (desired(MUTUAL_AUTHENTICATION)) then 5402 set packet.ap-options.MUTUAL-REQUIRED; 5403 else 5404 reset packet.ap-options.MUTUAL-REQUIRED; 5405 endif 5406 if (using session key for ticket) then 5407 set packet.ap-options.USE-SESSION-KEY; 5408 else 5409 reset packet.ap-options.USE-SESSION-KEY; 5410 endif 5411 packet.ticket := ticket; /* ticket */ 5412 generate authenticator; 5413 encode authenticator into OCTET STRING; 5414 encrypt OCTET STRING into packet.authenticator using session_key; 5416 A.10. KRB_AP_REQ verification 5418 receive packet; 5419 if (packet.pvno != 5) then 5420 either process using other protocol spec 5421 or error_out(KRB_AP_ERR_BADVERSION); 5422 endif 5423 if (packet.msg-type != KRB_AP_REQ) then 5424 error_out(KRB_AP_ERR_MSG_TYPE); 5425 endif 5426 if (packet.ticket.tkt_vno != 5) then 5427 either process using other protocol spec 5428 or error_out(KRB_AP_ERR_BADVERSION); 5429 endif 5430 if (packet.ap_options.USE-SESSION-KEY is set) then 5431 retrieve session key from ticket-granting ticket for 5432 packet.ticket.{sname,srealm,enc-part.etype}; 5433 else 5434 retrieve service key for 5435 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 5436 endif 5437 if (no_key_available) then 5438 if (cannot_find_specified_skvno) then 5439 error_out(KRB_AP_ERR_BADKEYVER); 5440 else 5441 error_out(KRB_AP_ERR_NOKEY); 5442 endif 5443 endif 5444 decrypt packet.ticket.enc-part into decr_ticket using 5445 retrieved key; 5446 if (decryption_error()) then 5447 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5448 endif 5449 decrypt packet.authenticator into decr_authenticator 5450 using decr_ticket.key; 5451 if (decryption_error()) then 5452 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5453 endif 5454 if (decr_authenticator.{cname,crealm} != 5455 decr_ticket.{cname,crealm}) then 5456 error_out(KRB_AP_ERR_BADMATCH); 5457 endif 5458 if (decr_ticket.caddr is present) then 5459 if (sender_address(packet) is not in 5461 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5462 decr_ticket.caddr) then 5463 error_out(KRB_AP_ERR_BADADDR); 5464 endif 5465 elseif (application requires addresses) then 5466 error_out(KRB_AP_ERR_BADADDR); 5467 endif 5468 if (not in_clock_skew(decr_authenticator.ctime, 5469 decr_authenticator.cusec)) then 5470 error_out(KRB_AP_ERR_SKEW); 5471 endif 5472 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 5473 error_out(KRB_AP_ERR_REPEAT); 5474 endif 5475 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 5476 get system_time; 5477 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 5478 (decr_ticket.flags.INVALID is set)) then 5479 /* it hasn't yet become valid */ 5480 error_out(KRB_AP_ERR_TKT_NYV); 5481 endif 5482 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 5483 error_out(KRB_AP_ERR_TKT_EXPIRED); 5484 endif 5485 if (decr_ticket.transited) then 5486 /* caller may ignore the TRANSITED-POLICY-CHECKED and do 5487 * check anyway */ 5488 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then 5489 if (check_transited_field(decr_ticket.transited) then 5490 error_out(KDC_AP_PATH_NOT_ACCPETED); 5491 endif 5492 endif 5493 endif 5494 /* caller must check decr_ticket.flags for any pertinent details */ 5495 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 5497 A.11. KRB_AP_REP generation 5499 packet.pvno := protocol version; /* 5 */ 5500 packet.msg-type := message type; /* KRB_AP_REP */ 5502 body.ctime := packet.ctime; 5503 body.cusec := packet.cusec; 5504 if (selecting sub-session key) then 5505 select sub-session key; 5506 body.subkey := sub-session key; 5507 endif 5508 if (using sequence numbers) then 5509 select initial sequence number; 5510 body.seq-number := initial sequence; 5511 endif 5513 encode body into OCTET STRING; 5515 select encryption type; 5516 encrypt OCTET STRING into packet.enc-part; 5518 A.12. KRB_AP_REP verification 5520 receive packet; 5522 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5523 if (packet.pvno != 5) then 5524 either process using other protocol spec 5525 or error_out(KRB_AP_ERR_BADVERSION); 5526 endif 5527 if (packet.msg-type != KRB_AP_REP) then 5528 error_out(KRB_AP_ERR_MSG_TYPE); 5529 endif 5530 cleartext := decrypt(packet.enc-part) using ticket's session key; 5531 if (decryption_error()) then 5532 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5533 endif 5534 if (cleartext.ctime != authenticator.ctime) then 5535 error_out(KRB_AP_ERR_MUT_FAIL); 5536 endif 5537 if (cleartext.cusec != authenticator.cusec) then 5538 error_out(KRB_AP_ERR_MUT_FAIL); 5539 endif 5540 if (cleartext.subkey is present) then 5541 save cleartext.subkey for future use; 5542 endif 5543 if (cleartext.seq-number is present) then 5544 save cleartext.seq-number for future verifications; 5545 endif 5546 return(AUTHENTICATION_SUCCEEDED); 5548 A.13. KRB_SAFE generation 5550 collect user data in buffer; 5552 /* assemble packet: */ 5553 packet.pvno := protocol version; /* 5 */ 5554 packet.msg-type := message type; /* KRB_SAFE */ 5556 body.user-data := buffer; /* DATA */ 5557 if (using timestamp) then 5558 get system_time; 5559 body.timestamp, body.usec := system_time; 5560 endif 5561 if (using sequence numbers) then 5562 body.seq-number := sequence number; 5563 endif 5564 body.s-address := sender host addresses; 5565 if (only one recipient) then 5566 body.r-address := recipient host address; 5567 endif 5568 checksum.cksumtype := checksum type; 5569 compute checksum over body; 5570 checksum.checksum := checksum value; /* checksum.checksum */ 5571 packet.cksum := checksum; 5572 packet.safe-body := body; 5574 A.14. KRB_SAFE verification 5576 receive packet; 5577 if (packet.pvno != 5) then 5578 either process using other protocol spec 5579 or error_out(KRB_AP_ERR_BADVERSION); 5580 endif 5581 if (packet.msg-type != KRB_SAFE) then 5583 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5584 error_out(KRB_AP_ERR_MSG_TYPE); 5585 endif 5586 if (packet.checksum.cksumtype is not both collision-proof 5587 and keyed) then 5588 error_out(KRB_AP_ERR_INAPP_CKSUM); 5589 endif 5590 if (safe_priv_common_checks_ok(packet)) then 5591 set computed_checksum := checksum(packet.body); 5592 if (computed_checksum != packet.checksum) then 5593 error_out(KRB_AP_ERR_MODIFIED); 5594 endif 5595 return (packet, PACKET_IS_GENUINE); 5596 else 5597 return common_checks_error; 5598 endif 5600 A.15. KRB_SAFE and KRB_PRIV common checks 5602 if (packet.s-address != O/S_sender(packet)) then 5603 /* O/S report of sender not who claims to have sent it */ 5604 error_out(KRB_AP_ERR_BADADDR); 5605 endif 5606 if ((packet.r-address is present) and 5607 (packet.r-address != local_host_address)) then 5608 /* was not sent to proper place */ 5609 error_out(KRB_AP_ERR_BADADDR); 5610 endif 5611 if (((packet.timestamp is present) and 5612 (not in_clock_skew(packet.timestamp,packet.usec))) or 5613 (packet.timestamp is not present and timestamp expected)) then 5614 error_out(KRB_AP_ERR_SKEW); 5615 endif 5616 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 5617 error_out(KRB_AP_ERR_REPEAT); 5618 endif 5620 if (((packet.seq-number is present) and 5621 ((not in_sequence(packet.seq-number)))) or 5622 (packet.seq-number is not present and sequence expected)) then 5623 error_out(KRB_AP_ERR_BADORDER); 5624 endif 5625 if (packet.timestamp not present and packet.seq-number 5626 not present) then 5627 error_out(KRB_AP_ERR_MODIFIED); 5628 endif 5630 save_identifier(packet.{timestamp,usec,s-address}, 5631 sender_principal(packet)); 5633 return PACKET_IS_OK; 5635 A.16. KRB_PRIV generation 5637 collect user data in buffer; 5639 /* assemble packet: */ 5640 packet.pvno := protocol version; /* 5 */ 5641 packet.msg-type := message type; /* KRB_PRIV */ 5643 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5644 packet.enc-part.etype := encryption type; 5646 body.user-data := buffer; 5647 if (using timestamp) then 5648 get system_time; 5649 body.timestamp, body.usec := system_time; 5650 endif 5651 if (using sequence numbers) then 5652 body.seq-number := sequence number; 5653 endif 5654 body.s-address := sender host addresses; 5655 if (only one recipient) then 5656 body.r-address := recipient host address; 5657 endif 5659 encode body into OCTET STRING; 5661 select encryption type; 5662 encrypt OCTET STRING into packet.enc-part.cipher; 5664 A.17. KRB_PRIV verification 5666 receive packet; 5667 if (packet.pvno != 5) then 5668 either process using other protocol spec 5669 or error_out(KRB_AP_ERR_BADVERSION); 5670 endif 5671 if (packet.msg-type != KRB_PRIV) then 5672 error_out(KRB_AP_ERR_MSG_TYPE); 5673 endif 5675 cleartext := decrypt(packet.enc-part) using negotiated key; 5676 if (decryption_error()) then 5677 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5678 endif 5680 if (safe_priv_common_checks_ok(cleartext)) then 5681 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 5682 else 5683 return common_checks_error; 5684 endif 5686 A.18. KRB_CRED generation 5688 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 5690 /* assemble packet: */ 5691 packet.pvno := protocol version; /* 5 */ 5692 packet.msg-type := message type; /* KRB_CRED */ 5694 for (tickets[n] in tickets to be forwarded) do 5695 packet.tickets[n] = tickets[n].ticket; 5696 done 5698 packet.enc-part.etype := encryption type; 5700 for (ticket[n] in tickets to be forwarded) do 5701 body.ticket-info[n].key = tickets[n].session; 5702 body.ticket-info[n].prealm = tickets[n].crealm; 5704 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5705 body.ticket-info[n].pname = tickets[n].cname; 5706 body.ticket-info[n].flags = tickets[n].flags; 5707 body.ticket-info[n].authtime = tickets[n].authtime; 5708 body.ticket-info[n].starttime = tickets[n].starttime; 5709 body.ticket-info[n].endtime = tickets[n].endtime; 5710 body.ticket-info[n].renew-till = tickets[n].renew-till; 5711 body.ticket-info[n].srealm = tickets[n].srealm; 5712 body.ticket-info[n].sname = tickets[n].sname; 5713 body.ticket-info[n].caddr = tickets[n].caddr; 5714 done 5716 get system_time; 5717 body.timestamp, body.usec := system_time; 5719 if (using nonce) then 5720 body.nonce := nonce; 5721 endif 5723 if (using s-address) then 5724 body.s-address := sender host addresses; 5725 endif 5726 if (limited recipients) then 5727 body.r-address := recipient host address; 5728 endif 5730 encode body into OCTET STRING; 5732 select encryption type; 5733 encrypt OCTET STRING into packet.enc-part.cipher 5734 using negotiated encryption key; 5736 A.19. KRB_CRED verification 5738 receive packet; 5739 if (packet.pvno != 5) then 5740 either process using other protocol spec 5741 or error_out(KRB_AP_ERR_BADVERSION); 5742 endif 5743 if (packet.msg-type != KRB_CRED) then 5744 error_out(KRB_AP_ERR_MSG_TYPE); 5745 endif 5747 cleartext := decrypt(packet.enc-part) using negotiated key; 5748 if (decryption_error()) then 5749 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5750 endif 5751 if ((packet.r-address is present or required) and 5752 (packet.s-address != O/S_sender(packet)) then 5753 /* O/S report of sender not who claims to have sent it */ 5754 error_out(KRB_AP_ERR_BADADDR); 5755 endif 5756 if ((packet.r-address is present) and 5757 (packet.r-address != local_host_address)) then 5758 /* was not sent to proper place */ 5759 error_out(KRB_AP_ERR_BADADDR); 5760 endif 5761 if (not in_clock_skew(packet.timestamp,packet.usec)) then 5762 error_out(KRB_AP_ERR_SKEW); 5763 endif 5765 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5766 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 5767 error_out(KRB_AP_ERR_REPEAT); 5768 endif 5769 if (packet.nonce is required or present) and 5770 (packet.nonce != expected-nonce) then 5771 error_out(KRB_AP_ERR_MODIFIED); 5772 endif 5774 for (ticket[n] in tickets that were forwarded) do 5775 save_for_later(ticket[n],key[n],principal[n], 5776 server[n],times[n],flags[n]); 5777 return 5779 A.20. KRB_ERROR generation 5781 /* assemble packet: */ 5782 packet.pvno := protocol version; /* 5 */ 5783 packet.msg-type := message type; /* KRB_ERROR */ 5785 get system_time; 5786 packet.stime, packet.susec := system_time; 5787 packet.realm, packet.sname := server name; 5789 if (client time available) then 5790 packet.ctime, packet.cusec := client_time; 5791 endif 5792 packet.error-code := error code; 5793 if (client name available) then 5794 packet.cname, packet.crealm := client name; 5795 endif 5796 if (error text available) then 5797 packet.e-text := error text; 5798 endif 5799 if (error data available) then 5800 packet.e-data := error data; 5801 endif 5803 B. Definition of common authorization data elements 5805 This appendix contains the definitions of common authorization data 5806 elements. These common authorization data elements are recursivly 5807 defined, meaning the ad-data for these types will itself contain a 5808 sequence of authorization data whose interpretation is affected by the 5809 encapsulating element. Depending on the meaning of the encapsulating 5810 element, the encapsulated elements may be ignored, might be interpreted 5811 as issued directly by the KDC, or they might be stored in a separate 5812 plaintext part of the ticket. The types of the encapsulating elements 5813 are specified as part of the Kerberos specification because the 5814 behavior based on these values should be understood across 5815 implementations whereas other elements need only be understood by the 5816 applications which they affect. 5818 In the definitions that follow, the value of the ad-type for the 5819 element will be specified in the subsection number, and the value of 5820 the ad-data will be as shown in the ASN.1 structure that follows the 5821 subsection heading. 5823 B.1. If relevant 5825 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5826 AD-IF-RELEVANT AuthorizationData 5828 AD elements encapsulated within the if-relevant element are intended 5829 for interpretation only by application servers that understand the 5830 particular ad-type of the embedded element. Application servers that do 5831 not understand the type of an element embedded within the if-relevant 5832 element may ignore the uninterpretable element. This element promotes 5833 interoperability across implementations which may have local extensions 5834 for authorization. 5836 B.2. Intended for server 5838 AD-INTENDED-FOR-SERVER SEQUENCE { 5839 intended-server[0] SEQUENCE OF PrincipalName 5840 elements[1] AuthorizationData 5841 } 5843 AD elements encapsulated within the intended-for-server element may be 5844 ignored if the application server is not in the list of principal names 5845 of intended servers. Further, a KDC issuing a ticket for an application 5846 server can remove this element if the application server is not in the 5847 list of intended servers. 5849 Application servers should check for their principal name in the 5850 intended-server field of this element. If their principal name is not 5851 found, this element should be ignored. If found, then the encapsulated 5852 elements should be evaluated in the same manner as if they were present 5853 in the top level authorization data field. Applications and application 5854 servers that do not implement this element should reject tickets that 5855 contain authorization data elements of this type. 5857 B.3. Intended for application class 5859 AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { 5860 intended-application-class[0] SEQUENCE OF GeneralString elements[1] 5861 AuthorizationData } AD elements encapsulated within the 5862 intended-for-application-class element may be ignored if the 5863 application server is not in one of the named classes of application 5864 servers. Examples of application server classes include "FILESYSTEM", 5865 and other kinds of servers. 5867 This element and the elements it encapulates may be safely ignored by 5868 applications, application servers, and KDCs that do not implement this 5869 element. 5871 B.4. KDC Issued 5873 AD-KDCIssued SEQUENCE { 5874 ad-checksum[0] Checksum, 5875 i-realm[1] Realm OPTIONAL, 5876 i-sname[2] PrincipalName OPTIONAL, 5877 elements[3] AuthorizationData. 5878 } 5880 ad-checksum 5881 A checksum over the elements field using a cryptographic checksum 5882 method that is identical to the checksum used to protect the 5883 ticket itself (i.e. using the same hash function and the same 5884 encryption algorithm used to encrypt the ticket) and using a key 5886 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5887 derived from the same key used to protect the ticket. 5888 i-realm, i-sname 5889 The name of the issuing principal if different from the KDC 5890 itself. This field would be used when the KDC can verify the 5891 authenticity of elements signed by the issuing principal and it 5892 allows this KDC to notify the application server of the validity 5893 of those elements. 5894 elements 5895 A sequence of authorization data elements issued by the KDC. 5896 The KDC-issued ad-data field is intended to provide a means for 5897 Kerberos principal credentials to embed within themselves privilege 5898 attributes and other mechanisms for positive authorization, amplifying 5899 the priveleges of the principal beyond what can be done using a 5900 credentials without such an a-data element. 5902 This can not be provided without this element because the definition of 5903 the authorization-data field allows elements to be added at will by the 5904 bearer of a TGT at the time that they request service tickets and 5905 elements may also be added to a delegated ticket by inclusion in the 5906 authenticator. 5908 For KDC-issued elements this is prevented because the elements are 5909 signed by the KDC by including a checksum encrypted using the server's 5910 key (the same key used to encrypt the ticket - or a key derived from 5911 that key). Elements encapsulated with in the KDC-issued element will be 5912 ignored by the application server if this "signature" is not present. 5913 Further, elements encapsulated within this element from a ticket 5914 granting ticket may be interpreted by the KDC, and used as a basis 5915 according to policy for including new signed elements within derivative 5916 tickets, but they will not be copied to a derivative ticket directly. 5917 If they are copied directly to a derivative ticket by a KDC that is not 5918 aware of this element, the signature will not be correct for the 5919 application ticket elements, and the field will be ignored by the 5920 application server. 5922 This element and the elements it encapulates may be safely ignored by 5923 applications, application servers, and KDCs that do not implement this 5924 element. 5926 B.5. And-Or 5928 AD-AND-OR SEQUENCE { 5929 condition-count[0] INTEGER, 5930 elements[1] AuthorizationData 5931 } 5933 When restrictive AD elements encapsulated within the and-or element are 5934 encountered, only the number specified in condition-count of the 5935 encapsulated conditions must be met in order to satisfy this element. 5936 This element may be used to implement an "or" operation by setting the 5937 condition-count field to 1, and it may specify an "and" operation by 5938 setting the condition count to the number of embedded elements. 5939 Application servers that do not implement this element must reject 5940 tickets that contain authorization data elements of this type. 5942 B.6. Mandatory ticket extensions 5944 AD-Mandatory-Ticket-Extensions Checksum 5946 Neuman, Ts'o, Kohl Expires: 10 September, 2000 5947 An authorization data element of type mandatory-ticket-extensions 5948 specifies a collision-proof checksum using the same hash algorithm used 5949 to protect the integrity of the ticket itself. This checksum will be 5950 calculated over an individual extension field. If there are more than 5951 one extension, multiple Mandatory-Ticket-Extensions authorization data 5952 elements may be present, each with a checksum for a different extension 5953 field. This restriction indicates that the ticket should not be 5954 accepted if a ticket extension is not present in the ticket for which 5955 the checksum does not match that checksum specified in the 5956 authorization data element. Application servers that do not implement 5957 this element must reject tickets that contain authorization data 5958 elements of this type. 5960 B.7. Authorization Data in ticket extensions 5962 AD-IN-Ticket-Extensions Checksum 5964 An authorization data element of type in-ticket-extensions specifies a 5965 collision-proof checksum using the same hash algorithm used to protect 5966 the integrity of the ticket itself. This checksum is calculated over a 5967 separate external AuthorizationData field carried in the ticket 5968 extensions. Application servers that do not implement this element must 5969 reject tickets that contain authorization data elements of this type. 5970 Application servers that do implement this element will search the 5971 ticket extensions for authorization data fields, calculate the 5972 specified checksum over each authorization data field and look for one 5973 matching the checksum in this in-ticket-extensions element. If not 5974 found, then the ticket must be rejected. If found, the corresponding 5975 authorization data elements will be interpreted in the same manner as 5976 if they were contained in the top level authorization data field. 5978 Note that if multiple external authorization data fields are present in 5979 a ticket, each will have a corresponding element of type 5980 in-ticket-extensions in the top level authorization data field, and the 5981 external entries will be linked to the corresponding element by their 5982 checksums. 5984 C. Definition of common ticket extensions 5986 This appendix contains the definitions of common ticket extensions. 5987 Support for these extensions is optional. However, certain extensions 5988 have associated authorization data elements that may require rejection 5989 of a ticket containing an extension by application servers that do not 5990 implement the particular extension. Other extensions have been defined 5991 beyond those described in this specification. Such extensions are 5992 described elswhere and for some of those extensions the reserved number 5993 may be found in the list of constants. 5995 It is known that older versions of Kerberos did not support this field, 5996 and that some clients will strip this field from a ticket when they 5997 parse and then reassemble a ticket as it is passed to the application 5998 servers. The presence of the extension will not break such clients, but 5999 any functionaly dependent on the extensions will not work when such 6000 tickets are handled by old clients. In such situations, some 6001 implementation may use alternate methods to transmit the information in 6002 the extensions field. 6004 C.1. Null ticket extension 6006 Neuman, Ts'o, Kohl Expires: 10 September, 2000 6007 TE-NullExtension OctetString -- The empty Octet String 6009 The te-data field in the null ticket extension is an octet string of 6010 lenght zero. This extension may be included in a ticket granting ticket 6011 so that the KDC can determine on presentation of the ticket granting 6012 ticket whether the client software will strip the extensions field. 6014 C.2. External Authorization Data 6016 TE-ExternalAuthorizationData AuthorizationData 6018 The te-data field in the external authorization data ticket extension 6019 is field of type AuthorizationData containing one or more authorization 6020 data elements. If present, a corresponding authorization data element 6021 will be present in the primary authorization data for the ticket and 6022 that element will contain a checksum of the external authorization data 6023 ticket extension. 6024 ----------------------------------------------------------------------- 6025 [TM] Project Athena, Athena, and Kerberos are trademarks of the 6026 Massachusetts Institute of Technology (MIT). No commercial use of these 6027 trademarks may be made without prior written permission of MIT. 6029 [1] Note, however, that many applications use Kerberos' functions only 6030 upon the initiation of a stream-based network connection. Unless an 6031 application subsequently provides integrity protection for the data 6032 stream, the identity verification applies only to the initiation of the 6033 connection, and does not guarantee that subsequent messages on the 6034 connection originate from the same principal. 6036 [2] Secret and private are often used interchangeably in the 6037 literature. In our usage, it takes two (or more) to share a secret, 6038 thus a shared DES key is a secret key. Something is only private when 6039 no one but its owner knows it. Thus, in public key cryptosystems, one 6040 has a public and a private key. 6042 [3] Of course, with appropriate permission the client could arrange 6043 registration of a separately-named prin- cipal in a remote realm, and 6044 engage in normal exchanges with that realm's services. However, for 6045 even small numbers of clients this becomes cumbersome, and more 6046 automatic methods as described here are necessary. 6048 [4] Though it is permissible to request or issue tick- ets with no 6049 network addresses specified. 6051 [5] The password-changing request must not be honored unless the 6052 requester can provide the old password (the user's current secret key). 6053 Otherwise, it would be possible for someone to walk up to an unattended 6054 ses- sion and change another user's password. 6056 [6] To authenticate a user logging on to a local system, the 6057 credentials obtained in the AS exchange may first be used in a TGS 6058 exchange to obtain credentials for a local server. Those credentials 6059 must then be verified by a local server through successful completion 6060 of the Client/Server exchange. 6062 [7] "Random" means that, among other things, it should be impossible to 6063 guess the next session key based on knowledge of past session keys. 6064 This can only be achieved in a pseudo-random number generator if it is 6065 based on cryptographic principles. It is more desirable to use a truly 6067 Neuman, Ts'o, Kohl Expires: 10 September, 2000 6068 random number generator, such as one based on measurements of random 6069 physical phenomena. 6071 [8] Tickets contain both an encrypted and unencrypted portion, so 6072 cleartext here refers to the entire unit, which can be copied from one 6073 message and replayed in another without any cryptographic skill. 6075 [9] Note that this can make applications based on unreliable transports 6076 difficult to code correctly. If the transport might deliver duplicated 6077 messages, either a new authenticator must be generated for each retry, 6078 or the application server must match requests and replies and replay 6079 the first reply in response to a detected duplicate. 6081 [10] This is used for user-to-user authentication as described in [8]. 6083 [11] Note that the rejection here is restricted to authenticators from 6084 the same principal to the same server. Other client principals 6085 communicating with the same server principal should not be have their 6086 authenticators rejected if the time and microsecond fields happen to 6087 match some other client's authenticator. 6089 [12] In the Kerberos version 4 protocol, the timestamp in the reply was 6090 the client's timestamp plus one. This is not necessary in version 5 6091 because version 5 messages are formatted in such a way that it is not 6092 possible to create the reply by judicious message surgery (even in 6093 encrypted form) without knowledge of the appropriate encryption keys. 6095 [13] Note that for encrypting the KRB_AP_REP message, the sub-session 6096 key is not used, even if present in the Authenticator. 6098 [14] Implementations of the protocol may wish to provide routines to 6099 choose subkeys based on session keys and random numbers and to generate 6100 a negotiated key to be returned in the KRB_AP_REP message. 6102 [15]This can be accomplished in several ways. It might be known 6103 beforehand (since the realm is part of the principal identifier), it 6104 might be stored in a nameserver, or it might be obtained from a 6105 configura- tion file. If the realm to be used is obtained from a 6106 nameserver, there is a danger of being spoofed if the nameservice 6107 providing the realm name is not authenti- cated. This might result in 6108 the use of a realm which has been compromised, and would result in an 6109 attacker's ability to compromise the authentication of the application 6110 server to the client. 6112 [16] If the client selects a sub-session key, care must be taken to 6113 ensure the randomness of the selected sub- session key. One approach 6114 would be to generate a random number and XOR it with the session key 6115 from the ticket-granting ticket. 6117 [17] This allows easy implementation of user-to-user authentication 6118 [8], which uses ticket-granting ticket session keys in lieu of secret 6119 server keys in situa- tions where such secret keys could be easily 6120 comprom- ised. 6122 [18] For the purpose of appending, the realm preceding the first listed 6123 realm is considered to be the null realm (""). 6125 [19] For the purpose of interpreting null subfields, the client's realm 6126 is considered to precede those in the transited field, and the server's 6128 Neuman, Ts'o, Kohl Expires: 10 September, 2000 6129 realm is considered to follow them. 6131 [20] This means that a client and server running on the same host and 6132 communicating with one another using the KRB_SAFE messages should not 6133 share a common replay cache to detect KRB_SAFE replays. 6135 [21] The implementation of the Kerberos server need not combine the 6136 database and the server on the same machine; it is feasible to store 6137 the principal database in, say, a network name service, as long as the 6138 entries stored therein are protected from disclosure to and 6139 modification by unauthorized parties. However, we recommend against 6140 such strategies, as they can make system management and threat analysis 6141 quite complex. 6143 [22] See the discussion of the padata field in section 5.4.2 for 6144 details on why this can be useful. 6146 [23] Warning for implementations that unpack and repack data structures 6147 during the generation and verification of embedded checksums: Because 6148 any checksums applied to data structures must be checked against the 6149 original data the length of bit strings must be preserved within a data 6150 structure between the time that a checksum is generated through 6151 transmission to the time that the checksum is verified. 6153 [24] It is NOT recommended that this time value be used to adjust the 6154 workstation's clock since the workstation cannot reliably determine 6155 that such a KRB_AS_REP actually came from the proper KDC in a timely 6156 manner. 6158 [25] Note, however, that if the time is used as the nonce, one must 6159 make sure that the workstation time is monotonically increasing. If the 6160 time is ever reset backwards, there is a small, but finite, probability 6161 that a nonce will be reused. 6163 [27] An application code in the encrypted part of a message provides an 6164 additional check that the message was decrypted properly. 6166 [29] An application code in the encrypted part of a message provides an 6167 additional check that the message was decrypted properly. 6169 [31] An application code in the encrypted part of a message provides an 6170 additional check that the message was decrypted properly. 6172 [32] If supported by the encryption method in use, an initialization 6173 vector may be passed to the encryption procedure, in order to achieve 6174 proper cipher chaining. The initialization vector might come from the 6175 last block of the ciphertext from the previous KRB_PRIV message, but it 6176 is the application's choice whether or not to use such an 6177 initialization vector. If left out, the default initialization vector 6178 for the encryption algorithm will be used. 6180 [33] This prevents an attacker who generates an incorrect AS request 6181 from obtaining verifiable plaintext for use in an off-line password 6182 guessing attack. 6184 [35] In the above specification, UNTAGGED OCTET STRING(length) is the 6185 notation for an octet string with its tag and length removed. It is not 6186 a valid ASN.1 type. The tag bits and length must be removed from the 6187 confounder since the purpose of the confounder is so that the message 6189 Neuman, Ts'o, Kohl Expires: 10 September, 2000 6190 starts with random data, but the tag and its length are fixed. For 6191 other fields, the length and tag would be redundant if they were 6192 included because they are specified by the encryption type. [36] The 6193 ordering of the fields in the CipherText is important. Additionally, 6194 messages encoded in this format must include a length as part of the 6195 msg-seq field. This allows the recipient to verify that the message has 6196 not been truncated. Without a length, an attacker could use a chosen 6197 plaintext attack to generate a message which could be truncated, while 6198 leaving the checksum intact. Note that if the msg-seq is an encoding of 6199 an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that 6200 encoding. 6202 [37] In some cases, it may be necessary to use a different "mix-in" 6203 string for compatibility reasons; see the discussion of padata in 6204 section 5.4.2. 6206 [38] In some cases, it may be necessary to use a different "mix-in" 6207 string for compatibility reasons; see the discussion of padata in 6208 section 5.4.2. 6210 [39] A variant of the key is used to limit the use of a key to a 6211 particular function, separating the functions of generating a checksum 6212 from other encryption performed using the session key. The constant 6213 F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The 6214 properties of DES precluded the use of the complement. The same 6215 constant is used for similar purpose in the Message Integrity Check in 6216 the Privacy Enhanced Mail standard. 6218 [40] This error carries additional information in the e- data field. 6219 The contents of the e-data field for this message is described in 6220 section 5.9.1.