idnits 2.17.1 draft-ietf-cat-kerberos-revisions-10.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 103 longer pages, the longest (page 50) being 70 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2059 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** 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 is 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 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 1802: '...ncodings that are marked OPTIONAL, but...' RFC 2119 keyword, line 2097: '... pausec[1] Microseconds OPTIONAL...' RFC 2119 keyword, line 2106: '... pausec[1] Microseconds OPTIONAL,...' RFC 2119 keyword, line 2107: '... pachecksum[2] Checksum OPTIONAL...' RFC 2119 keyword, line 2144: '... salt[1] OCTET STRING OPTIONAL...' (64 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 4304 has weird spacing: '...chanism rsa-m...' == Line 4427 has weird spacing: '...chanism rsa-m...' == Line 4457 has weird spacing: '...chanism rsa-m...' == Line 4496 has weird spacing: '...chanism rsa-m...' == Line 4533 has weird spacing: '...nctions tripl...' == (7 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The type of IPv6 addresses is twenty-four (24). [RFC2373]. The following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2001) is 8191 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) -- Looks like a reference, but probably isn't: '18' on line 1373 -- Looks like a reference, but probably isn't: '19' on line 1385 -- Looks like a reference, but probably isn't: '20' on line 1461 == Missing Reference: 'RFC1510' is mentioned on line 1749, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Missing Reference: 'RFC1964' is mentioned on line 1749, but not defined -- Looks like a reference, but probably isn't: '0' on line 6647 -- Looks like a reference, but probably isn't: '1' on line 6631 -- Looks like a reference, but probably isn't: '2' on line 6581 == Missing Reference: 'APPLICATION 1' is mentioned on line 2292, but not defined -- Looks like a reference, but probably isn't: '3' on line 6582 == Missing Reference: 'APPLICATION 3' is mentioned on line 2300, but not defined -- Looks like a reference, but probably isn't: '4' on line 3544 -- Looks like a reference, but probably isn't: '5' on line 3545 -- Looks like a reference, but probably isn't: '6' on line 3546 -- Looks like a reference, but probably isn't: '7' on line 3547 -- Looks like a reference, but probably isn't: '8' on line 7190 -- Looks like a reference, but probably isn't: '9' on line 3549 -- Looks like a reference, but probably isn't: '10' on line 3550 -- Looks like a reference, but probably isn't: '24' on line 2530 == Missing Reference: 'APPLICATION 2' is mentioned on line 2641, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2714, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2715, but not defined -- Looks like a reference, but probably isn't: '11' on line 3551 == Missing Reference: 'JBrezak' is mentioned on line 2924, but not defined -- Looks like a reference, but probably isn't: '25' on line 3040 == Missing Reference: 'APPLICATION 11' is mentioned on line 3094, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 3095, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 3107, but not defined -- Looks like a reference, but probably isn't: '27' on line 3107 == Missing Reference: 'APPLICATION 26' is mentioned on line 3108, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 3217, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 3269, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 3276, but not defined -- Looks like a reference, but probably isn't: '29' on line 3276 == Missing Reference: 'APPLICATION 20' is mentioned on line 3331, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 3399, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 3405, but not defined -- Looks like a reference, but probably isn't: '31' on line 3405 -- Looks like a reference, but probably isn't: '32' on line 3419 == Missing Reference: 'APPLICATION 22' is mentioned on line 3444, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 3451, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 3539, but not defined -- Looks like a reference, but probably isn't: '12' on line 3552 == Missing Reference: 'K' is mentioned on line 3935, but not defined == Missing Reference: 'Horowitz' is mentioned on line 4062, but not defined == Missing Reference: 'MD492' is mentioned on line 4448, but not defined == Missing Reference: 'ISO3309' is mentioned on line 4477, but not defined -- Looks like a reference, but probably isn't: '39' on line 4594 == Missing Reference: 'RFC 1779' is mentioned on line 4785, but not defined ** Obsolete undefined reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) == Missing Reference: 'Westerlund' is mentioned on line 4924, but not defined == Missing Reference: 'RFC2373' is mentioned on line 4871, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Missing Reference: 'RFC1884' is mentioned on line 4872, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Missing Reference: 'Danielsson' is mentioned on line 4924, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 5128, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) -- Looks like a reference, but probably isn't: '40' on line 5159 -- Looks like a reference, but probably isn't: '14' on line 6867 -- Looks like a reference, but probably isn't: '13' on line 6870 -- Looks like a reference, but probably isn't: '15' on line 6882 == Unused Reference: 'DS90' is defined on line 5368, but no explicit reference was found in the text == Unused Reference: 'Horowitz96' is defined on line 5372, but no explicit reference was found in the text == Unused Reference: 'HorowitzB96' is defined on line 5375, but no explicit reference was found in the text == Unused Reference: 'IS3309' is defined on line 5378, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 5382, but no explicit reference was found in the text == Unused Reference: 'X509-88' is defined on line 5432, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dolev91' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS90' -- Possible downref: Normative reference to a draft: ref. 'Horowitz96' -- No information found for draft-horowitz-kerb-key-derivation - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HorowitzB96' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS3309' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. (However, the state information for draft-horowitz-kerb-key-derivation is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'KNT92' -- No information found for draft-ietf-ipsec-hmac- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Krawczyk96' -- Possible downref: Non-RFC (?) normative reference: ref. 'LGDSR87' ** Obsolete normative reference: RFC 1320 (ref. 'MD4-92') (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5-92') -- Possible downref: Non-RFC (?) normative reference: ref. 'MNSS87' -- Possible downref: Non-RFC (?) normative reference: ref. 'Neu93' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'NT94' ** Downref: Normative reference to an Not Issued RFC: RFC 26 (ref. 'Pat92') -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-88' Summary: 19 errors (**), 0 flaws (~~), 48 warnings (==), 54 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 Ken Raeburn 5 Tom Yu 6 November 20, 2001 7 Expires 20 May, 2002 9 The Kerberos Network Authentication Service (V5) 10 draft-ietf-cat-kerberos-revisions-10 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC 2026. Internet-Drafts are working documents 16 of the Internet Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months and 21 may be updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet-Drafts as reference material or to cite them 23 other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 34 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 36 The distribution of this memo is unlimited. It is filed as 37 draft-ietf-cat-kerberos-revisions-10.txt, and expires May 20, 2002. Please 38 send comments to: ietf-krb-wg@anl.gov 40 ABSTRACT 42 This document provides an overview and specification of Version 5 of the 43 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 44 and its intended use that require more detailed or clearer explanation than 45 was provided in RFC1510. This document is intended to provide a detailed 46 description of the protocol, suitable for implementation, together with 47 descriptions of the appropriate use of protocol messages and fields within 48 those messages. 50 This document is not intended to describe Kerberos to the end user, system 51 administrator, or application developer. Higher level papers describing 52 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 53 are available elsewhere. 55 OVERVIEW 57 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 58 network authentication system is based. It also specifies Version 5 of the 59 Kerberos protocol. 61 The motivations, goals, assumptions, and rationale behind most design 62 decisions are treated cursorily; they are more fully described in a paper 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 112 will[1.1]. Kerberos performs authentication under these conditions as a 113 trusted third-party authentication service by using conventional (shared 114 secret key [1.2]) cryptography. Kerberos extensions (outside the scope of 115 this document) can provide for the use of public key cryptography during 116 certain phases of the authentication protocol [@RFCE: if PKINIT advances 117 concurrently include reference to the RFC here]. Such extensions support 118 Kerberos authentication for users registered with public key certification 119 authorities and provide certain benefits of public key cryptography in 120 situations where they are needed. 122 The basic Kerberos authentication process proceeds as follows: A client 123 sends a request to the authentication server (AS) requesting "credentials" 124 for a given server. The AS responds with these credentials, encrypted in the 125 client's key. The credentials consist of a "ticket" for the server and a 126 temporary encryption key (often called a "session key"). The client 127 transmits the ticket (which contains the client's identity and a copy of the 128 session key, all encrypted in the server's key) to the server. The session 129 key (now shared by the client and server) is used to authenticate the 130 client, and may optionally be used to authenticate the server. It may also 131 be used to encrypt further communication between the two parties or to 132 exchange a separate sub-session key to be used to encrypt further 133 communication. 135 Implementation of the basic protocol consists of one or more authentication 136 servers running on physically secure hosts. The authentication servers 137 maintain a database of principals (i.e., users and servers) and their secret 138 keys. Code libraries provide encryption and implement the Kerberos protocol. 139 In order to add authentication to its transactions, a typical network 140 application adds one or two calls to the Kerberos library directly or 141 through the Generic Security Services Application Programming Interface, 142 GSSAPI, described in separate document [ref to GSSAPI RFC]. These calls 143 result in the transmission of the necessary messages to achieve 144 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 183 function) of the client's message, keyed with the session key. Privacy and 184 integrity of the messages exchanged between principals can be secured by 185 encrypting the data to be passed using the session key contained in the 186 ticket or the sub-session key found in the authenticator. 188 The authentication exchanges mentioned above require read-only access to the 189 Kerberos database. Sometimes, however, the entries in the database must be 190 modified, such as when adding new principals or changing a principal's key. 191 This is done using a protocol between a client and a third Kerberos server, 192 the Kerberos Administration Server (KADM). There is also a protocol for 193 maintaining multiple copies of the Kerberos database. Neither of these 194 protocols are described in this document. 196 1.1. Cross-realm operation 198 The Kerberos protocol is designed to operate across organizational 199 boundaries. A client in one organization can be authenticated to a server in 200 another. Each organization wishing to run a Kerberos server establishes its 201 own "realm". The name of the realm in which a client is registered is part 202 of the client's name, and can be used by the end-service to decide whether 203 to honor a request. 205 By establishing "inter-realm" keys, the administrators of two realms can 206 allow a client authenticated in the local realm to prove its identity to 207 servers in other realms[1.3]. The exchange of inter-realm keys (a separate 208 key may be used for each direction) registers the ticket-granting service of 209 each realm as a principal in the other realm. A client is then able to 210 obtain a ticket-granting ticket for the remote realm's ticket-granting 211 service from its local realm. When that ticket-granting ticket is used, the 212 remote ticket-granting service uses the inter-realm key (which usually 213 differs from its own normal TGS key) to decrypt the ticket-granting ticket, 214 and is thus certain that it was issued by the client's own TGS. Tickets 215 issued by the remote ticket-granting service will indicate to the 216 end-service that the client was authenticated from another realm. 218 A realm is said to communicate with another realm if the two realms share an 219 inter-realm key, or if the local realm shares an inter-realm key with an 220 intermediate realm that communicates with the remote realm. An 221 authentication path is the sequence of intermediate realms that are 222 transited in communicating from one realm to another. 224 Realms are typically organized hierarchically. Each realm shares a key with 225 its parent and a different key with each child. If an inter-realm key is not 226 directly shared by two realms, the hierarchical organization allows an 227 authentication path to be easily constructed. If a hierarchical organization 228 is not used, it may be necessary to consult a database in order to construct 229 an authentication path between realms. 231 Although realms are typically hierarchical, intermediate realms may be 232 bypassed to achieve cross-realm authentication through alternate 233 authentication paths (these might be established to make communication 234 between two realms more efficient). It is important for the end-service to 235 know which realms were transited when deciding how much faith to place in 236 the authentication process. To facilitate this decision, a field in each 237 ticket contains the names of the realms that were involved in authenticating 238 the client. 240 The application server is ultimately responsible for accepting or rejecting 241 authentication and should check the transited field. The application server 242 may choose to rely on the KDC for the application server's realm to check 243 the transited field. The application server's KDC will set the 244 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 245 realms may also check the transited field as they issue 246 ticket-granting-tickets for other realms, but they are encouraged not to do 247 so. A client may request that the KDC's not check the transited field by 248 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 249 required to honor this flag. 251 1.2. Choosing a principal with which to communicate 253 The Kerberos protocol provides the means for verifying (subject to the 254 assumptions in 1.4) that the entity with which one communicates is the same 255 entity that was registered with the KDC using the claimed identity 256 (principal name). It is still necessary to determine whether that identity 257 corresponds to the entity with which one intends to communicate. 259 When appropriate data has been exchanged in advance, this determination may 260 be performed syntactically by the application based on the application 261 protocol specification, information provided by the user, and configuration 262 files. For example, the server principal name (including realm) for a telnet 263 server might be derived from the user specified host name (from the telnet 264 command line), the "host/" prefix specified in the application protocol 265 specification, and a mapping to a Kerberos realm derived syntactically from 266 the domain part of the specified hostname and information from the local 267 Kerberos realms database. 269 One can also rely on trusted third parties to make this determination, but 270 only when the data obtained from the third party is suitably integrity 271 protected wile resident on the third party server and when transmitted. 272 Thus, for example, one should not rely on an unprotected domain name system 273 record to map a host alias to the primary name of a server, accepting the 274 primary name as the party one intends to contact, since an attacker can 275 modify the mapping and impersonate the party with which one intended to 276 communicate. 278 1.3. Authorization 280 As an authentication service, Kerberos provides a means of verifying the 281 identity of principals on a network. Authentication is usually useful 282 primarily as a first step in the process of authorization, determining 283 whether a client may use a service, which objects the client is allowed to 284 access, and the type of access allowed for each. Kerberos does not, by 285 itself, provide authorization. Possession of a client ticket for a service 286 provides only for authentication of the client to that service, and in the 287 absence of a separate authorization procedure, it should not be considered 288 by an application as authorizing the use of that service. 290 Such separate authorization methods may be implemented as application 291 specific access control functions and may utilize files on the application 292 server, or on separately issued authorization credentials such as those 293 based on proxies [Neu93], or on other authorization services. Separately 294 authenticated authorization credentials may be embedded in a tickets 295 authorization data when encapsulated by the kdc-issued authorization data 296 element. 298 Applications should not accept the mere issuance of a service ticket by the 299 Kerberos server (even by a modified Kerberos server) as granting authority 300 to use the service, since such applications may become vulnerable to the 301 bypass of this authorization check in an environment if they interoperate 302 with other KDCs or where other options for application authentication (e.g. 303 the PKTAPP proposal) are provided. 305 1.4. Environmental assumptions 307 Kerberos imposes a few assumptions on the environment in which it can 308 properly function: 310 * "Denial of service" attacks are not solved with Kerberos. There are 311 places in the protocols where an intruder can prevent an application 312 from participating in the proper authentication steps. Detection and 313 solution of such attacks (some of which can appear to be not-uncommon 314 "normal" failure modes for the system) is usually best left to the 315 human administrators and users. 316 * Principals must keep their secret keys secret. If an intruder somehow 317 steals a principal's key, it will be able to masquerade as that 318 principal or impersonate any server to the legitimate principal. 319 * "Password guessing" attacks are not solved by Kerberos. If a user 320 chooses a poor password, it is possible for an attacker to successfully 321 mount an offline dictionary attack by repeatedly attempting to decrypt, 322 with successive entries from a dictionary, messages obtained which are 323 encrypted under a key derived from the user's password. 324 * Each host on the network must have a clock which is "loosely 325 synchronized" to the time of the other hosts; this synchronization is 326 used to reduce the bookkeeping needs of application servers when they 327 do replay detection. The degree of "looseness" can be configured on a 328 per-server basis, but is typically on the order of 5 minutes. If the 329 clocks are synchronized over the network, the clock synchronization 330 protocol must itself be secured from network attackers. 331 * Principal identifiers are not recycled on a short-term basis. A typical 332 mode of access control will use access control lists (ACLs) to grant 333 permissions to particular principals. If a stale ACL entry remains for 334 a deleted principal and the principal identifier is reused, the new 335 principal will inherit rights specified in the stale ACL entry. By not 336 re-using principal identifiers, the danger of inadvertent access is 337 removed. 339 1.5. Glossary of terms 341 Below is a list of terms used throughout this document. 343 Authentication 344 Verifying the claimed identity of a principal. 345 Authentication header 346 A record containing a Ticket and an Authenticator to be presented to a 347 server as part of the authentication process. 348 Authentication path 349 A sequence of intermediate realms transited in the authentication 350 process when communicating from one realm to another. 351 Authenticator 352 A record containing information that can be shown to have been recently 353 generated using the session key known only by the client and server. 354 Authorization 355 The process of determining whether a client may use a service, which 356 objects the client is allowed to access, and the type of access allowed 357 for each. 358 Capability 359 A token that grants the bearer permission to access an object or 360 service. In Kerberos, this might be a ticket whose use is restricted by 361 the contents of the authorization data field, but which lists no 362 network addresses, together with the session key necessary to use the 363 ticket. 364 Ciphertext 365 The output of an encryption function. Encryption transforms plaintext 366 into ciphertext. 367 Client 368 A process that makes use of a network service on behalf of a user. Note 369 that in some cases a Server may itself be a client of some other server 370 (e.g. a print server may be a client of a file server). 371 Credentials 372 A ticket plus the secret session key necessary to successfully use that 373 ticket in an authentication exchange. 374 KDC 375 Key Distribution Center, a network service that supplies tickets and 376 temporary session keys; or an instance of that service or the host on 377 which it runs. The KDC services both initial ticket and ticket-granting 378 ticket requests. The initial ticket portion is sometimes referred to as 379 the Authentication Server (or service). The ticket-granting ticket 380 portion is sometimes referred to as the ticket-granting server (or 381 service). 382 Kerberos 383 Aside from the 3-headed dog guarding Hades, the name given to Project 384 Athena's authentication service, the protocol used by that service, or 385 the code used to implement the authentication service. 386 Plaintext 387 The input to an encryption function or the output of a decryption 388 function. Decryption transforms ciphertext into plaintext. 389 Principal 390 A named client or server entity that participates in a network 391 communication, with one name that is considered canonical. 392 Principal identifier 393 The canonical name used to uniquely identify each different principal. 394 Seal 395 To encipher a record containing several fields in such a way that the 396 fields cannot be individually replaced without either knowledge of the 397 encryption key or leaving evidence of tampering. 399 Secret key 400 An encryption key shared by a principal and the KDC, distributed 401 outside the bounds of the system, with a long lifetime. In the case of 402 a human user's principal, the secret key may be derived from a 403 password. 404 Server 405 A particular Principal which provides a resource to network clients. 406 The server is sometimes referred to as the Application Server. 407 Service 408 A resource provided to network clients; often provided by more than one 409 server (for example, remote file service). 410 Session key 411 A temporary encryption key used between two principals, with a lifetime 412 limited to the duration of a single login "session". 413 Sub-session key 414 A temporary encryption key used between two principals, selected and 415 exchanged by the principals using the session key, and with a lifetime 416 limited to the duration of a single association. 417 Ticket 418 A record that helps a client authenticate itself to a server; it 419 contains the client's identity, a session key, a timestamp, and other 420 information, all sealed using the server's secret key. It only serves 421 to authenticate a client when presented along with a fresh 422 Authenticator. 424 2. Ticket flag uses and requests 426 Each Kerberos ticket contains a set of flags which are used to indicate 427 attributes of that ticket. Most flags may be requested by a client when the 428 ticket is obtained; some are automatically turned on and off by a Kerberos 429 server as required. The following sections explain what the various flags 430 mean, and gives examples of reasons to use such a flag. With the excepttion 431 of the ANONYMOUS and INVALID flags clients may ignore ticket flags that are 432 not recognized. 434 2.1. Initial, pre-authenticated, and hardware authenticated tickets 436 The INITIAL flag indicates that a ticket was issued using the AS protocol 437 and not issued based on a ticket-granting ticket. Application servers that 438 want to require the demonstrated knowledge of a client's secret key (e.g. a 439 password-changing program) can insist that this flag be set in any tickets 440 they accept, and thus be assured that the client's key was recently 441 presented to the application client. 443 The PRE-AUTHENT and HW-AUTHENT flags provide additional information about 444 the initial authentication, regardless of whether the current ticket was 445 issued directly (in which case INITIAL will also be set) or issued on the 446 basis of a ticket-granting ticket (in which case the INITIAL flag is clear, 447 but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 448 ticket-granting ticket). 450 2.2. Invalid tickets 452 The INVALID flag indicates that a ticket is invalid. Application servers 453 must reject tickets which have this flag set. A postdated ticket will 454 usually be issued in this form. Invalid tickets must be validated by the KDC 455 before use, by presenting them to the KDC in a TGS request with the VALIDATE 456 option specified. The KDC will only validate tickets after their starttime 457 has passed. The validation is required so that postdated tickets which have 458 been stolen before their starttime can be rendered permanently invalid 459 (through a hot-list mechanism) (see section 3.3.3.1). 461 2.3. Renewable tickets 463 Applications may desire to hold tickets which can be valid for long periods 464 of time. However, this can expose their credentials to potential theft for 465 equally long periods, and those stolen credentials would be valid until the 466 expiration time of the ticket(s). Simply using short-lived tickets and 467 obtaining new ones periodically would require the client to have long-term 468 access to its secret key, an even greater risk. Renewable tickets can be 469 used to mitigate the consequences of theft. Renewable tickets have two 470 "expiration times": the first is when the current instance of the ticket 471 expires, and the second is the latest permissible value for an individual 472 expiration time. An application client must periodically (i.e. before it 473 expires) present a renewable ticket to the KDC, with the RENEW option set in 474 the KDC request. The KDC will issue a new ticket with a new session key and 475 a later expiration time. All other fields of the ticket are left unmodified 476 by the renewal process. When the latest permissible expiration time arrives, 477 the ticket expires permanently. At each renewal, the KDC may consult a 478 hot-list to determine if the ticket had been reported stolen since its last 479 renewal; it will refuse to renew such stolen tickets, and thus the usable 480 lifetime of stolen tickets is reduced. 482 The RENEWABLE flag in a ticket is normally only interpreted by the 483 ticket-granting service (discussed below in section 3.3). It can usually be 484 ignored by application servers. However, some particularly careful 485 application servers may wish to disallow renewable tickets. 487 If a renewable ticket is not renewed by its expiration time, the KDC will 488 not renew the ticket. The RENEWABLE flag is reset by default, but a client 489 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 490 message. If it is set, then the renew-till field in the ticket contains the 491 time after which the ticket may not be renewed. 493 2.4. Postdated tickets 495 Applications may occasionally need to obtain tickets for use much later, 496 e.g. a batch submission system would need tickets to be valid at the time 497 the batch job is serviced. However, it is dangerous to hold valid tickets in 498 a batch queue, since they will be on-line longer and more prone to theft. 499 Postdated tickets provide a way to obtain these tickets from the KDC at job 500 submission time, but to leave them "dormant" until they are activated and 501 validated by a further request of the KDC. If a ticket theft were reported 502 in the interim, the KDC would refuse to validate the ticket, and the thief 503 would be foiled. 505 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 506 ticket-granting service. It can be ignored by application servers. This flag 507 must be set in a ticket-granting ticket in order to issue a postdated ticket 508 based on the presented ticket. It is reset by default; it may be requested 509 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 510 This flag does not allow a client to obtain a postdated ticket-granting 511 ticket; postdated ticket-granting tickets can only by obtained by requesting 512 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 513 postdated ticket will be the remaining life of the ticket-granting ticket at 514 the time of the request, unless the RENEWABLE option is also set, in which 515 case it can be the full life (endtime-starttime) of the ticket-granting 516 ticket. The KDC may limit how far in the future a ticket may be postdated. 518 The POSTDATED flag indicates that a ticket has been postdated. The 519 application server can check the authtime field in the ticket to see when 520 the original authentication occurred. Some services may choose to reject 521 postdated tickets, or they may only accept them within a certain period 522 after the original authentication. When the KDC issues a POSTDATED ticket, 523 it will also be marked as INVALID, so that the application client must 524 present the ticket to the KDC to be validated before use. 526 2.5. Proxiable and proxy tickets 528 At times it may be necessary for a principal to allow a service to perform 529 an operation on its behalf. The service must be able to take on the identity 530 of the client, but only for a particular purpose. A principal can allow a 531 service to take on the principal's identity for a particular purpose by 532 granting it a proxy. 534 The process of granting a proxy using the proxy and proxiable flags is used 535 to provide credentials for use with specific services. Though conceptually 536 also a proxy, user's wishing to delegate their identity for ANY purpose must 537 use the ticket forwarding mechanism described in the next section to forward 538 a ticket granting ticket. 540 The PROXIABLE flag in a ticket is normally only interpreted by the 541 ticket-granting service. It can be ignored by application servers. When set, 542 this flag tells the ticket-granting server that it is OK to issue a new 543 ticket (but not a ticket-granting ticket) with a different network address 544 based on this ticket. This flag is set if requested by the client on initial 545 authentication. By default, the client will request that it be set when 546 requesting a ticket granting ticket, and reset when requesting any other 547 ticket. 549 This flag allows a client to pass a proxy to a server to perform a remote 550 request on its behalf, e.g. a print service client can give the print server 551 a proxy to access the client's files on a particular file server in order to 552 satisfy a print request. 554 In order to complicate the use of stolen credentials, Kerberos tickets are 555 usually valid from only those network addresses specifically included in the 556 ticket[2.1]. When granting a proxy, the client must specify the new network 557 address from which the proxy is to be used, or indicate that the proxy is to 558 be issued for use from any address. 560 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 561 Application servers may check this flag and at their option they may require 562 additional authentication from the agent presenting the proxy in order to 563 provide an audit trail. 565 2.6. Forwardable tickets 567 Authentication forwarding is an instance of a proxy where the service 568 granted is complete use of the client's identity. An example where it might 569 be used is when a user logs in to a remote system and wants authentication 570 to work from that system as if the login were local. 572 The FORWARDABLE flag in a ticket is normally only interpreted by the 573 ticket-granting service. It can be ignored by application servers. The 574 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 575 flag, except ticket-granting tickets may also be issued with different 576 network addresses. This flag is reset by default, but users may request that 577 it be set by setting the FORWARDABLE option in the AS request when they 578 request their initial ticket-granting ticket. 580 This flag allows for authentication forwarding without requiring the user to 581 enter a password again. If the flag is not set, then authentication 582 forwarding is not permitted, but the same result can still be achieved if 583 the user engages in the AS exchange specifying the requested network 584 addresses and supplies a password. 586 The FORWARDED flag is set by the TGS when a client presents a ticket with 587 the FORWARDABLE flag set and requests a forwarded ticket by specifying the 588 FORWARDED KDC option and supplying a set of addresses for the new ticket. It 589 is also set in all tickets issued based on tickets with the FORWARDED flag 590 set. Application servers may choose to process FORWARDED tickets differently 591 than non-FORWARDED tickets. 593 2.7 Transited Policy Checking 595 In Kerberos, the application server is ultimately responsible for accepting 596 or rejecting authentication and should check that only suitably trusted 597 KDC's are relied upon to authenticate a principal. The transited field in 598 the ticket identifies which KDC's were involved in the authentication 599 process and an application server would normally check this field. While the 600 end server ultimately decides whether authentication is valid, the KDC for 601 the end server's realm may apply a realm specific policy for validating the 602 transited field and accepting credentials for cross-realm authentication. 603 When the KDC applies such checks and accepts such cross-realm authentication 604 it will set the TRANSITED-POLICY-CHECKED flag in the service tickets it 605 issues based on the cross-realm TGT. A client may request that the KDC's not 606 check the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDC's 607 are encouraged but not required to honor this flag. 609 2.8 Anonymous Tickets 611 When policy allows, a KDC may issue anonymous tickets for the purpose of 612 enabling encrypted communication between a client and server without 613 identifying the client to the server. Such anonymous tickets are issued with 614 a generic principal name configured on the KDC (e.g. "anonymous@") and will 615 have the ANONYMOUS flag set. A server accepting such a ticket may assume 616 that subsequent requests using the same ticket and session key originate 617 from the same user. Requests with the same username but different tickets 618 are likely to originate from different users. Users request anonymous ticket 619 by setting the REQUEST-ANONYMOUS option in an AS or TGS request. 621 2.9. Other KDC options 623 There are three additional options which may be set in a client's request of 624 the KDC. 626 2.9.1 Renewable-OK 628 The RENEWABLE-OK option indicates that the client will accept a renewable 629 ticket if a ticket with the requested life cannot otherwise be provided. If 630 a ticket with the requested life cannot be provided, then the KDC may issue 631 a renewable ticket with a renew-till equal to the the requested endtime. The 632 value of the renew-till field may still be adjusted by site-determined 633 limits or limits imposed by the individual principal or server. 635 2.9.2 ENC-TKT-IN-SKEY 637 In its basic form the Kerberos protocol supports authentication in a client 638 server setting and is not well suited to authentication in a peer-to-peer 639 environment because the long term key of the user does not remain on the 640 workstation after initial login. Authentication of such peers may be 641 supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-SKEY 642 option supports user-to-user authentication by allowing the KDC to issue a 643 service ticket encrypted using the session key from another ticket granting 644 ticket issued to another user. The ENC-TKT-IN-SKEY option is honored only by 645 the ticket-granting service. It indicates that the ticket to be issued for 646 the end server is to be encrypted in the session key from the additional 647 second ticket-granting ticket provided with the request. See section 3.3.3 648 for specific details. 650 3. Message Exchanges 652 The following sections describe the interactions between network clients and 653 servers and the messages involved in those exchanges. 655 3.1. The Authentication Service Exchange 657 Summary 658 Message direction Message type Section 659 1. Client to Kerberos KRB_AS_REQ 5.4.1 660 2. Kerberos to client KRB_AS_REP or 5.4.2 661 KRB_ERROR 5.9.1 663 The Authentication Service (AS) Exchange between the client and the Kerberos 664 Authentication Server is initiated by a client when it wishes to obtain 665 authentication credentials for a given server but currently holds no 666 credentials. In its basic form, the client's secret key is used for 667 encryption and decryption. This exchange is typically used at the initiation 668 of a login session to obtain credentials for a Ticket-Granting Server which 669 will subsequently be used to obtain credentials for other servers (see 670 section 3.3) without requiring further use of the client's secret key. This 671 exchange is also used to request credentials for services which must not be 672 mediated through the Ticket-Granting Service, but rather require a 673 principal's secret key, such as the password-changing service[3.1]. This 674 exchange does not by itself provide any assurance of the the identity of the 675 user[3.2]. 677 The exchange consists of two messages: KRB_AS_REQ from the client to 678 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 679 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 681 In the request, the client sends (in cleartext) its own identity and the 682 identity of the server for which it is requesting credentials. The response, 683 KRB_AS_REP, contains a ticket for the client to present to the server, and a 684 session key that will be shared by the client and the server. The session 685 key and additional information are encrypted in the client's secret key. The 686 KRB_AS_REP message contains information which can be used to detect replays, 687 and to associate it with the message to which it replies. 689 Without pre-authentication, the authentication server does not know whether 690 the client is actually the principal named in the request. It simply sends a 691 reply without knowing or caring whether they are the same. This is 692 acceptable because nobody but the principal whose identity was given in the 693 request will be able to use the reply. Its critical information is encrypted 694 in that principal's key. The initial request supports an optional field that 695 can be used to pass additional information that might be needed for the 696 initial exchange. This field may be used for pre-authentication as described 697 in section 3.1.1. 699 Various errors can occur; these are indicated by an error response 700 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not 701 encrypted. The KRB_ERROR message contains information which can be used to 702 associate it with the message to which it replies. If suitable 703 preauthentication has occurred, an optional checksum may be included in the 704 KRB_ERROR message to prevent fabrication or modification of the KRB_ERROR 705 message. When a checksum is not present, the lack of integrity protection 706 precludes the ability to detect replays, fabrications, or modifications of 707 the message, and the client must not depend on information in the KRB_ERROR 708 message for security critical operations. 710 3.1.1. Generation of KRB_AS_REQ message 712 The client may specify a number of options in the initial request. Among 713 these options are whether pre-authentication is to be performed; whether the 714 requested ticket is to be renewable, proxiable, or forwardable; whether it 715 should be postdated or allow postdating of derivative tickets; whether the 716 client requests an anonymous ticket; and whether a renewable ticket will be 717 accepted in lieu of a non-renewable ticket if the requested ticket 718 expiration date cannot be satisfied by a non-renewable ticket (due to 719 configuration constraints; see section 4). See section A.1 for pseudocode. 721 The client prepares the KRB_AS_REQ message and sends it to the KDC. 723 3.1.2. Receipt of KRB_AS_REQ message 725 If all goes well, processing the KRB_AS_REQ message will result in the 726 creation of a ticket for the client to present to the server. The format for 727 the ticket is described in section 5.3.1. The contents of the ticket are 728 determined as follows. 730 3.1.3. Generation of KRB_AS_REP message 732 The authentication server looks up the client and server principals named in 733 the KRB_AS_REQ in its database, extracting their respective keys. If the 734 requested client principal named in the request is not known because it 735 doesn't exist in the KDC's principal database, then an error message with a 736 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 738 If required, the server pre-authenticates the request, and if the 739 pre-authentication check fails, an error message with the code 740 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, but 741 was not present in the request, an error message with the code 742 KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO 743 pre-authentication field will be included in the KRB-ERROR message. If the 744 server cannot accommodate an encryption type requested by the client, an 745 error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC 746 generates a 'random' session key[3.3]. 748 When responding to an AS request, if there are multiple encryption keys 749 registered for a client in the Kerberos database (or if the key registered 750 supports multiple encryption types; e.g. DES3-CBC-SHA1 and 751 DES3-CBC-SHA1-KD), then the etype field from the AS request is used by the 752 KDC to select the encryption method to be used to protect the encrypted part 753 of the KRB_AS_REP message which is sent to the client. If there is more than 754 one supported strong encryption type in the etype list, the first valid 755 etype for which an encryption key is available is used. The encryption 756 method used to protect the encrypted part of the KRB_TGS_REP message is the 757 keytype of the session key found in the ticket granting ticket presented in 758 the KRB_TGS_REQ. 760 If the user's key was generated using an alternate string to key function 761 than that used by the selected encryption type, information needed by the 762 string to key function will be returned to the client in the padata field of 763 the KRB_AS_REP message using the PA-PW-SALT, PA-AFS3-SALT, or similar 764 pre-authentication typed values. This does not affect the encryption 765 performed by the KDC since the key stored in the principal database already 766 has the string to key transformation applied. 768 When the etype field is present in a KDC request, whether an AS or TGS 769 request, the KDC will attempt to assign the type of the random session key 770 from the list of methods in the etype field. The KDC will select the 771 appropriate type using the list of methods provided together with 772 information from the Kerberos database indicating acceptable encryption 773 methods for the application server. The KDC will not issue tickets with a 774 weak session key encryption type. 776 If the requested start time is absent, indicates a time in the past, or is 777 within the window of acceptable clock skew for the KDC and the POSTDATE 778 option has not been specified, then the start time of the ticket is set to 779 the authentication server's current time. If it indicates a time in the 780 future beyond the acceptable clock skew, but the POSTDATED option has not 781 been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise 782 the requested start time is checked against the policy of the local realm 783 (the administrator might decide to prohibit certain types or ranges of 784 postdated tickets), and if acceptable, the ticket's start time is set as 785 requested and the INVALID flag is set in the new ticket. The postdated 786 ticket must be validated before use by presenting it to the KDC after the 787 start time has been reached. 789 The expiration time of the ticket will be set to the earlier of the 790 requested endtime and a time determined by local policy, possibly determined 791 using realm or principal specific factors. For example, the expiration time 792 may be set to the minimum of the following: 794 * The expiration time (endtime) requested in the KRB_AS_REQ message. 795 * The ticket's start time plus the maximum allowable lifetime associated 796 with the client principal from the authentication server's database 797 (see section 4). 798 * The ticket's start time plus the maximum allowable lifetime associated 799 with the server principal. 800 * The ticket's start time plus the maximum lifetime set by the policy of 801 the local realm. 803 If the requested expiration time minus the start time (as determined above) 804 is less than a site-determined minimum lifetime, an error message with code 805 KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the 806 ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' 807 option was requested, then the 'RENEWABLE' flag is set in the new ticket, 808 and the renew-till value is set as if the 'RENEWABLE' option were requested 809 (the field and option names are described fully in section 5.4.1). 811 If the RENEWABLE option has been requested or if the RENEWABLE-OK option has 812 been set and a renewable ticket is to be issued, then the renew-till field 813 is set to the minimum of: 815 * Its requested value. 816 * The start time of the ticket plus the minimum of the two maximum 817 renewable lifetimes associated with the principals' database entries. 818 * The start time of the ticket plus the maximum renewable lifetime set by 819 the policy of the local realm. 821 The flags field of the new ticket will have the following options set if 822 they have been requested and if the policy of the local realm allows: 823 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS. If 824 the new ticket is post-dated (the start time is in the future), its INVALID 825 flag will also be set. 827 If all of the above succeed, the server will encrypt ciphertext part of the 828 ticket using the encryption key extracted from the server principal's record 829 in the Kerberos database using the encryption type associated with the 830 server principal's key (this choice is NOT affected by the etype field in 831 the request). It then formats a KRB_AS_REP message (see section 5.4.2), 832 copying the addresses in the request into the caddr of the response, placing 833 any required pre-authentication data into the padata of the response, and 834 encrypts the ciphertext part in the client's key using an acceptable 835 encryption method requested in the etype field of the request, and sends the 836 message to the client. See section A.2 for pseudocode. 838 3.1.4. Generation of KRB_ERROR message 840 Several errors can occur, and the Authentication Server responds by 841 returning an error message, KRB_ERROR, to the client, with the error-code, 842 e-text, and optional e-cksum fields set to appropriate values. The error 843 message contents and details are described in Section 5.9.1. 845 3.1.5. Receipt of KRB_AS_REP message 847 If the reply message type is KRB_AS_REP, then the client verifies that the 848 cname and crealm fields in the cleartext portion of the reply match what it 849 requested. If any padata fields are present, they may be used to derive the 850 proper secret key to decrypt the message. The client decrypts the encrypted 851 part of the response using its secret key, verifies that the nonce in the 852 encrypted part matches the nonce it supplied in its request (to detect 853 replays). It also verifies that the sname and srealm in the response match 854 those in the request (or are otherwise expected values), and that the host 855 address field is also correct. It then stores the ticket, session key, start 856 and expiration times, and other information for later use. The 857 key-expiration field from the encrypted part of the response may be checked 858 to notify the user of impending key expiration (the client program could 859 then suggest remedial action, such as a password change). See section A.3 860 for pseudocode. 862 Proper decryption of the KRB_AS_REP message is not sufficient for the host 863 to verify the identity of the user; the user and an attacker could cooperate 864 to generate a KRB_AS_REP format message which decrypts properly but is not 865 from the proper KDC. If the host wishes to verify the identity of the user, 866 it must require the user to present application credentials which can be 867 verified using a securely-stored secret key for the host. If those 868 credentials can be verified, then the identity of the user can be assured. 870 3.1.6. Receipt of KRB_ERROR message 872 If the reply message type is KRB_ERROR, then the client interprets it as an 873 error and performs whatever application-specific tasks are necessary to 874 recover. 876 3.2. The Client/Server Authentication Exchange 878 Summary 879 Message direction Message type Section 880 Client to Application server KRB_AP_REQ 5.5.1 881 [optional] Application server to client KRB_AP_REP or 5.5.2 882 KRB_ERROR 5.9.1 884 The client/server authentication (CS) exchange is used by network 885 applications to authenticate the client to the server and vice versa. The 886 client must have already acquired credentials for the server using the AS or 887 TGS exchange. 889 3.2.1. The KRB_AP_REQ message 891 The KRB_AP_REQ contains authentication information which should be part of 892 the first message in an authenticated transaction. It contains a ticket, an 893 authenticator, and some additional bookkeeping information (see section 894 5.5.1 for the exact format). The ticket by itself is insufficient to 895 authenticate a client, since tickets are passed across the network in 896 cleartext[3.4], so the authenticator is used to prevent invalid replay of 897 tickets by proving to the server that the client knows the session key of 898 the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is 899 referred to elsewhere as the 'authentication header.' 901 3.2.2. Generation of a KRB_AP_REQ message 903 When a client wishes to initiate authentication to a server, it obtains 904 (either through a credentials cache, the AS exchange, or the TGS exchange) a 905 ticket and session key for the desired service. The client may re-use any 906 tickets it holds until they expire. To use a ticket the client constructs a 907 new Authenticator from the the system time, its name, and optionally an 908 application specific checksum, an initial sequence number to be used in 909 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in 910 negotiations for a session key unique to this particular session. 911 Authenticators may not be re-used and will be rejected if replayed to a 912 server[3.5]. If a sequence number is to be included, it should be randomly 913 chosen so that even after many messages have been exchanged it is not likely 914 to collide with other sequence numbers in use. 916 The client may indicate a requirement of mutual authentication or the use of 917 a session-key based ticket by setting the appropriate flag(s) in the 918 ap-options field of the message. 920 The Authenticator is encrypted in the session key and combined with the 921 ticket to form the KRB_AP_REQ message which is then sent to the end server 922 along with any additional application-specific information. See section A.9 923 for pseudocode. 925 3.2.3. Receipt of KRB_AP_REQ message 927 Authentication is based on the server's current time of day (clocks must be 928 loosely synchronized), the authenticator, and the ticket. Several errors are 929 possible. If an error occurs, the server is expected to reply to the client 930 with a KRB_ERROR message. This message may be encapsulated in the 931 application protocol if its 'raw' form is not acceptable to the protocol. 932 The format of error messages is described in section 5.9.1. 934 The algorithm for verifying authentication information is as follows. If the 935 message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE 936 error. If the key version indicated by the Ticket in the KRB_AP_REQ is not 937 one the server can use (e.g., it indicates an old key, and the server no 938 longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is 939 returned. If the USE-SESSION-KEY flag is set in the ap-options field, it 940 indicates to the server that the ticket is encrypted in the session key from 941 the server's ticket-granting ticket rather than its secret key [3.6]. 943 Since it is possible for the server to be registered in multiple realms, 944 with different keys in each, the srealm field in the unencrypted portion of 945 the ticket in the KRB_AP_REQ is used to specify which secret key the server 946 should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is 947 returned if the server doesn't have the proper key to decipher the ticket. 949 The ticket is decrypted using the version of the server's key specified by 950 the ticket. If the decryption routines detect a modification of the ticket 951 (each encryption system must provide safeguards to detect modified 952 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned 953 (chances are good that different keys were used to encrypt and decrypt). 955 The authenticator is decrypted using the session key extracted from the 956 decrypted ticket. If decryption shows it to have been modified, the 957 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client 958 from the ticket are compared against the same fields in the authenticator. 959 If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might 960 not match, for example, if the wrong session key was used to encrypt the 961 authenticator). The addresses in the ticket (if any) are then searched for 962 an address matching the operating-system reported address of the client. If 963 no match is found or the server insists on ticket addresses but none are 964 present in the ticket, the KRB_AP_ERR_BADADDR error is returned. If the 965 local (server) time and the client time in the authenticator differ by more 966 than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error 967 is returned. 969 Unless the application server provides its own suitable means to protect 970 against replay (for example, a challenge-response sequence initiated by the 971 server after authentication, or use of a server-generated encryption 972 subkey), the server must utilize a replay cache to remember any 973 authenticator presented within the allowable clock skew. Careful analysis of 974 the application protocol and implementation is recommended before 975 eliminating this cache. The replay cache will store the server name, along 976 with the client name, time and microsecond fields from the recently-seen 977 authenticators and if a matching tuple is found, the KRB_AP_ERR_REPEAT error 978 is returned [3.7]. If a server loses track of authenticators presented 979 within the allowable clock skew, it must reject all requests until the clock 980 skew interval has passed, providing assurance that any lost or re-played 981 authenticators will fall outside the allowable clock skew and can no longer 982 be successfully replayed[3.8]. 984 If a sequence number is provided in the authenticator, the server saves it 985 for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey 986 is present, the server either saves it for later use or uses it to help 987 generate its own choice for a subkey to be returned in a KRB_AP_REP message. 989 If multiple servers (for example, different services on one machine, or a 990 single service implemented on multiple machines) share a service principal 991 (a practice we do not recommend in general, but acknowledge will be used in 992 some cases), they should also share this replay cache, or the application 993 protocol should be designed so as to eliminate the need for it. Note that 994 this applies to all of the services, if any of the application protocols 995 does not have replay protection built in; an authenticator used with such a 996 service could later be replayed to a different service with the same service 997 principal but no replay protection, if the former doesn't record the 998 authenticator information in the common replay cache. 1000 The server computes the age of the ticket: local (server) time minus the 1001 start time inside the Ticket. If the start time is later than the current 1002 time by more than the allowable clock skew or if the INVALID flag is set in 1003 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the 1004 current time is later than end time by more than the allowable clock skew, 1005 the KRB_AP_ERR_TKT_EXPIRED error is returned. 1007 If all these checks succeed without an error, the server is assured that the 1008 client possesses the credentials of the principal named in the ticket and 1009 thus, the client has been authenticated to the server. See section A.10 for 1010 pseudocode. 1012 Passing these checks provides only authentication of the named principal; it 1013 does not imply authorization to use the named service. Applications must 1014 make a separate authorization decisions based upon the authenticated name of 1015 the user, the requested operation, local access control information such as 1016 that contained in a .k5login or .k5users file, and possibly a separate 1017 distributed authorization service. 1019 3.2.4. Generation of a KRB_AP_REP message 1021 Typically, a client's request will include both the authentication 1022 information and its initial request in the same message, and the server need 1023 not explicitly reply to the KRB_AP_REQ. However, if mutual authentication 1024 (not only authenticating the client to the server, but also the server to 1025 the client) is being performed, the KRB_AP_REQ message will have 1026 MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is 1027 required in response. As with the error message, this message may be 1028 encapsulated in the application protocol if its "raw" form is not acceptable 1029 to the application's protocol. The timestamp and microsecond field used in 1030 the reply must be the client's timestamp and microsecond field (as provided 1031 in the authenticator)[3.9]. If a sequence number is to be included, it 1032 should be randomly chosen as described above for the authenticator. A subkey 1033 may be included if the server desires to negotiate a different subkey. The 1034 KRB_AP_REP message is encrypted in the session key extracted from the 1035 ticket. See section A.11 for pseudocode. 1037 3.2.5. Receipt of KRB_AP_REP message 1039 If a KRB_AP_REP message is returned, the client uses the session key from 1040 the credentials obtained for the server[3.10] to decrypt the message, and 1041 verifies that the timestamp and microsecond fields match those in the 1042 Authenticator it sent to the server. If they match, then the client is 1043 assured that the server is genuine. The sequence number and subkey (if 1044 present) are retained for later use. See section A.12 for pseudocode. 1046 3.2.6. Using the encryption key 1048 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server 1049 share an encryption key which can be used by the application. In some cases, 1050 the use of this session key will be implicit in the protocol; in others the 1051 method of use must be chosen from several alternatives. The 'true session 1052 key' to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses 1053 may be chosen by the application based on the session key from the ticket 1054 and subkeys in the KRB_AP_REP message and the authenticator[3.11]. To 1055 mitigate the effect of failures in random number generation on the client it 1056 is strongly encouraged that any key derived by an application for subsequent 1057 use include the full key entropy derived from the KDC generated session key 1058 carried in the ticket. We leave the protocol negotiations of how to use the 1059 key (e.g. selecting an encryption or checksum type) to the application 1060 programmer; the Kerberos protocol does not constrain the implementation 1061 options, but an example of how this might be done follows. 1063 One way that an application may choose to negotiate a key to be used for 1064 subsequent integrity and privacy protection is for the client to propose a 1065 key in the subkey field of the authenticator. The server can then choose a 1066 key using the proposed key from the client as input, returning the new 1067 subkey in the subkey field of the application reply. This key could then be 1068 used for subsequent communication. 1070 To make this example more concrete, if the communication patterns of an 1071 application dictates the use of encryption modes of operation incompatible 1072 with the encryption system used for the authenticator, then a key compatible 1073 with the required encryption system may be generated by either the client, 1074 the server, or collaboratively by both and exchanged using the subkey field. 1075 This generation might involve the use of a random number as a pre-key, 1076 initially generated by either party, which could then be encrypted using the 1077 session key from the ticket, and the result exchanged and used for 1078 subsequent encryption. By encrypting the pre-key with the session key from 1079 the ticket, randomness from the KDC generated key is assured of being 1080 present in the negotiated key. Application developers must be careful 1081 however, to use a means of introducing this entropy that does not allow an 1082 attacker to learn the session key from the ticket if it learns the key 1083 generated and used for subsequent communication. The reader should note that 1084 this is only an example, and that an analysis of the particular cryptosystem 1085 to be used, must be made before deciding how to generate values for the 1086 subkey fields, and the key to be used for subsequent communication. 1088 With both the one-way and mutual authentication exchanges, the peers should 1089 take care not to send sensitive information to each other without proper 1090 assurances. In particular, applications that require privacy or integrity 1091 should use the KRB_AP_REP response from the server to client to assure both 1092 client and server of their peer's identity. If an application protocol 1093 requires privacy of its messages, it can use the KRB_PRIV message (section 1094 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 1096 3.3. The Ticket-Granting Service (TGS) Exchange 1098 Summary 1099 Message direction Message type Section 1100 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1101 2. Kerberos to client KRB_TGS_REP or 5.4.2 1102 KRB_ERROR 5.9.1 1104 The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1105 initiated by a client when it wishes to obtain authentication credentials 1106 for a given server (which might be registered in a remote realm), when it 1107 wishes to renew or validate an existing ticket, or when it wishes to obtain 1108 a proxy ticket. In the first case, the client must already have acquired a 1109 ticket for the Ticket-Granting Service using the AS exchange (the 1110 ticket-granting ticket is usually obtained when a client initially 1111 authenticates to the system, such as when a user logs in). The message 1112 format for the TGS exchange is almost identical to that for the AS exchange. 1113 The primary difference is that encryption and decryption in the TGS exchange 1114 does not take place under the client's key. Instead, the session key from 1115 the ticket-granting ticket or renewable ticket, or sub-session key from an 1116 Authenticator is used. As is the case for all application servers, expired 1117 tickets are not accepted by the TGS, so once a renewable or ticket-granting 1118 ticket expires, the client must use a separate exchange to obtain valid 1119 tickets. 1121 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1122 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1123 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1124 client plus a request for credentials. The authentication information 1125 consists of the authentication header (KRB_AP_REQ) which includes the 1126 client's previously obtained ticket-granting, renewable, or invalid ticket. 1127 In the ticket-granting ticket and proxy cases, the request may include one 1128 or more of: a list of network addresses, a collection of typed authorization 1129 data to be sealed in the ticket for authorization use by the application 1130 server, or additional tickets (the use of which are described later). The 1131 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1132 session key from the ticket-granting ticket or renewable ticket, or if 1133 present, in the sub-session key from the Authenticator (part of the 1134 authentication header). The KRB_ERROR message contains an error code and 1135 text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1136 KRB_TGS_REP message contains information which can be used to detect 1137 replays, and to associate it with the message to which it replies. The 1138 KRB_ERROR message also contains information which can be used to associate 1139 it with the message to which it replies, but except when an optional 1140 checksum is included in the KRB_ERROR message, it is not possible to detect 1141 replays or fabrications of such messages. 1143 3.3.1. Generation of KRB_TGS_REQ message 1145 Before sending a request to the ticket-granting service, the client must 1146 determine in which realm the application server is believed to be 1147 registered[3.12]. If the client knows the service principal name and realm 1148 and it does not already possess a ticket-granting ticket for the appropriate 1149 realm, then one must be obtained. This is first attempted by requesting a 1150 ticket-granting ticket for the destination realm from a Kerberos server for 1151 which the client possesses a ticket-granting ticket (using the KRB_TGS_REQ 1152 message recursively). The Kerberos server may return a TGT for the desired 1153 realm in which case one can proceed. Alternatively, the Kerberos server may 1154 return a TGT for a realm which is 'closer' to the desired realm (further 1155 along the standard hierarchical path between the client's realm and the 1156 requested realm server's realm). 1158 Once the client obtains a ticket-granting ticket for the appropriate realm, 1159 it determines which Kerberos servers serve that realm, and contacts one. The 1160 list might be obtained through a configuration file or network service or it 1161 may be generated from the name of the realm; as long as the secret keys 1162 exchanged by realms are kept secret, only denial of service results from 1163 using a false Kerberos server. 1165 As in the AS exchange, the client may specify a number of options in the 1166 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing 1167 an authentication header as an element of the padata field, and including 1168 the same fields as used in the KRB_AS_REQ message along with several 1169 optional fields: the enc-authorization-data field for application server use 1170 and additional tickets required by some options. 1172 In preparing the authentication header, the client can select a sub-session 1173 key under which the response from the Kerberos server will be 1174 encrypted[3.13]. If the sub-session key is not specified, the session key 1175 from the ticket-granting ticket will be used. If the enc-authorization-data 1176 is present, it must be encrypted in the sub-session key, if present, from 1177 the authenticator portion of the authentication header, or if not present, 1178 using the session key from the ticket-granting ticket. 1180 Once prepared, the message is sent to a Kerberos server for the destination 1181 realm. See section A.5 for pseudocode. 1183 3.3.2. Receipt of KRB_TGS_REQ message 1185 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1186 message, but there are many additional checks to be performed. First, the 1187 Kerberos server must determine which server the accompanying ticket is for 1188 and it must select the appropriate key to decrypt it. For a normal 1189 KRB_TGS_REQ message, it will be for the ticket granting service, and the 1190 TGS's key will be used. If the TGT was issued by another realm, then the 1191 appropriate inter-realm key must be used. If the accompanying ticket is not 1192 a ticket granting ticket for the current realm, but is for an application 1193 server in the current realm, the RENEW, VALIDATE, or PROXY options are 1194 specified in the request, and the server for which a ticket is requested is 1195 the server named in the accompanying ticket, then the KDC will decrypt the 1196 ticket in the authentication header using the key of the server for which it 1197 was issued. If no ticket can be found in the padata field, the 1198 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1200 Once the accompanying ticket has been decrypted, the user-supplied checksum 1201 in the Authenticator must be verified against the contents of the request, 1202 and the message rejected if the checksums do not match (with an error code 1203 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1204 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1205 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1206 returned. If the authorization-data are present, they are decrypted using 1207 the sub-session key from the Authenticator. 1209 If any of the decryptions indicate failed integrity checks, the 1210 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1212 3.3.3. Generation of KRB_TGS_REP message 1214 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1215 but with its type field set to KRB_TGS_REP. The detailed specification is in 1216 section 5.4.2. 1218 The response will include a ticket for the requested server or for a ticket 1219 granting server of an intermediate KDC to be contacted to obtain the 1220 requested ticket. The Kerberos database is queried to retrieve the record 1221 for the appropriate server (including the key with which the ticket will be 1222 encrypted). If the request is for a ticket granting ticket for a remote 1223 realm, and if no key is shared with the requested realm, then the Kerberos 1224 server will select the realm 'closest' to the requested realm with which it 1225 does share a key, and use that realm instead. If the requested server cannot 1226 be found in the TGS database, then a TGT for another trusted realm may be 1227 returned instead of a ticket for the service. This TGT is a referral 1228 mechanism to cause the client to retry the request to the realm of the TGT. 1229 These are the only cases where the response for the KDC will be for a 1230 different server than that requested by the client. 1232 By default, the address field, the client's name and realm, the list of 1233 transited realms, the time of initial authentication, the expiration time, 1234 and the authorization data of the newly-issued ticket will be copied from 1235 the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1236 needs to be updated, but the transited type is not supported, the 1237 KDC_ERR_TRTYPE_NOSUPP error is returned. 1239 If the request specifies an endtime, then the endtime of the new ticket is 1240 set to the minimum of (a) that request, (b) the endtime from the TGT, and 1241 (c) the starttime of the TGT plus the minimum of the maximum life for the 1242 application server and the maximum life for the local realm (the maximum 1243 life for the requesting principal was already applied when the TGT was 1244 issued). If the new ticket is to be a renewal, then the endtime above is 1245 replaced by the minimum of (a) the value of the renew_till field of the 1246 ticket and (b) the starttime for the new ticket plus the life 1247 (endtime-starttime) of the old ticket. 1249 If the FORWARDED option has been requested, then the resulting ticket will 1250 contain the addresses specified by the client. This option will only be 1251 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1252 similar; the resulting ticket will contain the addresses specified by the 1253 client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1254 PROXY option will not be honored on requests for additional ticket-granting 1255 tickets. 1257 If the requested start time is absent, indicates a time in the past, or is 1258 within the window of acceptable clock skew for the KDC and the POSTDATE 1259 option has not been specified, then the start time of the ticket is set to 1260 the authentication server's current time. If it indicates a time in the 1261 future beyond the acceptable clock skew, but the POSTDATED option has not 1262 been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1263 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1264 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1265 postdated and the requested starttime is checked against the policy of the 1266 local realm. If acceptable, the ticket's start time is set as requested, and 1267 the INVALID flag is set. The postdated ticket must be validated before use 1268 by presenting it to the KDC after the starttime has been reached. However, 1269 in no case may the starttime, endtime, or renew-till time of a newly-issued 1270 postdated ticket extend beyond the renew-till time of the ticket-granting 1271 ticket. 1273 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1274 has been included in the request, the KDC will decrypt the additional ticket 1275 using the key for the server to which the additional ticket was issued and 1276 verify that it is a ticket-granting ticket. If the name of the requested 1277 server is missing from the request, the name of the client in the additional 1278 ticket will be used. Otherwise the name of the requested server will be 1279 compared to the name of the client in the additional ticket and if 1280 different, the request will be rejected. If the request succeeds, the 1281 session key from the additional ticket will be used to encrypt the new 1282 ticket that is issued instead of using the key of the server for which the 1283 new ticket will be used. 1285 If the name of the server in the ticket that is presented to the KDC as part 1286 of the authentication header is not that of the ticket-granting server 1287 itself, the server is registered in the realm of the KDC, and the RENEW 1288 option is requested, then the KDC will verify that the RENEWABLE flag is set 1289 in the ticket, that the INVALID flag is not set in the ticket, and that the 1290 renew_till time is still in the future. If the VALIDATE option is requested, 1291 the KDC will check that the starttime has passed and the INVALID flag is 1292 set. If the PROXY option is requested, then the KDC will check that the 1293 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1294 passes the hotlist check described in the next section, the KDC will issue 1295 the appropriate new ticket. 1297 The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1298 in the sub-session key from the Authenticator, if present, or the session 1299 key key from the ticket-granting ticket. It is not encrypted using the 1300 client's secret key. Furthermore, the client's key's expiration date and the 1301 key version number fields are left out since these values are stored along 1302 with the client's database record, and that record is not needed to satisfy 1303 a request based on a ticket-granting ticket. See section A.6 for pseudocode. 1305 3.3.3.1. Checking for revoked tickets 1307 Whenever a request is made to the ticket-granting server, the presented 1308 ticket(s) is(are) checked against a hot-list of tickets which have been 1309 canceled. This hot-list might be implemented by storing a range of issue 1310 timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1311 that range, it would be rejected. In this way, a stolen ticket-granting 1312 ticket or renewable ticket cannot be used to gain additional tickets 1313 (renewals or otherwise) once the theft has been reported to the KDC for the 1314 realm in which the server resides. Any normal ticket obtained before it was 1315 reported stolen will still be valid (because they require no interaction 1316 with the KDC), but only until their normal expiration time. If TGT's have 1317 been issued for cross-realm authentication, use of the cross-realm TGT will 1318 not be affected unless the hot-list is propagated to the KDC's for the 1319 realms for which such cross-realm tickets were issued. 1321 3.3.3.2. Encoding the transited field 1323 If the identity of the server in the TGT that is presented to the KDC as 1324 part of the authentication header is that of the ticket-granting service, 1325 but the TGT was issued from another realm, the KDC will look up the 1326 inter-realm key shared with that realm and use that key to decrypt the 1327 ticket. If the ticket is valid, then the KDC will honor the request, subject 1328 to the constraints outlined above in the section describing the AS exchange. 1329 The realm part of the client's identity will be taken from the 1330 ticket-granting ticket. The name of the realm that issued the 1331 ticket-granting ticket will be added to the transited field of the ticket to 1332 be issued. This is accomplished by reading the transited field from the 1333 ticket-granting ticket (which is treated as an unordered set of realm 1334 names), adding the new realm to the set, then constructing and writing out 1335 its encoded (shorthand) form (this may involve a rearrangement of the 1336 existing encoding). 1338 Note that the ticket-granting service does not add the name of its own 1339 realm. Instead, its responsibility is to add the name of the previous realm. 1340 This prevents a malicious Kerberos server from intentionally leaving out its 1341 own name (it could, however, omit other realms' names). 1343 The names of neither the local realm nor the principal's realm are to be 1344 included in the transited field. They appear elsewhere in the ticket and 1345 both are known to have taken part in authenticating the principal. Since the 1346 endpoints are not included, both local and single-hop inter-realm 1347 authentication result in a transited field that is empty. 1349 Because the name of each realm transited is added to this field, it might 1350 potentially be very long. To decrease the length of this field, its contents 1351 are encoded. The initially supported encoding is optimized for the normal 1352 case of inter-realm communication: a hierarchical arrangement of realms 1353 using either domain or X.500 style realm names. This encoding (called 1354 DOMAIN-X500-COMPRESS) is now described. 1356 Realm names in the transited field are separated by a ",". The ",", "\", 1357 trailing "."s, and leading spaces (" ") are special characters, and if they 1358 are part of a realm name, they must be quoted in the transited field by 1359 preceding them with a "\". 1361 A realm name ending with a "." is interpreted as being prepended to the 1362 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1363 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1365 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1367 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1368 would not be included in this field, and we would have: 1370 "EDU,MIT.,WASHINGTON.EDU" 1372 A realm name beginning with a "/" is interpreted as being appended to the 1373 previous realm[18]. If it is to stand by itself, then it should be preceded 1374 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1375 /COM/HP, /COM, and /COM/DEC as: 1377 "/COM,/HP,/APOLLO, /COM/DEC". 1379 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1380 they would not be included in this field, and we would have: 1382 "/COM,/HP" 1384 A null subfield preceding or following a "," indicates that all realms 1385 between the previous realm and the next realm have been traversed[19]. Thus, 1386 "," means that all realms along the path between the client and the server 1387 have been traversed. ",EDU, /COM," means that that all realms from the 1388 client's realm up to EDU (in a domain style hierarchy) have been traversed, 1389 and that everything from /COM down to the server's realm in an X.500 style 1390 has also been traversed. This could occur if the EDU realm in one hierarchy 1391 shares an inter-realm key directly with the /COM realm in another hierarchy. 1393 3.3.4. Receipt of KRB_TGS_REP message 1395 When the KRB_TGS_REP is received by the client, it is processed in the same 1396 manner as the KRB_AS_REP processing described above. The primary difference 1397 is that the ciphertext part of the response must be decrypted using the 1398 session key from the ticket-granting ticket rather than the client's secret 1399 key. The server name returned in the reply is the true principal name of the 1400 service. See section A.7 for pseudocode. 1402 3.4. The KRB_SAFE Exchange 1404 The KRB_SAFE message may be used by clients requiring the ability to detect 1405 modifications of messages they exchange. It achieves this by including a 1406 keyed collision-proof checksum of the user data and some control 1407 information. The checksum is keyed with an encryption key (usually the last 1408 key negotiated via subkeys, or the session key if no negotiation has 1409 occurred). 1411 3.4.1. Generation of a KRB_SAFE message 1413 When an application wishes to send a KRB_SAFE message, it collects its data 1414 and the appropriate control information and computes a checksum over them. 1415 The checksum algorithm should be a keyed one-way hash function (such as the 1416 RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), 1417 generated using the sub-session key if present, or the session key. 1418 Different algorithms may be selected by changing the checksum type in the 1419 message. Unkeyed or non-collision-proof checksums are not suitable for this 1420 use. 1422 The control information for the KRB_SAFE message includes both a timestamp 1423 and a sequence number. The designer of an application using the KRB_SAFE 1424 message must choose at least one of the two mechanisms. This choice should 1425 be based on the needs of the application protocol. 1427 Sequence numbers are useful when all messages sent will be received by one's 1428 peer. Connection state is presently required to maintain the session key, so 1429 maintaining the next sequence number should not present an additional 1430 problem. 1432 If the application protocol is expected to tolerate lost messages without 1433 them being resent, the use of the timestamp is the appropriate replay 1434 detection mechanism. Using timestamps is also the appropriate mechanism for 1435 multi-cast protocols where all of one's peers share a common sub-session 1436 key, but some messages will be sent to a subset of one's peers. 1438 After computing the checksum, the client then transmits the information and 1439 checksum to the recipient in the message format specified in section 5.6.1. 1441 3.4.2. Receipt of KRB_SAFE message 1443 When an application receives a KRB_SAFE message, it verifies it as follows. 1444 If any error occurs, an error code is reported for use by the application. 1446 The message is first checked by verifying that the protocol version and type 1447 fields match the current version and KRB_SAFE, respectively. A mismatch 1448 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1449 application verifies that the checksum used is a collision-proof keyed 1450 checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If 1451 the sender's address was included in the control information, the recipient 1452 verifies that the operating system's report of the sender's address matches 1453 the sender's address in the message, and (if a recipient address is 1454 specified or the recipient requires an address) that one of the recipient's 1455 addresses appears as the recipient's address in the message. A failed match 1456 for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and 1457 usec and/or the sequence number fields are checked. If timestamp and usec 1458 are expected and not present, or they are present but not current, the 1459 KRB_AP_ERR_SKEW error is generated. If the server name, along with the 1460 client name, time and microsecond fields from the Authenticator match any 1461 recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT 1462 error is generated. If an incorrect sequence number is included, or a 1463 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error 1464 is generated. If neither a time-stamp and usec or a sequence number is 1465 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is 1466 computed over the data and control information, and if it doesn't match the 1467 received checksum, a KRB_AP_ERR_MODIFIED error is generated. 1469 If all the checks succeed, the application is assured that the message was 1470 generated by its peer and was not modified in transit. 1472 3.5. The KRB_PRIV Exchange 1474 The KRB_PRIV message may be used by clients requiring confidentiality and 1475 the ability to detect modifications of exchanged messages. It achieves this 1476 by encrypting the messages and adding control information. 1478 3.5.1. Generation of a KRB_PRIV message 1480 When an application wishes to send a KRB_PRIV message, it collects its data 1481 and the appropriate control information (specified in section 5.7.1) and 1482 encrypts them under an encryption key (usually the last key negotiated via 1483 subkeys, or the session key if no negotiation has occurred). As part of the 1484 control information, the client must choose to use either a timestamp or a 1485 sequence number (or both); see the discussion in section 3.4.1 for 1486 guidelines on which to use. After the user data and control information are 1487 encrypted, the client transmits the ciphertext and some 'envelope' 1488 information to the recipient. 1490 3.5.2. Receipt of KRB_PRIV message 1492 When an application receives a KRB_PRIV message, it verifies it as follows. 1493 If any error occurs, an error code is reported for use by the application. 1495 The message is first checked by verifying that the protocol version and type 1496 fields match the current version and KRB_PRIV, respectively. A mismatch 1497 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1498 application then decrypts the ciphertext and processes the resultant 1499 plaintext. If decryption shows the data to have been modified, a 1500 KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was 1501 included in the control information, the recipient verifies that the 1502 operating system's report of the sender's address matches the sender's 1503 address in the message, and (if a recipient address is specified or the 1504 recipient requires an address) that one of the recipient's addresses appears 1505 as the recipient's address in the message. A failed match for either case 1506 generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1507 sequence number fields are checked. If timestamp and usec are expected and 1508 not present, or they are present but not current, the KRB_AP_ERR_SKEW error 1509 is generated. If the server name, along with the client name, time and 1510 microsecond fields from the Authenticator match any recently-seen such 1511 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 1512 number is included, or a sequence number is expected but not present, the 1513 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1514 a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1516 If all the checks succeed, the application can assume the message was 1517 generated by its peer, and was securely transmitted (without intruders able 1518 to see the unencrypted contents). 1520 3.6. The KRB_CRED Exchange 1522 The KRB_CRED message may be used by clients requiring the ability to send 1523 Kerberos credentials from one host to another. It achieves this by sending 1524 the tickets together with encrypted data containing the session keys and 1525 other information associated with the tickets. 1527 3.6.1. Generation of a KRB_CRED message 1529 When an application wishes to send a KRB_CRED message it first (using the 1530 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1531 constructs a KRB_CRED message using the ticket or tickets so obtained, 1532 placing the session key needed to use each ticket in the key field of the 1533 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1534 message. 1536 Other information associated with each ticket and obtained during the 1537 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1538 the encrypted part of the KRB_CRED message. The current time and, if 1539 specifically required by the application the nonce, s-address, and r-address 1540 fields, are placed in the encrypted part of the KRB_CRED message which is 1541 then encrypted under an encryption key previously exchanged in the KRB_AP 1542 exchange (usually the last key negotiated via subkeys, or the session key if 1543 no negotiation has occurred). 1545 3.6.2. Receipt of KRB_CRED message 1547 When an application receives a KRB_CRED message, it verifies it. If any 1548 error occurs, an error code is reported for use by the application. The 1549 message is verified by checking that the protocol version and type fields 1550 match the current version and KRB_CRED, respectively. A mismatch generates a 1551 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1552 decrypts the ciphertext and processes the resultant plaintext. If decryption 1553 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1554 generated. 1556 If present or required, the recipient verifies that the operating system's 1557 report of the sender's address matches the sender's address in the message, 1558 and that one of the recipient's addresses appears as the recipient's address 1559 in the message. A failed match for either case generates a 1560 KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field 1561 if required) are checked next. If the timestamp and usec are not present, or 1562 they are present but not current, the KRB_AP_ERR_SKEW error is generated. 1564 If all the checks succeed, the application stores each of the new tickets in 1565 its ticket cache together with the session key and other information in the 1566 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1567 message. 1569 4. The Kerberos Database 1571 The Kerberos server must have access to a database containing the principal 1572 identifiers and secret keys of any principals to be authenticated[4.1] using 1573 such secret keys. The keying material in the database must be protected so 1574 that they are only accessible to the Kerberos server and administrative 1575 functions specifically authorized to access such material. Specific 1576 implementations may handle the storage of keying material separate from the 1577 Kerberos database (e.g. in hardware) or by encrypting the keying material 1578 before placing it in the Kerberos database. Some implementations might 1579 provide a means for using long term secret keys, but not for retrieving them 1580 from the Kerberos database. 1582 4.1. Database contents 1584 A database entry will typically contain the following fields, though in some 1585 instances a KDC may obtain these values through other means: 1587 Field Value 1589 name Principal's identifier 1590 key Principal's secret key 1591 p_kvno Principal's key version 1592 max_life Maximum lifetime for Tickets 1593 max_renewable_life Maximum total lifetime for renewable Tickets 1595 The name field is an encoding of the principal's identifier. The key field 1596 contains an encryption key. This key is the principal's secret key. (The key 1597 can be encrypted before storage under a Kerberos "master key" to protect it 1598 in case the database is compromised but the master key is not. In that case, 1599 an extra field must be added to indicate the master key version used, see 1600 below.) The p_kvno field is the key version number of the principal's secret 1601 key. The max_life field contains the maximum allowable lifetime (endtime - 1602 starttime) for any Ticket issued for this principal. The max_renewable_life 1603 field contains the maximum allowable total lifetime for any renewable Ticket 1604 issued for this principal. (See section 3.1 for a description of how these 1605 lifetimes are used in determining the lifetime of a given Ticket.) 1607 A server may provide KDC service to several realms, as long as the database 1608 representation provides a mechanism to distinguish between principal records 1609 with identifiers which differ only in the realm name. 1611 When an application server's key changes, if the change is routine (i.e. not 1612 the result of disclosure of the old key), the old key should be retained by 1613 the server until all tickets that had been issued using that key have 1614 expired. Because of this, it is possible for several keys to be active for a 1615 single principal. Ciphertext encrypted in a principal's key is always tagged 1616 with the version of the key that was used for encryption, to help the 1617 recipient find the proper key for decryption. 1619 When more than one key is active for a particular principal, the principal 1620 will have more than one record in the Kerberos database. The keys and key 1621 version numbers will differ between the records (the rest of the fields may 1622 or may not be the same). Whenever Kerberos issues a ticket, or responds to a 1623 request for initial authentication, the most recent key (known by the 1624 Kerberos server) will be used for encryption. This is the key with the 1625 highest key version number. 1627 4.2. Additional fields 1629 Project Athena's KDC implementation uses additional fields in its database: 1631 Field Value 1633 K_kvno Kerberos' key version 1634 expiration Expiration date for entry 1635 attributes Bit field of attributes 1636 mod_date Timestamp of last modification 1637 mod_name Modifying principal's identifier 1639 The K_kvno field indicates the key version of the Kerberos master key under 1640 which the principal's secret key is encrypted. 1642 After an entry's expiration date has passed, the KDC will return an error to 1643 any client attempting to gain tickets as or for the principal. (A database 1644 may want to maintain two expiration dates: one for the principal, and one 1645 for the principal's current key. This allows password aging to work 1646 independently of the principal's expiration date. However, due to the 1647 limited space in the responses, the KDC combines the key expiration and 1648 principal expiration date into a single value called 'key_exp', which is 1649 used as a hint to the user to take administrative action.) 1651 The attributes field is a bitfield used to govern the operations involving 1652 the principal. This field might be useful in conjunction with user 1653 registration procedures, for site-specific policy implementations (Project 1654 Athena currently uses it for their user registration process controlled by 1655 the system-wide database service, Moira [LGDSR87]), to identify whether a 1656 principal can play the role of a client or server or both, to note whether a 1657 server is appropriately trusted to receive credentials delegated by a 1658 client, or to identify the 'string to key' conversion algorithm used for a 1659 principal's key[4.2]. Other bits are used to indicate that certain ticket 1660 options should not be allowed in tickets encrypted under a principal's key 1661 (one bit each): Disallow issuing postdated tickets, disallow issuing 1662 forwardable tickets, disallow issuing tickets based on TGT authentication, 1663 disallow issuing renewable tickets, disallow issuing proxiable tickets, and 1664 disallow issuing tickets for which the principal is the server. 1666 The mod_date field contains the time of last modification of the entry, and 1667 the mod_name field contains the name of the principal which last modified 1668 the entry. 1670 4.3. Frequently Changing Fields 1672 Some KDC implementations may wish to maintain the last time that a request 1673 was made by a particular principal. Information that might be maintained 1674 includes the time of the last request, the time of the last request for a 1675 ticket-granting ticket, the time of the last use of a ticket-granting 1676 ticket, or other times. This information can then be returned to the user in 1677 the last-req field (see section 5.2). 1679 Other frequently changing information that can be maintained is the latest 1680 expiration time for any tickets that have been issued using each key. This 1681 field would be used to indicate how long old keys must remain valid to allow 1682 the continued use of outstanding tickets. 1684 4.4. Site Constants 1686 The KDC implementation should have the following configurable constants or 1687 options, to allow an administrator to make and enforce policy decisions: 1689 * The minimum supported lifetime (used to determine whether the 1690 KDC_ERR_NEVER_VALID error should be returned). This constant should 1691 reflect reasonable expectations of round-trip time to the KDC, 1692 encryption/decryption time, and processing time by the client and 1693 target server, and it should allow for a minimum 'useful' lifetime. 1694 * The maximum allowable total (renewable) lifetime of a ticket 1695 (renew_till - starttime). 1696 * The maximum allowable lifetime of a ticket (endtime - starttime). 1697 * Whether to allow the issue of tickets with empty address fields 1698 (including the ability to specify that such tickets may only be issued 1699 if the request specifies some authorization_data). 1700 * Whether proxiable, forwardable, renewable or post-datable tickets are 1701 to be issued. 1703 5. Message Specifications 1705 NOTE: We are continuing to work on changes to message format extensibility 1706 as discussed at the London meeting. We believe the general form discussed in 1707 London will continue to be a useful strategy for pursuing this goal. We 1708 expect to have additional information by the Salt Lake City meeting. TODO: 1709 TypedData needs to be looked at carefully, particularly with regard to 1710 TD-APP-DEFINED-ERROR, etc. Some significant changes from 1510 to here have 1711 been written up; more proofreading is needed. - tlyu 1713 The Kerberos protocol is defined here in terms of Abstract Syntax Notation 1714 One (ASN.1), which provides a syntax for specifying both the abstract layout 1715 of protocol messages as well as their encodings. Implementors not utilizing 1716 an existing ASN.1 compiler or support library are cautioned to thoroughly 1717 understand the actual ASN.1 specification to ensure correct implementation 1718 behavior, as there is more complexity in the notation than is immediately 1719 obvious, and some tutorials and guides to ASN.1 are misleading or erroneous. 1721 Note that in several places, there have been changes here from RFC 1510 that 1722 change the abstract types. This is in part to address widespread assumptions 1723 that various implementations have made, in some cases unintentionally 1724 violating the ASN.1 standard in various ways. These will be clearly flagged 1725 when they occur. The changes to the abstract types can cause incompatible 1726 encodings to be emitted when certain encoding rules, e.g. the Packed 1727 Encoding Rules (PER) are used. This should not be relevant for Kerberos, 1728 since Kerberos explicitly specifies the use of the Distinguished Encoding 1729 Rules (DER). This might be an issue for protocols wishing to use Kerberos 1730 types with other encoding rules. (This practice is not recommended.) With 1731 very few exceptions (most notably the usages of BIT STRING), the encodings 1732 emitted by the DER, which are the only encodings permitted by this document 1733 and by RFC 1510, remain identical. 1735 The type definitions in this section assume an ASN.1 module definition of 1736 the following form: 1738 Kerberos5 { 1739 iso (1), org(3), dod(6), internet(1), security(5), kerberosV5(2) 1740 } DEFINITIONS ::= BEGIN 1742 -- rest of definitions here 1744 END 1746 This specifies an explicit non-automatic tagging for the ASN.1 type 1747 definitions. 1749 Note that in some other publications [RFC1510] [RFC1964], the "dod" portion 1750 of the object identifier is erroneously specified as having the value "5". 1752 Note that elsewhere in this document, nomenclature for various message types 1753 is inconsistent, but seems to largely follow C language conventions, 1754 including use of underscore (_) characters and all-caps spelling of names 1755 intended to be numeric constants. Also, in some places, identifiers 1756 (especially ones refering to constants) are written in all-caps in order to 1757 distinguish them from surrounding explanatory text. 1759 The ASN.1 notation does not permit underscores in identifiers, so in actual 1760 ASN.1 definitions, underscores are replaced with hyphens (-). Additionally, 1761 structure member names and defined values in ASN.1 must begin with a 1762 lowercase letter, while type names must begin with an uppercase letter. 1764 5.1. Specific Compatibility Notes on ASN.1 1766 For compatibility purposes, implementors should heed the following specific 1767 notes regarding the use of ASN.1 in Kerberos. These notes do not describe a 1768 non-standard usage of ASN.1, but rather some historical quirks and 1769 non-compliance of various implementations, as well as historical 1770 ambiguities, which, while being valid ASN.1, can lead to confusion during 1771 implementation. 1773 5.1.1. ASN.1 Distinguished Encoding Rules 1775 The encoding of Kerberos protocol messages shall obey the Distinguished 1776 Encoding Rules (DER) of ASN.1 as described in X.690 (1997). Some 1777 implementations (believed to be primarly ones derived from DCE 1.1 and 1778 earlier) are known to use the more general Basic Encoding Rules (BER); in 1779 particular, these implementations send indefinite encodings of lengths. 1780 Implementations may accept such encodings in the interests of backwards 1781 compatibility, though implementors are warned that decoding fully-general 1782 BER is fraught with peril. 1784 5.1.2. Optional Fields in ASN.1 Sequences 1786 Some implementations behave as if certain default values are equivalent to 1787 omission of an optional value. Implementations should handle this case 1788 gracefully. For example, the seq-number field in an Authenticator is 1789 optional, but some implementations use an internal value of zero to indicate 1790 that the field is to be omitted upon encoding. [While it is possible to use 1791 the DEFAULT qualifier for the ASN.1 notation of a SEQUENCE member in order 1792 to mandate this behavior, the result would be that the member would be 1793 mandatory to omit if the value intended is that specified by the DEFAULT 1794 keyword. This limits the possible semantics of the protocol.] 1796 5.1.3. Zero-length SEQUENCE Types 1798 There are places in the protocol where a message contains a SEQUENCE OF type 1799 as an optional member, or a SEQUENCE type where all members are optional. 1800 This can result in an encoding that contains an zero-length SEQUENCE or 1801 SEQUENCE OF encoding. In general, implementations should not send 1802 zero-length SEQUENCE OF or SEQUENCE encodings that are marked OPTIONAL, but 1803 should accept them. [XXX there may be cases where an empty SEQUENCE type has 1804 useful semantics, though] 1806 5.1.4. Unrecognized Tag Numbers 1808 Future revisions to this protocol may include new message types with 1809 different APPLICATION class tag numbers. Such revisions should protect older 1810 implementations by only sending the message types to parties that are known 1811 to understand them, e.g. by means of a flag bit set by the receiver in a 1812 preceding request. In the interest of robust error handling, implementations 1813 should gracefully handle receiving a message with an unrecognized tag 1814 anyway, and return an error message if appropriate. 1816 5.1.5. Tag Numbers Greater Than 30 1818 A naive implementation of a DER ASN.1 decoder may experience problems with 1819 ASN.1 tag numbers greater than 30, due such tag numbers being encoded using 1820 more than one byte. Future revisions of this protocol may utilize tag 1821 numbers greater than 30, and implementations should be prepared to 1822 gracefully return an error, if appropriate, if they do not recognize the 1823 tag. 1825 5.2. Basic Kerberos Types 1827 This section defines a number of basic types that are potentially used in 1828 multiple Kerberos protocol messages. 1830 5.2.1. KerberosString 1832 [XXX The following paragraphs may need some editing, or maybe they want to 1833 live in a footnote] 1835 The original specification of the Kerberos protocol in RFC 1510 uses 1836 GeneralString in numerous places for human-readable string data. Historical 1837 implementations of Kerberos cannot utilize the full power of GeneralString. 1838 This ASN.1 type requires the use of designation and invocation escape 1839 sequences as specified in ISO 2022 to switch character sets, and the default 1840 character set that is designated for G0 is basically US ASCII, which mostly 1841 works. In practice, many implementations end up treating GeneralStrings as 1842 if they were strings of whatever character set the implementation defaults 1843 to, without regard for correct usage of character set designation escape 1844 sequences. 1846 Also, DER prohibits the invocation of character sets into any but the G0 and 1847 C0 sets, which seems to outright prohibit the encoding of characters with 1848 the high bit set. Unfortunately, this seems to have the side effect of 1849 prohibiting the transmission of Latin-1 characters or any other characters 1850 that belong to a 96-character set, since it is prohibited to invoke them 1851 into G0. Some inconclusive discussion has taken place within the ASN.1 1852 community on this subject. For now, we must assume that the ASN.1 1853 specification of GeneralString as currently published is fundamentally 1854 flawed in several ways. 1856 One method of resolving these myriad difficulties is to constrain the use of 1857 GeneralString to only include IA5String, which is essentially the US-ASCII. 1858 US-ASCII control characters should in general not be used in KerberosString, 1859 except for cases such as newlines in lengthy error messages. 1861 The new (since RFC 1510) type KerberosString, defined below, is a CHOICE 1862 containing a GeneralString that is constrained to only contain characters in 1863 IA5String (which are US-ASCII). Note that the ASN.1 standard does not permit 1864 the use of escape sequences to change the character sets while encoding an 1865 IA5String. 1867 KerberosString ::= CHOICE { 1868 general GeneralString (IA5String), 1869 ... 1870 } 1872 This CHOICE is extensible, so that when an interoperable solution for 1873 internationalization is chosen, it will be easier to specify the changed 1874 types. In the future, changes to this protocol that allow for extensions to 1875 this CHOICE will be specified so that the transmitting party has some way of 1876 knowing whether the receiving party can accept the chosen alternative of the 1877 CHOICE. 1879 Implementations may choose to accept GeneralString values that contain 1880 characters other than those permitted by IA5String, but they should be aware 1881 that character set designation codes will likely be absent, and that the 1882 encoding should probably be treated as locale-specific in almost every way. 1883 Implementations may also choose to emit GeneralString values that are beyond 1884 those permitted by IA5String, but should be aware that doing so is 1885 extraordinarily risky from an interoperability perspective. 1887 Some existing implementations use GeneralString to encode unescaped 1888 locale-specific characters. This is in violation of the ASN.1 standard. Most 1889 of these implementations encode US-ASCII in the left-hand half, so as long 1890 the implementation transmits only US-ASCII, the ASN.1 standard is not 1891 violated in this regard. As soon as such an implementation encodes unescaped 1892 locale-specific characters with the high bit set, it violates the ASN.1 1893 standard. 1895 Other implementations have been known to use GeneralString to contain a 1896 UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 is a 1897 different encoding, not a 94 or 96 character "G" set as defined by ISO 2022. 1898 It is believed that these implementations do not even use the ISO 2022 1899 escape sequence to change the character encoding. Even if implementations 1900 were to announce the change of encoding by using that escape sequence, the 1901 ASN.1 standard prohibits the use of any escape sequences other than those 1902 used to designate/invoke "G" or "C" sets allowed by GeneralString. 1904 Future revisions to this protocol will almost certainly allow for a more 1905 interoperable representation of principal names, probably including 1906 UTF8String. 1908 Note that both applying a new constraint to a previously unconstrained type 1909 and replacing a type with a CHOICE containing that type constitute creations 1910 of new ASN.1 types. In the case here, the change here does not result in a 1911 changed encoding under DER. Also, note that various text in the ASN.1 1912 standard actually suggests the strategy of replacing a type with a CHOICE 1913 containing that type for certain deprecated types, even though this creates 1914 a new type. 1916 5.2.2. Realm and PrincipalName 1918 Realm ::= KerberosString 1919 PrincipalName ::= SEQUENCE { 1920 name-type[0] Int32, 1921 name-string[1] SEQUENCE OF KerberosString 1922 } 1924 Kerberos realm names are encoded as KerberosStrings. Realms shall not 1925 contain a character with the code 0 (the ASCII NUL). Most realms will 1926 usually consist of several components separated by periods (.), in the style 1927 of Internet Domain Names, or separated by slashes (/) in the style of X.500 1928 names. Acceptable forms for realm names are specified in section 7. A 1929 PrincipalName is a typed sequence of components consisting of the following 1930 sub-fields: 1932 name-type 1933 This field specifies the type of name that follows. Pre-defined values 1934 for this field are specified in section 7.2. The name-type should be 1935 treated as a hint. Ignoring the name type, no two names can be the same 1936 (i.e. at least one of the components, or the realm, must be different). 1937 This constraint may be eliminated in the future. 1938 name-string 1939 This field encodes a sequence of components that form a name, each 1940 component encoded as a KerberosString. Taken together, a PrincipalName 1941 and a Realm form a principal identifier. Most PrincipalNames will have 1942 only a few components (typically one or two). 1944 5.2.3. KerberosTime 1946 KerberosTime ::= GeneralizedTime 1947 -- with no fractional seconds 1949 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 1950 KerberosTime value shall not include any fractional portions of the seconds. 1951 As required by the DER, it further shall not include any separators, and it 1952 shall specify the UTC time zone (Z). Example: The only valid format for UTC 1953 time 6 minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z. 1955 5.2.4. Constrained Integer types 1957 Some integer members of types should be constrained to values representable 1958 in 32 bits, for compatibility with reasonable implementation limits. 1960 Int32 ::= INTEGER (-2147483648..2147483647) 1961 -- signed values representable in 32 bits 1963 UInt32 :: = INTEGER (0..4294967295) 1964 -- unsigned 32 bit values 1966 Microseconds ::= INTEGER (0..99999) 1967 -- microseconds 1969 While this results in changes to the abstract types from the RFC 1510 1970 version, the encoding in DER should be unaltered. Historical implementations 1971 were typically limited to 32-bit integer values anyway, and assigned numbers 1972 should fall in the space of integer values representable in 32 bits in order 1973 to promote interoperability anyway. 1975 There are some members of messages types that are still defined as 1976 unconstrained INTEGER types, but many of these have a (non-ASN.1) constraint 1977 applied in the descriptive text. There are specific cases where more 1978 discussion needs to occur regarding possible constraints, such as for the 1979 nonce fields in various messages. 1981 5.2.5. HostAddress and HostAddresses 1983 HostAddress ::= SEQUENCE { 1984 addr-type[0] Int32, 1985 address[1] OCTET STRING 1986 } 1988 HostAddresses ::= SEQUENCE OF HostAddress 1990 The host address encodings consists of two fields: 1992 addr-type 1993 This field specifies the type of address that follows. Pre-defined 1994 values for this field are specified in section 8.1. 1995 address 1996 This field encodes a single address of type addr-type. 1998 The two forms differ slightly. HostAddress contains exactly one address; 1999 HostAddresses contains a sequence of possibly many addresses. 2001 5.2.6. AuthorizationData 2003 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2004 ad-type[0] Int32, 2005 ad-data[1] OCTET STRING 2006 } 2008 ad-data 2009 This field contains authorization data to be interpreted according to 2010 the value of the corresponding ad-type field. 2011 ad-type 2012 This field specifies the format for the ad-data subfield. All negative 2013 values are reserved for local use. Non-negative values are reserved for 2014 registered use. 2016 Each sequence of type and data is referred to as an authorization element. 2017 Elements may be application specific, however, there is a common set of 2018 recursive elements that should be understood by all implementations. These 2019 elements contain other elements embedded within them, and the interpretation 2020 of the encapsulating element determines which of the embedded elements must 2021 be interpreted, and which may be ignored. Definitions for these common 2022 elements may be found in Appendix B. 2024 5.2.7. PA-DATA 2026 Historically, PA-DATA have been known as "pre-authentication data", meaning 2027 that they were used to augment the initial authentication with the KDC. 2028 Since that time, they have also been used as a typed hole with which to 2029 extend protocol exchanges with the KDC. 2031 PA-DATA ::= SEQUENCE { 2032 padata-type[1] Int32, 2033 padata-value[2] OCTET STRING 2034 -- might be encoded AP-REQ 2035 } 2037 padata-type 2038 indicates the way that the padata-value element is to be interpreted. 2039 Negative values of padata-type are reserved for unregistered use; 2040 non-negative values are used for a registered interpretation of the 2041 element type. 2042 padata-value 2043 Usually contains the DER encoding of another type; the padata-type 2044 field identifies which type is encoded here. 2046 padata-type name contents of padata-value 2048 1 pa-tgs-req DER encoding of AP-REQ 2050 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 2052 3 pa-pw-salt salt (not ASN.1 encoded) 2054 10 pa-etype-info DER encoding of PA-ETYPE-INFO 2056 20 pa-use-specified-kvno DER encoding of INTEGER 2058 [XXX -- the following paragraph needs discussion, as does the general 2059 concept of authenticating the cleartext pieces of the protocol] 2060 This field may also contain information needed by certain extensions to the 2061 Kerberos protocol. For example, it might be used to initially verify the 2062 identity of a client before any response is returned. When this field is 2063 used to authenticate or pre-authenticate a request, it should contain a 2064 keyed checksum over the KDC-REQ-BODY to bind the pre-authentication data to 2065 rest of the request. The KDC, as a matter of policy, may decide whether to 2066 honor a KDC-REQ which includes any pre-authentication data that does not 2067 contain the checksum field. 2069 It may also be used by the client to specify the version of a key that is 2070 being used for accompanying preauthentication, and/or which should be used 2071 to encrypt the reply from the KDC. [XXX the following paragraph should apply 2072 perhaps to PA-DATA in general] 2074 The padata field can also contain information needed to help the KDC or the 2075 client select the key needed for generating or decrypting the response. This 2076 form of the padata is useful for supporting the use of certain token cards 2077 with Kerberos. The details of such extensions are specified in separate 2078 documents. See [Pat92] for additional uses of this field. 2080 5.2.7.1. PA-TGS-REQ 2082 In the case of requests for additional tickets (KRB_TGS_REQ), padata-value 2083 will contain an encoded AP-REQ. The checksum in the authenticator (which 2084 must be collision-proof) is to be computed over the KDC-REQ-BODY encoding. 2086 5.2.7.2. Encrypted Timestamp Pre-authentication 2088 There are pre-authentication types that may be used to pre-authenticate a 2089 client by means of an encrypted timestamp. The original PA-ENC-TIMESTAMP 2090 does not contain a checksum of the KDC-REQ-BODY, while the PA-ENC-TIMESTAMP2 2091 does. 2093 PA-ENC-TIMESTAMP ::= EncryptedData -- encrypted PA-ENC-TS-ENC 2095 PA-ENC-TS-ENC ::= SEQUENCE { 2096 patimestamp[0] KerberosTime, -- client's time 2097 pausec[1] Microseconds OPTIONAL 2098 } 2100 -- XXX maybe remove ENC-TIMESTAMP2 for now? 2102 PA-ENC-TIMESTAMP2 ::= EncryptedData -- encrypted PA-ENC-TS2-ENC 2104 PA-ENC-TS2-ENC ::= SEQUENCE { 2105 patimestamp[0] KerberosTime, -- client's time 2106 pausec[1] Microseconds OPTIONAL, 2107 pachecksum[2] Checksum OPTIONAL 2108 -- keyed checksum of KDC-REQ-BODY 2109 } 2111 Patimestamp contains the client's time, and pausec contains the 2112 microseconds, which may be omitted if a client will not generate more than 2113 one request per second. The ciphertext (padata-value) consists of the 2114 PA-ENC-TS-ENC or PA-ENC-TS2-ENC encoding, encrypted using the client's 2115 secret key. 2117 This preauthentication type was not present in RFC 1510, but many 2118 implementations support it. 2120 5.2.7.3. PA-PW-SALT 2122 The padata-value for this preauthentication type contains the salt for the 2123 string-to-key to be used by the client to obtain the key for decrypting the 2124 encrypted part of an AS-REP message. Unfortunately, for historical reasons, 2125 the character set to be used is unspecified and probably locale-specific. 2127 This preauthentication type was not present in RFC 1510, but many 2128 implementations support it. It is necessary in any case where the salt for 2129 the string-to-key algorithm is not the default. 2131 In the trivial example, a zero-length salt string is very commonplace for 2132 realms that have converted their principal databases from Kerberos 4. 2134 5.2.7.4. PA-ETYPE-INFO 2136 The ETYPE-INFO preauthentication type is sent by the KDC in a KRB-ERROR 2137 indicating a requirement for additional preauthentication. It is usually 2138 used to notify a client of which key to use for the encryption of an 2139 encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP 2140 preauthentication value. 2142 ETYPE-INFO-ENTRY ::= SEQUENCE { 2143 etype[0] INTEGER, 2144 salt[1] OCTET STRING OPTIONAL 2145 } 2147 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 2149 The salt, like that of PA-PW-SALT, is also completely unspecified with 2150 respect to character set and is probably locale-specific. 2152 [XXX -- not clear whether ETYPE-INFO or PW-SALT should take precedence if 2153 they conflict] 2155 This preauthentication type was not present in RFC 1510, but many 2156 implementations that support encrypted timestamps for preauthentication need 2157 to support ETYPE-INFO as well. 2159 5.2.7.5. PA-USE-SPECIFIED-KVNO 2161 The KDC should only accept and abide by the value of the use-specified-kvno 2162 preauthentication data field when the specified key is still valid and until 2163 use of a new key is confirmed. This situation is likely to occur primarily 2164 during the period during which an updated key is propagating to other KDC's 2165 in a realm. 2167 5.2.8. KerberosFlags 2169 For several message types, a specific constrained bit string type, 2170 KerberosFlags, is used. 2172 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) 2174 Compatibility note: the following paragraphs describe a change from the 2175 RFC1510 description of bit strings that would result in incompatility in the 2176 case of an implementation that strictly conformed to ASN.1 DER and RFC1510. 2178 ASN.1 bit strings have multiple uses. The simplest use of a bit string is to 2179 contain a vector of bits, with no particular meaning attached to individual 2180 bits. This vector of bits is not necessarily a multiple of eight bits long. 2181 The use in Kerberos of a bit string as a compact boolean vector wherein each 2182 element has a distinct meaning poses some problems. The natural notation for 2183 a compact boolean vector is the ASN.1 "NamedBit" notation, and the DER 2184 require that encodings of a bit string using "NamedBit" notation exclude any 2185 trailing zero bits. This truncation is easy to neglect, especially given C 2186 language implementations that may naturally choose to store boolean vectors 2187 as 32 bit integers. 2189 For example, if the notation for KDCOptions were to include the "NamedBit" 2190 notation, as in RFC 1510, and a KDCOptions value to be encoded had only the 2191 "forwardable" (bit number one) bit set, the DER encoding must only include 2192 two bits: the first reserved bit ("reserved", bit number zero, value zero) 2193 and the one-valued bit (bit number one) for "forwardable". 2195 Most existing implementations of Kerberos unconditionally send 32 bits on 2196 the wire when encoding bit strings used as boolean vectors. This behavior 2197 violates the ASN.1 syntax used for flag values in RFC 1510, but occurs on 2198 such a widely installed base that the protocol description is being modified 2199 to accomodate it. 2201 Consequently, this document removes the "NamedBit" notations for individual 2202 bits, relegating them to comments. The size constraint on the KerberosFlags 2203 type requires that at least 32 bits be encoded at all times, though a 2204 lenient implementation may choose to accept fewer than 32 bits and to treat 2205 the missing bits as set to zero. 2207 Currently, no uses of KerberosFlags specify more than 32 bits worth of 2208 flags, although future revisions of this document may do so. When more than 2209 32 bits are to be transmitted in a KerberosFlags value, future revisions to 2210 this document will likely specify that the smallest number of bits needed to 2211 encode the highest-numbered one-valued bit should be sent. This is somewhat 2212 similar to the DER encoding of a bit string that is declared with the 2213 "NamedBit" notation. 2215 5.2.9. Cryptosystem-related Types 2217 Many Kerberos protocol messages contain an EncryptedData as a container for 2218 arbitrary encrypted data, which is often the encrypted encoding of another 2219 data type. Fields within EncryptedData assist the recipient in selecting a 2220 key with which to decrypt the enclosed data. 2222 EncryptedData ::= SEQUENCE { 2223 etype[0] Int32, -- EncryptionType 2224 kvno[1] INTEGER OPTIONAL, 2225 cipher[2] OCTET STRING -- ciphertext 2226 } 2228 etype 2229 This field identifies which encryption algorithm was used to encipher 2230 the cipher. Detailed specifications for selected encryption types 2231 appear in section 6. 2232 kvno 2233 This field contains the version number of the key under which data is 2234 encrypted. It is only present in messages encrypted under long lasting 2235 keys, such as principals' secret keys. 2236 cipher 2237 This field contains the enciphered text, encoded as an OCTET STRING. 2239 The EncryptionKey type is the means by which cryptographic keys used for 2240 encryption are transfered. 2242 EncryptionKey ::= SEQUENCE { 2243 keytype[0] Int32, -- actually encryption type 2244 keyvalue[1] OCTET STRING 2245 } 2247 keytype 2248 This field specifies the encryption type of the encryption key that 2249 follows in the keyvalue field. While its name is "keytype", it actually 2250 specifies an encryption type. Previously, multiple cryptosystems that 2251 performed encryption differently but were capable of using keys with 2252 the same characteristics were permitted to share an assigned number to 2253 designate the type of key; this usage is now deprecated. 2254 keyvalue 2255 This field contains the key itself, encoded as an octet string. 2257 All negative values for the encryption key type are reserved for local 2258 use. All non-negative values are reserved for officially assigned type 2259 fields and interpretations. 2261 Messages containing cleartext data to be authenticated will usually do so by 2262 using a member of type Checksum. Most instances of Checksum use a keyed 2263 hash, though exceptions will be noted. 2265 Checksum ::= SEQUENCE { 2266 cksumtype[0] Int32, 2267 checksum[1] OCTET STRING 2268 } 2270 cksumtype 2271 This field indicates the algorithm used to generate the accompanying 2272 checksum. 2273 checksum 2274 This field contains the checksum itself, encoded as an octet string. 2276 Detailed specification of selected checksum types appear in section 6. 2277 Negative values for the checksum type are reserved for local use. All 2278 non-negative values are reserved for officially assigned type fields 2279 and interpretations. 2281 5.3. Tickets and Authenticators 2283 This section describes the format and encryption parameters for tickets and 2284 authenticators. When a ticket or authenticator is included in a protocol 2285 message it is treated as an opaque object. 2287 5.3.1. Tickets 2289 A ticket is a record that helps a client authenticate to a service. A Ticket 2290 contains the following information: 2292 Ticket ::= [APPLICATION 1] SEQUENCE { 2293 tkt-vno[0] INTEGER, 2294 realm[1] Realm, 2295 sname[2] PrincipalName, 2296 enc-part[3] EncryptedData --EncTicketPart 2297 } 2299 -- Encrypted part of ticket 2300 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2301 flags[0] TicketFlags, 2302 key[1] EncryptionKey, 2303 crealm[2] Realm, 2304 cname[3] PrincipalName, 2305 transited[4] TransitedEncoding, 2306 authtime[5] KerberosTime, 2307 starttime[6] KerberosTime OPTIONAL, 2308 endtime[7] KerberosTime, 2309 renew-till[8] KerberosTime OPTIONAL, 2310 caddr[9] HostAddresses OPTIONAL, 2311 authorization-data[10] AuthorizationData OPTIONAL 2312 } 2314 -- encoded Transited field 2315 TransitedEncoding ::= SEQUENCE { 2316 tr-type[0] Int32, -- must be registered 2317 contents[1] OCTET STRING 2318 } 2320 TicketFlags ::= KerberosFlags 2321 -- reserved(0), 2322 -- forwardable(1), 2323 -- forwarded(2), 2324 -- proxiable(3), 2325 -- proxy(4), 2326 -- may-postdate(5), 2327 -- postdated(6), 2328 -- invalid(7), 2329 -- renewable(8), 2330 -- initial(9), 2331 -- pre-authent(10), 2332 -- hw-authent(11), 2333 -- transited-policy-checked(12), 2334 -- ok-as-delegate(13) 2335 -- anonymous(14) 2337 The encoding of EncTicketPart is encrypted in the key shared by Kerberos and 2338 the end server (the server's secret key). See section 6 for the format of 2339 the ciphertext. 2341 tkt-vno 2342 This field specifies the version number for the ticket format. This 2343 document describes version number 5. 2345 realm 2346 This field specifies the realm that issued a ticket. It also serves to 2347 identify the realm part of the server's principal identifier. Since a 2348 Kerberos server can only issue tickets for servers within its realm, 2349 the two will always be identical. 2350 sname 2351 This field specifies all components of the name part of the server's 2352 identity, including those parts that identify a specific instance of a 2353 service. 2354 enc-part 2355 This field holds the encrypted encoding of the EncTicketPart sequence. 2356 flags 2357 This field indicates which of various options were used or requested 2358 when the ticket was issued. It is a bit-field, where the selected 2359 options are indicated by the bit being set (1), and the unselected 2360 options and reserved fields being reset (0). [XXX X.690 ref and notes 2361 on pitfalls?] The meanings of the flags are: 2362 Bit(s) Name Description 2364 0 reserved Reserved for future expansion of this 2365 field. 2367 The FORWARDABLE flag is normally only 2368 interpreted by the TGS, and can be 2369 ignored by end servers. When set, this 2370 1 forwardable flag tells the ticket-granting server 2371 that it is OK to issue a new 2372 ticket-granting ticket with a 2373 different network address based on the 2374 presented ticket. 2376 When set, this flag indicates that the 2377 ticket has either been forwarded or 2378 2 forwarded was issued based on authentication 2379 involving a forwarded ticket-granting 2380 ticket. 2382 The PROXIABLE flag is normally only 2383 interpreted by the TGS, and can be 2384 ignored by end servers. The PROXIABLE 2385 flag has an interpretation identical 2386 3 proxiable to that of the FORWARDABLE flag, 2387 except that the PROXIABLE flag tells 2388 the ticket-granting server that only 2389 non-ticket-granting tickets may be 2390 issued with different network 2391 addresses. 2393 4 proxy When set, this flag indicates that a 2394 ticket is a proxy. 2396 The MAY-POSTDATE flag is normally only 2397 interpreted by the TGS, and can be 2398 5 may-postdate ignored by end servers. This flag 2399 tells the ticket-granting server that 2400 a post-dated ticket may be issued 2401 based on this ticket-granting ticket. 2403 This flag indicates that this ticket 2404 has been postdated. The end-service 2405 6 postdated can check the authtime field to see 2406 when the original authentication 2407 occurred. 2409 This flag indicates that a ticket is 2410 invalid, and it must be validated by 2411 7 invalid the KDC before use. Application 2412 servers must reject tickets which have 2413 this flag set. 2415 The RENEWABLE flag is normally only 2416 interpreted by the TGS, and can 2417 usually be ignored by end servers 2418 8 renewable (some particularly careful servers may 2419 wish to disallow renewable tickets). A 2420 renewable ticket can be used to obtain 2421 a replacement ticket that expires at a 2422 later date. 2424 This flag indicates that this ticket 2425 9 initial was issued using the AS protocol, and 2426 not issued based on a ticket-granting 2427 ticket. 2429 This flag indicates that during 2430 initial authentication, the client was 2431 authenticated by the KDC before a 2432 10 pre-authent ticket was issued. The strength of the 2433 preauthentication method is not 2434 indicated, but is acceptable to the 2435 KDC. 2437 This flag indicates that the protocol 2438 employed for initial authentication 2439 required the use of hardware expected 2440 11 hw-authent to be possessed solely by the named 2441 client. The hardware authentication 2442 method is selected by the KDC and the 2443 strength of the method is not 2444 indicated. 2446 This flag indicates that the KDC for 2447 the realm has checked the transited 2448 field against a realm defined policy 2449 for trusted certifiers. If this flag 2450 is reset (0), then the application 2451 server must check the transited field 2452 itself, and if unable to do so it must 2453 reject the authentication. If the flag 2454 12 transited- is set (1) then the application server 2455 policy-checked 2456 may skip its own validation of the 2457 transited field, relying on the 2458 validation performed by the KDC. At 2459 its option the application server may 2460 still apply its own validation based 2461 on a separate policy for acceptance. 2463 This flag is new since RFC 1510. 2465 This flag indicates that the server 2466 (not the client) specified in the 2467 ticket has been determined by policy 2468 of the realm to be a suitable 2469 recipient of delegation. A client can 2470 use the presence of this flag to help 2471 it make a decision whether to delegate 2472 credentials (either grant a proxy or a 2473 forwarded ticket granting ticket) to 2474 13 ok-as-delegate this server. The client is free to 2475 ignore the value of this flag. When 2476 setting this flag, an administrator 2477 should consider the Security and 2478 placement of the server on which the 2479 service will run, as well as whether 2480 the service requires the use of 2481 delegated credentials. 2483 This flag is new since RFC 1510. 2485 This flag indicates that the principal 2486 named in the ticket is a generic 2487 principal for the realm and does not 2488 identify the individual using the 2489 ticket. The purpose of the ticket is 2490 only to securely distribute a session 2491 key, and not to identify the user. 2492 14 anonymous Subsequent requests using the same 2493 ticket and session may be considered 2494 as originating from the same user, but 2495 requests with the same username but a 2496 different ticket are likely to 2497 originate from different users. 2499 This flag is new since RFC 1510. 2501 15-31 reserved Reserved for future use. 2502 key 2503 This field exists in the ticket and the KDC response and is used to 2504 pass the session key from Kerberos to the application server and the 2505 client. The field's encoding is described in section 6.2. 2506 crealm 2507 This field contains the name of the realm in which the client is 2508 registered and in which initial authentication took place. 2509 cname 2510 This field contains the name part of the client's principal identifier. 2511 transited 2512 This field lists the names of the Kerberos realms that took part in 2513 authenticating the user to whom this ticket was issued. It does not 2514 specify the order in which the realms were transited. See section 2515 3.3.3.2 for details on how this field encodes the traversed realms. 2516 When the names of CA's are to be embedded in the transited field (as 2517 specified for some extensions to the protocol), the X.500 names of the 2518 CA's should be mapped into items in the transited field using the 2519 mapping defined by RFC2253. 2520 authtime 2521 This field indicates the time of initial authentication for the named 2522 principal. It is the time of issue for the original ticket on which 2523 this ticket is based. It is included in the ticket to provide 2524 additional information to the end service, and to provide the necessary 2525 information for implementation of a `hot list' service at the KDC. An 2526 end service that is particularly paranoid could refuse to accept 2527 tickets for which the initial authentication occurred "too far" in the 2528 past. This field is also returned as part of the response from the KDC. 2529 When returned as part of the response to initial authentication 2530 (KRB_AS_REP), this is the current time on the Kerberos server[24]. 2531 starttime 2532 This field in the ticket specifies the time after which the ticket is 2533 valid. Together with endtime, this field specifies the life of the 2534 ticket. If it is absent from the ticket, its value should be treated as 2535 that of the authtime field. 2536 endtime 2537 This field contains the time after which the ticket will not be honored 2538 (its expiration time). Note that individual services may place their 2539 own limits on the life of a ticket and may reject tickets which have 2540 not yet expired. As such, this is really an upper bound on the 2541 expiration time for the ticket. 2542 renew-till 2543 This field is only present in tickets that have the RENEWABLE flag set 2544 in the flags field. It indicates the maximum endtime that may be 2545 included in a renewal. It can be thought of as the absolute expiration 2546 time for the ticket, including all renewals. 2547 caddr 2548 This field in a ticket contains zero (if omitted) or more (if present) 2549 host addresses. These are the addresses from which the ticket can be 2550 used. If there are no addresses, the ticket can be used from any 2551 location. The decision by the KDC to issue or by the end server to 2552 accept zero-address tickets is a policy decision and is left to the 2553 Kerberos and end-service administrators; they may refuse to issue or 2554 accept such tickets. The suggested and default policy, however, is that 2555 such tickets will only be issued or accepted when additional 2556 information that can be used to restrict the use of the ticket is 2557 included in the authorization_data field. Such a ticket is a 2558 capability. 2560 Network addresses are included in the ticket to make it harder for an 2561 attacker to use stolen credentials. Because the session key is not sent 2562 over the network in cleartext, credentials can't be stolen simply by 2563 listening to the network; an attacker has to gain access to the session 2564 key (perhaps through operating system security breaches or a careless 2565 user's unattended session) to make use of stolen tickets. 2567 It is important to note that the network address from which a 2568 connection is received cannot be reliably determined. Even if it could 2569 be, an attacker who has compromised the client's workstation could use 2570 the credentials from there. Including the network addresses only makes 2571 it more difficult, not impossible, for an attacker to walk off with 2572 stolen credentials and then use them from a "safe" location. 2574 authorization-data 2575 The authorization-data field is used to pass authorization data from 2576 the principal on whose behalf a ticket was issued to the application 2577 service. If no authorization data is included, this field will be left 2578 out. Experience has shown that the name of this field is confusing, and 2579 that a better name for this field would be restrictions. Unfortunately, 2580 it is not possible to change the name of this field at this time. 2582 This field contains restrictions on any authority obtained on the basis 2583 of authentication using the ticket. It is possible for any principal in 2584 posession of credentials to add entries to the authorization data field 2585 since these entries further restrict what can be done with the ticket. 2586 Such additions can be made by specifying the additional entries when a 2587 new ticket is obtained during the TGS exchange, or they may be added 2588 during chained delegation using the authorization data field of the 2589 authenticator. 2591 Because entries may be added to this field by the holder of 2592 credentials, except when an entry is separately authenticated by 2593 encapsulation in the kdc-issued element, it is not allowable for the 2594 presence of an entry in the authorization data field of a ticket to 2595 amplify the privileges one would obtain from using a ticket. 2597 The data in this field may be specific to the end service; the field 2598 will contain the names of service specific objects, and the rights to 2599 those objects. The format for this field is described in section 5.2. 2600 Although Kerberos is not concerned with the format of the contents of 2601 the sub-fields, it does carry type information (ad-type). 2603 By using the authorization_data field, a principal is able to issue a 2604 proxy that is valid for a specific purpose. For example, a client 2605 wishing to print a file can obtain a file server proxy to be passed to 2606 the print server. By specifying the name of the file in the 2607 authorization_data field, the file server knows that the print server 2608 can only use the client's rights when accessing the particular file to 2609 be printed. 2611 A separate service providing authorization or certifying group 2612 membership may be built using the authorization-data field. In this 2613 case, the entity granting authorization (not the authorized entity), 2614 may obtain a ticket in its own name (e.g. the ticket is issued in the 2615 name of a privilege server), and this entity adds restrictions on its 2616 own authority and delegates the restricted authority through a proxy to 2617 the client. The client would then present this authorization credential 2618 to the application server separately from the authentication exchange. 2619 Alternatively, such authorization credentials may be embedded in the 2620 ticket authenticating the authorized entity, when the authorization is 2621 separately authenticated using the kdc-issued authorization data 2622 element (see B.4). 2624 Similarly, if one specifies the authorization-data field of a proxy and 2625 leaves the host addresses blank, the resulting ticket and session key 2626 can be treated as a capability. See [Neu93] for some suggested uses of 2627 this field. 2629 The authorization-data field is optional and does not have to be 2630 included in a ticket. 2632 5.3.2. Authenticators 2634 An authenticator is a record sent with a ticket to a server to certify the 2635 client's knowledge of the encryption key in the ticket, to help the server 2636 detect replays, and to help choose a "true session key" to use with the 2637 particular session. The encoding is encrypted in the ticket's session key 2638 shared by the client and the server: 2640 -- Unencrypted authenticator 2641 Authenticator ::= [APPLICATION 2] SEQUENCE { 2642 authenticator-vno[0] INTEGER, 2643 crealm[1] Realm, 2644 cname[2] PrincipalName, 2645 cksum[3] Checksum OPTIONAL, 2646 cusec[4] Microseconds, 2647 ctime[5] KerberosTime, 2648 subkey[6] EncryptionKey OPTIONAL, 2649 seq-number[7] UInt32 OPTIONAL, 2650 authorization-data[8] AuthorizationData OPTIONAL 2651 } 2653 authenticator-vno 2654 This field specifies the version number for the format of the 2655 authenticator. This document specifies version 5. 2656 crealm and cname 2657 These fields are the same as those described for the ticket in section 2658 5.3.1. 2659 cksum 2660 This field contains a checksum of the the application data that 2661 accompanies the KRB_AP_REQ. 2662 cusec 2663 This field contains the microsecond part of the client's timestamp. Its 2664 value (before encryption) ranges from 0 to 999999. It often appears 2665 along with ctime. The two fields are used together to specify a 2666 reasonably accurate timestamp. 2667 ctime 2668 This field contains the current time on the client's host. 2669 subkey 2670 This field contains the client's choice for an encryption key which is 2671 to be used to protect this specific application session. Unless an 2672 application specifies otherwise, if this field is left out the session 2673 key from the ticket will be used. 2674 seq-number 2675 This optional field includes the initial sequence number to be used by 2676 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 2677 detect replays (It may also be used by application specific messages). 2678 When included in the authenticator this field specifies the initial 2679 sequence number for messages from the client to the server. When 2680 included in the AP-REP message, the initial sequence number is that for 2681 messages from the server to the client. When used in KRB_PRIV or 2682 KRB_SAFE messages, it is incremented by one after each message is sent. 2683 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to 2684 zero following the value 2^32 - 1. 2686 For sequence numbers to adequately support the detection of replays 2687 they should be non-repeating, even across connection boundaries. The 2688 initial sequence number should be random and uniformly distributed 2689 across the full space of possible sequence numbers, so that it cannot 2690 be guessed by an attacker and so that it and the successive sequence 2691 numbers do not repeat other sequences. 2693 authorization-data 2694 This field is the same as described for the ticket in section 5.3.1. It 2695 is optional and will only appear when additional restrictions are to be 2696 placed on the use of a ticket, beyond those carried in the ticket 2697 itself. 2699 5.4. Specifications for the AS and TGS exchanges 2701 This section specifies the format of the messages used in the exchange 2702 between the client and the Kerberos server. The format of possible error 2703 messages appears in section 5.9.1. 2705 5.4.1. KRB_KDC_REQ definition 2707 The KRB_KDC_REQ message has no type of its own. Instead, its type is one of 2708 KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial 2709 ticket or an additional ticket. In either case, the message is sent from the 2710 client to the Authentication Server to request credentials for a service. 2712 The message fields are: 2714 AS-REQ ::= [APPLICATION 10] KDC-REQ 2715 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2717 KDC-REQ ::= SEQUENCE { 2718 pvno[1] INTEGER, 2719 msg-type[2] INTEGER, 2720 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2721 req-body[4] KDC-REQ-BODY 2722 } 2724 KDC-REQ-BODY ::= SEQUENCE { 2725 kdc-options[0] KDCOptions, 2726 cname[1] PrincipalName OPTIONAL, 2727 -- Used only in AS-REQ 2728 realm[2] Realm, -- Server's realm 2729 -- Also client's in AS-REQ 2730 sname[3] PrincipalName OPTIONAL, 2731 from[4] KerberosTime OPTIONAL, 2732 till[5] KerberosTime, 2733 rtime[6] KerberosTime OPTIONAL, 2734 nonce[7] INTEGER, 2735 etype[8] SEQUENCE OF Int32, 2736 -- EncryptionType, 2737 -- in preference order 2738 addresses[9] HostAddresses OPTIONAL, 2739 enc-authorization-data[10] EncryptedData OPTIONAL, 2740 -- Encrypted AuthorizationData 2741 -- encoding 2742 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2743 } 2744 KDCOptions ::= KerberosFlags 2745 -- reserved(0), 2746 -- forwardable(1), 2747 -- forwarded(2), 2748 -- proxiable(3), 2749 -- proxy(4), 2750 -- allow-postdate(5), 2751 -- postdated(6), 2752 -- unused7(7), 2753 -- renewable(8), 2754 -- unused9(9), 2755 -- unused10(10), 2756 -- unused11(11), 2757 -- unused12(12), 2758 -- unused13(13), 2759 -- requestanonymous(14), 2760 -- canonicalize(15), 2761 -- disable-transited-check(26), 2762 -- renewable-ok(27), 2763 -- enc-tkt-in-skey(28), 2764 -- renew(30), 2765 -- validate(31) 2767 The fields in this message are: 2769 pvno 2770 This field is included in each message, and specifies the protocol 2771 version number. This document specifies protocol version 5. 2772 msg-type 2773 This field indicates the type of a protocol message. It will almost 2774 always be the same as the application identifier associated with a 2775 message. It is included to make the identifier more readily accessible 2776 to the application. For the KDC-REQ message, this type will be 2777 KRB_AS_REQ or KRB_TGS_REQ. 2778 padata 2779 Contains pre-authentication data. Requests for additional tickets 2780 (KRB_TGS_REQ) must contain a padata of PA-TGS-REQ. 2782 The padata (pre-authentication data) field contains a sequence of 2783 authentication information which may be needed before credentials can 2784 be issued or decrypted. In most requests for initial authentication 2785 (KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left 2786 out. 2787 req-body 2788 This field is a placeholder delimiting the extent of the remaining 2789 fields. If a checksum is to be calculated over the request, it is 2790 calculated over an encoding of the KDC-REQ-BODY sequence which is 2791 enclosed within the req-body field. 2792 kdc-options 2793 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2794 KDC and indicates the flags that the client wants set on the tickets as 2795 well as other information that is to modify the behavior of the KDC. 2796 Where appropriate, the name of an option may be the same as the flag 2797 that is set by that option. Although in most case, the bit in the 2798 options field will be the same as that in the flags field, this is not 2799 guaranteed, so it is not acceptable to simply copy the options field to 2800 the flags field. There are various checks that must be made before 2801 honoring an option anyway. 2803 The kdc_options field is a bit-field, where the selected options are 2804 indicated by the bit being set (1), and the unselected options and 2805 reserved fields being reset (0). The encoding of the bits is specified 2806 in section 5.2. The options are described in more detail above in 2807 section 2. The meanings of the options are: 2808 Bits Name Description 2810 0 RESERVED Reserved for future expansion of 2811 this field. 2813 The FORWARDABLE option indicates 2814 that the ticket to be issued is to 2815 have its forwardable flag set. It 2816 1 FORWARDABLE may only be set on the initial 2817 request, or in a subsequent request 2818 if the ticket-granting ticket on 2819 which it is based is also 2820 forwardable. 2822 The FORWARDED option is only 2823 specified in a request to the 2824 ticket-granting server and will only 2825 be honored if the ticket-granting 2826 ticket in the request has its 2827 2 FORWARDED FORWARDABLE bit set. This option 2828 indicates that this is a request for 2829 forwarding. The address(es) of the 2830 host from which the resulting ticket 2831 is to be valid are included in the 2832 addresses field of the request. 2834 The PROXIABLE option indicates that 2835 the ticket to be issued is to have 2836 its proxiable flag set. It may only 2837 3 PROXIABLE be set on the initial request, or in 2838 a subsequent request if the 2839 ticket-granting ticket on which it 2840 is based is also proxiable. 2842 The PROXY option indicates that this 2843 is a request for a proxy. This 2844 option will only be honored if the 2845 ticket-granting ticket in the 2846 4 PROXY request has its PROXIABLE bit set. 2847 The address(es) of the host from 2848 which the resulting ticket is to be 2849 valid are included in the addresses 2850 field of the request. 2852 The ALLOW-POSTDATE option indicates 2853 that the ticket to be issued is to 2854 have its MAY-POSTDATE flag set. It 2855 5 ALLOW-POSTDATE may only be set on the initial 2856 request, or in a subsequent request 2857 if the ticket-granting ticket on 2858 which it is based also has its 2859 MAY-POSTDATE flag set. 2861 The POSTDATED option indicates that 2862 this is a request for a postdated 2863 ticket. This option will only be 2864 honored if the ticket-granting 2865 ticket on which it is based has its 2866 6 POSTDATED MAY-POSTDATE flag set. The resulting 2867 ticket will also have its INVALID 2868 flag set, and that flag may be reset 2869 by a subsequent request to the KDC 2870 after the starttime in the ticket 2871 has been reached. 2873 7 UNUSED This option is presently unused. 2875 The RENEWABLE option indicates that 2876 the ticket to be issued is to have 2877 its RENEWABLE flag set. It may only 2878 be set on the initial request, or 2879 when the ticket-granting ticket on 2880 8 RENEWABLE which the request is based is also 2881 renewable. If this option is 2882 requested, then the rtime field in 2883 the request contains the desired 2884 absolute expiration time for the 2885 ticket. 2887 9 RESERVED Reserved for PK-Cross 2889 10-13 UNUSED These options are presently unused. 2891 The REQUEST-ANONYMOUS option 2892 indicates that the ticket to be 2893 issued is not to identify the user 2894 to which it was issued. Instead, the 2895 principal identifier is to be 2896 generic, as specified by the policy 2897 of the realm (e.g. usually 2898 anonymous@realm). The purpose of the 2899 14 REQUEST-ANONYMOUS ticket is only to securely 2900 distribute a session key, and not to 2901 identify the user. The ANONYMOUS 2902 flag on the ticket to be returned 2903 should be set. If the local realms 2904 policy does not permit anonymous 2905 credentials, the request is to be 2906 rejected. 2908 This flag is new since RFC 1510 2910 The CANONICALIZE option indicates 2911 that the client will accept the 2912 return of a true server name instead 2913 of the name specified in the 2914 request. In addition the client will 2915 be able to process any TGT referrals 2916 that will direct the client to 2917 another realm to locate the 2918 15 CANONICALIZE requested server. If a KDC does not 2919 support name- canonicalization, the 2920 option is ignored and the 2921 appropriate 2922 KDC_ERR_C_PRINCIPAL_UNKNOWN or 2923 KDC_ERR_S_PRINCIPAL_UNKNOWN error is 2924 returned. [JBrezak] 2926 This flag is new since RFC 1510 2927 16-25 RESERVED Reserved for future use. 2929 By default the KDC will check the 2930 transited field of a 2931 ticket-granting-ticket against the 2932 policy of the local realm before it 2933 will issue derivative tickets based 2934 on the ticket granting ticket. If 2935 this flag is set in the request, 2936 checking of the transited field is 2937 disabled. Tickets issued without the 2938 26 DISABLE-TRANSITED-CHECK performance of this check will be 2939 noted by the reset (0) value of the 2940 TRANSITED-POLICY-CHECKED flag, 2941 indicating to the application server 2942 that the tranisted field must be 2943 checked locally. KDC's are 2944 encouraged but not required to honor 2945 the DISABLE-TRANSITED-CHECK option. 2947 This flag is new since RFC 1510 2949 The RENEWABLE-OK option indicates 2950 that a renewable ticket will be 2951 acceptable if a ticket with the 2952 requested life cannot otherwise be 2953 provided. If a ticket with the 2954 requested life cannot be provided, 2955 27 RENEWABLE-OK then a renewable ticket may be 2956 issued with a renew-till equal to 2957 the the requested endtime. The value 2958 of the renew-till field may still be 2959 limited by local limits, or limits 2960 selected by the individual principal 2961 or server. 2963 This option is used only by the 2964 ticket-granting service. The 2965 ENC-TKT-IN-SKEY option indicates 2966 28 ENC-TKT-IN-SKEY that the ticket for the end server 2967 is to be encrypted in the session 2968 key from the additional 2969 ticket-granting ticket provided. 2971 29 RESERVED Reserved for future use. 2973 This option is used only by the 2974 ticket-granting service. The RENEW 2975 option indicates that the present 2976 request is for a renewal. The ticket 2977 provided is encrypted in the secret 2978 key for the server on which it is 2979 30 RENEW valid. This option will only be 2980 honored if the ticket to be renewed 2981 has its RENEWABLE flag set and if 2982 the time in its renew-till field has 2983 not passed. The ticket to be renewed 2984 is passed in the padata field as 2985 part of the authentication header. 2987 This option is used only by the 2988 ticket-granting service. The 2989 VALIDATE option indicates that the 2990 request is to validate a postdated 2991 ticket. It will only be honored if 2992 the ticket presented is postdated, 2993 presently has its INVALID flag set, 2994 31 VALIDATE and would be otherwise usable at 2995 this time. A ticket cannot be 2996 validated before its starttime. The 2997 ticket presented for validation is 2998 encrypted in the key of the server 2999 for which it is valid and is passed 3000 in the padata field as part of the 3001 authentication header. 3002 cname and sname 3003 These fields are the same as those described for the ticket in section 3004 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is 3005 specified. If absent, the name of the server is taken from the name of 3006 the client in the ticket passed as additional-tickets. 3007 enc-authorization-data 3008 The enc-authorization-data, if present (and it can only be present in 3009 the TGS_REQ form), is an encoding of the desired authorization-data 3010 encrypted under the sub-session key if present in the Authenticator, or 3011 alternatively from the session key in the ticket-granting ticket, both 3012 from the padata field in the KRB_AP_REQ. 3013 realm 3014 This field specifies the realm part of the server's principal 3015 identifier. In the AS exchange, this is also the realm part of the 3016 client's principal identifier. If the CANONICALIZE option is set, the 3017 realm is used as a hint to the KDC for its database lookup. 3018 from 3019 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3020 requests when the requested ticket is to be postdated. It specifies the 3021 desired start time for the requested ticket. If this field is omitted 3022 then the KDC should use the current time instead. 3023 till 3024 This field contains the expiration date requested by the client in a 3025 ticket request. [XXX This was optional in kerberos-revisions, but 3026 required in 1510. we should make it required and specify semantics for 3027 19700101000000Z] It is optional and if omitted the requested ticket is 3028 to have the maximum endtime permitted according to KDC policy for the 3029 parties to the authentication exchange as limited by expiration date of 3030 the ticket granting ticket or other preauthentication credentials. 3031 rtime 3032 This field is the requested renew-till time sent from a client to the 3033 KDC in a ticket request. It is optional. 3034 nonce 3035 This field is part of the KDC request and response. It it intended to 3036 hold a random number generated by the client. If the same number is 3037 included in the encrypted response from the KDC, it provides evidence 3038 that the response is fresh and has not been replayed by an attacker. 3039 Nonces must never be re-used. Ideally, it should be generated randomly, 3040 but if the correct time is known, it may suffice[25]. 3041 etype 3042 This field specifies the desired encryption algorithm to be used in the 3043 response. 3045 addresses 3046 This field is included in the initial request for tickets, and 3047 optionally included in requests for additional tickets from the 3048 ticket-granting server. It specifies the addresses from which the 3049 requested ticket is to be valid. Normally it includes the addresses for 3050 the client's host. If a proxy is requested, this field will contain 3051 other addresses. The contents of this field are usually copied by the 3052 KDC into the caddr field of the resulting ticket. 3053 additional-tickets 3054 Additional tickets may be optionally included in a request to the 3055 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 3056 specified, then the session key from the additional ticket will be used 3057 in place of the server's key to encrypt the new ticket. When the 3058 ENC-TKT-IN-SKEY option is used for user-to-user authentication, this 3059 addional ticket may be a TGT issued by the local realm or an 3060 inter-realm TGT issued for the current KDC's realm by a remote KDC. If 3061 more than one option which requires additional tickets has been 3062 specified, then the additional tickets are used in the order specified 3063 by the ordering of the options bits (see kdc-options, above). 3065 The application tag number will be either ten (10) or twelve (12) depending 3066 on whether the request is for an initial ticket (AS-REQ) or for an 3067 additional ticket (TGS-REQ). 3069 The optional fields (addresses, authorization-data and additional-tickets) 3070 are only included if necessary to perform the operation specified in the 3071 kdc-options field. 3073 It should be noted that in KRB_TGS_REQ, the protocol version number appears 3074 twice and two different message types appear: the KRB_TGS_REQ message 3075 contains these fields as does the authentication header (KRB_AP_REQ) that is 3076 passed in the padata field. 3078 5.4.2. KRB_KDC_REP definition 3080 The KRB_KDC_REP message format is used for the reply from the KDC for either 3081 an initial (AS) request or a subsequent (TGS) request. There is no message 3082 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 3083 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 3084 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 3085 the client's secret key, and the client's key version number is included in 3086 the key version number for the encrypted data. For KRB_TGS_REP, the 3087 ciphertext is encrypted in the sub-session key from the Authenticator, or if 3088 absent, the session key from the ticket-granting ticket used in the request. 3089 In that case, no version number will be present in the EncryptedData 3090 sequence. 3092 The KRB_KDC_REP message contains the following fields: 3094 AS-REP ::= [APPLICATION 11] KDC-REP 3095 TGS-REP ::= [APPLICATION 13] KDC-REP 3097 KDC-REP ::= SEQUENCE { 3098 pvno[0] INTEGER, 3099 msg-type[1] INTEGER, 3100 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 3101 crealm[3] Realm, 3102 cname[4] PrincipalName, 3103 ticket[5] Ticket, 3104 enc-part[6] EncryptedData 3105 -- EncASREpPart or EncTGSReoOart 3106 } 3107 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart -- note [27] 3108 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 3110 EncKDCRepPart ::= SEQUENCE { 3111 key[0] EncryptionKey, 3112 last-req[1] LastReq, 3113 nonce[2] INTEGER, 3114 key-expiration[3] KerberosTime OPTIONAL, 3115 flags[4] TicketFlags, 3116 authtime[5] KerberosTime, 3117 starttime[6] KerberosTime OPTIONAL, 3118 endtime[7] KerberosTime, 3119 renew-till[8] KerberosTime OPTIONAL, 3120 srealm[9] Realm, 3121 sname[10] PrincipalName, 3122 caddr[11] HostAddresses OPTIONAL 3123 } 3124 LastReq ::= SEQUENCE OF SEQUENCE { 3125 lr-type[0] Int32, 3126 lr-value[1] KerberosTime 3127 } 3129 pvno and msg-type 3130 These fields are described above in section 5.4.1. msg-type is either 3131 KRB_AS_REP or KRB_TGS_REP. 3132 padata 3133 This field is described in detail in section 5.4.1. One possible use 3134 for this field is to encode an alternate "mix-in" string to be used 3135 with a string-to-key algorithm (such as is described in section 6.3.2). 3136 This ability is useful to ease transitions if a realm name needs to 3137 change (e.g. when a company is acquired); in such a case all existing 3138 password-derived entries in the KDC database would be flagged as 3139 needing a special mix-in string until the next password change. 3140 crealm, cname, srealm and sname 3141 These fields are the same as those described for the ticket in section 3142 5.3.1. 3143 ticket 3144 The newly-issued ticket, from section 5.3.1. 3145 enc-part 3146 This field is a place holder for the ciphertext and related information 3147 that forms the encrypted part of a message. The description of the 3148 encrypted part of the message follows each appearance of this field. 3149 The encrypted part is encoded as described in section 6.1. 3150 key 3151 This field is the same as described for the ticket in section 5.3.1. 3152 last-req 3153 This field is returned by the KDC and specifies the time(s) of the last 3154 request by a principal. Depending on what information is available, 3155 this might be the last time that a request for a ticket-granting ticket 3156 was made, or the last time that a request based on a ticket-granting 3157 ticket was successful. It also might cover all servers for a realm, or 3158 just the particular server. Some implementations may display this 3159 information to the user to aid in discovering unauthorized use of one's 3160 identity. It is similar in spirit to the last login time displayed when 3161 logging into timesharing systems. 3162 lr-type 3163 This field indicates how the following lr-value field is to be 3164 interpreted. Negative values indicate that the information 3165 pertains only to the responding server. Non-negative values 3166 pertain to all servers for the realm. 3168 If the lr-type field is zero (0), then no information is conveyed 3169 by the lr-value subfield. If the absolute value of the lr-type 3170 field is one (1), then the lr-value subfield is the time of last 3171 initial request for a TGT. If it is two (2), then the lr-value 3172 subfield is the time of last initial request. If it is three (3), 3173 then the lr-value subfield is the time of issue for the newest 3174 ticket-granting ticket used. If it is four (4), then the lr-value 3175 subfield is the time of the last renewal. If it is five (5), then 3176 the lr-value subfield is the time of last request (of any type). 3177 If it is (6), then the lr-value subfield is the time when the 3178 password will expire. 3179 lr-value 3180 This field contains the time of the last request. the time must be 3181 interpreted according to the contents of the accompanying lr-type 3182 subfield. 3183 nonce 3184 This field is described above in section 5.4.1. 3185 key-expiration 3186 The key-expiration field is part of the response from the KDC and 3187 specifies the time that the client's secret key is due to expire. The 3188 expiration might be the result of password aging or an account 3189 expiration. This field will usually be left out of the TGS reply since 3190 the response to the TGS request is encrypted in a session key and no 3191 client information need be retrieved from the KDC database. It is up to 3192 the application client (usually the login program) to take appropriate 3193 action (such as notifying the user) if the expiration time is imminent. 3194 flags, authtime, starttime, endtime, renew-till and caddr 3195 These fields are duplicates of those found in the encrypted portion of 3196 the attached ticket (see section 5.3.1), provided so the client may 3197 verify they match the intended request and to assist in proper ticket 3198 caching. If the message is of type KRB_TGS_REP, the caddr field will 3199 only be filled in if the request was for a proxy or forwarded ticket, 3200 or if the user is substituting a subset of the addresses from the 3201 ticket granting ticket. If the client-requested addresses are not 3202 present or not used, then the addresses contained in the ticket will be 3203 the same as those included in the ticket-granting ticket. 3205 5.5. Client/Server (CS) message specifications 3207 This section specifies the format of the messages used for the 3208 authentication of the client to the application server. 3210 5.5.1. KRB_AP_REQ definition 3212 The KRB_AP_REQ message contains the Kerberos protocol version number, the 3213 message type KRB_AP_REQ, an options field to indicate any options in use, 3214 and the ticket and authenticator themselves. The KRB_AP_REQ message is often 3215 referred to as the 'authentication header'. 3217 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3218 pvno[0] INTEGER, 3219 msg-type[1] INTEGER, 3220 ap-options[2] APOptions, 3221 ticket[3] Ticket, 3222 authenticator[4] EncryptedData 3223 -- Authenticator from 5.3.2 3224 } 3225 APOptions ::= KerberosFlags 3226 -- reserved(0), 3227 -- use-session-key(1), 3228 -- mutual-required(2) 3230 pvno and msg-type 3231 These fields are described above in section 5.4.1. msg-type is 3232 KRB_AP_REQ. 3233 ap-options 3234 This field appears in the application request (KRB_AP_REQ) and affects 3235 the way the request is processed. It is a bit-field, where the selected 3236 options are indicated by the bit being set (1), and the unselected 3237 options and reserved fields being reset (0). The encoding of the bits 3238 is specified in section 5.2. The meanings of the options are: 3239 Bit(s) Name Description 3241 0 reserved Reserved for future expansion of this field. 3243 The USE-SESSION-KEY option indicates that the 3244 ticket the client is presenting to a server 3245 1 use-session-key is encrypted in the session key from the 3246 server's ticket-granting ticket. When this 3247 option is not specified, the ticket is 3248 encrypted in the server's secret key. 3250 The MUTUAL-REQUIRED option tells the server 3251 2 mutual-required that the client requires mutual 3252 authentication, and that it must respond with 3253 a KRB_AP_REP message. 3255 3-31 reserved Reserved for future use. 3256 ticket 3257 This field is a ticket authenticating the client to the server. 3258 authenticator 3259 This contains the authenticator, which includes the client's choice of 3260 a subkey. Its encoding is described in section 5.3.2. 3262 5.5.2. KRB_AP_REP definition 3264 The KRB_AP_REP message contains the Kerberos protocol version number, the 3265 message type, and an encrypted time- stamp. The message is sent in in 3266 response to an application request (KRB_AP_REQ) where the mutual 3267 authentication option has been selected in the ap-options field. 3269 AP-REP ::= [APPLICATION 15] SEQUENCE { 3270 pvno[0] INTEGER, 3271 msg-type[1] INTEGER, 3272 enc-part[2] EncryptedData 3273 -- EncAPRepPart 3274 } 3276 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { -- note [29] 3277 ctime[0] KerberosTime, 3278 cusec[1] Microseconds, 3279 subkey[2] EncryptionKey OPTIONAL, 3280 seq-number[3] UInt32 OPTIONAL 3281 } 3282 The encoded EncAPRepPart is encrypted in the shared session key of the 3283 ticket. The optional subkey field can be used in an application-arranged 3284 negotiation to choose a per association session key. 3286 pvno and msg-type 3287 These fields are described above in section 5.4.1. msg-type is 3288 KRB_AP_REP. 3289 enc-part 3290 This field is described above in section 5.4.2. 3291 ctime 3292 This field contains the current time on the client's host. 3293 cusec 3294 This field contains the microsecond part of the client's timestamp. 3295 subkey 3296 This field contains an encryption key which is to be used to protect 3297 this specific application session. See section 3.2.6 for specifics on 3298 how this field is used to negotiate a key. Unless an application 3299 specifies otherwise, if this field is left out, the sub-session key 3300 from the authenticator, or if also left out, the session key from the 3301 ticket will be used. 3302 seq-number 3303 This field is described above in section 5.3.2. 3305 5.5.3. Error message reply 3307 If an error occurs while processing the application request, the KRB_ERROR 3308 message will be sent in response. See section 5.9.1 for the format of the 3309 error message. The cname and crealm fields may be left out if the server 3310 cannot determine their appropriate values from the corresponding KRB_AP_REQ 3311 message. If the authenticator was decipherable, the ctime and cusec fields 3312 will contain the values from it. 3314 5.6. KRB_SAFE message specification 3316 This section specifies the format of a message that can be used by either 3317 side (client or server) of an application to send a tamper-proof message to 3318 its peer. It presumes that a session key has previously been exchanged (for 3319 example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3321 There are two KRB_SAFE messages; the KRB-SAFE message is the one specified 3322 in RFC 1510. The KRB-SAFE2 message is new with this document, and shares a 3323 number of fields with the old KRB-SAFE message. 3325 5.6.1. KRB_SAFE definition 3327 The KRB_SAFE message contains user data along with a collision-proof 3328 checksum keyed with the last encryption key negotiated via subkeys, or the 3329 session key if no negotiation has occurred. The message fields are: 3331 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3332 pvno[0] INTEGER, 3333 msg-type[1] INTEGER, 3334 safe-body[2] KRB-SAFE-BODY, 3335 cksum[3] Checksum 3336 } 3338 KRB-SAFE-BODY ::= SEQUENCE { 3339 user-data[0] OCTET STRING, 3340 timestamp[1] KerberosTime OPTIONAL, 3341 usec[2] Microseconds OPTIONAL, 3342 seq-number[3] UInt32 OPTIONAL, 3343 s-address[4] HostAddress, 3344 r-address[5] HostAddress OPTIONAL 3345 } 3346 pvno and msg-type 3347 These fields are described above in section 5.4.1. msg-type is KRB_SAFE 3348 or KRB_SAFE2, respectively, for the KRB-SAFE and KRB-SAFE2 messages. 3349 safe-body 3350 This field is a placeholder for the body of the KRB-SAFE message. 3351 cksum 3352 This field contains the checksum of the application data. Checksum 3353 details are described in section 6.4. 3355 The checksum is computed over the encoding of the KRB-SAFE sequence. 3356 First, the cksum is set to a type zero, zero-length value and the 3357 checksum is computed over the encoding of the KRB-SAFE sequence, then 3358 the checksum is set to the result of that computation, and finally the 3359 KRB-SAFE sequence is encoded again. This method, while different than 3360 the one specified in RFC 1510, corresponds to existing practice. 3361 user-data 3362 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 3363 the application specific data that is being passed from the sender to 3364 the recipient. 3365 timestamp 3366 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 3367 are the current time as known by the sender of the message. By checking 3368 the timestamp, the recipient of the message is able to make sure that 3369 it was recently generated, and is not a replay. 3370 usec 3371 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 3372 the microsecond part of the timestamp. 3373 seq-number 3374 This field is described above in section 5.3.2. 3375 s-address 3376 Sender's address. 3378 This field specifies the address in use by the sender of the message. 3379 It may be omitted if not required by the application protocol. 3380 r-address 3381 This field specifies the address in use by the recipient of the 3382 message. It may be omitted for some uses (such as broadcast protocols), 3383 but the recipient may arbitrarily reject such messages. This field, 3384 along with s-address, can be used to help detect messages which have 3385 been incorrectly or maliciously delivered to the wrong recipient. 3387 5.7. KRB_PRIV message specification 3389 This section specifies the format of a message that can be used by either 3390 side (client or server) of an application to securely and privately send a 3391 message to its peer. It presumes that a session key has previously been 3392 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3394 5.7.1. KRB_PRIV definition 3396 The KRB_PRIV message contains user data encrypted in the Session Key. The 3397 message fields are: 3399 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3400 pvno[0] INTEGER, 3401 msg-type[1] INTEGER, 3402 enc-part[3] EncryptedData 3403 -- EncKrbPrivPart 3404 } 3405 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { --note [31] 3406 user-data[0] OCTET STRING, 3407 timestamp[1] KerberosTime OPTIONAL, 3408 usec[2] Microseconds OPTIONAL, 3409 seq-number[3] UInt32 OPTIONAL, 3410 s-address[4] HostAddress, -- sender's addr 3411 r-address[5] HostAddress OPTIONAL -- recip's addr 3412 } 3414 pvno and msg-type 3415 These fields are described above in section 5.4.1. msg-type is 3416 KRB_PRIV. 3417 enc-part 3418 This field holds an encoding of the EncKrbPrivPart sequence encrypted 3419 under the session key[32]. This encrypted encoding is used for the 3420 enc-part field of the KRB-PRIV message. See section 6 for the format of 3421 the ciphertext. 3422 user-data, timestamp, usec, s-address and r-address 3423 These fields are described above in section 5.6.1. 3424 seq-number 3425 This field is described above in section 5.3.2. 3427 5.8. KRB_CRED message specification 3429 This section specifies the format of a message that can be used to send 3430 Kerberos credentials from one principal to another. It is presented here to 3431 encourage a common mechanism to be used by applications when forwarding 3432 tickets or providing proxies to subordinate servers. It presumes that a 3433 session key has already been exchanged perhaps by using the 3434 KRB_AP_REQ/KRB_AP_REP messages. 3436 5.8.1. KRB_CRED definition 3438 The KRB_CRED message contains a sequence of tickets to be sent and 3439 information needed to use the tickets, including the session key from each. 3440 The information needed to use the tickets is encrypted under an encryption 3441 key previously exchanged or transferred alongside the KRB_CRED message. The 3442 message fields are: 3444 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3445 pvno[0] INTEGER, 3446 msg-type[1] INTEGER, -- KRB_CRED 3447 tickets[2] SEQUENCE OF Ticket, 3448 enc-part[3] EncryptedData -- EncKrbCredPart 3449 } 3451 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3452 ticket-info[0] SEQUENCE OF KrbCredInfo, 3453 nonce[1] INTEGER OPTIONAL, 3454 timestamp[2] KerberosTime OPTIONAL, 3455 usec[3] Microseconds OPTIONAL, 3456 s-address[4] HostAddress OPTIONAL, 3457 r-address[5] HostAddress OPTIONAL 3458 } 3459 KrbCredInfo ::= SEQUENCE { 3460 key[0] EncryptionKey, 3461 prealm[1] Realm OPTIONAL, 3462 pname[2] PrincipalName OPTIONAL, 3463 flags[3] TicketFlags OPTIONAL, 3464 authtime[4] KerberosTime OPTIONAL, 3465 starttime[5] KerberosTime OPTIONAL, 3466 endtime[6] KerberosTime OPTIONAL 3467 renew-till[7] KerberosTime OPTIONAL, 3468 srealm[8] Realm OPTIONAL, 3469 sname[9] PrincipalName OPTIONAL, 3470 caddr[10] HostAddresses OPTIONAL 3471 } 3473 pvno and msg-type 3474 These fields are described above in section 5.4.1. msg-type is 3475 KRB_CRED. 3476 tickets 3477 These are the tickets obtained from the KDC specifically for use by the 3478 intended recipient. Successive tickets are paired with the 3479 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3480 message. 3481 enc-part 3482 This field holds an encoding of the EncKrbCredPart sequence encrypted 3483 under the session key shared between the sender and the intended 3484 recipient. This encrypted encoding is used for the enc-part field of 3485 the KRB-CRED message. See section 6 for the format of the ciphertext. 3486 nonce 3487 If practical, an application may require the inclusion of a nonce 3488 generated by the recipient of the message. If the same value is 3489 included as the nonce in the message, it provides evidence that the 3490 message is fresh and has not been replayed by an attacker. A nonce must 3491 never be re-used; it should be generated randomly by the recipient of 3492 the message and provided to the sender of the message in an application 3493 specific manner. 3494 timestamp and usec 3495 These fields specify the time that the KRB-CRED message was generated. 3496 The time is used to provide assurance that the message is fresh. 3497 s-address and r-address 3498 These fields are described above in section 5.6.1. They are used 3499 optionally to provide additional assurance of the integrity of the 3500 KRB-CRED message. 3501 key 3502 This field exists in the corresponding ticket passed by the KRB-CRED 3503 message and is used to pass the session key from the sender to the 3504 intended recipient. The field's encoding is described in section 6.2. 3506 The following fields are optional. If present, they can be associated with 3507 the credentials in the remote ticket file. If left out, then it is assumed 3508 that the recipient of the credentials already knows their value. 3510 prealm and pname 3511 The name and realm of the delegated principal identity. 3512 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3513 These fields contain the values of the corresponding fields from the 3514 ticket found in the ticket field. Descriptions of the fields are 3515 identical to the descriptions in the KDC-REP message. 3517 5.9. Error message specification 3519 This section specifies the format for the KRB_ERROR message. The fields 3520 included in the message are intended to return as much information as 3521 possible about an error. It is not expected that all the information 3522 required by the fields will be available for all types of errors. If the 3523 appropriate information is not available when the message is composed, the 3524 corresponding field will be left out of the message. 3526 Note that since the KRB_ERROR message is only optionally integrity 3527 protected, it is quite possible for an intruder to synthesize or modify such 3528 a message. In particular, this means that unless appropriate integrity 3529 protection mechanisms have been applied to the KRB_ERROR message, the client 3530 should not use any fields in this message for security-critical purposes, 3531 such as setting a system clock or generating a fresh authenticator. The 3532 message can be useful, however, for advising a user on the reason for some 3533 failure. 3535 5.9.1. KRB_ERROR definition 3537 The KRB_ERROR message consists of the following fields: 3539 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3540 pvno[0] INTEGER, 3541 msg-type[1] INTEGER, 3542 ctime[2] KerberosTime OPTIONAL, 3543 cusec[3] Microseconds OPTIONAL, 3544 stime[4] KerberosTime, 3545 susec[5] Microseconds, 3546 error-code[6] Int32, 3547 crealm[7] Realm OPTIONAL, 3548 cname[8] PrincipalName OPTIONAL, 3549 realm[9] Realm, -- Correct realm 3550 sname[10] PrincipalName, -- Correct name 3551 e-text[11] KerberosString OPTIONAL, 3552 e-data[12] OCTET STRING OPTIONAL 3553 } 3555 pvno and msg-type 3556 These fields are described above in section 5.4.1. msg-type is 3557 KRB_ERROR. 3558 ctime 3559 This field is described above in section 5.4.1. 3560 cusec 3561 This field is described above in section 5.5.2. 3562 stime 3563 This field contains the current time on the server. It is of type 3564 KerberosTime. 3565 susec 3566 This field contains the microsecond part of the server's timestamp. Its 3567 value ranges from 0 to 999999. It appears along with stime. The two 3568 fields are used in conjunction to specify a reasonably accurate 3569 timestamp. 3570 error-code 3571 This field contains the error code returned by Kerberos or the server 3572 when a request fails. To interpret the value of this field see the list 3573 of error codes in section 8. Implementations are encouraged to provide 3574 for national language support in the display of error messages. 3575 crealm, cname, srealm and sname 3576 These fields are described above in section 5.3.1. 3578 e-text 3579 This field contains additional text to help explain the error code 3580 associated with the failed request (for example, it might include a 3581 principal name which was unknown). 3582 e-data 3583 This field contains additional data about the error for use by the 3584 application to help it recover from or handle the error. If present, 3585 this field will contain the encoding of a sequence of TypedData 3586 (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, 3587 in which case it will contain the encoding of a sequence of of padata 3588 fields (METHOD-DATA below), each corresponding to an acceptable 3589 pre-authentication method and optionally containing data for the 3590 method: 3592 TYPED-DATA ::= SEQUENCE of TypedData 3593 METHOD-DATA ::= SEQUENCE of PA-DATA 3595 TypedData ::= SEQUENCE { 3596 data-type[0] Int32, 3597 data-value[1] OCTET STRING OPTIONAL 3598 } 3600 Note that the padata-type field in the PA-DATA structure and the 3601 data-type field in the TypedData structure share a common range of 3602 allocated values which are coordinated to avoid conflicts. One Kerberos 3603 error message, KDC_ERR_PREAUTH_REQUIRED, embeds elements of type 3604 PA-DATA, while all other error messages embed TypedData. 3606 While preauthentication methods of type PA-DATA should be encapsulated 3607 within a TypedData element of type TD-PADATA, for compatibility with 3608 old clients, the KDC should include PA-DATA types below 22 directly as 3609 method-data. All new implementations interpreting the METHOD-DATA field 3610 for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of 3611 TD-PADATA, extract the typed data field and interpret the use any 3612 elements encapsulated in the TD-PADATA elements as if they were present 3613 in the METHOD-DATA sequence. 3615 Unless otherwise specified, unrecognized TypedData elements within the 3616 KRB-ERROR message MAY be ignored by implementations that do not support 3617 them. Note that all TypedData MAY be bound to the KRB-ERROR message via 3618 the checksum field. 3620 An application may use the TD-APP-DEFINED-ERROR typed data type for 3621 data carried in a Kerberos error message that is specific to the 3622 application. TD-APP-SPECIFIC must set the data-type value of TypedData 3623 to TD-APP-SPECIFIC and the data-value field to 3625 AppSpecificTypedData as follows: 3626 AppSpecificTypedData ::= SEQUENCE { 3627 oid[0] OPTIONAL OBJECT IDENTIFIER, 3628 -- identifies the application 3629 data-value[1] OCTET STRING 3630 -- application 3631 -- specific data 3632 } 3633 o The TD-REQ-NONCE TypedData MAY be used to bind a KRB-ERROR to a 3634 KDC-REQ. The data-value is an INTEGER that is equivalent to the 3635 nonce in a KDC-REQ. 3637 o The TD-REQ-SEQ TypedData MAY be used for binding a KRB-ERROR to 3638 the sequence number from an authenticator. The data-value is an 3639 INTEGER, and it is identical to sequence number sent in the 3640 authenticator. 3642 o The data-value for TD-KRB-PRINCIPAL is the Kerberos-defined 3643 PrincipalName. The data-value for TD-KRB-REALM is the 3644 Kerberos-defined Realm. These TypedData types MAY be used to 3645 indicate principal and realm name when appropriate. 3647 ------------------------------------------------------------------------ 3649 5.10. Application Tag Numbers 3651 The following table lists the application class tag numbers used by various 3652 data types defined in this section. 3653 Tag Number(s) Type Name Comments 3655 0 unused 3657 1 Ticket 3659 2 Authenticator 3661 3 EncTicketPart 3663 4-10 unused 3665 10 AS-REQ 3667 11 AS-REP 3669 12 TGS-REQ 3671 13 TGS-REP 3673 14 AP-REQ 3675 15 AP-REP 3677 16 TGT-REQ 3679 17-19 unused 3681 20 KRB-SAFE 3683 21 KRB-PRIV 3685 22 KRB-PRIV 3687 23-24 unused 3689 25 EncASRepPart 3691 26 EncTGSRepPart 3692 27 EncApRepPart 3694 28 EncKrbPrivPart 3696 29 EncKrbCredPart 3698 30 KRB-ERROR 3700 6. Encryption and Checksum Specifications 3702 Work is still needed on this section. 3704 * Re-synchronize the key usage value list with any changes Tom 3705 makes to the message definitions. KRB-ERROR checksum, for 3706 example, and any new message types. 3707 * More talking with cryptographers about the "combine-keys" 3708 function in the simplified profile. I've been talking a 3709 little with Uri Blumenthal, but he hasn't had a lot of time 3710 for this. 3711 * Test vections need to go into an appendix. Submitted, 3712 appendix letter not yet assigned; I'm using "Z" in this text. 3713 Appendix letter also not yet assigned for deprecated checksum 3714 algorithms, assuming "Y". 3715 * More detailed list of differences from RFC 1510, to update 3716 the "Significant changes" appendix. 3717 * Are sections 6.2 and 6.3 what we want to recommend for 3718 external use in section 6.7, or just a subset? 3719 * Fix up reference to Bellovin paper. 3720 * Fix anything marked with "@@". 3722 See end notes for other issues. 3724 -- Ken 2001-11-20 3726 The Kerberos protocols described in this document are designed to encrypt 3727 blocks of arbitrary sizes, using stream encryption ciphers, or more 3728 commonly, block encryption ciphers, such as the Data Encryption Standard 3729 [DES77], and triple DES variants, in conjunction with block chaining and 3730 checksum methods [DESM80]. Encryption is used to prove the identities of the 3731 network entities participating in message exchanges. The Key Distribution 3732 Center for each realm is trusted by all principals registered in that realm 3733 to store a secret key in confidence. Proof of knowledge of this secret key 3734 is used to verify the authenticity of a principal. 3736 The KDC uses the principal's secret key (in the AS exchange) or a shared 3737 session key (in the TGS exchange) to encrypt responses to ticket requests; 3738 the ability to obtain the secret key or session key implies the knowledge of 3739 the appropriate keys and the identity of the KDC. The ability of a principal 3740 to decrypt the KDC response and present a Ticket and a properly formed 3741 Authenticator (generated with the session key from the KDC response) to a 3742 service verifies the identity of the principal; likewise the ability of the 3743 service to extract the session key from the Ticket and prove its knowledge 3744 thereof in a response verifies the identity of the service. 3746 The Kerberos protocols generally assume that the encryption used is secure 3747 from cryptanalysis; however, in some cases, the order of fields in the 3748 encrypted portions of messages as defined in this section is chosen to 3749 minimize the effects of poorly chosen keys under certain types of 3750 cryptographic attacks. It is still important to choose good keys. If keys 3751 are derived from user-typed passwords, those passwords need to be well 3752 chosen to make brute force attacks more difficult. Poorly chosen keys still 3753 make easy targets for intruders. 3755 The following sections specify the encryption and checksum mechanisms 3756 currently defined for Kerberos, as well as a framework for defining future 3757 mechanisms. The encodings, chaining, padding and other requirements for each 3758 are described. Test vectors for several functions are given in appendix Z. 3760 See also appendix Y for deprecated checksum algorithms defined in RFC 1510, 3761 which may still be in use by some implementations, but are not part of this 3762 version of the specification. 3764 6.1. Concepts 3766 Both encryption and checksum mechanism are defined in terms of profiles, 3767 detailed in later sections. Each specifies a collection of operations and 3768 attributes that must be defined for a mechanism. A Kerberos encryption or 3769 checksum mechanism is not complete if it does not specify all of these 3770 operations and attributes. 3772 An encryption mechanism must provide for confidentiality and integrity of 3773 the original plaintext. (Integrity checking may be achieved by incorporating 3774 a checksum, if the encryption mode does not provide an integrity check 3775 itself.) It must also provide non-malleability [Bellare98, Dolev91]. Use of 3776 a random confounder prepended to the plaintext is recommended. It should not 3777 be possible to determine if two ciphertexts correspond to the same 3778 plaintext, without knowledge of the key. 3780 A checksum mechanism[6.1] must provide proof of the integrity of the 3781 associated message, and must preserve the confidentiality of the message in 3782 case it is not sent in the clear. It should be infeasible to find two 3783 plaintexts which have the same checksum. It is NOT required that an 3784 eavesdropper be unable to determine if two checksums are for the same 3785 message; it is assumed that the messages themselves will be visible to any 3786 such eavesdropper. 3788 Due to advances in cryptography, it is considered unwise by some 3789 cryptographers to use the same key for multiple purposes [@@reference??]. 3790 Since keys are used in performing a number of different functions in 3791 Kerberos, it is desirable to use different keys for each of these purposes, 3792 even though we start with a single long-term or session key. 3794 We do this by enumerating the different uses of keys within Kerberos, and 3795 making the "usage number" an input to the encryption or checksum mechanisms. 3796 Later sections define simplified profile templates for encryption and 3797 checksum mechanisms that use a key derivation function applied to a CBC mode 3798 (or similar) cipher and a checksum or hash algorithm. 3800 We distinguish the "base key" used in the EncryptedKey object from the 3801 "specific key" to be used for a particular instance of encryption or 3802 checksum operations. It is expected but not required that the specific key 3803 will be one or more separate keys derived from the original protocol key and 3804 the key usage number. The specific key is not explicitly referenced outside 3805 of section 6 in this document; when other sections mention encrypting or 3806 decrypting data with a given key, that key is the "base key", and the 3807 "specific key" generation and use is implicit, as is the use of a key usage 3808 number. 3810 Key Usage Values 3812 This is a list of key usage number definitions and reserved ranges, 3813 including values for all places keys are used in the Kerberos protocol and 3814 associated section numbers. 3816 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 3817 client key (section 5.4.1) 3818 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key or 3819 application session key), encrypted with the service key 3820 (section 5.4.2) 3821 3. AS-REP encrypted part (includes TGS session key or application 3822 session key), encrypted with the client key (section 5.4.2) 3823 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS 3824 session key (section 5.4.1) 3825 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS 3826 authenticator subkey (section 5.4.1) 3827 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed with 3828 the TGS session key (sections 5.3.2, 5.4.1) 3829 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes TGS 3830 authenticator subkey), encrypted with the TGS session key 3831 (section 5.3.2) 3832 8. TGS-REP encrypted part (includes application session key), 3833 encrypted with the TGS session key (section 5.4.2) 3834 9. TGS-REP encrypted part (includes application session key), 3835 encrypted with the TGS authenticator subkey (section 5.4.2) 3836 10. AP-REQ Authenticator cksum, keyed with the application session 3837 key (section 5.3.2) 3838 11. AP-REQ Authenticator (includes application authenticator 3839 subkey), encrypted with the application session key (section 3840 5.3.2) 3841 12. AP-REP encrypted part (includes application session subkey), 3842 encrypted with the application session key (section 5.5.2) 3843 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 3844 application (section 5.7.1) 3845 14. KRB-CRED encrypted part, encrypted with a key chosen by the 3846 application (section 5.6.1) 3847 15. KRB-SAFE cksum, keyed with a key chosen by the application 3848 (section 5.8.1) 3849 18. KRB-ERROR checksum (e-cksum in section 5.9.1) 3850 19. AD-KDCIssued checksum (ad-checksum in appendix B.4) 3851 20. Checksum for Mandatory Ticket Extensions (appendix B.6) 3852 21. Checksum in Authorization Data in Ticket Extensions (appendix 3853 B.7) 3854 22-24. Reserved for use in GSSAPI mechanisms derived from RFC 1964. 3855 (raeburn/MIT) 3856 25-511. Reserved for future use in Kerberos and related protocols. 3857 512-1023. Reserved for uses internal to a Kerberos implementation. [6.2] 3859 A few of these key usages need a little clarification. A service which 3860 receives an AP-REQ has no way to know if the enclosed Ticket was part of an 3861 AS-REP or TGS-REP. Therefore, key usage 2 must always be used for generating 3862 a Ticket, whether it is in response to an AS-REQ or TGS-REQ. 3864 Key usage values between 1024 and 2047 (inclusive) are reserved for 3865 application use. Applications should use even values for encryption and odd 3866 values for checksums within this range. 3868 There might exist other documents which define protocols in terms of the 3869 RFC1510 encryption types or checksum types. Such documents would not know 3870 about key usages. In order that these documents continue to be meaningful 3871 until they are updated, key usages 1024 and 1025 must be used to derive keys 3872 for encryption and checksums, respectively.[6.3] New protocols defined in 3873 terms of the Kerberos encryption and checksum types should use their own key 3874 usage values. Key usages are unsigned 32 bit integers; zero is not 3875 permitted. Usage numbers may be registered with IANA to avoid conflicts. 3877 6.2. Encryption mechanism attributes 3879 An encryption mechanism profile must define the following attributes and 3880 operations: 3882 protocol key format 3883 This describes what OCTET STRING values represent valid keys. For 3884 encryption mechanisms that don't have perfectly dense key spaces, this 3885 will describe the representation used for encoding keys. It need not 3886 describe specific values that are not valid or desirable for use; such 3887 values should be avoid by all key generation routines. 3888 specific key structure 3889 This is not a protocol format at all, but a description of the keying 3890 material derived from the chosen key and used to encrypt or decrypt 3891 data or compute or verify a checksum. It may be a single key, a set of 3892 keys, or a combination of the original key with additional data. The 3893 authors recommend using one or more keys derived from the original key 3894 via one-way functions. 3895 required checksum mechanism 3896 This indicates a checksum mechanism that must be available when this 3897 encryption mechanism is used. Since Kerberos has no built in mechanism 3898 for negotiating checksum mechanisms, once an encryption mechanism has 3899 been decided upon, the corresponding checksum mechanism can simply be 3900 used. 3901 key-generation seed length, K 3902 This is the length of the random bitstring needed to generate a key 3903 with the encryption scheme's random-to-key function (described below). 3904 This must be a fixed value so that various techniques for producing a 3905 random bitstring of a given length may be used with key generation 3906 functions. 3907 key generation functions 3908 Keys must be generated in a number of cases, from different types of 3909 inputs. All function specifications must indicate how to generate keys 3910 in the proper wire format, and must avoid generation of "weak" keys if 3911 the cryptosystem has such. Entropy from each source should be preserved 3912 as much as possible. Many of the inputs, while unknown, may be at least 3913 partly predictable (e.g., a password string is likely to be entirely in 3914 the ASCII subset and of fairly short length in many environments; a 3915 semi-random string may include timestamps); the benefit of such 3916 predictability to an attacker must be minimized. 3918 string-to-key (UTF8String, UTF8String, integer)->(protocol-key) 3919 This function generates a key from two UTF-8 strings and an 3920 integer. One of the strings is normally the principal's password, 3921 but is in general merely a secret string. The other string is a 3922 "salt" intended to produce different keys from the same password 3923 for different users or realms. The integer is known for historical 3924 reasons as the "salt type", but may be used for selection between 3925 multiple string-to-key algorithms. The salt string and type may be 3926 altered by preauth data from the KDC; in the default case, the 3927 salt string is simply a concatenation of the principal's realm and 3928 name components, with no separators, and the salt type is zero. 3930 This should be a one-way function, so that compromising a user's 3931 key in one realm does not compromise the user's key in another 3932 realm, even if the same password (but a different salt string) is 3933 used. 3935 random-to-key (bitstring[K])->(protocol-key) 3936 This function generates a key from a random bit string of a 3937 specific size. It may be assumed that all the bits of the input 3938 string are equally random, even though the entropy present in the 3939 random source may be limited. 3940 combine-keys (protocol-key, protocol-key)->(protocol-key) 3941 This function takes two input keys and produces a new key. This 3942 function is not used in this RFC, but may be used by 3943 preauthentication methods or other applications to be defined 3944 later. This operation must be commutative; this requirement lets 3945 us specify "combine keys A and B" in other documents without 3946 worrying about ordering. 3947 key-derivation (protocol-key, integer)->(specific-key) 3948 In this function, the byte string input is based on the key usage 3949 values specified above; the usage values must be assumed to be 3950 known to an attacker. For cryptosystems with dense key spaces, 3951 this function should be the key derivation function outlined in 3952 section 6.1. 3953 cipher state 3954 initial cipher state (specific-key)->(state) 3955 This describes any initial state setup needed before encrypting 3956 arbitrary amounts of data with a given specific key; the specific key 3957 must be the only input needed for this initialization. For example, a 3958 block cipher used in CBC mode must specify an initial vector. (For 3959 security reasons, the key itself should not be used as the IVEC.) This 3960 data may be carried over from one encryption or decryption operation to 3961 another. Unless otherwise specified, however, each encryption or 3962 decryption operation in this RFC uses a freshly initialized state and 3963 is thus independent of all other encryptions and decryptions. 3965 This state should be treated as opaque in any uses outside of an 3966 encryption algorithm definition. 3967 encrypt (specific-key, state, bytestring)->(state, bytestring) 3968 This function takes the specific key, cipher state, and plaintext as 3969 input, and generates ciphertext and a new cipher state as outputs. If 3970 the basic encryption algorithm itself does not provide for integrity 3971 protection (as DES in CBC mode does not do), then some form of MAC or 3972 checksum must be included that can be verified by the receiver. Some 3973 random factor such as a confounder should be included so that an 3974 observer cannot know if two messages contain the same plaintext, even 3975 if the cipher state and specific keys are the same. The exact length of 3976 the plaintext need not be encoded, but if it is not and if padding is 3977 required, the padding must be added at the end of the string so that 3978 the decrypted version may be parsed from the beginning. 3980 The output will be used as the OCTET STRING in the EncryptedData type, 3981 defined in section 5.1. 3983 decrypt (specific-key, state, bytestring)->(state, bytestring) 3984 This function takes the specific key, cipher state, and ciphertext as 3985 inputs, and verifies the integrity of the supplied ciphertext. If the 3986 ciphertext's integrity is intact, this function produces the plaintext 3987 and a new cipher state as outputs; otherwise, an error indication must 3988 be returned, and the data discarded. 3990 This function's byte string input is the OCTET STRING from the 3991 EncryptedData type, defined in section 5.1. 3993 The result of the decryption may be longer than the original plaintext, 3994 if the encryption mode requires padding to a multiple of a block size. 3995 If this is the case, any extra padding will be after the decoded 3996 plaintext. An application protocol which needs to know the exact length 3997 of the message must encode a length or recognizable "end of message" 3998 marker within the plaintext. 4000 These operations and attributes are all that should be required to support 4001 Kerberos and various proposed preauthentication schemes. 4003 The reader is reminded that cryptography is a complex and growing field, and 4004 proof of the security of an algorithm is often difficult, even for those 4005 with extensive training in the field. Merely making an algorithm complicated 4006 is more likely to make it hard to analyze than it is to make it secure. This 4007 should be kept in mind when defining functions for new cryptosystems; simple 4008 applications of existing, trusted algorithms are more likely to be secure 4009 than a complicated home-grown scheme. 4011 6.3. Checksum mechanism attributes 4013 A checksum mechanism profile must define the following attributes and 4014 operations: 4016 associated encryption algorithm(s) 4017 This essentially indicates the type of encryption key this checksum 4018 mechanism can be used with. A single checksum mechanism may have more 4019 than one associated encryption algorithm if they share the same wire 4020 key format, string-to-key function, and key derivation function. (This 4021 combination means that, for example, a checksum type and password are 4022 adequate to get the specific key used to compute a checksum.) 4023 get_mic function 4024 This function generates a MIC token for a given specific key (see 4025 section 6.2), and message (represented as an octet string), that may be 4026 used to verify the integrity of the associated message. This function 4027 is not required to return the same deterministic result on every use; 4028 it need only generate a token that the verify_mic routine can check. 4030 The output of this function will also dictate the size of the checksum. 4031 It must be a fixed size. 4033 verify_mic function 4034 Given a specific key, message, and MIC, this function ascertains 4035 whether the message integrity has been compromised. For a deterministic 4036 get_mic routine, the corresponding verify_mic may simply generate 4037 another checksum and compare them. 4039 The get_mic and verify_mic operations must be able to handle inputs of 4040 arbitrary length; if any padding is needed, the padding scheme must be 4041 specified as part of these functions. 4043 These operations and attributes are all that should be required to support 4044 Kerberos and various proposed preauthentication schemes. 4046 6.4. A simplified profile for CBC-mode ciphers using key derivation 4048 The profile outlines in sections 6.2 and 6.3 describes a large number of 4049 operations that must be defined for encryption and checksum algorithms to be 4050 used with Kerberos. We describe here a simpler profile from which both 4051 encryption and checksum mechanism definitions can be generated, filling in 4052 uses of key derivation in appropriate places, providing integrity 4053 protection, and defining multiple operations for the cryptosystem profile 4054 based on a smaller set of operations given in the simplified profile. Not 4055 all of the existing cryptosystems for Kerberos fit into this simplified 4056 profile, but we recommend that future cryptosystems use it or something 4057 based on it. 4059 Not all of the operations in the complete profiles are defined through this 4060 mechanism; several must still be defined for each new algorithm pair. 4062 A key derivation function [Horowitz] 4064 Rather than define some scheme by which a "protocol key" is composed of a 4065 large number of encryption keys, we use keys derived from a base key to 4066 perform cryptographic operations. The base key must be used only for 4067 generating the derived keys, and this derivation must be non-invertible and 4068 entropy-preserving. Given these restrictions, compromise of one derived key 4069 does not compromise the other subkeys. Attack of the base key is limited, 4070 since it is only used for derivation, and is not exposed to any user data. 4072 Since the derived key has as much entropy as the base keys (if the 4073 cryptosystem is good), password-derived keys have the full benefit of all 4074 the entropy in the password. 4076 To generate a derived key from a base key, we generate a pseudorandom byte 4077 string, using an algorithm DR described below, and generate a key from that 4078 byte string using a function dependent on the encryption algorithm; the 4079 input length needed for that function, which is also dependent on the 4080 encryption algorithm, dictates the length of the string to be generated by 4081 the DR algorithm (the value "k" below). 4083 Derived Key = DK(Base Key, Well-Known Constant) 4085 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 4087 DR(Key, Constant) = k-truncate(E(Key, Constant)) 4089 Here DR is the random-byte generation function described below, and DK is 4090 the key-derivation function produced from it. In this construction, E(Key, 4091 Plaintext) is a block cipher, Constant is a well-known constant determined 4092 by the specific usage of this function, and k-truncate truncates its 4093 argument by taking the first k bits. Here, k is the key generation seed 4094 length needed for the encryption system. 4096 The output of the DR function is a string of bits; the actual key is 4097 produced by applying the cryptosystem's random-to-key operation on this 4098 bitstring. 4100 If the output of E is shorter than k bits, then some entropy in the key will 4101 be lost. If the Constant is smaller than the block size of E, then it must 4102 be padded so it may be encrypted. 4104 In either of these situations, a variation of the above construction is 4105 used, where the folded Constant is encrypted, and the resulting output is 4106 fed back into the encryption as necessary (the | indicates concatentation): 4108 K1 = E(Key, n-fold(Constant)) 4109 K2 = E(Key, K1) 4110 K3 = E(Key, K2) 4111 K4 = ... 4113 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 4115 n-fold is an algorithm which takes m input bits and ``stretches'' them to 4116 form n output bits with equal contribution from each input bit to the 4117 output, as described in [Blumenthal96]: 4119 We first define a primitive called n-folding, which takes a 4120 variable-length input block and produces a fixed-length output 4121 sequence. The intent is to give each input bit approximately equal 4122 weight in determining the value of each output bit. Note that 4123 whenever we need to treat a string of bytes as a number, the 4124 assumed representation is Big-Endian -- Most Significant Byte 4125 first. 4127 To n-fold a number X, replicate the input value to a length that 4128 is the least common multiple of n and the length of X. Before each 4129 repetition, the input is rotated to the right by 13 bit positions. 4130 The successive n-bit chunks are added together using 4131 1's-complement addition (that is, with end-around carry) to yield 4132 a n-bit result.... 4134 Test vectors for n-fold are supplied in Appendix Z. [6.4] 4136 In this document, n-fold is always used to produce n bits of output, where n 4137 is the block size of E. 4139 The size of the Constant must not be larger than the block size of E, 4140 because reducing the length of the Constant by n-folding can cause 4141 collisions. 4143 If the size of the Constant is smaller than the block size of E, then the 4144 Constant must be n-folded to the block size of E. This string is used as 4145 input to E. If the block size of E is less than the key size, then the 4146 output from E is taken as input to a second invocation of E. This process is 4147 repeated until the number of bits accumulated is greater than or equal to 4148 the key size of E. When enough bits have been computed, the first k are 4149 taken as the derived key. 4151 Since the derived key is the result of one or more encryptions in the base 4152 key, deriving the base key from the derived key is equivalent to determining 4153 the key from a very small number of plaintext/ciphertext pairs. Thus, this 4154 construction is as strong as the cryptosystem itself. 4156 6.4.1. Simplified profile parameters 4158 These are the operations and attributes that must be defined: 4160 protocol key format 4161 string-to-key function 4162 key-generation seed length, k 4163 random-to-key function 4164 As above for the normal encryption mechanism profile. 4165 unkeyed hash algorithm, H 4166 This should be a collision-resistant hash algorithm such as SHA-1, 4167 suitable for use in an HMAC. It must support inputs of arbitrary 4168 length. 4170 encryption block size, n 4171 encryption/decryption functions, E and D 4172 These are basic encryption and decryption functions for messages of 4173 sizes that are multiples of the block size. No integrity checking or 4174 confounder should be included here. They take as input the IV or 4175 similar data, a protocol-format key, and a byte string, returning a new 4176 IV and byte string. 4178 The encryption function is not required to use CBC mode, but is assumed 4179 to be using something with similar properties. In particular, 4180 prepending a one-block confounder to the plaintext should alter the 4181 entire ciphertext (comparable to choosing and including a random 4182 initial vector for CBC mode). 4184 While there are still a number of properties to specify, they are fewer and 4185 simpler than in the full profile. 4187 6.4.2. Cryptosystem profile based on simplified profile 4189 protocol key As given. 4190 format 4191 specific key Three protocol-format keys: { Kc, Ke, Ki }. 4192 structure 4193 key-generation As given. 4194 seed length 4195 required The checksum mechanism defined by the simplified checksum 4196 checksum profile given later. 4197 mechanism 4198 cipher state Initial vector, initialized to all zero. 4199 encryption The ciphertext output is the concatenation of the output of 4200 function the basic encryption function E and an HMAC using the 4201 specified hash function H, both applied to the padded 4202 plaintext with a confounder: 4204 ciphertext = E(Ke, confounder | plaintext | padding) | 4205 HMAC(Ki, confounder | plaintext | padding) 4206 HMAC(K,M) = H(K | H(K | M)) 4208 One block of random confounder data is prepended to the 4209 plaintext, and padding added to the end to bring the length 4210 to a multiple of the encryption algorithm's block size. The 4211 initial vector for encryption is supplied by the cipher 4212 state, and the last block of the output of E is the new 4213 IVEC for the new cipher state. 4214 decryption Decryption is performed by extracting the encrypted portion 4215 function of the ciphertext, decrypting using key Ke from the 4216 specific key, and verifying the HMAC. If the HMAC is 4217 incorrect, an error must be reported. Otherwise, the 4218 confounder and padding are discarded and the remaining 4219 plaintext returned. As with encryption, the cipher state 4220 input indicates the IVEC to use, and the last block of the 4221 encrypted portion of the ciphertext is put into the new 4222 cipher state to be used as the next IVEC. 4223 key generation 4224 functions: 4225 string-to-key As given. 4226 function 4227 random-to-key As given. 4228 function 4229 combine-keys @@ Needs to be specified. How about: 4230 function 4231 combine-keys(K1,K2) 4232 /* First, protect original keys against exposure 4233 with DR. */ 4234 R1 = DR(K1, n-fold(K2)) /* length k */ 4235 R2 = DR(K2, n-fold(K1)) /* length k */ 4236 /* Using k-fold on length 2k means just add with 4237 wrap-around carry. */ 4238 rnd = k-fold(R1 | R2) 4239 tkey = random-to-key(rnd) 4240 key = DK(tkey, CombineConstant) 4242 @@ This should be commutative, which keeps the 4243 specifications simpler, and I think should protect each 4244 key's contribution from exposure of the other key. Or 4245 should we just go with an XOR combination of the random 4246 bytes? (But that works poorly should the two keys happen to 4247 be the same due to sloppy or weird protocol specs, or 4248 parallel construction of contributed keys.) Do we need the 4249 two DK invocations at the start? Would one at the end be 4250 better? Do we need either? 4252 Here CombineConstant is the byte string {0x63 0x6f 0x6d 4253 0x62 0x69 0x6e 0x65} corresponding to the ASCII encoding of 4254 the string "combine". 4256 @@ Need a cryptographer to review this. Asked Uri 4257 Blumenthal, he said he'd look it over when he has time. 4258 key-derivation Three keys are generated, using the DK function described 4259 function above, and the key usage number, represented as a 32-bit 4260 integer in big-endian byte order. One is used for 4261 generating checksums only; the other two are used for 4262 encrypting and integrity protection for ciphertext. These 4263 keys are generated as follows (with "|" indicating 4264 concatenation): 4266 Kc = DK(base-key, usage|0x99)); 4267 Ke = DK(base-key, usage|0xAA); 4268 Ki = DK(base-key, usage|0x55); 4270 6.4.3. Checksum profiles based on simplified profile 4272 When an encryption system is defined using the simplified profile given in 4273 section 6.4.1, a checksum algorithm may be defined for it as follows: 4275 associated cryptosystem as defined above 4276 get_mic HMAC(Kc, message) 4277 verify_mic get_mic and compare 4279 The HMAC function and key Kc are as described in section 6.4.2. 4281 6.5. Profiles for Kerberos encryption systems 4283 These are the currently defined encryption systems for Kerberos. The astute 4284 reader will notice that some of them do not fulfill all of the requirements 4285 outlined above. These weaker encryption systems are defined for backwards 4286 compatibility; newer implementations should attempt to make use of the 4287 stronger encryption systems when possible. 4289 The full list of encryption type number assignments is given in section 8.3. 4291 6.5.1. null 4293 If no encryption is in use, the encryption system is said to be the NULL 4294 encryption system. In the NULL encryption system there is no checksum, 4295 confounder or padding. The ciphertext is simply the plaintext. The NULL Key 4296 is used by the null encryption system and is zero octets in length. 4298 This encryption system should not be used for protection of data. It exists 4299 primarily to associate with the rsa-md5 checksum type, but may also be 4300 useful for testing protocol implementations. 4302 protocol key format zero-length bit string 4303 specific key structure empty 4304 required checksum mechanism rsa-md5 4305 key-generation seed length 0 4306 cipher state none 4307 initial cipher state none 4308 encryption function identity 4309 decryption function identity, no integrity check 4310 key generation functions: 4311 string-to-key empty string 4312 random-to-key empty string 4313 combine-keys empty string 4314 key-derivation empty string 4316 The null encryption algorithm is assigned the etype value zero (0). 4318 6.5.2. des-cbc-md5 4320 The des-cbc-md5 encryption mode encrypts information under the Data 4321 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 4322 An MD5 checksum (described in [MD5-92]) is applied to the confounder and 4323 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 4324 bytes. As a result, the data to be encrypted (the concatenation of 4325 confounder, checksum, and message) must be padded to an 8 byte boundary 4326 before encryption. 4328 Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are 4329 concatenated to make the 64-bit inputs for the DES algorithms. The first 4330 octet supplies the 8 most significant bits (with the octet's MSbit used as 4331 the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., 4332 and the eighth octet supplies the 8 least significant bits. 4334 Encryption under DES using cipher block chaining requires an additional 4335 input in the form of an initialization vector. Unless otherwise specified, 4336 zero should be used as the initialization vector. Kerberos' use of DES 4337 requires an 8 octet confounder. 4339 The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 4340 shall not be used for encrypting messages for use in Kerberos. Additionally, 4341 because of the way that keys are derived for the encryption of checksums, 4342 keys shall not be used that yield 'weak' or 'semi-weak' keys when 4343 eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0. 4345 A DES key is 8 octets of data, with keytype one (1). This consists of 56 4346 bits of key, and 8 parity bits (one per octet). The key is encoded as a 4347 series of 8 octets written in MSB-first order. The bits within the key are 4348 also encoded in MSB order. For example, if the encryption key is 4349 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where 4350 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity 4351 bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the 4352 MSbit). [See the FIPS 81 introduction for reference.] 4353 Encryption data format 4355 The format for the data to be encrypted includes a one-block confounder, a 4356 checksum, the encoded plaintext, and any necessary padding, as described in 4357 the following diagram. The msg-seq field contains the part of the protocol 4358 message described in section 5 which is to be encrypted. The confounder, 4359 checksum, and padding are all untagged and untyped. 4361 +-----------+----------+-------------+-----+ 4362 |confounder | check | msg-seq | pad | 4363 +-----------+----------+-------------+-----+ 4365 One generates a random confounder of one block, placing it in confounder; 4366 zeroes out check; calculates the appropriate checksum over confounder, 4367 check, and msg-seq, placing the result in check; adds the necessary padding; 4368 then encrypts using the specified encryption type and the appropriate key. 4370 String to key transformation 4372 To generate a DES key from a UTF-8 text string (password), a "salt" is 4373 concatenated to the text string, and then padded with ASCII nulls to an 8 4374 byte boundary. 4376 This string is then fan-folded and eXclusive-ORed with itself to form an 8 4377 byte DES key. Before eXclusive-ORing a block, every byte is shifted one bit 4378 to the left to leave the lowest bit zero. The key is the "corrected" by 4379 correcting the parity on the key, and if the key matches a 'weak' or 4380 'semi-weak' key as described in the DES specification, it is eXclusive-ORed 4381 with the constant 00000000000000F0. This key is then used to generate a DES 4382 CBC checksum on the initial string (with the salt appended). The result of 4383 the CBC checksum is the "corrected" as described above to form the result 4384 which is return as the key. 4386 Pseudocode follows: 4388 key_correction(key) { 4389 fixparity(key); 4390 if (is_weak_key_key(key)) 4391 key = key XOR 0xF0; 4392 return(key); 4393 } 4395 mit_des_string_to_key(string,salt) { 4396 odd = 1; 4397 s = string + salt; 4398 tempkey = NULL; 4399 pad(s); /* with nulls to 8 byte boundary */ 4400 for (8byteblock in s) { 4401 if (odd == 0) { 4402 odd = 1; 4403 reverse(8byteblock) 4404 } 4405 else odd = 0; 4406 left shift every byte in 8byteblock one bit; 4407 tempkey = tempkey XOR 8byteblock; 4408 } 4409 tempkey = key_correction(tempkey); 4410 key = key_correction(DES-CBC-check(s,tempkey)); 4411 return(key); 4412 } 4413 des_string_to_key(type,string,salt) { 4414 if (type == 0) 4415 mit_des_string_to_key(string,salt); 4416 else if (type == 1) 4417 afs_des_string_to_key(string,salt); 4418 } 4420 The AFS string-to-key algorithm is not defined here, but salt type value one 4421 (1) is reserved for that use. 4423 The encryption system parameters for des-cbc-md5 are: 4425 protocol key format 8 bytes, parity in low bit of each 4426 specific key structure copy of original key 4427 required checksum mechanism rsa-md5-des 4428 key-generation seed length 8 bytes 4429 cipher state 8 bytes (CBC initial vector) 4430 initial cipher state all-zero 4431 encryption function des-cbc(confounder | checksum | msg | pad) 4433 with checksum computed as described above 4434 decryption function decrypt encrypted text and verify checksum 4435 key generation functions: 4436 string-to-key des_string_to_key 4437 random-to-key copy input, then fix parity bits 4438 (discards low bit of each input byte) 4439 combine-keys bitwise XOR, then fix parity bits 4440 key-derivation identity 4442 The des-cbc-md5 encryption type is assigned the etype value three (3). 4444 6.5.3. des-cbc-md4 4446 The des-cbc-md4 encryption mode encrypts information under the Data 4447 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 4448 An MD4 checksum (described in [MD492]) is applied to the confounder and 4449 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 4450 bytes. As a result, the data to be encrypted (the concatenation of 4451 confounder, checksum, and message) must be padded to an 8 byte boundary 4452 before encryption. The details of the encryption of this data are identical 4453 to those for the des-cbc-md5 encryption mode. 4455 protocol key format 8 bytes, parity in low bit of each 4456 specific key structure copy of original key 4457 required checksum mechanism rsa-md4-des 4458 key-generation seed length 8 bytes 4459 cipher state 8 bytes (CBC initial vector) 4460 initial cipher state all-zero 4461 encryption function des-cbc(confounder | checksum | msg | pad) 4463 with checksum computed as described above 4464 decryption function decrypt encrypted text and verify checksum 4465 key generation functions: 4466 string-to-key des_string_to_key 4467 random-to-key copy input, then fix parity bits 4468 combine-keys bitwise XOR, then fix parity bits 4469 key-derivation identity 4471 The des-cbc-md4 encryption algorithm is assigned the etype value two (2). 4473 6.5.4. des-cbc-crc 4475 The des-cbc-crc encryption mode encrypts information under the Data 4476 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A 4477 4-octet CRC-32 checksum (described in ISO 3309 [ISO3309]) is computed over 4478 the confounder and message sequence (msg-seq) and placed in the cksum field. 4479 DES blocks are 8 bytes. As a result, the data to be encrypted (the 4480 concatenation of confounder, checksum, and message) must be padded to an 8 4481 byte boundary before encryption. Unless otherwise specified, the key should 4482 be used as the initialization vector, unlike for the other Kerberos DES 4483 encryption schemes. The other details of the encryption of this data are 4484 identical to those for the des-cbc-md5 encryption mode. 4486 Note that, since the CRC-32 checksum is not collision-proof, an attacker 4487 could use a probabilistic chosen-plaintext attack to generate a valid 4488 message even if a confounder is used [SG92]. The use of collision-proof 4489 checksums is recommended for environments where such attacks represent a 4490 significant threat. The use of the CRC-32 as the checksum for ticket or 4491 authenticator is no longer mandated as an interoperability requirement for 4492 Kerberos Version 5 Specification 1 (See section 9.1 for specific details). 4494 protocol key format 8 bytes, parity in low bit of each 4495 specific key structure copy of original key 4496 required checksum mechanism rsa-md5-des 4497 key-generation seed length 8 bytes 4498 cipher state 8 bytes (CBC initial vector) 4499 initial cipher state copy of original key 4500 encryption function des-cbc(confounder | checksum | msg | pad) 4502 with checksum computed as described above 4503 decryption function decrypt encrypted text and verify checksum 4504 key generation functions: 4505 string-to-key des_string_to_key 4506 random-to-key copy input, then fix parity bits 4507 combine-keys bitwise XOR, then fix parity bits 4508 key-derivation identity 4510 The des-cbc-crc encryption algorithm is assigned the etype value one (1). 4512 6.5.5. des3-cbc-hmac-sha1-kd 4514 This encryption type is based on the Triple DES cryptosystem in Outer-CBC 4515 mode, and the HMAC-SHA1 [Krawczyk96] message authentication algorithm. 4517 A Triple DES key is the concatenation of three DES keys as described above 4518 for des-cbc-md5. A Triple DES key is generated from random data by creating 4519 three DES keys from separate sequences of random data. 4521 EncryptedData using this type must be generated as described in section 4522 6.4.2. If the length of the input data is not a multiple of the block size, 4523 zero octets must be used to pad the plaintext to the next eight-octet 4524 boundary. The counfounder must be eight random octets (one block). 4526 The simplified profile for Triple DES, with key derivation as defined in 4527 section 6.4, is as follows: 4529 protocol key format 24 bytes, parity in low bit of each 4530 key-generation seed length 21 bytes 4531 hash function SHA-1 4532 block size 8 bytes 4533 encryption, decryption functions triple-DES EDE in outer CBC mode 4534 key generation functions: 4535 random-to-key see below 4536 string-to-key DES3string-to-key (see below) 4538 The des3-cbc-hmac-sha1-kd encryption type is assigned the value sixteen 4539 (16). 4541 Triple DES Key Production (random-to-key, string-to-key) 4543 The 168 bits of random key data are converted to a protocol key value as 4544 follows. First, the 168 bits are divided into three groups of 56 bits, which 4545 are expanded individually into 64 bits as follows: 4547 1 2 3 4 5 6 7 p 4548 9 10 11 12 13 14 15 p 4549 17 18 19 20 21 22 23 p 4550 25 26 27 28 29 30 31 p 4551 33 34 35 36 37 38 39 p 4552 41 42 43 44 45 46 47 p 4553 49 50 51 52 53 54 55 p 4554 56 48 40 32 24 16 8 p 4556 The "p" bits are parity bits computed over the data bits. The output of the 4557 three expansions are concatenated to form the protocol key value. 4559 When the HMAC-SHA1 of a string is computed, the key is used in the protocol 4560 key form. 4562 The string-to-key function is used to tranform UTF-8 passwords into DES3 4563 keys. The DES3 string-to-key function relies on the "N-fold" algorithm and 4564 DK function, described in section 6.4. 4566 The n-fold algorithm is applied to the password string concatenated with a 4567 salt value. For 3-key triple DES, the operation will involve a 168-fold of 4568 the input password string, to generate an intermediate key, from which the 4569 user's long-term key will be derived with the DK function. The DES3 4570 string-to-key function is shown here in pseudocode: 4572 DES3string-to-key(passwordString, salt, key) 4574 s = passwordString + salt 4575 tmpKey = random-to-key(168-fold(s)) 4576 key = DK (tmpKey, KerberosConstant) 4578 No weak-key checking is performed. The KerberosConstant value is the byte 4579 string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to 4580 the ASCII encoding for the string "kerberos". 4582 6.6. Profiles for Kerberos checksums 4584 These are the checksum types currently defined for Kerberos. The full list 4585 of checksum type number assignments is given in section 8.3. 4587 6.6.1. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) 4589 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by 4590 prepending an 8 octet confounder before the text, applying the RSA MD4 4591 checksum algorithm [MD4-92], and encrypting the confounder and the checksum 4592 using DES in cipher-block-chaining (CBC) mode using a variant of the key, 4593 where the variant is computed by eXclusive-ORing the key with the constant 4594 F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The 4595 resulting checksum is 24 octets long. This checksum is tamper-proof and 4596 believed to be collision-proof. 4598 The DES specifications identify some weak keys' and 'semi-weak keys'; those 4599 keys shall not be used for generating RSA-MD4 checksums for use in Kerberos. 4601 The format for the checksum is described in the following diagram: 4603 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4604 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 4605 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4607 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 4608 get_mic des-cbc(key XOR F0F0F0F0F0F0F0F0, 4609 confounder | rsa-md4(confounder | msg)) 4611 verify_mic decrypt and verify rsa-md4 checksum 4613 The rsa-md4-des checksum algorithm is assigned a checksum type number of 4614 three (3). 4616 6.6.2. The RSA MD5 Checksum (rsa-md5) 4618 The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm 4619 [MD5-92]. The algorithm takes as input an input message of arbitrary length 4620 and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to 4621 be collision-proof. However, since it is unkeyed, it must be used with 4622 caution. Currently it is used by some implementations in places where the 4623 checksum itself is part of a larger message that will be encrypted. Its use 4624 is not recommended. 4626 associated cryptosystem null 4627 get_mic rsa-md5(msg) 4628 verify_mic get_mic and compare 4630 The rsa-md5 checksum algorithm is assigned a checksum type number of seven 4631 (7). 4633 6.6.3. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) 4635 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by 4636 prepending an 8 octet confounder before the text, applying the RSA MD5 4637 checksum algorithm, and encrypting the confounder and the checksum using DES 4638 in cipher-block-chaining (CBC) mode using a variant of the key, where the 4639 variant is computed by eXclusive-ORing the key with the hexadecimal constant 4640 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 4641 checksum is 24 octets long. This checksum is tamper-proof and believed to be 4642 collision-proof. 4644 The DES specifications identify some 'weak keys' and 'semi-weak keys'; those 4645 keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos. 4647 The format for the checksum is described in the following diagram: 4649 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4650 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 4651 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4653 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 4654 get_mic des-cbc(key XOR F0F0F0F0F0F0F0F0, 4655 confounder | rsa-md5(confounder | msg)) 4657 verify_mic decrypt and verify rsa-md5 checksum 4659 The rsa-md5-des checksum algorithm is assigned a checksum type number of 4660 eight (8). 4662 6.6.4. The HMAC-SHA1-DES3-KD Checksum (hmac-sha1-des3-kd) 4664 This checksum type is defined as outlined in section 6.3 above, using the 4665 des3-hmac-sha1-kd encryption algorithm parameters. The checksum is thus a 4666 SHA-1 HMAC using the computed key Kc over the message to be protected. 4668 The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type number 4669 of twelve (12). 4671 6.7. Use of Kerberos encryption outside this specification 4673 Several Kerberos-based application protocols and preauthentication systems 4674 have been designed and deployed that perform encryption and message 4675 integrity checks in various ways. While in some cases there may be good 4676 reason for specifying these protocols in terms of specific encryption or 4677 checksum algorithms, we anticipate that in many cases this will not be true, 4678 and more generic approaches independent of particular algorithms will be 4679 desirable. Rather than having each protocol designer reinvent schemes for 4680 protecting data, using multiple keys, etc, we have attempted to present in 4681 this section a general framework that should be sufficient not only for the 4682 Kerberos protocol itself but also for many preauthentication systems and 4683 application protocols, while trying to avoid some of the assumptions that 4684 can work their way into such protocol designs.[6.5] Such assumptions, while 4685 they may hold for any given set of encryption and checksum algorithms, may 4686 not be true of the next algorithms to be defined, leaving the application 4687 protocol unable to make use of those algorithms without updates to its 4688 specification. 4690 The Kerberos protocol uses only the attributes and operations described in 4691 sections 6.2 and 6.3. Preauthentication systems and application protocols 4692 making use of Kerberos are encouraged to use them as well. 4694 While we don't recommend it, undoubtedly some application protocols will 4695 continue to use the key data directly, even if only in some of the currently 4696 existing protocol specifications. An implementation intended to support 4697 general Kerberos applications may therefore need to make the key data 4698 available, as well as the attributes and operations described in sections 4699 6.2 and 6.3. [6.6] 4700 7. Naming Constraints 4702 7.1. Realm Names 4704 Although realm names are encoded as GeneralStrings and although a realm can 4705 technically select any name it chooses, interoperability across realm 4706 boundaries requires agreement on how realm names are to be assigned, and 4707 what information they imply. 4709 To enforce these conventions, each realm must conform to the conventions 4710 itself, and it must require that any realms with which inter-realm keys are 4711 shared also conform to the conventions and require the same from its 4712 neighbors. 4714 Kerberos realm names are case sensitive. Realm names that differ only in the 4715 case of the characters are not equivalent. There are presently four styles 4716 of realm names: domain, X500, other, and reserved. Examples of each style 4717 follow: 4719 domain: ATHENA.MIT.EDU (example) 4720 X500: C=US/O=OSF (example) 4721 other: NAMETYPE:rest/of.name=without-restrictions (example) 4722 reserved: reserved, but will not conflict with above 4724 Domain names must look like domain names: they consist of components 4725 separated by periods (.) and they contain neither colons (:) nor slashes 4726 (/). Though domain names themselves are case insensitive, in order for 4727 realms to match, the case must match as well. When establishing a new realm 4728 name based on an internet domain name it is recommended by convention that 4729 the characters be converted to upper case. 4731 X.500 names contain an equal (=) and cannot contain a colon (:) before the 4732 equal. The realm names for X.500 names will be string representations of the 4733 names with components separated by slashes. Leading and trailing slashes 4734 will not be included. Note that the slash separator is consistent with 4735 Kerberos implementations based on RFC1510, but it is different from the 4736 separator recommended in RFC2253. 4738 Names that fall into the other category must begin with a prefix that 4739 contains no equal (=) or period (.) and the prefix must be followed by a 4740 colon (:) and the rest of the name. All prefixes must be assigned before 4741 they may be used. Presently none are assigned. 4743 The reserved category includes strings which do not fall into the first 4744 three categories. All names in this category are reserved. It is unlikely 4745 that names will be assigned to this category unless there is a very strong 4746 argument for not using the 'other' category. 4748 These rules guarantee that there will be no conflicts between the various 4749 name styles. The following additional constraints apply to the assignment of 4750 realm names in the domain and X.500 categories: the name of a realm for the 4751 domain or X.500 formats must either be used by the organization owning (to 4752 whom it was assigned) an Internet domain name or X.500 name, or in the case 4753 that no such names are registered, authority to use a realm name may be 4754 derived from the authority of the parent realm. For example, if there is no 4755 domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4756 authorize the creation of a realm with that name. 4758 This is acceptable because the organization to which the parent is assigned 4759 is presumably the organization authorized to assign names to its children in 4760 the X.500 and domain name systems as well. If the parent assigns a realm 4761 name without also registering it in the domain name or X.500 hierarchy, it 4762 is the parent's responsibility to make sure that there will not in the 4763 future exist a name identical to the realm name of the child unless it is 4764 assigned to the same entity as the realm name. 4766 7.2. Principal Names 4768 As was the case for realm names, conventions are needed to ensure that all 4769 agree on what information is implied by a principal name. The name-type 4770 field that is part of the principal name indicates the kind of information 4771 implied by the name. The name-type should be treated as a hint. Ignoring the 4772 name type, no two names can be the same (i.e. at least one of the 4773 components, or the realm, must be different). The following name types are 4774 defined: 4776 name-type value meaning 4778 NT-UNKNOWN 0 Name type not known 4779 NT-PRINCIPAL 1 General principal name (e.g. username, or 4780 DCE principal) 4781 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4782 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4783 NT-SRV-XHST 4 Service with slash-separated host name components 4784 NT-UID 5 Unique ID 4785 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4786 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4787 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 4789 When a name implies no information other than its uniqueness at a particular 4790 time the name type PRINCIPAL should be used. The principal name type should 4791 be used for users, and it might also be used for a unique server. If the 4792 name is a unique machine generated ID that is guaranteed never to be 4793 reassigned then the name type of UID should be used (note that it is 4794 generally a bad idea to reassign names of any type since stale entries might 4795 remain in access control lists). 4797 If the first component of a name identifies a service and the remaining 4798 components identify an instance of the service in a server specified manner, 4799 then the name type of SRV-INST should be used. An example of this name type 4800 is the Kerberos ticket-granting service whose name has a first component of 4801 krbtgt and a second component identifying the realm for which the ticket is 4802 valid. 4804 If instance is a single component following the service name and the 4805 instance identifies the host on which the server is running, then the name 4806 type SRV-HST should be used. This type is typically used for Internet 4807 services such as telnet and the Berkeley R commands. If the separate 4808 components of the host name appear as successive components following the 4809 name of the service, then the name type SRV-XHST should be used. This type 4810 might be used to identify servers on hosts with X.500 names where the slash 4811 (/) might otherwise be ambiguous. 4813 A name type of NT-X500-PRINCIPAL should be used when a name from an X.509 4814 certificate is translated into a Kerberos name. The encoding of the X.509 4815 name as a Kerberos principal shall conform to the encoding rules specified 4816 in RFC 2253. 4818 A name type of SMTP allows a name to be of a form that resembles a SMTP 4819 email name. This name, including an "@" and a domain name, is used as the 4820 one component of the principal name. 4822 A name type of UNKNOWN should be used when the form of the name is not 4823 known. When comparing names, a name of type UNKNOWN will match principals 4824 authenticated with names of any type. A principal authenticated with a name 4825 of type UNKNOWN, however, will only match other names of type UNKNOWN. 4827 Names of any type with an initial component of 'krbtgt' are reserved for the 4828 Kerberos ticket granting service. See section 8.2.3 for the form of such 4829 names. 4831 7.2.1. Name of server principals 4833 The principal identifier for a server on a host will generally be composed 4834 of two parts: (1) the realm of the KDC with which the server is registered, 4835 and (2) a two-component name of type NT-SRV-HST if the host name is an 4836 Internet domain name or a multi-component name of type NT-SRV-XHST if the 4837 name of the host is of a form such as X.500 that allows slash (/) 4838 separators. The first component of the two- or multi-component name will 4839 identify the service and the latter components will identify the host. Where 4840 the name of the host is not case sensitive (for example, with Internet 4841 domain names) the name of the host must be lower case. If specified by the 4842 application protocol for services such as telnet and the Berkeley R commands 4843 which run with system privileges, the first component may be the string 4844 'host' instead of a service specific identifier. When a host has an official 4845 name and one or more aliases and the official name can be reliably 4846 determined, the official name of the host should be used when constructing 4847 the name of the server principal. 4849 8. Constants and other defined values 4851 8.1. Host address types 4853 All negative values for the host address type are reserved for local use. 4854 All non-negative values are reserved for officially assigned type fields and 4855 interpretations. 4857 The values of the types for the following addresses are chosen to match the 4858 defined address family constants in the Berkeley Standard Distributions of 4859 Unix. They can be found in with symbolic names AF_xxx (where xxx is an 4860 abbreviation of the address family name). 4862 Internet (IPv4) Addresses 4864 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB 4865 order. The IPv4 loopback address should not appear in a Kerberos packet. The 4866 type of IPv4 addresses is two (2). 4868 Internet (IPv6) Addresses [Westerlund] 4870 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The 4871 type of IPv6 addresses is twenty-four (24). [RFC2373]. The following 4872 addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 4874 * the Unspecified Address 4875 * the Loopback Address 4876 * Link-Local addresses 4877 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 4879 CHAOSnet addresses 4881 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order. 4882 The type of CHAOSnet addresses is five (5). 4884 ISO addresses 4886 ISO addresses are variable-length. The type of ISO addresses is seven (7). 4888 Xerox Network Services (XNS) addresses 4890 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The 4891 type of XNS addresses is six (6). 4893 AppleTalk Datagram Delivery Protocol (DDP) addresses 4895 AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network 4896 number. The first octet of the address is the node number; the remaining two 4897 octets encode the network number in MSB order. The type of AppleTalk DDP 4898 addresses is sixteen (16). 4900 DECnet Phase IV addresses 4902 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The 4903 type of DECnet Phase IV addresses is twelve (12). 4905 Netbios addresses 4907 Netbios addresses are 16-octet addresses typically composed of 1 to 15 4908 characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0. 4909 The type of Netbios addresses is 20 (0x14). 4911 8.2. KDC messages 4913 8.2.1. UDP/IP transport 4915 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP 4916 IP transport, the client shall send a UDP datagram containing only an 4917 encoding of the request to port 88 (decimal) at the KDC's IP address; the 4918 KDC will respond with a reply datagram containing only an encoding of the 4919 reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at 4920 the sender's IP address. Kerberos servers supporting IP transport must 4921 accept UDP requests on port 88 (decimal). The response to a request made 4922 through UDP/IP transport must also use UDP/IP transport. 4924 8.2.2. TCP/IP transport [Westerlund,Danielsson] 4926 Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and 4927 clients should support the sending of TCP requests on port 88 (decimal). 4928 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new 4929 connection will be established for each authentication exchange (request and 4930 response). The KRB_KDC_REP or KRB_ERROR message will be returned to the 4931 client on the same TCP stream that was established for the request. The 4932 response to a request made through TCP/IP transport must also use TCP/IP 4933 transport. Implementors should note that some extensions to the Kerberos 4934 protocol will not work if any implementation not supporting the TCP 4935 transport is involved (client or KDC). Implementors are strongly urged to 4936 support the TCP transport on both the client and server and are advised that 4937 the current notation of "should" support will likely change in the future to 4938 must support. The KDC may close the TCP stream after sending a response, but 4939 may leave the stream open if it expects a followup - in which case it may 4940 close the stream at any time if resource constraints or other factors make 4941 it desirable to do so. Care must be taken in managing TCP/IP connections 4942 with the KDC to prevent denial of service attacks based on the number of 4943 TCP/IP connections with the KDC that remain open. If multiple exchanges with 4944 the KDC are needed for certain forms of preauthentication, multiple TCP 4945 connections may be required. A client may close the stream after receiving 4946 response, and should close the stream if it does not expect to send followup 4947 messages. The client must be prepared to have the stream closed by the KDC 4948 at anytime, in which case it must simply connect again when it is ready to 4949 send subsequent messages. 4951 The first four octets of the TCP stream used to transmit the request request 4952 will encode in network byte order the length of the request (KRB_KDC_REQ), 4953 and the length will be followed by the request itself. The response will 4954 similarly be preceded by a 4 octet encoding in network byte order of the 4955 length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by 4956 the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the 4957 integer represented by the first 4 octets, then the next 4 octets will be 4958 read, extending the length of the field by another 4 octets (less the sign 4959 bit of the additional four octets which is reserved for future expansion and 4960 which at present must be zero). 4962 8.2.3. OSI transport 4964 During authentication of an OSI client to an OSI server, the mutual 4965 authentication of an OSI server to an OSI client, the transfer of 4966 credentials from an OSI client to an OSI server, or during exchange of 4967 private or integrity checked messages, Kerberos protocol messages may be 4968 treated as opaque objects and the type of the authentication mechanism will 4969 be: 4971 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5), kerberosv5(2)} 4973 Depending on the situation, the opaque object will be an authentication 4974 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message 4975 (KRB_SAFE), a private message (KRB_PRIV), or a credentials message 4976 (KRB_CRED). The opaque data contains an application code as specified in the 4977 ASN.1 description for each message. The application code may be used by 4978 Kerberos to determine the message type. 4980 8.2.4. Name of the TGS 4982 The principal identifier of the ticket-granting service shall be composed of 4983 three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part 4984 name of type NT-SRV-INST, with the first part "krbtgt" and the second part 4985 the name of the realm which will accept the ticket-granting ticket. For 4986 example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 4987 used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier 4988 of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 4989 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get 4990 tickets from the MIT.EDU realm has a principal identifier of 4991 "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name). 4993 8.3. Protocol constants and associated values 4995 The following tables list constants used in the protocol and define their 4996 meanings. Ranges are specified in the "specification" section that limit the 4997 values of constants for which values are defined here. This allows 4998 implementations to make assumptions about the maximum values that will be 4999 received for these constants. Implementation receiving values outside the 5000 range specified in the "specification" section may reject the request, but 5001 they must recover cleanly. 5003 Encryption type etype value block size minimum pad size confounder size 5004 NULL 0 1 0 0 5005 des-cbc-crc 1 8 4 8 5006 des-cbc-md4 2 8 0 8 5007 des-cbc-md5 3 8 0 8 5008 [reserved] 4 5009 des3-cbc-md5 5 8 0 8 5010 [reserved] 6 5011 des3-cbc-sha1 7 8 0 8 5012 dsaWithSHA1-CmsOID 9 (pkinit) 5013 md5WithRSAEncryption-CmsOID 10 (pkinit) 5014 sha1WithRSAEncryption-CmsOID 11 (pkinit) 5015 rc2CBC-EnvOID 12 (pkinit) 5016 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 5017 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 5018 des-ede3-cbc-Env-OID 15 (pkinit) 5019 des3-cbc-sha1-kd 16 (Tom Yu) 5020 rc4-hmac 23 (swift) 5021 rc4-hmac-exp 24 (swift) 5022 subkey-keynaterial 65 (opaque mhur) 5024 [reserved] 0x8003 5026 Checksum type sumtype value checksum size 5027 CRC32 1 4 5028 rsa-md4 2 16 5029 rsa-md4-des 3 24 5030 des-mac 4 16 5031 des-mac-k 5 8 5032 rsa-md4-des-k 6 16 (drop rsa ?) 5033 rsa-md5 7 16 (drop rsa ?) 5034 rsa-md5-des 8 24 (drop rsa ?) 5035 rsa-md5-des3 9 24 (drop rsa ?) 5036 hmac-sha1-des3-kd 12 20 5037 hmac-sha1-des3 13 20 5038 sha1 (unkeyed) 14 20 5040 padata and data types padata-type value comment 5042 PA-TGS-REQ 1 5043 PA-ENC-TIMESTAMP 2 5044 PA-PW-SALT 3 5045 [reserved] 4 5046 PA-ENC-UNIX-TIME 5 (depricated) 5047 PA-SANDIA-SECUREID 6 5048 PA-SESAME 7 5049 PA-OSF-DCE 8 5050 PA-CYBERSAFE-SECUREID 9 5051 PA-AFS3-SALT 10 5052 PA-ETYPE-INFO 11 5053 PA-SAM-CHALLENGE 12 (sam/otp) 5054 PA-SAM-RESPONSE 13 (sam/otp) 5055 PA-PK-AS-REQ 14 (pkinit) 5056 PA-PK-AS-REP 15 (pkinit) 5057 PA-USE-SPECIFIED-KVNO 20 5058 PA-SAM-REDIRECT 21 (sam/otp) 5059 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 5060 TD-PADATA 22 (embeds padata) 5061 PA-SAM-ETYPE-INFO 23 (sam/otp) 5062 PA-ALT-PRINC 24 (crawdad@fnal.gov) 5063 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 5064 TD-KRB-PRINCIPAL 102 PrincipalName (see Sec.5.9.1) 5065 TD-KRB-REALM 103 Realm (see Sec.5.9.1) 5066 TD-TRUSTED-CERTIFIERS 104 from PKINIT 5067 TD-CERTIFICATE-INDEX 105 from PKINIT 5068 TD-APP-DEFINED-ERROR 106 application specific (see Sec.5.9.1) 5069 TD-REQ-NONCE 107 INTEGER (see Sec.5.9.1) 5070 TD-REQ-SEQ 108 INTEGER (see Sec.5.9.1) 5071 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 5073 authorization data type ad-type value 5074 AD-IF-RELEVANT 1 5075 AD-INTENDED-FOR-SERVER 2 5076 AD-INTENDED-FOR-APPLICATION-CLASS 3 5077 AD-KDC-ISSUED 4 5078 AD-OR 5 5079 AD-MANDATORY-TICKET-EXTENSIONS 6 5080 AD-IN-TICKET-EXTENSIONS 7 5081 reserved values 8-63 5082 OSF-DCE 64 5083 SESAME 65 5084 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 5085 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 5087 Ticket Extension Types 5089 TE-TYPE-NULL 0 Null ticket extension 5090 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 5091 [reserved] 2 TE-TYPE-PKCROSS-KDC (I have reservations) 5092 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 5093 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 5094 [reserved] 5 TE-TYPE-DEST-HOST (I have reservations) 5096 alternate authentication type method-type value 5097 reserved values 0-63 5098 ATT-CHALLENGE-RESPONSE 64 5100 transited encoding type tr-type value 5101 DOMAIN-X500-COMPRESS 1 5102 reserved values all others 5104 Label Value Meaning or MIT code 5106 pvno 5 current Kerberos protocol version number 5107 message types (Will be updated to match section 5) 5109 KRB_AS_REQ 10 Request for initial authentication 5110 KRB_AS_REP 11 Response to KRB_AS_REQ request 5111 KRB_TGS_REQ 12 Request for authentication based on TGT 5112 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 5113 KRB_AP_REQ 14 application request to server 5114 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 5115 KRB_SAFE 20 Safe (checksummed) application message 5116 KRB_PRIV 21 Private (encrypted) application message 5117 KRB_CRED 22 Private (encrypted) message to forward credentials 5118 KRB_ERROR 30 Error response 5120 name types 5122 KRB_NT_UNKNOWN 0 Name type not known 5123 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5124 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 5125 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 5126 KRB_NT_SRV_XHST 4 Service with host as remaining components 5127 KRB_NT_UID 5 Unique ID 5128 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5130 error codes 5132 KDC_ERR_NONE 0 No error 5133 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 5134 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 5135 KDC_ERR_BAD_PVNO 3 Requested protocol version number 5136 not supported 5137 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 5138 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 5139 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 5140 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 5141 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 5142 KDC_ERR_NULL_KEY 9 The client or server has a null key 5143 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 5144 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 5145 KDC_ERR_POLICY 12 KDC policy rejects request 5146 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 5147 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 5148 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 5149 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 5150 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 5151 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 5152 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 5153 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 5154 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 5155 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 5156 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password 5157 to reset 5158 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 5159 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 5160 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 5161 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 5162 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 5163 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 5164 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 5165 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 5166 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 5167 KRB_AP_ERR_REPEAT 34 Request is a replay 5168 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 5169 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 5170 KRB_AP_ERR_SKEW 37 Clock skew too great 5171 KRB_AP_ERR_BADADDR 38 Incorrect net address 5172 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 5173 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 5174 KRB_AP_ERR_MODIFIED 41 Message stream modified 5175 KRB_AP_ERR_BADORDER 42 Message out of order 5176 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 5177 KRB_AP_ERR_NOKEY 45 Service key not available 5178 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 5179 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 5180 KRB_AP_ERR_METHOD 48 Alternative authentication method required 5181 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 5182 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 5183 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 5184 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 5185 KRB_ERR_GENERIC 60 Generic error (description in e-text) 5186 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 5187 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 5188 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 5189 KDC_ERROR_INVALID_SIG 64 (pkinit) 5190 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 5191 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 5192 KRB_AP_ERR_NO_TGT 67 (user-to-user) 5193 KDC_ERR_WRONG_REALM 68 (user-to-user) 5194 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 5195 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 5196 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 5197 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 5198 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 5199 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 5200 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 5201 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 5202 9. Interoperability requirements 5204 Version 5 of the Kerberos protocol supports a myriad of options. Among these 5205 are multiple encryption and checksum types, alternative encoding schemes for 5206 the transited field, optional mechanisms for pre-authentication, the 5207 handling of tickets with no addresses, options for mutual authentication, 5208 user to user authentication, support for proxies, forwarding, postdating, 5209 and renewing tickets, the format of realm names, and the handling of 5210 authorization data. 5212 In order to ensure the interoperability of realms, it is necessary to define 5213 a minimal configuration which must be supported by all implementations. This 5214 minimal configuration is subject to change as technology does. For example, 5215 if at some later date it is discovered that one of the required encryption 5216 or checksum algorithms is not secure, it will be replaced. 5218 9.1. Specification 2 5220 This section defines the second specification of these options. 5221 Implementations which are configured in this way can be said to support 5222 Kerberos Version 5 Specification 2 (5.1). Specification 1 (deprecated) may 5223 be found in RFC1510. 5225 Transport 5227 TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance 5228 to specification 2. Kerberos clients claiming conformance to specification 2 5229 must support UDP/IP transport for messages with the KDC and should support 5230 TCP/IP transport. 5232 Encryption and checksum methods 5234 The following encryption and checksum mechanisms must be supported. 5235 Implementations may support other mechanisms as well, but the additional 5236 mechanisms may only be used when communicating with principals known to also 5237 support them: This list is to be determined and should correspond to section 5238 6. 5240 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD, RIJNDAEL(decide identifier) 5241 Checksums: CRC-32, DES-MAC, DES-MAC-K, DES-MD5, HMAC-SHA1-DES3-KD 5243 Realm Names 5245 All implementations must understand hierarchical realms in both the Internet 5246 Domain and the X.500 style. When a ticket granting ticket for an unknown 5247 realm is requested, the KDC must be able to determine the names of the 5248 intermediate realms between the KDCs realm and the requested realm. 5250 Transited field encoding 5252 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 5253 Alternative encodings may be supported, but they may be used only when that 5254 encoding is supported by ALL intermediate realms. 5256 Pre-authentication methods 5258 The TGS-REQ method must be supported. The TGS-REQ method is not used on the 5259 initial request. The PA-ENC-TIMESTAMP method must be supported by clients 5260 but whether it is enabled by default may be determined on a realm by realm 5261 basis. If not used in the initial request and the error 5262 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 5263 acceptable method, the client should retry the initial request using the 5264 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 5265 PA-ENC-TIMESTAMP method, but if not supported the server should ignore the 5266 presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5268 Mutual authentication 5270 Mutual authentication (via the KRB_AP_REP message) must be supported. 5272 Ticket addresses and flags 5274 All KDC's must pass through tickets that carry no addresses (i.e. if a TGT 5275 contains no addresses, the KDC will return derivative tickets), but each 5276 realm may set its own policy for issuing such tickets, and each application 5277 server will set its own policy with respect to accepting them. 5279 Proxies and forwarded tickets must be supported. Individual realms and 5280 application servers can set their own policy on when such tickets will be 5281 accepted. 5283 All implementations must recognize renewable and postdated tickets, but need 5284 not actually implement them. If these options are not supported, the 5285 starttime and endtime in the ticket shall specify a ticket's entire useful 5286 life. When a postdated ticket is decoded by a server, all implementations 5287 shall make the presence of the postdated flag visible to the calling server. 5289 User-to-user authentication 5291 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option) 5292 must be provided by implementations, but individual realms may decide as a 5293 matter of policy to reject such requests on a per-principal or realm-wide 5294 basis. 5296 Authorization data 5298 Implementations must pass all authorization data subfields from 5299 ticket-granting tickets to any derivative tickets unless directed to 5300 suppress a subfield as part of the definition of that registered subfield 5301 type (it is never incorrect to pass on a subfield, and no registered 5302 subfield types presently specify suppression at the KDC). 5304 Implementations must make the contents of any authorization data subfields 5305 available to the server when a ticket is used. Implementations are not 5306 required to allow clients to specify the contents of the authorization data 5307 fields. 5309 Constant ranges 5311 All protocol constants are constrained to 32 bit (signed) values unless 5312 further constrained by the protocol definition. This limit is provided to 5313 allow implementations to make assumptions about the maximum values that will 5314 be received for these constants. Implementation receiving values outside 5315 this range may reject the request, but they must recover cleanly. 5317 9.2. Recommended KDC values 5319 Following is a list of recommended values for a KDC implementation, based on 5320 the list of suggested configuration constants (see section 4.4). 5322 minimum lifetime 5 minutes 5323 maximum renewable lifetime 1 week 5324 maximum ticket lifetime 1 day 5325 empty addresses only when suitable restrictions appear 5326 in authorization data 5327 proxiable, etc. Allowed. 5329 10. IANA considerations 5331 An appendix will be created with the tables that IANA will need to start 5332 maintaining. 5334 * cryptosystem registration 5335 * usage number registration 5337 11. ACKNOWLEDGEMENTS 5339 T.B.S. 5341 12. REFERENCES 5343 [Blumenthal96] 5344 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers", 5345 Proceedings of PRAGOCRYPT '96, 1996. 5346 [Bellare98] 5347 Bellare, M., Desai, A., Pointcheval, D., Rogaway, P., "Relations Among 5348 Notions of Security for Public-Key Encryption Schemes". Extended 5349 abstract published in Advances in Cryptology- Crypto 98 Proceedings, 5350 Lecture Notes in Computer Science Vol. 1462, H. Krawcyzk ed., 5351 Springer-Verlag, 1998. 5352 [DES77] 5353 National Bureau of Standards, U.S. Department of Commerce, "Data 5354 Encryption Standard," Federal Information Processing Standards 5355 Publication 46, Washington, DC (1977). 5356 [DESM80] 5357 National Bureau of Standards, U.S. Department of Com- merce, "DES Modes 5358 of Operation," Federal Information Processing Standards Publication 81, 5359 Springfield, VA (December 1980). 5360 [Dolev91] 5361 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 5362 Proceedings of the 23rd Annual Symposium on Theory of Computing, ACM, 5363 1991. 5364 [DS81] 5365 Dorothy E. Denning and Giovanni Maria Sacco, "Time- stamps in Key 5366 Distribution Protocols," Communications of the ACM, Vol. 24(8), pp. 5367 533-536 (August 1981). 5368 [DS90] 5369 Don Davis and Ralph Swick, "Workstation Services and Kerberos 5370 Authentication at Project Athena," Technical Memorandum TM-424, MIT 5371 Laboratory for Computer Science (February 1990). 5372 [Horowitz96] 5373 Horowitz, M., "Key Derivation for Authentication, Integrity, and 5374 Privacy", draft-horowitz-key-derivation-02.txt, August 1998. 5375 [HorowitzB96] 5376 Horowitz, M., "Key Derivation for Kerberos V5", draft- 5377 horowitz-kerb-key-derivation-01.txt, September 1998. 5378 [IS3309] 5379 International Organization for Standardization, "ISO Information 5380 Processing Systems - Data Communication - High-Level Data Link Control 5381 Procedure - Frame Struc- ture," IS 3309 (October 1984). 3rd Edition. 5382 [KBC96] 5383 H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- Hashing for 5384 Message Authentication," Working Draft 5385 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 5386 [KNT92] 5387 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The Evolution 5388 of the Kerberos Authentication Service," in an IEEE Computer Society 5389 Text soon to be published (June 1992). 5390 [Krawczyk96] 5391 Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: Keyed-Hashing for 5392 Message Authentication", draft-ietf-ipsec-hmac- md5-01.txt, August, 5393 1996. 5394 [LGDSR87] 5395 P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- merfeld, and K. 5396 Raeburn, Section E.1: Service Manage- ment System, M.I.T. Project 5397 Athena, Cambridge, Mas- sachusetts (1987). 5398 [MD4-92] 5399 R. Rivest, "The MD4 Message Digest Algorithm," RFC 1320, MIT Laboratory 5400 for Computer Science (April 1992). 5401 [MD5-92] 5402 R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, MIT Laboratory 5403 for Computer Science (April 1992). 5404 [MNSS87] 5405 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section 5406 E.2.1: Kerberos Authentication and Authorization System, M.I.T. Project 5407 Athena, Cambridge, Massachusetts (December 21, 1987). 5408 [Neu93] 5409 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 5410 Distributed Systems," in Proceedings of the 13th International 5411 Conference on Distributed Com- puting Systems, Pittsburgh, PA (May, 5412 1993). 5413 [NS78] 5414 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5415 Authentication in Large Networks of Com- puters," Communications of the 5416 ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5417 [NT94] 5418 B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- cation Service 5419 for Computer Networks," IEEE Communica- tions Magazine, Vol. 32(9), pp. 5420 33-38 (September 1994). 5421 [Pat92]. 5422 J. Pato, Using Pre-Authentication to Avoid Password Guessing Attacks, 5423 Open Software Foundation DCE Request for Comments 26 (December 1992). 5424 [SG92] 5425 Stuart G. Stubblebine and Virgil D. Gligor, "On Message Integrity in 5426 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 5427 Research in Security and Privacy, Oakland, California (May 1992). 5428 [SNS88] 5429 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- beros: An 5430 Authentication Service for Open Network Sys- tems," pp. 191-202 in 5431 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 5432 [X509-88] 5433 CCITT, Recommendation X.509: The Directory Authentica- tion Framework, 5434 December 1988. 5436 A. Pseudo-code for protocol processing 5438 This appendix provides pseudo-code describing how the messages are to be 5439 constructed and interpreted by clients and servers. [we are waiting on 5440 verification code from Microsoft for possible replacement] 5442 A.1. KRB_AS_REQ generation 5444 request.pvno := protocol version; /* pvno = 5 */ 5445 request.msg-type := message type; /* type = KRB_AS_REQ */ 5447 if(pa_enc_timestamp_required) then 5448 request.padata.padata-type = PA-ENC-TIMESTAMP; 5449 get system_time; 5450 padata-body.patimestamp,pausec = system_time; 5451 encrypt padata-body into request.padata.padata-value 5452 using client.key; /* derived from password */ 5453 endif 5455 body.kdc-options := users's preferences; 5456 body.cname := user's name; 5457 body.realm := user's realm; 5458 body.sname := service's name; /* usually "krbtgt", = 5459 "localrealm" */ 5460 if (body.kdc-options.POSTDATED is set) then 5461 body.from := requested starting time; 5462 else 5463 omit body.from; 5464 endif 5465 body.till := requested end time; 5466 if (body.kdc-options.RENEWABLE is set) then 5467 body.rtime := requested final renewal time; 5468 endif 5469 body.nonce := random_nonce(); 5470 body.etype := requested etypes; 5471 if (user supplied addresses) then 5472 body.addresses := user's addresses; 5473 else 5474 omit body.addresses; 5475 endif 5476 omit body.enc-authorization-data; 5477 request.req-body := body; 5479 kerberos := lookup(name of local kerberos server (or = 5480 servers)); 5481 send(packet,kerberos); 5483 wait(for response); 5484 if (timed_out) then 5485 retry or use alternate server; 5486 endif 5488 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 5490 decode message into req; 5492 client := lookup(req.cname,req.realm); 5493 server := lookup(req.sname,req.realm); 5495 get system_time; 5496 kdc_time := system_time.seconds; 5498 if (!client) then 5499 /* no client in Database */ 5500 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 5501 endif 5502 if (!server) then 5503 /* no server in Database */ 5504 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5505 endif 5507 if(client.pa_enc_timestamp_required and 5508 pa_enc_timestamp not present) then 5509 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 5510 endif 5512 if(pa_enc_timestamp present) then 5513 decrypt req.padata-value into decrypted_enc_timestamp 5514 using client.key; 5515 using auth_hdr.authenticator.subkey; 5516 if (decrypt_error()) then 5517 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5518 if(decrypted_enc_timestamp is not within allowable skew) = 5519 then 5520 error_out(KDC_ERR_PREAUTH_FAILED); 5521 endif 5522 if(decrypted_enc_timestamp and usec is replay) 5523 error_out(KDC_ERR_PREAUTH_FAILED); 5524 endif 5525 add decrypted_enc_timestamp and usec to replay cache; 5526 endif 5528 use_etype := first supported etype in req.etypes; 5530 if (no support for req.etypes) then 5531 error_out(KDC_ERR_ETYPE_NOSUPP); 5532 endif 5534 new_tkt.vno := ticket version; /* = 5 */ 5535 new_tkt.sname := req.sname; 5536 new_tkt.srealm := req.srealm; 5537 reset all flags in new_tkt.flags; 5539 /* It should be noted that local policy may affect the */ 5540 /* processing of any of these flags. For example, some */ 5541 /* realms may refuse to issue renewable tickets */ 5543 if (req.kdc-options.FORWARDABLE is set) then 5544 set new_tkt.flags.FORWARDABLE; 5545 endif 5546 if (req.kdc-options.PROXIABLE is set) then 5547 set new_tkt.flags.PROXIABLE; 5548 endif 5550 if (req.kdc-options.ALLOW-POSTDATE is set) then 5551 set new_tkt.flags.MAY-POSTDATE; 5552 endif 5553 if ((req.kdc-options.RENEW is set) or 5554 (req.kdc-options.VALIDATE is set) or 5555 (req.kdc-options.PROXY is set) or 5556 (req.kdc-options.FORWARDED is set) or 5557 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 5558 error_out(KDC_ERR_BADOPTION); 5559 endif 5561 new_tkt.session := random_session_key(); 5562 new_tkt.cname := req.cname; 5563 new_tkt.crealm := req.crealm; 5564 new_tkt.transited := empty_transited_field(); 5566 new_tkt.authtime := kdc_time; 5568 if (req.kdc-options.POSTDATED is set) then 5569 if (against_postdate_policy(req.from)) then 5570 error_out(KDC_ERR_POLICY); 5571 endif 5572 set new_tkt.flags.POSTDATED; 5573 set new_tkt.flags.INVALID; 5574 new_tkt.starttime := req.from; 5575 else 5576 omit new_tkt.starttime; /* treated as authtime when omitted = 5577 */ 5578 endif 5579 if (req.till = 0) then 5580 till := infinity; 5581 else 5582 till := req.till; 5583 endif 5585 new_tkt.endtime := min(till, 5586 new_tkt.starttime+client.max_life, 5587 new_tkt.starttime+server.max_life, 5588 new_tkt.starttime+max_life_for_realm); 5590 if ((req.kdc-options.RENEWABLE-OK is set) and 5591 (new_tkt.endtime < req.till)) then 5592 /* we set the RENEWABLE option for later processing */ 5593 set req.kdc-options.RENEWABLE; 5594 req.rtime := req.till; 5595 endif 5597 if (req.rtime = 0) then 5598 rtime := infinity; 5599 else 5600 rtime := req.rtime; 5601 endif 5603 if (req.kdc-options.RENEWABLE is set) then 5604 set new_tkt.flags.RENEWABLE; 5605 new_tkt.renew-till := min(rtime, 5606 new_tkt.starttime+client.max_rlife, 5607 new_tkt.starttime+server.max_rlife, 5608 new_tkt.starttime+max_rlife_for_realm); 5609 else 5610 omit new_tkt.renew-till; /* only present if RENEWABLE */ 5611 endif 5613 if (req.addresses) then 5614 new_tkt.caddr := req.addresses; 5615 else 5616 omit new_tkt.caddr; 5617 endif 5619 new_tkt.authorization_data := empty_authorization_data(); 5621 encode to-be-encrypted part of ticket into OCTET STRING; 5622 new_tkt.enc-part := encrypt OCTET STRING 5623 using etype_for_key(server.key), server.key, server.p_kvno; 5625 /* Start processing the response */ 5627 resp.pvno := 5; 5628 resp.msg-type := KRB_AS_REP; 5629 resp.cname := req.cname; 5630 resp.crealm := req.realm; 5631 resp.ticket := new_tkt; 5633 resp.key := new_tkt.session; 5634 resp.last-req := fetch_last_request_info(client); 5635 resp.nonce := req.nonce; 5636 resp.key-expiration := client.expiration; 5637 resp.flags := new_tkt.flags; 5639 resp.authtime := new_tkt.authtime; 5640 resp.starttime := new_tkt.starttime; 5641 resp.endtime := new_tkt.endtime; 5643 if (new_tkt.flags.RENEWABLE) then 5644 resp.renew-till := new_tkt.renew-till; 5645 endif 5647 resp.realm := new_tkt.realm; 5648 resp.sname := new_tkt.sname; 5650 resp.caddr := new_tkt.caddr; 5652 encode body of reply into OCTET STRING; 5654 resp.enc-part := encrypt OCTET STRING 5655 using use_etype, client.key, client.p_kvno; 5656 send(resp); 5658 A.3. KRB_AS_REP verification 5660 decode response into resp; 5662 if (resp.msg-type = KRB_ERROR) then 5663 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 5664 set pa_enc_timestamp_required; 5665 goto KRB_AS_REQ; 5666 endif 5667 process_error(resp); 5668 return; 5669 endif 5671 /* On error, discard the response, and zero the session key */ 5672 /* from the response immediately */ 5674 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 5675 resp.padata); 5676 unencrypted part of resp := decode of decrypt of resp.enc-part 5677 using resp.enc-part.etype and key; 5678 zero(key); 5680 if (common_as_rep_tgs_rep_checks fail) then 5681 destroy resp.key; 5682 return error; 5683 endif 5685 if near(resp.princ_exp) then 5686 print(warning message); 5687 endif 5688 save_for_later(ticket,session,client,server,times,flags); 5690 A.4. KRB_AS_REP and KRB_TGS_REP common checks 5692 if (decryption_error() or 5693 (req.cname != resp.cname) or 5694 (req.realm != resp.crealm) or 5695 (req.sname != resp.sname) or 5696 (req.realm != resp.realm) or 5697 (req.nonce != resp.nonce) or 5698 (req.addresses != resp.caddr)) then 5699 destroy resp.key; 5700 return KRB_AP_ERR_MODIFIED; 5701 endif 5703 /* make sure no flags are set that shouldn't be, and that all that */ 5704 /* should be are set */ 5705 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 5706 destroy resp.key; 5707 return KRB_AP_ERR_MODIFIED; 5708 endif 5710 if ((req.from = 0) and 5711 (resp.starttime is not within allowable skew)) then 5712 destroy resp.key; 5713 return KRB_AP_ERR_SKEW; 5714 endif 5715 if ((req.from != 0) and (req.from != resp.starttime)) then 5716 destroy resp.key; 5717 return KRB_AP_ERR_MODIFIED; 5718 endif 5719 if ((req.till != 0) and (resp.endtime > req.till)) then 5720 destroy resp.key; 5721 return KRB_AP_ERR_MODIFIED; 5722 endif 5724 if ((req.kdc-options.RENEWABLE is set) and 5725 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 5726 destroy resp.key; 5727 return KRB_AP_ERR_MODIFIED; 5728 endif 5729 if ((req.kdc-options.RENEWABLE-OK is set) and 5730 (resp.flags.RENEWABLE) and 5731 (req.till != 0) and 5732 (resp.renew-till > req.till)) then 5733 destroy resp.key; 5734 return KRB_AP_ERR_MODIFIED; 5735 endif 5736 A.5. KRB_TGS_REQ generation 5738 /* Note that make_application_request might have to recursivly */ 5739 /* call this routine to get the appropriate ticket-granting ticket */ 5741 request.pvno := protocol version; /* pvno = 5 */ 5742 request.msg-type := message type; /* type = KRB_TGS_REQ */ 5744 body.kdc-options := users's preferences; 5745 /* If the TGT is not for the realm of the end-server */ 5746 /* then the sname will be for a TGT for the end-realm */ 5747 /* and the realm of the requested ticket (body.realm) */ 5748 /* will be that of the TGS to which the TGT we are */ 5749 /* sending applies */ 5750 body.sname := service's name; 5751 body.realm := service's realm; 5753 if (body.kdc-options.POSTDATED is set) then 5754 body.from := requested starting time; 5755 else 5756 omit body.from; 5757 endif 5758 body.till := requested end time; 5759 if (body.kdc-options.RENEWABLE is set) then 5760 body.rtime := requested final renewal time; 5761 endif 5762 body.nonce := random_nonce(); 5763 body.etype := requested etypes; 5764 if (user supplied addresses) then 5765 body.addresses := user's addresses; 5766 else 5767 omit body.addresses; 5768 endif 5770 body.enc-authorization-data := user-supplied data; 5771 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5772 body.additional-tickets_ticket := second TGT; 5773 endif 5775 request.req-body := body; 5776 check := generate_checksum (req.body,checksumtype); 5778 request.padata[0].padata-type := PA-TGS-REQ; 5779 request.padata[0].padata-value := create a KRB_AP_REQ using 5780 the TGT and checksum 5782 /* add in any other padata as required/supplied */ 5784 kerberos := lookup(name of local kerberose server (or servers)); 5785 send(packet,kerberos); 5787 wait(for response); 5788 if (timed_out) then 5789 retry or use alternate server; 5790 endif 5792 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5794 /* note that reading the application request requires first 5795 determining the server for which a ticket was issued, and choosing the 5796 correct key for decryption. The name of the server appears in the 5797 plaintext part of the ticket. */ 5799 if (no KRB_AP_REQ in req.padata) then 5800 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5801 endif 5802 verify KRB_AP_REQ in req.padata; 5804 /* Note that the realm in which the Kerberos server is operating is 5805 determined by the instance from the ticket-granting ticket. The realm 5806 in the ticket-granting ticket is the realm under which the ticket 5807 granting ticket was issued. It is possible for a single Kerberos 5808 server to support more than one realm. */ 5810 auth_hdr := KRB_AP_REQ; 5811 tgt := auth_hdr.ticket; 5813 if (tgt.sname is not a TGT for local realm and is not req.sname) then 5814 error_out(KRB_AP_ERR_NOT_US); 5816 realm := realm_tgt_is_for(tgt); 5818 decode remainder of request; 5820 if (auth_hdr.authenticator.cksum is missing) then 5821 error_out(KRB_AP_ERR_INAPP_CKSUM); 5822 endif 5824 if (auth_hdr.authenticator.cksum type is not supported) then 5825 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5826 endif 5827 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 5828 error_out(KRB_AP_ERR_INAPP_CKSUM); 5829 endif 5831 set computed_checksum := checksum(req); 5832 if (computed_checksum != auth_hdr.authenticatory.cksum) then 5833 error_out(KRB_AP_ERR_MODIFIED); 5834 endif 5836 server := lookup(req.sname,realm); 5838 if (!server) then 5839 if (is_foreign_tgt_name(req.sname)) then 5840 server := best_intermediate_tgs(req.sname); 5841 else 5842 /* no server in Database */ 5843 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5844 endif 5845 endif 5847 session := generate_random_session_key(); 5849 use_etype := first supported etype in req.etypes; 5851 if (no support for req.etypes) then 5852 error_out(KDC_ERR_ETYPE_NOSUPP); 5853 endif 5854 new_tkt.vno := ticket version; /* = 5 */ 5855 new_tkt.sname := req.sname; 5856 new_tkt.srealm := realm; 5857 reset all flags in new_tkt.flags; 5859 /* It should be noted that local policy may affect the */ 5860 /* processing of any of these flags. For example, some */ 5861 /* realms may refuse to issue renewable tickets */ 5863 new_tkt.caddr := tgt.caddr; 5864 resp.caddr := NULL; /* We only include this if they change */ 5865 if (req.kdc-options.FORWARDABLE is set) then 5866 if (tgt.flags.FORWARDABLE is reset) then 5867 error_out(KDC_ERR_BADOPTION); 5868 endif 5869 set new_tkt.flags.FORWARDABLE; 5870 endif 5871 if (req.kdc-options.FORWARDED is set) then 5872 if (tgt.flags.FORWARDABLE is reset) then 5873 error_out(KDC_ERR_BADOPTION); 5874 endif 5875 set new_tkt.flags.FORWARDED; 5876 new_tkt.caddr := req.addresses; 5877 resp.caddr := req.addresses; 5878 endif 5879 if (tgt.flags.FORWARDED is set) then 5880 set new_tkt.flags.FORWARDED; 5881 endif 5883 if (req.kdc-options.PROXIABLE is set) then 5884 if (tgt.flags.PROXIABLE is reset) 5885 error_out(KDC_ERR_BADOPTION); 5886 endif 5887 set new_tkt.flags.PROXIABLE; 5888 endif 5889 if (req.kdc-options.PROXY is set) then 5890 if (tgt.flags.PROXIABLE is reset) then 5891 error_out(KDC_ERR_BADOPTION); 5892 endif 5893 set new_tkt.flags.PROXY; 5894 new_tkt.caddr := req.addresses; 5895 resp.caddr := req.addresses; 5896 endif 5898 if (req.kdc-options.ALLOW-POSTDATE is set) then 5899 if (tgt.flags.MAY-POSTDATE is reset) 5900 error_out(KDC_ERR_BADOPTION); 5901 endif 5902 set new_tkt.flags.MAY-POSTDATE; 5903 endif 5904 if (req.kdc-options.POSTDATED is set) then 5905 if (tgt.flags.MAY-POSTDATE is reset) then 5906 error_out(KDC_ERR_BADOPTION); 5907 endif 5908 set new_tkt.flags.POSTDATED; 5909 set new_tkt.flags.INVALID; 5910 if (against_postdate_policy(req.from)) then 5911 error_out(KDC_ERR_POLICY); 5912 endif 5913 new_tkt.starttime := req.from; 5914 endif 5916 if (req.kdc-options.VALIDATE is set) then 5917 if (tgt.flags.INVALID is reset) then 5918 error_out(KDC_ERR_POLICY); 5919 endif 5920 if (tgt.starttime > kdc_time) then 5921 error_out(KRB_AP_ERR_NYV); 5922 endif 5923 if (check_hot_list(tgt)) then 5924 error_out(KRB_AP_ERR_REPEAT); 5925 endif 5926 tkt := tgt; 5927 reset new_tkt.flags.INVALID; 5928 endif 5930 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 5931 and those already processed) is set) then 5932 error_out(KDC_ERR_BADOPTION); 5933 endif 5935 new_tkt.authtime := tgt.authtime; 5937 if (req.kdc-options.RENEW is set) then 5938 /* Note that if the endtime has already passed, the ticket would */ 5939 /* have been rejected in the initial authentication stage, so */ 5940 /* there is no need to check again here */ 5941 if (tgt.flags.RENEWABLE is reset) then 5942 error_out(KDC_ERR_BADOPTION); 5943 endif 5944 if (tgt.renew-till < kdc_time) then 5945 error_out(KRB_AP_ERR_TKT_EXPIRED); 5946 endif 5947 tkt := tgt; 5948 new_tkt.starttime := kdc_time; 5949 old_life := tgt.endttime - tgt.starttime; 5950 new_tkt.endtime := min(tgt.renew-till, 5951 new_tkt.starttime + old_life); 5952 else 5953 new_tkt.starttime := kdc_time; 5954 if (req.till = 0) then 5955 till := infinity; 5956 else 5957 till := req.till; 5958 endif 5959 new_tkt.endtime := min(till, 5960 new_tkt.starttime+client.max_life, 5961 new_tkt.starttime+server.max_life, 5962 new_tkt.starttime+max_life_for_realm, 5963 tgt.endtime); 5965 if ((req.kdc-options.RENEWABLE-OK is set) and 5966 (new_tkt.endtime < req.till) and 5967 (tgt.flags.RENEWABLE is set) then 5968 /* we set the RENEWABLE option for later processing */ 5969 set req.kdc-options.RENEWABLE; 5970 req.rtime := min(req.till, tgt.renew-till); 5971 endif 5972 endif 5973 if (req.rtime = 0) then 5974 rtime := infinity; 5975 else 5976 rtime := req.rtime; 5977 endif 5979 if ((req.kdc-options.RENEWABLE is set) and 5980 (tgt.flags.RENEWABLE is set)) then 5981 set new_tkt.flags.RENEWABLE; 5982 new_tkt.renew-till := min(rtime, 5983 new_tkt.starttime+client.max_rlife, 5984 new_tkt.starttime+server.max_rlife, 5985 new_tkt.starttime+max_rlife_for_realm, 5986 tgt.renew-till); 5987 else 5988 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 5989 endif 5990 if (req.enc-authorization-data is present) then 5991 decrypt req.enc-authorization-data into decrypted_authorization_data 5992 using auth_hdr.authenticator.subkey; 5993 if (decrypt_error()) then 5994 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5995 endif 5996 endif 5997 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 5998 decrypted_authorization_data; 6000 new_tkt.key := session; 6001 new_tkt.crealm := tgt.crealm; 6002 new_tkt.cname := req.auth_hdr.ticket.cname; 6004 if (realm_tgt_is_for(tgt) := tgt.realm) then 6005 /* tgt issued by local realm */ 6006 new_tkt.transited := tgt.transited; 6007 else 6008 /* was issued for this realm by some other realm */ 6009 if (tgt.transited.tr-type not supported) then 6010 error_out(KDC_ERR_TRTYPE_NOSUPP); 6011 endif 6012 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 6013 /* Don't check tranited field if TGT for foreign realm,=20 6014 * or requested not to check */ 6015 if (is_not_foreign_tgt_name(new_tkt.server)=20 6016 && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then 6017 /* Check it, so end-server does not have to=20 6018 * but don't fail, end-server may still accept it */ 6019 if (check_transited_field(new_tkt.transited) == OK) 6020 set = 6021 new_tkt.flags.TRANSITED-POLICY-CHECKED; 6022 endif 6023 endif 6024 endif 6026 encode encrypted part of new_tkt into OCTET STRING; 6027 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 6028 if (server not specified) then 6029 server = req.second_ticket.client; 6030 endif 6031 if ((req.second_ticket is not a TGT) or 6032 (req.second_ticket.client != server)) then 6033 error_out(KDC_ERR_POLICY); 6034 endif 6036 new_tkt.enc-part := encrypt OCTET STRING using 6037 using etype_for_key(second-ticket.key), second-ticket.key; 6038 else 6039 new_tkt.enc-part := encrypt OCTET STRING 6040 using etype_for_key(server.key), server.key, server.p_kvno; 6041 endif 6043 resp.pvno := 5; 6044 resp.msg-type := KRB_TGS_REP; 6045 resp.crealm := tgt.crealm; 6046 resp.cname := tgt.cname; 6047 resp.ticket := new_tkt; 6049 resp.key := session; 6050 resp.nonce := req.nonce; 6051 resp.last-req := fetch_last_request_info(client); 6052 resp.flags := new_tkt.flags; 6054 resp.authtime := new_tkt.authtime; 6055 resp.starttime := new_tkt.starttime; 6056 resp.endtime := new_tkt.endtime; 6058 omit resp.key-expiration; 6060 resp.sname := new_tkt.sname; 6061 resp.realm := new_tkt.realm; 6063 if (new_tkt.flags.RENEWABLE) then 6064 resp.renew-till := new_tkt.renew-till; 6065 endif 6067 encode body of reply into OCTET STRING; 6069 if (req.padata.authenticator.subkey) 6070 resp.enc-part := encrypt OCTET STRING using use_etype, 6071 req.padata.authenticator.subkey; 6072 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 6074 send(resp); 6076 =09 6078 A.7. KRB_TGS_REP verification 6080 decode response into resp; 6082 if (resp.msg-type = KRB_ERROR) then 6083 process_error(resp); 6084 return; 6085 endif 6087 /* On error, discard the response, and zero the session key from 6088 the response immediately */ 6090 if (req.padata.authenticator.subkey) 6091 unencrypted part of resp := decode of decrypt of resp.enc-part 6092 using resp.enc-part.etype and subkey; 6093 else unencrypted part of resp := decode of decrypt of resp.enc-part 6094 using resp.enc-part.etype and tgt's session key; 6095 if (common_as_rep_tgs_rep_checks fail) then 6096 destroy resp.key; 6097 return error; 6098 endif 6100 check authorization_data as necessary; 6101 save_for_later(ticket,session,client,server,times,flags); 6103 A.8. Authenticator generation 6105 body.authenticator-vno := authenticator vno; /* = 5 */ 6106 body.cname, body.crealm := client name; 6107 if (supplying checksum) then 6108 body.cksum := checksum; 6109 endif 6110 get system_time; 6111 body.ctime, body.cusec := system_time; 6112 if (selecting sub-session key) then 6113 select sub-session key; 6114 body.subkey := sub-session key; 6115 endif 6116 if (using sequence numbers) then 6117 select initial sequence number; 6118 body.seq-number := initial sequence; 6119 endif 6121 A.9. KRB_AP_REQ generation 6123 obtain ticket and session_key from cache; 6125 packet.pvno := protocol version; /* 5 */ 6126 packet.msg-type := message type; /* KRB_AP_REQ */ 6128 if (desired(MUTUAL_AUTHENTICATION)) then 6129 set packet.ap-options.MUTUAL-REQUIRED; 6130 else 6131 reset packet.ap-options.MUTUAL-REQUIRED; 6132 endif 6133 if (using session key for ticket) then 6134 set packet.ap-options.USE-SESSION-KEY; 6135 else 6136 reset packet.ap-options.USE-SESSION-KEY; 6137 endif 6138 packet.ticket := ticket; /* ticket */ 6139 generate authenticator; 6140 encode authenticator into OCTET STRING; 6141 encrypt OCTET STRING into packet.authenticator using session_key; 6143 A.10. KRB_AP_REQ verification 6145 receive packet; 6146 if (packet.pvno != 5) then 6147 either process using other protocol spec 6148 or error_out(KRB_AP_ERR_BADVERSION); 6149 endif 6150 if (packet.msg-type != KRB_AP_REQ) then 6151 error_out(KRB_AP_ERR_MSG_TYPE); 6152 endif 6153 if (packet.ticket.tkt_vno != 5) then 6154 either process using other protocol spec 6155 or error_out(KRB_AP_ERR_BADVERSION); 6156 endif 6157 if (packet.ap_options.USE-SESSION-KEY is set) then 6158 retrieve session key from ticket-granting ticket for 6159 packet.ticket.{sname,srealm,enc-part.etype}; 6160 else 6161 retrieve service key for 6162 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 6163 endif 6164 if (no_key_available) then 6165 if (cannot_find_specified_skvno) then 6166 error_out(KRB_AP_ERR_BADKEYVER); 6167 else 6168 error_out(KRB_AP_ERR_NOKEY); 6169 endif 6170 endif 6171 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 6172 if (decryption_error()) then 6173 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6174 endif 6175 decrypt packet.authenticator into decr_authenticator 6176 using decr_ticket.key; 6177 if (decryption_error()) then 6178 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6179 endif 6180 if (decr_authenticator.{cname,crealm} != 6181 decr_ticket.{cname,crealm}) then 6182 error_out(KRB_AP_ERR_BADMATCH); 6183 endif 6184 if (decr_ticket.caddr is present) then 6185 if (sender_address(packet) is not in decr_ticket.caddr) then 6186 error_out(KRB_AP_ERR_BADADDR); 6187 endif 6188 elseif (application requires addresses) then 6189 error_out(KRB_AP_ERR_BADADDR); 6190 endif 6191 if (not in_clock_skew(decr_authenticator.ctime, 6192 decr_authenticator.cusec)) then 6193 error_out(KRB_AP_ERR_SKEW); 6194 endif 6195 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 6196 error_out(KRB_AP_ERR_REPEAT); 6197 endif 6198 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 6199 get system_time; 6200 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 6201 (decr_ticket.flags.INVALID is set)) then 6202 /* it hasn't yet become valid */ 6203 error_out(KRB_AP_ERR_TKT_NYV); 6204 endif 6205 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 6206 error_out(KRB_AP_ERR_TKT_EXPIRED); 6207 endif 6208 if (decr_ticket.transited) then 6209 /* caller may ignore the TRANSITED-POLICY-CHECKED and do 6210 * check anyway */ 6211 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then 6212 if (check_transited_field(decr_ticket.transited) then 6213 error_out(KDC_AP_PATH_NOT_ACCPETED); 6214 endif 6215 endif 6216 endif 6217 /* caller must check decr_ticket.flags for any pertinent details */ 6218 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 6220 A.11. KRB_AP_REP generation 6222 packet.pvno := protocol version; /* 5 */ 6223 packet.msg-type := message type; /* KRB_AP_REP */ 6225 body.ctime := packet.ctime; 6226 body.cusec := packet.cusec; 6227 if (selecting sub-session key) then 6228 select sub-session key; 6229 body.subkey := sub-session key; 6230 endif 6231 if (using sequence numbers) then 6232 select initial sequence number; 6233 body.seq-number := initial sequence; 6234 endif 6236 encode body into OCTET STRING; 6238 select encryption type; 6239 encrypt OCTET STRING into packet.enc-part; 6241 A.12. KRB_AP_REP verification 6243 receive packet; 6244 if (packet.pvno != 5) then 6245 either process using other protocol spec 6246 or error_out(KRB_AP_ERR_BADVERSION); 6247 endif 6248 if (packet.msg-type != KRB_AP_REP) then 6249 error_out(KRB_AP_ERR_MSG_TYPE); 6250 endif 6251 cleartext := decrypt(packet.enc-part) using ticket's session key; 6252 if (decryption_error()) then 6253 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6254 endif 6255 if (cleartext.ctime != authenticator.ctime) then 6256 error_out(KRB_AP_ERR_MUT_FAIL); 6257 endif 6258 if (cleartext.cusec != authenticator.cusec) then 6259 error_out(KRB_AP_ERR_MUT_FAIL); 6260 endif 6261 if (cleartext.subkey is present) then 6262 save cleartext.subkey for future use; 6263 endif 6264 if (cleartext.seq-number is present) then 6265 save cleartext.seq-number for future verifications; 6266 endif 6267 return(AUTHENTICATION_SUCCEEDED); 6269 A.13. KRB_SAFE generation 6271 collect user data in buffer; 6272 /* assemble packet: */ 6273 packet.pvno := protocol version; /* 5 */ 6274 packet.msg-type := message type; /* KRB_SAFE */ 6276 body.user-data := buffer; /* DATA */ 6277 if (using timestamp) then 6278 get system_time; 6279 body.timestamp, body.usec := system_time; 6280 endif 6281 if (using sequence numbers) then 6282 body.seq-number := sequence number; 6283 endif 6284 body.s-address := sender host addresses; 6285 if (only one recipient) then 6286 body.r-address := recipient host address; 6287 endif 6288 checksum.cksumtype := checksum type; 6289 compute checksum over body; 6290 checksum.checksum := checksum value; /* checksum.checksum */ 6291 packet.cksum := checksum; 6292 packet.safe-body := body; 6294 A.14. KRB_SAFE verification 6296 receive packet; 6297 if (packet.pvno != 5) then 6298 either process using other protocol spec 6299 or error_out(KRB_AP_ERR_BADVERSION); 6300 endif 6301 if (packet.msg-type != KRB_SAFE) then 6302 error_out(KRB_AP_ERR_MSG_TYPE); 6303 endif 6304 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 6305 error_out(KRB_AP_ERR_INAPP_CKSUM); 6306 endif 6307 if (safe_priv_common_checks_ok(packet)) then 6308 set computed_checksum := checksum(packet.body); 6309 if (computed_checksum != packet.checksum) then 6310 error_out(KRB_AP_ERR_MODIFIED); 6311 endif 6312 return (packet, PACKET_IS_GENUINE); 6313 else 6314 return common_checks_error; 6315 endif 6317 A.15. KRB_SAFE and KRB_PRIV common checks 6319 if (packet.s-address != O/S_sender(packet)) then 6320 /* O/S report of sender not who claims to have sent it */ 6321 error_out(KRB_AP_ERR_BADADDR); 6322 endif 6323 if ((packet.r-address is present) and 6324 (packet.r-address != local_host_address)) then 6325 /* was not sent to proper place */ 6326 error_out(KRB_AP_ERR_BADADDR); 6327 endif 6328 if (((packet.timestamp is present) and 6329 (not in_clock_skew(packet.timestamp,packet.usec))) or 6330 (packet.timestamp is not present and timestamp expected)) then 6331 error_out(KRB_AP_ERR_SKEW); 6332 endif 6333 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6334 error_out(KRB_AP_ERR_REPEAT); 6335 endif 6337 if (((packet.seq-number is present) and 6338 ((not in_sequence(packet.seq-number)))) or 6339 (packet.seq-number is not present and sequence expected)) then 6340 error_out(KRB_AP_ERR_BADORDER); 6341 endif 6342 if (packet.timestamp not present and packet.seq-number not present) then 6343 error_out(KRB_AP_ERR_MODIFIED); 6344 endif 6346 save_identifier(packet.{timestamp,usec,s-address}, 6347 sender_principal(packet)); 6349 return PACKET_IS_OK; 6351 A.16. KRB_PRIV generation 6353 collect user data in buffer; 6355 /* assemble packet: */ 6356 packet.pvno := protocol version; /* 5 */ 6357 packet.msg-type := message type; /* KRB_PRIV */ 6359 packet.enc-part.etype := encryption type; 6361 body.user-data := buffer; 6362 if (using timestamp) then 6363 get system_time; 6364 body.timestamp, body.usec := system_time; 6365 endif 6366 if (using sequence numbers) then 6367 body.seq-number := sequence number; 6368 endif 6369 body.s-address := sender host addresses; 6370 if (only one recipient) then 6371 body.r-address := recipient host address; 6372 endif 6374 encode body into OCTET STRING; 6376 select encryption type; 6377 encrypt OCTET STRING into packet.enc-part.cipher; 6379 A.17. KRB_PRIV verification 6381 receive packet; 6382 if (packet.pvno != 5) then 6383 either process using other protocol spec 6384 or error_out(KRB_AP_ERR_BADVERSION); 6385 endif 6386 if (packet.msg-type != KRB_PRIV) then 6387 error_out(KRB_AP_ERR_MSG_TYPE); 6388 endif 6390 cleartext := decrypt(packet.enc-part) using negotiated key; 6391 if (decryption_error()) then 6392 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6393 endif 6395 if (safe_priv_common_checks_ok(cleartext)) then 6396 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 6397 else 6398 return common_checks_error; 6399 endif 6401 A.18. KRB_CRED generation 6403 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 6405 /* assemble packet: */ 6406 packet.pvno := protocol version; /* 5 */ 6407 packet.msg-type := message type; /* KRB_CRED */ 6409 for (tickets[n] in tickets to be forwarded) do 6410 packet.tickets[n] = tickets[n].ticket; 6411 done 6413 packet.enc-part.etype := encryption type; 6415 for (ticket[n] in tickets to be forwarded) do 6416 body.ticket-info[n].key = tickets[n].session; 6417 body.ticket-info[n].prealm = tickets[n].crealm; 6418 body.ticket-info[n].pname = tickets[n].cname; 6419 body.ticket-info[n].flags = tickets[n].flags; 6420 body.ticket-info[n].authtime = tickets[n].authtime; 6421 body.ticket-info[n].starttime = tickets[n].starttime; 6422 body.ticket-info[n].endtime = tickets[n].endtime; 6423 body.ticket-info[n].renew-till = tickets[n].renew-till; 6424 body.ticket-info[n].srealm = tickets[n].srealm; 6425 body.ticket-info[n].sname = tickets[n].sname; 6426 body.ticket-info[n].caddr = tickets[n].caddr; 6427 done 6429 get system_time; 6430 body.timestamp, body.usec := system_time; 6432 if (using nonce) then 6433 body.nonce := nonce; 6434 endif 6436 if (using s-address) then 6437 body.s-address := sender host addresses; 6438 endif 6439 if (limited recipients) then 6440 body.r-address := recipient host address; 6441 endif 6443 encode body into OCTET STRING; 6445 select encryption type; 6446 encrypt OCTET STRING into packet.enc-part.cipher 6447 using negotiated encryption key; 6449 A.19. KRB_CRED verification 6451 receive packet; 6452 if (packet.pvno != 5) then 6453 either process using other protocol spec 6454 or error_out(KRB_AP_ERR_BADVERSION); 6455 endif 6456 if (packet.msg-type != KRB_CRED) then 6457 error_out(KRB_AP_ERR_MSG_TYPE); 6458 endif 6460 cleartext := decrypt(packet.enc-part) using negotiated key; 6461 if (decryption_error()) then 6462 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6463 endif 6464 if ((packet.r-address is present or required) and 6465 (packet.s-address != O/S_sender(packet)) then 6466 /* O/S report of sender not who claims to have sent it */ 6467 error_out(KRB_AP_ERR_BADADDR); 6468 endif 6469 if ((packet.r-address is present) and 6470 (packet.r-address != local_host_address)) then 6471 /* was not sent to proper place */ 6472 error_out(KRB_AP_ERR_BADADDR); 6473 endif 6474 if (not in_clock_skew(packet.timestamp,packet.usec)) then 6475 error_out(KRB_AP_ERR_SKEW); 6476 endif 6477 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6478 error_out(KRB_AP_ERR_REPEAT); 6479 endif 6480 if (packet.nonce is required or present) and 6481 (packet.nonce != expected-nonce) then 6482 error_out(KRB_AP_ERR_MODIFIED); 6483 endif 6485 for (ticket[n] in tickets that were forwarded) do 6486 save_for_later(ticket[n],key[n],principal[n], 6487 server[n],times[n],flags[n]); 6488 return 6490 A.20. KRB_ERROR generation 6492 /* assemble packet: */ 6493 packet.pvno := protocol version; /* 5 */ 6494 packet.msg-type := message type; /* KRB_ERROR */ 6496 get system_time; 6497 packet.stime, packet.susec := system_time; 6498 packet.realm, packet.sname := server name; 6500 if (client time available) then 6501 packet.ctime, packet.cusec := client_time; 6502 endif 6503 packet.error-code := error code; 6504 if (client name available) then 6505 packet.cname, packet.crealm := client name; 6506 endif 6507 if (error text available) then 6508 packet.e-text := error text; 6509 endif 6510 if (error data available) then 6511 packet.e-data := error data; 6512 endif 6513 B. Definition of common authorization data elements 6515 This appendix contains the definitions of common authorization data 6516 elements. These common authorization data elements are recursivly defined, 6517 meaning the ad-data for these types will itself contain a sequence of 6518 authorization data whose interpretation is affected by the encapsulating 6519 element. Depending on the meaning of the encapsulating element, the 6520 encapsulated elements may be ignored, might be interpreted as issued 6521 directly by the KDC, or they might be stored in a separate plaintext part of 6522 the ticket. The types of the encapsulating elements are specified as part of 6523 the Kerberos specification because the behavior based on these values should 6524 be understood across implementations whereas other elements need only be 6525 understood by the applications which they affect. 6527 In the definitions that follow, the value of the ad-type for the element 6528 will be specified in the subsection number, and the value of the ad-data 6529 will be as shown in the ASN.1 structure that follows the subsection heading. 6531 B.1. If relevant 6533 AD-IF-RELEVANT AuthorizationData 6535 AD elements encapsulated within the if-relevant element are intended for 6536 interpretation only by application servers that understand the particular 6537 ad-type of the embedded element. Application servers that do not understand 6538 the type of an element embedded within the if-relevant element may ignore 6539 the uninterpretable element. This element promotes interoperability across 6540 implementations which may have local extensions for authorization. 6542 B.2. Intended for server 6544 AD-INTENDED-FOR-SERVER SEQUENCE { 6545 intended-server[0] SEQUENCE OF PrincipalName 6546 elements[1] AuthorizationData 6547 } 6549 AD elements encapsulated within the intended-for-server element may be 6550 ignored if the application server is not in the list of principal names of 6551 intended servers. Further, a KDC issuing a ticket for an application server 6552 can remove this element if the application server is not in the list of 6553 intended servers. 6555 Application servers should check for their principal name in the 6556 intended-server field of this element. If their principal name is not found, 6557 this element should be ignored. If found, then the encapsulated elements 6558 should be evaluated in the same manner as if they were present in the top 6559 level authorization data field. Applications and application servers that do 6560 not implement this element should reject tickets that contain authorization 6561 data elements of this type. 6563 B.3. Intended for application class 6565 AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] 6566 SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements 6567 encapsulated within the intended-for-application-class element may be 6568 ignored if the application server is not in one of the named classes of 6569 application servers. Examples of application server classes include 6570 "FILESYSTEM", and other kinds of servers. 6572 This element and the elements it encapulates may be safely ignored by 6573 applications, application servers, and KDCs that do not implement this 6574 element. 6576 B.4. KDC Issued 6578 AD-KDCIssued SEQUENCE { 6579 ad-checksum[0] Checksum, 6580 i-realm[1] Realm OPTIONAL, 6581 i-sname[2] PrincipalName OPTIONAL, 6582 elements[3] AuthorizationData. 6583 } 6585 ad-checksum 6586 A checksum over the elements field using a cryptographic checksum 6587 method that is identical to the checksum used to protect the ticket 6588 itself (i.e. using the same hash function and the same encryption 6589 algorithm used to encrypt the ticket) and using a key derived from the 6590 same key used to protect the ticket. 6591 i-realm, i-sname 6592 The name of the issuing principal if different from the KDC itself. 6593 This field would be used when the KDC can verify the authenticity of 6594 elements signed by the issuing principal and it allows this KDC to 6595 notify the application server of the validity of those elements. 6596 elements 6597 A sequence of authorization data elements issued by the KDC. 6599 The KDC-issued ad-data field is intended to provide a means for Kerberos 6600 principal credentials to embed within themselves privilege attributes and 6601 other mechanisms for positive authorization, amplifying the priveleges of 6602 the principal beyond what can be done using a credentials without such an 6603 a-data element. 6605 This can not be provided without this element because the definition of the 6606 authorization-data field allows elements to be added at will by the bearer 6607 of a TGT at the time that they request service tickets and elements may also 6608 be added to a delegated ticket by inclusion in the authenticator. 6610 For KDC-issued elements this is prevented because the elements are signed by 6611 the KDC by including a checksum encrypted using the server's key (the same 6612 key used to encrypt the ticket - or a key derived from that key). Elements 6613 encapsulated with in the KDC-issued element will be ignored by the 6614 application server if this "signature" is not present. Further, elements 6615 encapsulated within this element from a ticket granting ticket may be 6616 interpreted by the KDC, and used as a basis according to policy for 6617 including new signed elements within derivative tickets, but they will not 6618 be copied to a derivative ticket directly. If they are copied directly to a 6619 derivative ticket by a KDC that is not aware of this element, the signature 6620 will not be correct for the application ticket elements, and the field will 6621 be ignored by the application server. 6623 This element and the elements it encapulates may be safely ignored by 6624 applications, application servers, and KDCs that do not implement this 6625 element. 6627 B.5. And-Or 6629 AD-AND-OR SEQUENCE { 6630 condition-count[0] INTEGER, 6631 elements[1] AuthorizationData 6632 } 6634 When restrictive AD elements encapsulated within the and-or element are 6635 encountered, only the number specified in condition-count of the 6636 encapsulated conditions must be met in order to satisfy this element. This 6637 element may be used to implement an "or" operation by setting the 6638 condition-count field to 1, and it may specify an "and" operation by setting 6639 the condition count to the number of embedded elements. Application servers 6640 that do not implement this element must reject tickets that contain 6641 authorization data elements of this type. 6643 B.6. Mandatory ticket extensions 6645 AD-Mandatory-Ticket-Extensions SEQUENCE { 6646 te-type[0] INTEGER, 6647 te-checksum[0] Checksum 6648 } 6650 An authorization data element of type mandatory-ticket-extensions specifies 6651 the type and a collision-proof checksum using the same hash algorithm used 6652 to protect the integrity of the ticket itself. This checksum will be 6653 calculated over an individual extension field of the type indicated. If 6654 there are more than one extension, multiple Mandatory-Ticket-Extensions 6655 authorization data elements may be present, each with a checksum for a 6656 different extension field. This restriction indicates that the ticket should 6657 not be accepted if a ticket extension is not present in the ticket for which 6658 the type and checksum do not match that checksum specified in the 6659 authorization data element. Note that although the type is redundant for the 6660 purposes of the comparison, it makes the comparison easier when multiple 6661 extensions are present. Application servers that do not implement this 6662 element must reject tickets that contain authorization data elements of this 6663 type. 6665 B.7. Authorization Data in ticket extensions 6667 AD-IN-Ticket-Extensions Checksum 6669 An authorization data element of type in-ticket-extensions specifies a 6670 collision-proof checksum using the same hash algorithm used to protect the 6671 integrity of the ticket itself. This checksum is calculated over a separate 6672 external AuthorizationData field carried in the ticket extensions. 6673 Application servers that do not implement this element must reject tickets 6674 that contain authorization data elements of this type. Application servers 6675 that do implement this element will search the ticket extensions for 6676 authorization data fields, calculate the specified checksum over each 6677 authorization data field and look for one matching the checksum in this 6678 in-ticket-extensions element. If not found, then the ticket must be 6679 rejected. If found, the corresponding authorization data elements will be 6680 interpreted in the same manner as if they were contained in the top level 6681 authorization data field. 6683 Note that if multiple external authorization data fields are present in a 6684 ticket, each will have a corresponding element of type in-ticket-extensions 6685 in the top level authorization data field, and the external entries will be 6686 linked to the corresponding element by their checksums. 6688 C. Definition of common ticket extensions 6690 This appendix contains the definitions of common ticket extensions. Support 6691 for these extensions is optional. However, certain extensions have 6692 associated authorization data elements that may require rejection of a 6693 ticket containing an extension by application servers that do not implement 6694 the particular extension. Other extensions have been defined beyond those 6695 described in this specification. Such extensions are described elswhere and 6696 for some of those extensions the reserved number may be found in the list of 6697 constants. 6699 It is known that older versions of Kerberos did not support this field, and 6700 that some clients will strip this field from a ticket when they parse and 6701 then reassemble a ticket as it is passed to the application servers. The 6702 presence of the extension will not break such clients, but any functionaly 6703 dependent on the extensions will not work when such tickets are handled by 6704 old clients. In such situations, some implementation may use alternate 6705 methods to transmit the information in the extensions field. 6707 C.1. Null ticket extension 6709 TE-NullExtension OctetString -- The empty Octet String 6711 The te-data field in the null ticket extension is an octet string of lenght 6712 zero. This extension may be included in a ticket granting ticket so that the 6713 KDC can determine on presentation of the ticket granting ticket whether the 6714 client software will strip the extensions field. =20 6716 C.2. External Authorization Data 6718 TE-ExternalAuthorizationData AuthorizationData 6720 The te-data field in the external authorization data ticket extension is 6721 field of type AuthorizationData containing one or more authorization data 6722 elements. If present, a corresponding authorization data element will be 6723 present in the primary authorization data for the ticket and that element 6724 will contain a checksum of the external authorization data ticket extension. 6726 D. Significant changes since RFC 1510 6728 Section 1: The preamble and introduction does not define the protocol, 6729 mention is made in the introduction regarding the ability to rely on the KDC 6730 to check the transited field, and on the inclusion of a flag in a ticket 6731 indicating that this check has occurred. This is a new capability not 6732 present in RFC1510. Pre-existing implementation may ignore or not set this 6733 flag without negative security implications. 6735 The definition of the secret key says that in the case of a user the key may 6736 be derived from a password. In 1510, it said that the key was derived from 6737 the password. This change was made to accommodate situations where the user 6738 key might be stored on a smart-card, or otherwise obtained independent of a 6739 password. 6741 The introduction also mentions the use of public key for initial 6742 authentication in Kerberos by reference. RFC1510 did not include such a 6743 reference. 6745 Section 1.2 was added to explain that while Kerberos provides authentication 6746 of a named principal, it is still the responsibility of the application to 6747 ensure that the authenticated name is the entity with which the application 6748 wishes to communicate. 6750 Section 2: No changes were made to existing options and flags specified in 6751 RFC1510, though text was revised to make the description and intent of 6752 existing options clearer, especially with respect to the ENC-TKT-IN-SKEY 6753 option (now section 2.9.3) which is used for user-to-user authentication. 6754 New options and ticket flags added since RFC1510 include transited policy 6755 checking (section 2.7), anonymous tickets (section 2.8) and name 6756 canonicalization (section since dropped, but flags remain). 6758 Section 3: Added mention of the optional checksum field in the KRB-ERROR 6759 message. Added mention of name canonicalization (since deleted) and 6760 anonymous tickets in exposition on KDC options. Mention of the name 6761 canonicalization case was included in the description of the KDC reply 6762 (3.1.3). A warning regarding generation of session keys for application use 6763 was added, urging the inclusion of key entropy from the KDC generated 6764 session key in the ticket. An example regarding use of the subsession key 6765 was added to section 3.2.6. Descriptions of the pa-etype-info, and 6766 pa-pw-salt preauthentication data items were added. 6768 Changes to section 4: Added language about who has access to the keys in the 6769 Kerberos database. Also made it clear that KDC's may obtain the information 6770 from some database field through other means - for example, one form of 6771 pkinit may extract some of these fields from a certificate. 6773 Section 5: The message specification section has undergone a major rewrite 6774 to eliminate confusion regarding different versions of ASN.1, and to 6775 highlight those areas where the Kerberos protocol does not strictly follow 6776 ASN.1. These are changes to make the description more clear, rather than 6777 changes to the protocol. 6779 Major changes were made to message numbers, providing a clearer 6780 interoperability path for messages that have new optional fields. The 6781 specific additions to these messages are listed specifically elswhere in 6782 this document. 6784 A statement regarding the carrying of unrecognized additional fields in 6785 ASN.1 encoding through in tickets was added (still waiting on some better 6786 text regarding this). 6788 Ticket flags and KDC options were added to support the new functions 6789 described elsewhere in this document. The encoding of the options flags are 6790 now described to be no less than 32 bits, and the smallest number of bits 6791 beyond 32 needed to encode any set bits. It also describes the encoding of 6792 the bitstring as using "unnamed" bits. 6794 An optional ticket extensions field was added to support the carrying of 6795 auxiliary data that allows the passing of auxiliary that is to accompany a 6796 ticket to the verifier. 6798 (Still pending, Tom Yu's request to change the application codes on KDC 6799 message to indicate which minor rev of the protocol - I think this might 6800 break things, but am not sure). 6802 Definition of the PA-USE-SPECIFIED-KVNO preauthentication data field was 6803 added. 6805 The optional e-cksum field was added to the KRB-ERROR message and the e-data 6806 filed was generalized for use in other than the KDC_ERR_PREAUTH_REQUIRED 6807 error. The TypedData structure was defined. Type tags for TypedData are 6808 defined in the same sequence as the PA-DATA type space to avoid confusion 6809 with the use of the PA-DATA namespace previously used for the e-data field 6810 for the KDC_ERR_PREAUTH_REQUIRED error. 6812 Section 6: Section 6 has undergone a major rewrite to more redily convey how 6813 to add new encryption and checksum methods to Kerberos. New encryption 6814 methods were added. Existing methods that are in use have not changed, but 6815 their descriptions have to yield bettwer symmetry with the discussions of 6816 the new methods. 6818 Section 7: Words were added describing the convention that domain based 6819 realm names for newly created realms should be specified as upper case. This 6820 recommendation does not make lower case realm names illegal. Words were 6821 added highlighting that the slash separated components in the X500 style of 6822 realm names is consistent with existing RFC1510 based implementations, but 6823 that it conflicts with the general recommendation of X.500 name 6824 representation specified in RFC2253. 6826 There were suggestions on the list regarding extensions to or new name 6827 types. These require discussion at the IETF meeting. My own feeling at this 6828 point is that in the absence of a strong consensus for adding new types at 6829 this time, I would rather not add new name types in the current draft, but 6830 leave things open for additions later. 6832 Section 8: Since RFC1510, the definition of the TCP transport for Kerberos 6833 messages was added. 6835 Section 9: Requirements for supporting DES3-CBC-SHA1-KD encryption and 6836 HMAC-SHA1-DES3-KD checksums were added. 6838 I would like to make support for Rijndael mandatory and for us to have a 6839 SINGLE standard for use of Rijndale in these revisions. 6841 Y. Deprecated checksum types 6843 Work is still needed on this section. 6845 * More detailed list of differences from RFC 1510, to update 6846 the "Significant changes" appendix. 6847 * Compare specs against actual implementations (e.g., choice of 6848 ivec) and make sure they match. 6850 See end notes for other issues. 6852 -- Ken 2001-11-20 6854 Give me an appendix letter? 6856 This section describes some checksum mechanisms defined in RFC 1510 but 6857 considered deprecated in this specification. While the authors believe the 6858 mechanisms currently in common use have all been included in section 6, 6859 these deprecated mechanisms may still be available in older implementations, 6860 so we include them here, modified to fit the framework outlined in 6. They 6861 are not required for an implementation to be conformant to this 6862 specification. 6864 Y.1. The CRC-32 Checksum (crc32) 6866 The CRC-32 checksum calculates a checksum based on a cyclic redundancy check 6867 as described in ISO 3309 [14]. The resulting checksum is four (4) octets in 6868 length. The CRC-32 is neither keyed nor collision-proof. The use of this 6869 checksum is not recommended. An attacker using a probabilistic 6870 chosen-plaintext attack as described in [13] might be able to generate an 6871 alternative message that satisfies the checksum. The use of collision-proof 6872 checksums is recommended for environments where such attacks represent a 6873 significant threat. 6874 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 6875 get_mic crc32(msg) 6877 verify_mic compute checksum and compare 6878 The crc32 checksum algorithm is assigned a checksum type number of one (1). 6880 Y.2. The RSA MD4 Checksum (rsa-md4) 6882 The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm [15]. 6883 The algorithm takes as input an input message of arbitrary length and 6884 produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to be 6885 collision-proof. 6886 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 6887 get_mic md4(msg) 6889 verify_mic compute checksum and compare 6890 The rsa-md4 checksum algorithm is assigned a checksum type number of two 6891 (2). 6893 Y.3. DES cipher-block chained checksum (des-mac) 6895 The DES-MAC checksum is computed by prepending an 8 octet confounder to the 6896 plaintext, performing a DES CBC-mode encryption on the result using the key 6897 and an initialization vector of zero, taking the last block of the 6898 ciphertext, prepending the same confounder and encrypting the pair using DES 6899 in cipher-block-chaining (CBC) mode using a a variant of the key, where the 6900 variant is computed by eXclusive-ORing the key with the constant 6901 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 6902 checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This 6903 checksum is tamper-proof and collision-proof. The DES specifications 6904 identify some "weak" and "semiweak" keys; those keys shall not be used for 6905 generating DES-MAC checksums for use in Kerberos, nor shall a key be used 6906 whose veriant is "weak" or "semi-weak". 6907 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 6908 cryptosystem 6909 get_mic des-cbc(key XOR F0F0F0F0F0F0F0F0, 6910 confounder | des-mac(key, confounder | msg, ivec=0), 6911 ivec=0) 6913 verify_mic decrypt, compute DES MAC using confounder, compare 6914 The des-mac checksum algorithm is assigned a checksum type number of four 6915 (4). 6917 Y.4. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k) 6919 The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by 6920 applying the RSA MD4 checksum algorithm and encrypting the results using DES 6921 in cipherblock-chaining (CBC) mode using a DES key as both key and 6922 initialization vector. The resulting checksum is 16 octets long. This 6923 checksum is tamper-proof and believed to be collision-proof. Note that this 6924 checksum type is the old method for encoding the RSA-MD4-DES checksum and it 6925 is no longer recommended. 6926 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 6927 get_mic des-cbc(key, md4(msg), ivec=key) 6929 verify_mic compute CRC-32 and compare 6930 The rsa-md4-des-k checksum algorithm is assigned a checksum type number of 6931 six (6). 6933 Y.5. DES cipher-block chained checksum alternative (des-mac-k) 6935 The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption 6936 of the plaintext, and using the last block of the ciphertext as the checksum 6937 value. It is keyed with an encryption key and an initialization vector; any 6938 uses which do not specify an additional initialization vector will use the 6939 key as both key and initialization vector. The resulting checksum is 64 bits 6940 (8 octets) long. This checksum is tamper-proof and collision-proof. Note 6941 that this checksum type is the old method for encoding the DESMAC checksum 6942 and it is no longer recommended. The DES specifications identify some "weak 6943 keys"; those keys shall not be used for generating DES-MAC checksums for use 6944 in Kerberos. 6945 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 6946 get_mic des-mac(key, msg, ivec=key or given) 6948 verify_mic compute MAC and compare 6949 The des-mac-k checksum algorithm is assigned a checksum type number of five 6950 (5). 6952 Appendix Z. Test Vectors 6954 This section provides test vectors for various functions defined or 6955 described in section 6. For convenience, most inputs are ASCII strings, 6956 though some UTF-8 samples should be provided for string-to-key functions. 6957 Keys and other binary data are specified as hexadecimal strings. 6959 Z.1. n-fold 6961 The n-fold function is defined in section 6.4. As noted there, the sample 6962 vector in the original paper defining the algorithm appears to be incorrect. 6963 Here are values provided by Marc Horowitz: 6965 64-fold("012345") = 6966 64-fold(303132333435) = be072631276b1955 6968 56-fold("password") = 6969 56-fold(70617373776f7264) = 78a07b6caf85fa 6971 64-fold("Rough Consensus, and Running Code") = 6972 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 6973 6e696e6720436f6465) = bb6ed30870b7f0e0 6975 168-fold("password") = 6976 168-fold(70617373776f7264) = 6977 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 6979 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 6980 192-fold(4d41535341434856534554545320494e5354495456544520 6981 4f4620544543484e4f4c4f4759) = 6982 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 6984 Z.2. mit_des_string_to_key 6986 The function mit_des_string_to_key is defined in section 6.5.2. We present 6987 here several test values, with some of the intermediate results. The fourth 6988 test demonstrates the use of UTF-8 with three characters. The last two tests 6989 are specifically constructed so as to trigger the weak-key fixups for the 6990 intermediate key produced by fan-folding; we have no test cases that cause 6991 such fixups for the final key. 6993 UTF-8 encodings: 6994 eszett C3 9F 6995 s-caron C5 A1 6996 c-acute C4 87 6998 Test vector: 7000 salt: "ATHENA.MIT.EDUraeburn" 415448454e412e4d49542e4544557261656275726e 7001 password: "password" 70617373776f7264 7002 fan-fold result: c01e38688ac86c2e 7003 intermediate key: c11f38688ac86d2f 7004 DES key: cbc22fae235298e3 7006 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 7007 password: "potatoe" 706f7461746f65 7008 fan-fold result: a028944ee63c0416 7009 intermediate key: a129944fe63d0416 7010 DES key: df3d32a74fd92a01 7011 salt: "EXAMPLE.COMbuckaroo" 4558414d504c452e434f4d6275636b61726f6f 7012 password: "penny" 70656e6e79 7013 fan-fold result: 96d2d87e925c64ee 7014 intermediate key: 97d3d97f925d64ef 7015 DES key: 9443a2e532fdc4f1 7017 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 7018 415448454e412e4d49542e4544554a757269c5a169c487 7019 password: eszett c39f 7020 fan-fold result: b8f6c40e305afc9e 7021 intermediate key: b9f7c40e315bfd9e 7022 DES key: 62c81a5232b5e69d 7024 salt: "AAAAAAAA" 4141414141414141 7025 password: "11119999" 3131313139393939 7026 fan-fold result: e0e0e0e0f0f0f0f0 7027 intermediate key: e0e0e0e0f1f1f101 7028 DES key: 984054d0f1a73e31 7030 salt: "FFFFAAAA" 4646464641414141 7031 password: "NNNN6666" 4e4e4e4e36363636 7032 fan-fold result: 1e1e1e1e0e0e0e0e 7033 intermediate key: 1f1f1f1f0e0e0efe 7034 DES key: c4bf6b25adf7a4f8 7036 Z.3. DES3 DR and DK 7038 These tests show the derived-random and derived-key values for the 7039 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions defined 7040 in section 6.5.5. The input keys were randomly generated; the usage values 7041 are ones actually used by Kerberos. 7043 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 7044 usage: 0000000155 7045 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 7046 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 7048 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 7049 usage: 00000001aa 7050 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 7051 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 7053 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 7054 usage: 0000000155 7055 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 7056 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 7058 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 7059 usage: 00000001aa 7060 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 7061 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 7063 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 7064 usage: 6b65726265726f73 7065 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 7066 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 7068 key: b55e983467e551b3e5d0e5b6c80d45769423a873dc62b30e 7069 usage: 636f6d62696e65 7070 DR: 0127398bacc81a2a62bc45f8d4c151bbcdd5cb788a 7071 DK: 0126388aadc81a1f2a62bc45f8d5c19151bacdd5cb798a3e 7072 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 7073 usage: 0000000155 7074 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 7075 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 7077 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 7078 usage: 00000001aa 7079 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 7080 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 7082 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 7083 usage: 0000000155 7084 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 7085 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 7087 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 7088 usage: 00000001aa 7089 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 7090 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 7092 Z.4. DES3string_to_key 7094 These are the keys generated for some of the above input strings for 7095 triple-DES with key derivation as defined in section 6.5.5. 7097 salt: "ATHENA.MIT.EDUraeburn" 7098 passwd: "password" 7099 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 7101 salt: "WHITEHOUSE.GOVdanny" 7102 passwd: "potatoe" 7103 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 7105 salt: "EXAMPLE.COMbuckaroo" 7106 passwd: "penny" 7107 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 7109 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 7110 passwd: eszett 7111 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 7113 Z.5. DES3 combine-keys 7115 PLACEHOLDER FOR NEW DATA 7116 ------------------------------------------------------------------------ 7118 Footnotes: 7120 TM 7121 Project Athena, Athena, and Kerberos are trademarks of the 7122 Massachusetts Institute of Technology (MIT). No commercial use of these 7123 trademarks may be made without prior written permission of MIT. 7125 1.1 7126 Note, however, that many applications use Kerberos' functions only upon 7127 the initiation of a stream-based network connection. Unless an 7128 application subsequently provides integrity protection for the data 7129 stream, the identity verification applies only to the initiation of the 7130 connection, and does not guarantee that subsequent messages on the 7131 connection originate from the same principal. 7133 1.2 7134 Secret and private are often used interchangeably in the literature. In 7135 our usage, it takes two (or more) to share a secret, thus a shared DES 7136 key is a secret key. Something is only private when no one but its 7137 owner knows it. Thus, in public key cryptosystems, one has a public and 7138 a private key. 7140 1.3 7141 Of course, with appropriate permission the client could arrange 7142 registration of a separately-named principal in a remote realm, and 7143 engage in normal exchanges with that realm's services. However, for 7144 even small numbers of clients this becomes cumbersome, and more 7145 automatic methods as described here are necessary. 7147 2.1 7148 Though it is permissible to request or issue tick- ets with no network 7149 addresses specified. 7151 2.2 7152 It is important that the KDC be sent the name as typed by the user, and 7153 not only the canonical form of the name. If the domain name system was 7154 used to find the canonical name on the client side, the mapping is 7155 vulnerable. 7156 3.1 7157 The password-changing request must not be honored unless the requester 7158 can provide the old password (the user's current secret key). 7159 Otherwise, it would be possible for someone to walk up to an unattended 7160 session and change another user's password. 7162 3.2 7163 To authenticate a user logging on to a local system, the credentials 7164 obtained in the AS exchange may first be used in a TGS exchange to 7165 obtain credentials for a local server. Those credentials must then be 7166 verified by a local server through successful completion of the 7167 Client/Server exchange. 7169 3.3 7170 "Random" means that, among other things, it should be impossible to 7171 guess the next session key based on knowledge of past session keys. 7172 This can only be achieved in a pseudo-random number generator if it is 7173 based on cryptographic principles. It is more desirable to use a truly 7174 random number generator, such as one based on measurements of random 7175 physical phenomena. 7177 3.4 7178 Tickets contain both an encrypted and unencrypted portion, so cleartext 7179 here refers to the entire unit, which can be copied from one message 7180 and replayed in another without any cryptographic skill. 7182 3.5 7183 Note that this can make applications based on unreliable transports 7184 difficult to code correctly. If the transport might deliver duplicated 7185 messages, either a new authenticator must be generated for each retry, 7186 or the application server must match requests and replies and replay 7187 the first reply in response to a detected duplicate. 7189 3.6 7190 This allows easy implementation of user-to-user authentication [8], 7191 which uses ticket-granting ticket session keys in lieu of secret server 7192 keys in situations where such secret keys could be easily compromised. 7194 3.7 7195 Note also that the rejection here is restricted to authenticators from the 7196 same principal to the same server. Other client principals communicating 7197 with the same server principal should not be have their authenticators 7198 rejected if the time and microsecond fields happen to match some other 7199 client's authenticator. 7201 3.8 7202 If this is not done, an attacker could subvert the authentication by 7203 recording the ticket and authenticator sent over the network to a 7204 server and replaying them following an event that caused the server to 7205 lose track of recently seen authenticators. 7207 3.9 7208 In the Kerberos version 4 protocol, the timestamp in the reply was the 7209 client's timestamp plus one. This is not necessary in version 5 because 7210 version 5 messages are formatted in such a way that it is not possible 7211 to create the reply by judicious message surgery (even in encrypted 7212 form) without knowledge of the appropriate encryption keys. 7214 3.10 7215 Note that for encrypting the KRB_AP_REP message, the sub-session key is 7216 not used, even if present in the Authenticator. 7218 3.11 7219 Implementations of the protocol may wish to provide routines to choose 7220 subkeys based on session keys and random numbers and to generate a 7221 negotiated key to be returned in the KRB_AP_REP message. 7223 3.12 7224 This can be accomplished in several ways. It might be known beforehand 7225 (since the realm is part of the principal identifier), it might be stored in 7226 a nameserver, or it might be obtained from a configuration file. If the 7227 realm to be used is obtained from a nameserver, there is a danger of being 7228 spoofed if the nameservice providing the realm name is not authenticated. 7229 This might result in the use of a realm which has been compromised, and 7230 would result in an attacker's ability to compromise the authentication of 7231 the application server to the client. 7233 3.13 7234 If the client selects a sub-session key, care must be taken to ensure 7235 the randomness of the selected sub-session key. One approach would be 7236 to generate a random number and XOR it with the session key from the 7237 ticket-granting ticket. 7239 4.1 7240 The implementation of the Kerberos server need not combine the database 7241 and the server on the same machine; it is feasible to store the 7242 principal database in, say, a network name service, as long as the 7243 entries stored therein are protected from disclosure to and 7244 modification by unauthorized parties. However, we recommend against 7245 such strategies, as they can make system management and threat analysis 7246 quite complex. 7248 4.2 7249 See the discussion of the padata field in section 5.4.2 for details on 7250 why this can be useful. 7252 6.1 7253 While Message Authentication Code (MAC) or Message Integrity Check 7254 (MIC) would be more appropriate terms for many of the uses in this 7255 section, we continue to use the term "checksum" for historical reasons. 7256 6.2 7257 For example, a pseudo-random number generator may be seeded with a 7258 session key, but to protect the original key from any accidental 7259 weakness in the PRNG, use possibly-known data encrypted or checksummed 7260 using the key rather than using the key directly. Usage numbers in this 7261 reserved range should help avoid accidentally seeding the PRNG with a 7262 value also computed and perhaps exposed to an attacker elsewhere. 7263 6.3 7264 Of course, this does not apply to protocols that do their own 7265 encryption independent of this framework, directly using the key 7266 resulting from the Kerberos authentication exchange. 7267 6.4 7268 It should be noted that the sample vector in Appendix B.2 of the 7269 original paper appears to be incorrect. Two independent implementations 7270 from the specification (one in C by Marc Horowitz, and another in 7271 Scheme by Bill Sommerfeld) agree on a value different from that in 7272 [Blumenthal96]. 7273 6.5 7274 Some problematic assumptions we've seen, and sometimes made, include: 7275 that a random bitstring is always valid as a key (not true for DES keys 7276 with parity); that the basic block encryption chaining mode provides no 7277 integrity checking, or can easily be separated from such checking (not 7278 true for many modes in development that do both simultaneously); that a 7279 checksum for a message always results in the same value (not true if a 7280 confounder is incorporated); that an initial vector is used (may not be 7281 true if a block cipher in CBC mode is not in use); that the key is a 7282 clever thing to use as the initial vector for CBC mode encryption (not 7283 true @@REF Bellovin paper). 7284 6.6 7285 Perhaps one of the more common reasons for directly performing 7286 encryption is direct control over the negotiation and to select a 7287 "sufficiently strong" encryption algorithm (whatever that means in the 7288 context of a given application). While Kerberos directly provides no 7289 facility for negotiating encryption types between the application 7290 client and server, there are other means for accomplishing similar 7291 goals. For example, requesting only "strong" session key types from the 7292 KDC, and assuming that the type actually returned by the KDC will be 7293 understood and supported by the application server.