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