idnits 2.17.1 draft-ietf-cat-kerberos-revisions-07.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. ** Bad filename characters: the document name given in the document, 'draft-ietf-cat-kerberos-revisions-07.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-cat-kerberos-revisions-07.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-cat-kerberos-revisions-07.txt.', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-cat-kerberos-revisions-07.txt.', but the file name used is 'draft-ietf-cat-kerberos-revisions-07' ** 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 57 longer pages, the longest (page 13) 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 1612 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 2006: '... extensions[4] TicketExtensions OPTIONAL...' RFC 2119 keyword, line 2017: '... starttime[6] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2019: '... renew-till[8] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2020: '... caddr[9] HostAddresses OPTIONAL,...' RFC 2119 keyword, line 2021: '... authorization-data[10] AuthorizationData OPTIONAL...' (65 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 2964 has weird spacing: '... future expan...' == Line 2968 has weird spacing: '... option indi...' == Line 2970 has weird spacing: '... in the sessi...' == Line 2971 has weird spacing: '... key from ...' == Line 2972 has weird spacing: '... is not speci...' == (26 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 24, 2001) is 8374 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'JBrezak' is mentioned on line 3519, but not defined -- Looks like a reference, but probably isn't: '18' on line 1447 -- Looks like a reference, but probably isn't: '19' on line 1459 -- Looks like a reference, but probably isn't: '20' on line 1535 -- Looks like a reference, but probably isn't: '0' on line 5378 -- Looks like a reference, but probably isn't: '1' on line 5362 -- Looks like a reference, but probably isn't: '23' on line 1960 == Missing Reference: 'APPLICATION 1' is mentioned on line 2001, but not defined -- Looks like a reference, but probably isn't: '2' on line 5312 -- Looks like a reference, but probably isn't: '3' on line 5313 -- Looks like a reference, but probably isn't: '4' on line 3271 == Missing Reference: 'APPLICATION 3' is mentioned on line 2010, but not defined -- Looks like a reference, but probably isn't: '5' on line 3272 -- Looks like a reference, but probably isn't: '6' on line 3273 -- Looks like a reference, but probably isn't: '7' on line 3274 -- Looks like a reference, but probably isn't: '8' on line 5637 -- Looks like a reference, but probably isn't: '9' on line 3276 -- Looks like a reference, but probably isn't: '10' on line 3277 -- Looks like a reference, but probably isn't: '24' on line 2238 == Missing Reference: 'APPLICATION 2' is mentioned on line 2348, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2420, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2421, but not defined -- Looks like a reference, but probably isn't: '11' on line 3278 -- Looks like a reference, but probably isn't: '25' on line 2783 == Missing Reference: 'APPLICATION 11' is mentioned on line 2837, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 2838, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 2852, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 2937, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 2998, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 3056, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 3125, but not defined -- Looks like a reference, but probably isn't: '32' on line 3146 == Missing Reference: 'APPLICATION 22' is mentioned on line 3171, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 3177, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 3266, but not defined -- Looks like a reference, but probably isn't: '12' on line 3279 -- Looks like a reference, but probably isn't: '13' on line 3280 -- Looks like a reference, but probably isn't: '33' on line 3386 == Missing Reference: 'RFC 1779' is mentioned on line 3482, but not defined ** Obsolete undefined reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) == Missing Reference: 'Raeburn' is mentioned on line 3519, but not defined == Missing Reference: 'Westerlund' is mentioned on line 3624, but not defined == Missing Reference: 'RFC1883' is mentioned on line 3570, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Missing Reference: 'RFC1884' is mentioned on line 3571, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Missing Reference: 'Danielsson' is mentioned on line 3624, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 3825, 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 3853 == Unused Reference: 'DS90' is defined on line 4057, but no explicit reference was found in the text == Unused Reference: 'DES77' is defined on line 4074, but no explicit reference was found in the text == Unused Reference: 'DESM80' is defined on line 4079, but no explicit reference was found in the text == Unused Reference: 'SG92' is defined on line 4084, but no explicit reference was found in the text == Unused Reference: 'IS3309' is defined on line 4089, but no explicit reference was found in the text == Unused Reference: 'MD4-92' is defined on line 4094, but no explicit reference was found in the text == Unused Reference: 'MD5-92' is defined on line 4098, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 4102, but no explicit reference was found in the text == Unused Reference: 'Horowitz96' is defined on line 4106, but no explicit reference was found in the text == Unused Reference: 'HorowitzB96' is defined on line 4110, but no explicit reference was found in the text == Unused Reference: 'Krawczyk96' is defined on line 4113, but no explicit reference was found in the text == Unused Reference: 'TM' is defined on line 5582, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NT94' -- Possible downref: Non-RFC (?) normative reference: ref. 'MNSS87' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'KNT92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Neu93' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS90' -- Possible downref: Non-RFC (?) normative reference: ref. 'LGDSR87' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-88' ** Downref: Normative reference to an Not Issued RFC: RFC 26 (ref. 'Pat92') -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS3309' ** Obsolete normative reference: RFC 1320 (ref. 'MD4-92') (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5-92') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'KBC96') -- 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' -- 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-ietf-ipsec-hmac-md5 is not up-to-date. The last update was unsuccessful) -- Duplicate reference: draft-ietf-ipsec-hmac-md5, mentioned in 'Krawczyk96', was also mentioned in 'KBC96'. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'Krawczyk96') -- Possible downref: Non-RFC (?) normative reference: ref. 'TM' Summary: 21 errors (**), 1 flaw (~~), 48 warnings (==), 47 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 November 24, 2000 5 Expires May 24, 2001 7 The Kerberos Network Authentication Service (V5) 9 draft-ietf-cat-kerberos-revisions-07.txt. 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. Internet-Drafts are working documents 15 of the Internet Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet-Drafts as reference material or to cite them 22 other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 33 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 35 The distribution of this memo is unlimited. It is filed as 36 draft-ietf-cat-kerberos-revisions-07.txt, and expires May 24, 2001. 37 Please send comments to: ietf-krb-wg@anl.gov 39 ABSTRACT 41 This document provides an overview and specification of Version 5 of the 42 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 43 and its intended use that require more detailed or clearer explanation than 44 was provided in RFC1510. This document is intended to provide a detailed 45 description of the protocol, suitable for implementation, together with 46 descriptions of the appropriate use of protocol messages and fields within 47 those messages. 49 This document is not intended to describe Kerberos to the end user, system 50 administrator, or application developer. Higher level papers describing 51 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 52 are available elsewhere. 54 OVERVIEW 56 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 57 network authentication system is based. It also specifies Version 5 of the 58 Kerberos protocol. 60 The motivations, goals, assumptions, and rationale behind most design 61 decisions are treated cursorily; they are more fully described in a paper 62 available in IEEE communications [NT94] and earlier in the Kerberos portion 63 of the Athena Technical Plan [MNSS87]. The protocols have been a proposed 64 standard and are being considered for advancement for draft standard through 65 the IETF standard process. Comments are encouraged on the presentation, but 66 only minor refinements to the protocol as implemented or extensions that fit 67 within current protocol framework will be considered at this time. 69 Requests for addition to an electronic mailing list for discussion of 70 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. 71 This mailing list is gatewayed onto the Usenet as the group 72 comp.protocols.kerberos. Requests for further information, including 73 documents and code availability, may be sent to info-kerberos@MIT.EDU. 75 BACKGROUND 77 The Kerberos model is based in part on Needham and Schroeder's trusted 78 third-party authentication protocol [NS78] and on modifications suggested by 79 Denning and Sacco [DS81]. The original design and implementation of Kerberos 80 Versions 1 through 4 was the work of two former Project Athena staff 81 members, Steve Miller of Digital Equipment Corporation and Clifford Neuman 82 (now at the Information Sciences Institute of the University of Southern 83 California), along with Jerome Saltzer, Technical Director of Project 84 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members 85 of Project Athena have also contributed to the work on Kerberos. 87 Version 5 of the Kerberos protocol (described in this document) has evolved 88 from Version 4 based on new requirements and desires for features not 89 available in Version 4. The design of Version 5 of the Kerberos protocol was 90 led by Clifford Neuman and John Kohl with much input from the community. The 91 development of the MIT reference implementation was led at MIT by John Kohl 92 and Theodore T'so, with help and contributed code from many others. Since 93 RFC1510 was issued, extensions and revisions to the protocol have been 94 proposed by many individuals. Some of these proposals are reflected in this 95 document. Where such changes involved significant effort, the document cites 96 the contribution of the proposer. 98 Reference implementations of both version 4 and version 5 of Kerberos are 99 publicly available and commercial implementations have been developed and 100 are widely used. Details on the differences between Kerberos Versions 4 and 101 5 can be found in [KNT92]. 103 1. Introduction 105 Kerberos provides a means of verifying the identities of principals, (e.g. a 106 workstation user or a network server) on an open (unprotected) network. This 107 is accomplished without relying on assertions by the host operating system, 108 without basing trust on host addresses, without requiring physical security 109 of all the hosts on the network, and under the assumption that packets 110 traveling along the network can be read, modified, and inserted at 111 will[1.1]. Kerberos performs authentication under these conditions as a 112 trusted third-party authentication service by using conventional (shared 113 secret key [1.2]) cryptography. Kerberos extensions described in [PKINIT 114 reference as RFC] provide for the use of public key cryptography during 115 certain phases of the authentication protocol. These extensions allow 116 authentication of users registered with public key certification 117 authorities, and provide certain benefits of public key cryptography in 118 situations where they are needed. 120 The basic Kerberos authentication process proceeds as follows: A client 121 sends a request to the authentication server (AS) requesting 'credentials' 122 for a given server. The AS responds with these credentials, encrypted in the 123 client's key. The credentials consist of 1) a 'ticket' for the server and 2) 124 a temporary encryption key (often called a "session key"). The client 125 transmits the ticket (which contains the client's identity and a copy of the 126 session key, all encrypted in the server's key) to the server. The session 127 key (now shared by the client and server) is used to authenticate the 128 client, and may optionally be used to authenticate the server. It may also 129 be used to encrypt further communication between the two parties or to 130 exchange a separate sub-session key to be used to encrypt further 131 communication. 133 Implementation of the basic protocol consists of one or more authentication 134 servers running on physically secure hosts. The authentication servers 135 maintain a database of principals (i.e., users and servers) and their secret 136 keys. Code libraries provide encryption and implement the Kerberos protocol. 137 In order to add authentication to its transactions, a typical network 138 application adds one or two calls to the Kerberos library directly or 139 through the Generic Security Services Application Programming Interface, 140 GSSAPI, described in separate document [ref to GSSAPI RFC]. These calls 141 result in the transmission of the necessary messages to achieve 142 authentication. 144 The Kerberos protocol consists of several sub-protocols (or exchanges). 145 There are two basic methods by which a client can ask a Kerberos server for 146 credentials. In the first approach, the client sends a cleartext request for 147 a ticket for the desired server to the AS. The reply is sent encrypted in 148 the client's secret key. Usually this request is for a ticket-granting 149 ticket (TGT) which can later be used with the ticket-granting server (TGS). 150 In the second method, the client sends a request to the TGS. The client uses 151 the TGT to authenticate itself to the TGS in the same manner as if it were 152 contacting any other application server that requires Kerberos 153 authentication. The reply is encrypted in the session key from the TGT. 154 Though the protocol specification describes the AS and the TGS as separate 155 servers, they are implemented in practice as different protocol entry points 156 within a single Kerberos server. 158 Once obtained, credentials may be used to verify the identity of the 159 principals in a transaction, to ensure the integrity of messages exchanged 160 between them, or to preserve privacy of the messages. The application is 161 free to choose whatever protection may be necessary. 163 To verify the identities of the principals in a transaction, the client 164 transmits the ticket to the application server. Since the ticket is sent "in 165 the clear" (parts of it are encrypted, but this encryption doesn't thwart 166 replay) and might be intercepted and reused by an attacker, additional 167 information is sent to prove that the message originated with the principal 168 to whom the ticket was issued. This information (called the authenticator) 169 is encrypted in the session key, and includes a timestamp. The timestamp 170 proves that the message was recently generated and is not a replay. 171 Encrypting the authenticator in the session key proves that it was generated 172 by a party possessing the session key. Since no one except the requesting 173 principal and the server know the session key (it is never sent over the 174 network in the clear) this guarantees the identity of the client. 176 The integrity of the messages exchanged between principals can also be 177 guaranteed using the session key (passed in the ticket and contained in the 178 credentials). This approach provides detection of both replay attacks and 179 message stream modification attacks. It is accomplished by generating and 180 transmitting a collision-proof checksum (elsewhere called a hash or digest 181 function) of the client's message, keyed with the session key. Privacy and 182 integrity of the messages exchanged between principals can be secured by 183 encrypting the data to be passed using the session key contained in the 184 ticket or the sub-session key found in the authenticator. 186 The authentication exchanges mentioned above require read-only access to the 187 Kerberos database. Sometimes, however, the entries in the database must be 188 modified, such as when adding new principals or changing a principal's key. 189 This is done using a protocol between a client and a third Kerberos server, 190 the Kerberos Administration Server (KADM). There is also a protocol for 191 maintaining multiple copies of the Kerberos database. Neither of these 192 protocols are described in this document. 194 1.1. Cross-realm operation 196 The Kerberos protocol is designed to operate across organizational 197 boundaries. A client in one organization can be authenticated to a server in 198 another. Each organization wishing to run a Kerberos server establishes its 199 own 'realm'. The name of the realm in which a client is registered is part 200 of the client's name, and can be used by the end-service to decide whether 201 to honor a request. 203 By establishing 'inter-realm' keys, the administrators of two realms can 204 allow a client authenticated in the local realm to prove its identity to 205 servers in other realms[1.3]. The exchange of inter-realm keys (a separate 206 key may be used for each direction) registers the ticket-granting service of 207 each realm as a principal in the other realm. A client is then able to 208 obtain a ticket-granting ticket for the remote realm's ticket-granting 209 service from its local realm. When that ticket-granting ticket is used, the 210 remote ticket-granting service uses the inter-realm key (which usually 211 differs from its own normal TGS key) to decrypt the ticket-granting ticket, 212 and is thus certain that it was issued by the client's own TGS. Tickets 213 issued by the remote ticket-granting service will indicate to the 214 end-service that the client was authenticated from another realm. 216 A realm is said to communicate with another realm if the two realms share an 217 inter-realm key, or if the local realm shares an inter-realm key with an 218 intermediate realm that communicates with the remote realm. An 219 authentication path is the sequence of intermediate realms that are 220 transited in communicating from one realm to another. 222 Realms are typically organized hierarchically. Each realm shares a key with 223 its parent and a different key with each child. If an inter-realm key is not 224 directly shared by two realms, the hierarchical organization allows an 225 authentication path to be easily constructed. If a hierarchical organization 226 is not used, it may be necessary to consult a database in order to construct 227 an authentication path between realms. 229 Although realms are typically hierarchical, intermediate realms may be 230 bypassed to achieve cross-realm authentication through alternate 231 authentication paths (these might be established to make communication 232 between two realms more efficient). It is important for the end-service to 233 know which realms were transited when deciding how much faith to place in 234 the authentication process. To facilitate this decision, a field in each 235 ticket contains the names of the realms that were involved in authenticating 236 the client. 238 The application server is ultimately responsible for accepting or rejecting 239 authentication and should check the transited field. The application server 240 may choose to rely on the KDC for the application server's realm to check 241 the transited field. The application server's KDC will set the 242 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 243 realms may also check the transited field as they issue 244 ticket-granting-tickets for other realms, but they are encouraged not to do 245 so. A client may request that the KDC's not check the transited field by 246 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 247 required to honor this flag. 249 1.2. Choosing a principal with which to communicate 251 The Kerberos protocol provides the means for verifying (subject to the 252 assumptions in 1.4) that the entity with which one communicates is the same 253 entity that was registered with the KDC using the claimed identity 254 (principal name). It is still necessary to determine whether that identity 255 corresponds to the entity with which one intends to communicate. 257 When appropriate data has been exchanged in advance, this determination may 258 be performed syntactically by the application based on the application 259 protocol specification, information provided by the user, and configuration 260 files. For example, the server principal name (including realm) for a telnet 261 server might be derived from the user specified host name (from the telnet 262 command line), the "host/" prefix specified in the application protocol 263 specification, and a mapping to a Kerberos realm derived syntactically from 264 the domain part of the specified hostname and information from the local 265 Kerberos realms database. 267 One can also rely on trusted third parties to make this determination, but 268 only when the data obtained from the third party is suitably integrity 269 protected wile resident on the third party server and when transmitted. 270 Thus, for example, one should not rely on an unprotected domain name system 271 record to map a host alias to the primary name of a server, accepting the 272 primary name as the party one intends to contact since an attacker can 273 modify the mapping and impersonate the party with which one intended to 274 communicate. 276 If a Kerberos server supports name canonicalization, it may be relied upon 277 as a third party to aid in this determination. When utilizing the name 278 canonicalization function provided by the Kerberos server, a client, having 279 already located the instance of a service it wishes to contact, makes a 280 request to the KDC using the server's name information as specified by the 281 user. The Kerberos server will attempt to locate a service principal in its 282 database that corresponds to the requested name and return a ticket for the 283 appropriate server principal to the client. If the KDC determines that the 284 correct server principal is registered in another realm, the KDC will 285 provide a referral to the Kerberos realm that is known to contain the 286 requested service principal. The name canonicalization function supports 287 identity mapping only, and it may not be used as a general name service to 288 locate service instances. There is no guarantee that the returned server 289 principal name (identity) will embed the name of the host on which the 290 server resides. 292 1.3. Authorization 294 As an authentication service, Kerberos provides a means of verifying the 295 identity of principals on a network. Authentication is usually useful 296 primarily as a first step in the process of authorization, determining 297 whether a client may use a service, which objects the client is allowed to 298 access, and the type of access allowed for each. Kerberos does not, by 299 itself, provide authorization. Possession of a client ticket for a service 300 provides only for authentication of the client to that service, and in the 301 absence of a separate authorization procedure, it should not be considered 302 by an application as authorizing the use of that service. 304 Such separate authorization methods may be implemented as application 305 specific access control functions and may utilize files on the application 306 server, or on separately issued authorization credentials such as those 307 based on proxies [Neu93], or on other authorization services. Separately 308 authenticated authorization credentials may be embedded in a tickets 309 authorization data when encapsulated by the kdc-issued authorization data 310 element. 312 Applications should not accept the mere issuance of a service ticket by the 313 Kerberos server (even by a modified Kerberos server) as granting authority 314 to use the service, since such applications may become vulnerable to the 315 bypass of this authorization check in an environment if they interoperate 316 with other KDCs or where other options for application authentication (e.g. 317 the PKTAPP proposal) are provided. 319 1.4. Environmental assumptions 321 Kerberos imposes a few assumptions on the environment in which it can 322 properly function: 324 * 'Denial of service' attacks are not solved with Kerberos. There are 325 places in the protocols where an intruder can prevent an application 326 from participating in the proper authentication steps. Detection and 327 solution of such attacks (some of which can appear to be not-uncommon 328 'normal' failure modes for the system) is usually best left to the 329 human administrators and users. 330 * Principals must keep their secret keys secret. If an intruder somehow 331 steals a principal's key, it will be able to masquerade as that 332 principal or impersonate any server to the legitimate principal. 334 * 'Password guessing' attacks are not solved by Kerberos. If a user 335 chooses a poor password, it is possible for an attacker to successfully 336 mount an offline dictionary attack by repeatedly attempting to decrypt, 337 with successive entries from a dictionary, messages obtained which are 338 encrypted under a key derived from the user's password. 339 * Each host on the network must have a clock which is 'loosely 340 synchronized' to the time of the other hosts; this synchronization is 341 used to reduce the bookkeeping needs of application servers when they 342 do replay detection. The degree of "looseness" can be configured on a 343 per-server basis, but is typically on the order of 5 minutes. If the 344 clocks are synchronized over the network, the clock synchronization 345 protocol must itself be secured from network attackers. 346 * Principal identifiers are not recycled on a short-term basis. A typical 347 mode of access control will use access control lists (ACLs) to grant 348 permissions to particular principals. If a stale ACL entry remains for 349 a deleted principal and the principal identifier is reused, the new 350 principal will inherit rights specified in the stale ACL entry. By not 351 re-using principal identifiers, the danger of inadvertent access is 352 removed. 354 1.5. Glossary of terms 356 Below is a list of terms used throughout this document. 358 Authentication 359 Verifying the claimed identity of a principal. 360 Authentication header 361 A record containing a Ticket and an Authenticator to be presented to a 362 server as part of the authentication process. 363 Authentication path 364 A sequence of intermediate realms transited in the authentication 365 process when communicating from one realm to another. 366 Authenticator 367 A record containing information that can be shown to have been recently 368 generated using the session key known only by the client and server. 369 Authorization 370 The process of determining whether a client may use a service, which 371 objects the client is allowed to access, and the type of access allowed 372 for each. 373 Capability 374 A token that grants the bearer permission to access an object or 375 service. In Kerberos, this might be a ticket whose use is restricted by 376 the contents of the authorization data field, but which lists no 377 network addresses, together with the session key necessary to use the 378 ticket. 379 Ciphertext 380 The output of an encryption function. Encryption transforms plaintext 381 into ciphertext. 382 Client 383 A process that makes use of a network service on behalf of a user. Note 384 that in some cases a Server may itself be a client of some other server 385 (e.g. a print server may be a client of a file server). 386 Credentials 387 A ticket plus the secret session key necessary to successfully use that 388 ticket in an authentication exchange. 390 KDC 391 Key Distribution Center, a network service that supplies tickets and 392 temporary session keys; or an instance of that service or the host on 393 which it runs. The KDC services both initial ticket and ticket-granting 394 ticket requests. The initial ticket portion is sometimes referred to as 395 the Authentication Server (or service). The ticket-granting ticket 396 portion is sometimes referred to as the ticket-granting server (or 397 service). 398 Kerberos 399 Aside from the 3-headed dog guarding Hades, the name given to Project 400 Athena's authentication service, the protocol used by that service, or 401 the code used to implement the authentication service. 402 Plaintext 403 The input to an encryption function or the output of a decryption 404 function. Decryption transforms ciphertext into plaintext. 405 Principal 406 A named client or server entity that participates in a network 407 communication, with one name that is considered canonical. 408 Principal identifier 409 The canonical name used to uniquely identify each different principal. 410 Seal 411 To encipher a record containing several fields in such a way that the 412 fields cannot be individually replaced without either knowledge of the 413 encryption key or leaving evidence of tampering. 414 Secret key 415 An encryption key shared by a principal and the KDC, distributed 416 outside the bounds of the system, with a long lifetime. In the case of 417 a human user's principal, the secret key may be derived from a 418 password. 419 Server 420 A particular Principal which provides a resource to network clients. 421 The server is sometimes referred to as the Application Server. 422 Service 423 A resource provided to network clients; often provided by more than one 424 server (for example, remote file service). 425 Session key 426 A temporary encryption key used between two principals, with a lifetime 427 limited to the duration of a single login "session". 428 Sub-session key 429 A temporary encryption key used between two principals, selected and 430 exchanged by the principals using the session key, and with a lifetime 431 limited to the duration of a single association. 432 Ticket 433 A record that helps a client authenticate itself to a server; it 434 contains the client's identity, a session key, a timestamp, and other 435 information, all sealed using the server's secret key. It only serves 436 to authenticate a client when presented along with a fresh 437 Authenticator. 439 2. Ticket flag uses and requests 441 Each Kerberos ticket contains a set of flags which are used to indicate 442 attributes of that ticket. Most flags may be requested by a client when the 443 ticket is obtained; some are automatically turned on and off by a Kerberos 444 server as required. The following sections explain what the various flags 445 mean, and gives examples of reasons to use such a flag. 447 2.1. Initial, pre-authenticated, and hardware authenticated tickets 449 The INITIAL flag indicates that a ticket was issued using the AS protocol 450 and not issued based on a ticket-granting ticket. Application servers that 451 want to require the demonstrated knowledge of a client's secret key (e.g. a 452 password-changing program) can insist that this flag be set in any tickets 453 they accept, and thus be assured that the client's key was recently 454 presented to the application client. 456 The PRE-AUTHENT and HW-AUTHENT flags provide additional information about 457 the initial authentication, regardless of whether the current ticket was 458 issued directly (in which case INITIAL will also be set) or issued on the 459 basis of a ticket-granting ticket (in which case the INITIAL flag is clear, 460 but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 461 ticket-granting ticket). 463 2.2. Invalid tickets 465 The INVALID flag indicates that a ticket is invalid. Application servers 466 must reject tickets which have this flag set. A postdated ticket will 467 usually be issued in this form. Invalid tickets must be validated by the KDC 468 before use, by presenting them to the KDC in a TGS request with the VALIDATE 469 option specified. The KDC will only validate tickets after their starttime 470 has passed. The validation is required so that postdated tickets which have 471 been stolen before their starttime can be rendered permanently invalid 472 (through a hot-list mechanism) (see section 3.3.3.1). 474 2.3. Renewable tickets 476 Applications may desire to hold tickets which can be valid for long periods 477 of time. However, this can expose their credentials to potential theft for 478 equally long periods, and those stolen credentials would be valid until the 479 expiration time of the ticket(s). Simply using short-lived tickets and 480 obtaining new ones periodically would require the client to have long-term 481 access to its secret key, an even greater risk. Renewable tickets can be 482 used to mitigate the consequences of theft. Renewable tickets have two 483 "expiration times": the first is when the current instance of the ticket 484 expires, and the second is the latest permissible value for an individual 485 expiration time. An application client must periodically (i.e. before it 486 expires) present a renewable ticket to the KDC, with the RENEW option set in 487 the KDC request. The KDC will issue a new ticket with a new session key and 488 a later expiration time. All other fields of the ticket are left unmodified 489 by the renewal process. When the latest permissible expiration time arrives, 490 the ticket expires permanently. At each renewal, the KDC may consult a 491 hot-list to determine if the ticket had been reported stolen since its last 492 renewal; it will refuse to renew such stolen tickets, and thus the usable 493 lifetime of stolen tickets is reduced. 495 The RENEWABLE flag in a ticket is normally only interpreted by the 496 ticket-granting service (discussed below in section 3.3). It can usually be 497 ignored by application servers. However, some particularly careful 498 application servers may wish to disallow renewable tickets. 500 If a renewable ticket is not renewed by its expiration time, the KDC will 501 not renew the ticket. The RENEWABLE flag is reset by default, but a client 502 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 503 message. If it is set, then the renew-till field in the ticket contains the 504 time after which the ticket may not be renewed. 506 2.4. Postdated tickets 508 Applications may occasionally need to obtain tickets for use much later, 509 e.g. a batch submission system would need tickets to be valid at the time 510 the batch job is serviced. However, it is dangerous to hold valid tickets in 511 a batch queue, since they will be on-line longer and more prone to theft. 512 Postdated tickets provide a way to obtain these tickets from the KDC at job 513 submission time, but to leave them "dormant" until they are activated and 514 validated by a further request of the KDC. If a ticket theft were reported 515 in the interim, the KDC would refuse to validate the ticket, and the thief 516 would be foiled. 518 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 519 ticket-granting service. It can be ignored by application servers. This flag 520 must be set in a ticket-granting ticket in order to issue a postdated ticket 521 based on the presented ticket. It is reset by default; it may be requested 522 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 523 This flag does not allow a client to obtain a postdated ticket-granting 524 ticket; postdated ticket-granting tickets can only by obtained by requesting 525 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 526 postdated ticket will be the remaining life of the ticket-granting ticket at 527 the time of the request, unless the RENEWABLE option is also set, in which 528 case it can be the full life (endtime-starttime) of the ticket-granting 529 ticket. The KDC may limit how far in the future a ticket may be postdated. 531 The POSTDATED flag indicates that a ticket has been postdated. The 532 application server can check the authtime field in the ticket to see when 533 the original authentication occurred. Some services may choose to reject 534 postdated tickets, or they may only accept them within a certain period 535 after the original authentication. When the KDC issues a POSTDATED ticket, 536 it will also be marked as INVALID, so that the application client must 537 present the ticket to the KDC to be validated before use. 539 2.5. Proxiable and proxy tickets 541 At times it may be necessary for a principal to allow a service to perform 542 an operation on its behalf. The service must be able to take on the identity 543 of the client, but only for a particular purpose. A principal can allow a 544 service to take on the principal's identity for a particular purpose by 545 granting it a proxy. 547 The process of granting a proxy using the proxy and proxiable flags is used 548 to provide credentials for use with specific services. Though conceptually 549 also a proxy, user's wishing to delegate their identity for ANY purpose must 550 use the ticket forwarding mechanism described in the next section to forward 551 a ticket granting ticket. 553 The PROXIABLE flag in a ticket is normally only interpreted by the 554 ticket-granting service. It can be ignored by application servers. When set, 555 this flag tells the ticket-granting server that it is OK to issue a new 556 ticket (but not a ticket-granting ticket) with a different network address 557 based on this ticket. This flag is set if requested by the client on initial 558 authentication. By default, the client will request that it be set when 559 requesting a ticket granting ticket, and reset when requesting any other 560 ticket. 562 This flag allows a client to pass a proxy to a server to perform a remote 563 request on its behalf, e.g. a print service client can give the print server 564 a proxy to access the client's files on a particular file server in order to 565 satisfy a print request. 567 In order to complicate the use of stolen credentials, Kerberos tickets are 568 usually valid from only those network addresses specifically included in the 569 ticket[2.1]. When granting a proxy, the client must specify the new network 570 address from which the proxy is to be used, or indicate that the proxy is to 571 be issued for use from any address. 573 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 574 Application servers may check this flag and at their option they may require 575 additional authentication from the agent presenting the proxy in order to 576 provide an audit trail. 578 2.6. Forwardable tickets 580 Authentication forwarding is an instance of a proxy where the service 581 granted is complete use of the client's identity. An example where it might 582 be used is when a user logs in to a remote system and wants authentication 583 to work from that system as if the login were local. 585 The FORWARDABLE flag in a ticket is normally only interpreted by the 586 ticket-granting service. It can be ignored by application servers. The 587 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 588 flag, except ticket-granting tickets may also be issued with different 589 network addresses. This flag is reset by default, but users may request that 590 it be set by setting the FORWARDABLE option in the AS request when they 591 request their initial ticket-granting ticket. 593 This flag allows for authentication forwarding without requiring the user to 594 enter a password again. If the flag is not set, then authentication 595 forwarding is not permitted, but the same result can still be achieved if 596 the user engages in the AS exchange specifying the requested network 597 addresses and supplies a password. 599 The FORWARDED flag is set by the TGS when a client presents a ticket with 600 the FORWARDABLE flag set and requests a forwarded ticket by specifying the 601 FORWARDED KDC option and supplying a set of addresses for the new ticket. It 602 is also set in all tickets issued based on tickets with the FORWARDED flag 603 set. Application servers may choose to process FORWARDED tickets differently 604 than non-FORWARDED tickets. 606 2.7 Transited Policy Checking 608 While the application server is ultimately responsible for accepting or 609 rejecting authentication and should check the transited field, a KDC may 610 apply a realm specific policy for validating the transited field and 611 accepting credentials for cross-realm authentication. When the KDC applies 612 such checks and accepts such cross-realm authentication it will set the 613 TRANSITED-POLICY-CHECKED flag in the service tickets it issues based on the 614 cross-realm TGT. A client may request that the KDC's not check the transited 615 field by setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but 616 not required to honor this flag. 618 2.8 Anonymous Tickets 620 When policy allows, a KDC may issue anonymous tickets for the purpose of 621 enabling encrypted communication between a client and server without 622 identifying the client to the server. Such anonymous tickets are issued with 623 a generic principal name configured on the KDC (e.g. "anonymous@") and will 624 have the ANONYMOUS flag set. A server accepting such a ticket may assume 625 that subsequent requests using the same ticket and session key originate 626 from the same user. Requests with the same username but different tickets 627 are likely to originate from different users. Users request anonymous ticket 628 by setting the REQUEST-ANONYMOUS option in an AS or TGS request. 630 2.9. Other KDC options 632 There are three additional options which may be set in a client's request of 633 the KDC. 635 2.9.1 Name canonicalization [JBrezak] 637 The NAME-CANONICALIZATION option allows the KDC to replace the name of the 638 client or server requested by the client with the canonical form of the 639 principal's name, if known, or to refer the client to a KDC for the realm 640 with which the requested principal is registered. 642 Where name cannonicalization is supported a client who can identify a 643 principal but does not know the full principal name can request that the 644 Kerberos server attempt to lookup the name in its database and use the 645 canonical name of the requested principal or return a referral to a realm 646 that has the requested principal in its namespace. Use of name 647 canonicalization supports the case where a principal has multiple common 648 names (names typed by a user[2.2]), all of which are known to the KDC, but 649 only one Kerberos identity (the canonical name is the Kerberos principal 650 name). Name canonicalization is intended solely to provide a secure mapping 651 from the name known by a user to its principal identifier. It is not 652 intended for use as a general purpose nameserver or to identify instances of 653 a service. 655 The CANONICALIZE flag in a ticket request is used to indicate to the 656 Kerberos server that the client will accept an alternative name to the 657 principal in the request or a referral to another realm. When name 658 cannonicalization is supported in a realm, all instances of the AS and TGS 659 for the realm must be able to interpret requests with this flag. In realms 660 where name cannonicalization is not supported, this flag may be ignored. By 661 using this flag, the client can avoid extensive configuration needed to map 662 specific host names to a particular realm. 664 2.9.2 Renewable-OK 666 The RENEWABLE-OK option indicates that the client will accept a renewable 667 ticket if a ticket with the requested life cannot otherwise be provided. If 668 a ticket with the requested life cannot be provided, then the KDC may issue 669 a renewable ticket with a renew-till equal to the the requested endtime. The 670 value of the renew-till field may still be adjusted by site-determined 671 limits or limits imposed by the individual principal or server. 673 2.9.3 ENC-TKT-IN-SKEY 675 The ENC-TKT-IN-SKEY option supports user-to-user authentication. It allows 676 the KDC to issue a service ticket encrypted using the session key from a 677 ticket granting ticket issued to another user. This is needed to support 678 peer-to-peer authentication since the long term key of the user does not 679 remain on the workstation after initial login. The ENC-TKT-IN-SKEY option is 680 honored only by the ticket-granting service. It indicates that the ticket to 681 be issued for the end server is to be encrypted in the session key from the 682 additional second ticket-granting ticket provided with the request. See 683 section 3.3.3 for specific details. 685 3. Message Exchanges 687 The following sections describe the interactions between network clients and 688 servers and the messages involved in those exchanges. 690 3.1. The Authentication Service Exchange 692 Summary 693 Message direction Message type Section 694 1. Client to Kerberos KRB_AS_REQ 5.4.1 695 2. Kerberos to client KRB_AS_REP or 5.4.2 696 KRB_ERROR 5.9.1 698 The Authentication Service (AS) Exchange between the client and the Kerberos 699 Authentication Server is initiated by a client when it wishes to obtain 700 authentication credentials for a given server but currently holds no 701 credentials. In its basic form, the client's secret key is used for 702 encryption and decryption. This exchange is typically used at the initiation 703 of a login session to obtain credentials for a Ticket-Granting Server which 704 will subsequently be used to obtain credentials for other servers (see 705 section 3.3) without requiring further use of the client's secret key. This 706 exchange is also used to request credentials for services which must not be 707 mediated through the Ticket-Granting Service, but rather require a 708 principal's secret key, such as the password-changing service[3.1]. This 709 exchange does not by itself provide any assurance of the the identity of the 710 user[3.2]. 712 The exchange consists of two messages: KRB_AS_REQ from the client to 713 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 714 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 716 In the request, the client sends (in cleartext) its own identity and the 717 identity of the server for which it is requesting credentials. The response, 718 KRB_AS_REP, contains a ticket for the client to present to the server, and a 719 session key that will be shared by the client and the server. The session 720 key and additional information are encrypted in the client's secret key. The 721 KRB_AS_REP message contains information which can be used to detect replays, 722 and to associate it with the message to which it replies. 724 Without pre-authentication, the authentication server does not know whether 725 the client is actually the principal named in the request. It simply sends a 726 reply without knowing or caring whether they are the same. This is 727 acceptable because nobody but the principal whose identity was given in the 728 request will be able to use the reply. Its critical information is encrypted 729 in that principal's key. The initial request supports an optional field that 730 can be used to pass additional information that might be needed for the 731 initial exchange. This field may be used for pre-authentication as described 732 in section 3.1.1. 734 Various errors can occur; these are indicated by an error response 735 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not 736 encrypted. The KRB_ERROR message contains information which can be used to 737 associate it with the message to which it replies. If suitable 738 preauthentication has occurred, an optional checksum may be included in the 739 KRB_ERROR message to prevent fabrication or modification of the KRB_ERROR 740 message. When a checksum is not present, the lack of integrity protection 741 precludes the ability to detect replays, fabrications, or modifications of 742 the message, and the client must not depend on information in the KRB_ERROR 743 message for security critical operations. 745 3.1.1. Generation of KRB_AS_REQ message 747 The client may specify a number of options in the initial request. Among 748 these options are whether pre-authentication is to be performed; whether the 749 requested ticket is to be renewable, proxiable, or forwardable; whether it 750 should be postdated or allow postdating of derivative tickets; whether the 751 client requests name-canonicalization or an anonymous ticket; and whether a 752 renewable ticket will be accepted in lieu of a non-renewable ticket if the 753 requested ticket expiration date cannot be satisfied by a non-renewable 754 ticket (due to configuration constraints; see section 4). See section A.1 755 for pseudocode. 757 The client prepares the KRB_AS_REQ message and sends it to the KDC. 759 3.1.2. Receipt of KRB_AS_REQ message 761 If all goes well, processing the KRB_AS_REQ message will result in the 762 creation of a ticket for the client to present to the server. The format for 763 the ticket is described in section 5.3.1. The contents of the ticket are 764 determined as follows. 766 3.1.3. Generation of KRB_AS_REP message 768 The authentication server looks up the client and server principals named in 769 the KRB_AS_REQ in its database, extracting their respective keys. If the 770 requested client principal named in the request is not known because it 771 doesn't exist in the KDC's principal database and if an acceptable canonical 772 name of the client is not known, then an error message with a 773 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 775 If the request had the CANONICALIZE option set and if the AS finds the 776 canonical name for the client and it is in another realm, then an error 777 message with a KDC_ERR_WRONG_REALM error code and the cname and crealm in 778 the error message will contain the true client principal name and realm. In 779 this case, since no key is shared with the client, the response from the KDC 780 is not integrity protected and the referral can only be considered a hint; 781 the validity of the referral is validated upon successful completion of 782 initial authentication with the correct AS using the appropriate user key. 784 If required, the server pre-authenticates the request, and if the 785 pre-authentication check fails, an error message with the code 786 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, but 787 was not present in the request, an error message with the code 788 KDC_ERR_PREAUTH_FAILED is returned and the PA-ETYPE-INFO pre-authentication 789 field will be included in the KRB-ERROR message. If the server cannot 790 accommodate an encryption type requested by the client, an error message 791 with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a 792 'random' session key[3.3]. 794 When responding to an AS request, if there are multiple encryption keys 795 registered for a client in the Kerberos database (or if the key registered 796 supports multiple encryption types; e.g. DES3-CBC-SHA1 and 797 DES3-CBC-SHA1-KD), then the etype field from the AS request is used by the 798 KDC to select the encryption method to be used to protect the encrypted part 799 of the KRB_AS_REP message which is sent to the client. If there is more than 800 one supported strong encryption type in the etype list, the first valid 801 etype for which an encryption key is available is used. The encryption 802 method used to protect the encrypted part of the KRB_TGS_REP message is the 803 keytype of the session key found in the ticket granting ticket presented in 804 the KRB_TGS_REQ. 806 If the user's key was generated using an alternate string to key function 807 than that used by the selected encryption type, information needed by the 808 string to key function will be returned to the client in the padata field of 809 the KRB_AS_REP message using the PA-PW-SALT, PA-AFS3-SALT, or similar 810 pre-authentication typed values. This does not affect the encryption 811 performed by the KDC since the key stored in the principal database already 812 has the string to key transformation applied. 814 When the etype field is present in a KDC request, whether an AS or TGS 815 request, the KDC will attempt to assign the type of the random session key 816 from the list of methods in the etype field. The KDC will select the 817 appropriate type using the list of methods provided together with 818 information from the Kerberos database indicating acceptable encryption 819 methods for the application server. The KDC will not issue tickets with a 820 weak session key encryption type. 822 If the requested start time is absent, indicates a time in the past, or is 823 within the window of acceptable clock skew for the KDC and the POSTDATE 824 option has not been specified, then the start time of the ticket is set to 825 the authentication server's current time. If it indicates a time in the 826 future beyond the acceptable clock skew, but the POSTDATED option has not 827 been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise 828 the requested start time is checked against the policy of the local realm 829 (the administrator might decide to prohibit certain types or ranges of 830 postdated tickets), and if acceptable, the ticket's start time is set as 831 requested and the INVALID flag is set in the new ticket. The postdated 832 ticket must be validated before use by presenting it to the KDC after the 833 start time has been reached. 835 The expiration time of the ticket will be set to the earlier of the 836 requested endtime and a time determined by local policy, possibly determined 837 using realm or principal specific factors. For example, the expiration time 838 may be set to the minimum of the following: 840 * The expiration time (endtime) requested in the KRB_AS_REQ message. 841 * The ticket's start time plus the maximum allowable lifetime associated 842 with the client principal from the authentication server's database 843 (see section 4). 844 * The ticket's start time plus the maximum allowable lifetime associated 845 with the server principal. 846 * The ticket's start time plus the maximum lifetime set by the policy of 847 the local realm. 849 If the requested expiration time minus the start time (as determined above) 850 is less than a site-determined minimum lifetime, an error message with code 851 KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the 852 ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' 853 option was requested, then the 'RENEWABLE' flag is set in the new ticket, 854 and the renew-till value is set as if the 'RENEWABLE' option were requested 855 (the field and option names are described fully in section 5.4.1). 857 If the RENEWABLE option has been requested or if the RENEWABLE-OK option has 858 been set and a renewable ticket is to be issued, then the renew-till field 859 is set to the minimum of: 861 * Its requested value. 862 * The start time of the ticket plus the minimum of the two maximum 863 renewable lifetimes associated with the principals' database entries. 864 * The start time of the ticket plus the maximum renewable lifetime set by 865 the policy of the local realm. 867 The flags field of the new ticket will have the following options set if 868 they have been requested and if the policy of the local realm allows: 869 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS. If 870 the new ticket is post-dated (the start time is in the future), its INVALID 871 flag will also be set. 873 If all of the above succeed, the server will encrypt ciphertext part of the 874 ticket using the encryption key extracted from the server principal's record 875 in the Kerberos database using the encryption type associated with the 876 server principal's key (this choice is NOT affected by the etype field in 877 the request). It then formats a KRB_AS_REP message (see section 5.4.2), 878 copying the addresses in the request into the caddr of the response, placing 879 any required pre-authentication data into the padata of the response, and 880 encrypts the ciphertext part in the client's key using an acceptable 881 encryption method requested in the etype field of the request, and sends the 882 message to the client. See section A.2 for pseudocode. 884 3.1.4. Generation of KRB_ERROR message 886 Several errors can occur, and the Authentication Server responds by 887 returning an error message, KRB_ERROR, to the client, with the error-code, 888 e-text, and optional e-cksum fields set to appropriate values. The error 889 message contents and details are described in Section 5.9.1. 891 3.1.5. Receipt of KRB_AS_REP message 893 If the reply message type is KRB_AS_REP, then the client verifies that the 894 cname and crealm fields in the cleartext portion of the reply match what it 895 requested. If any padata fields are present, they may be used to derive the 896 proper secret key to decrypt the message. The client decrypts the encrypted 897 part of the response using its secret key, verifies that the nonce in the 898 encrypted part matches the nonce it supplied in its request (to detect 899 replays). It also verifies that the sname and srealm in the response match 900 those in the request (or are otherwise expected values), and that the host 901 address field is also correct. It then stores the ticket, session key, start 902 and expiration times, and other information for later use. The 903 key-expiration field from the encrypted part of the response may be checked 904 to notify the user of impending key expiration (the client program could 905 then suggest remedial action, such as a password change). See section A.3 906 for pseudocode. 908 Proper decryption of the KRB_AS_REP message is not sufficient for the host 909 to verify the identity of the user; the user and an attacker could cooperate 910 to generate a KRB_AS_REP format message which decrypts properly but is not 911 from the proper KDC. If the host wishes to verify the identity of the user, 912 it must require the user to present application credentials which can be 913 verified using a securely-stored secret key for the host. If those 914 credentials can be verified, then the identity of the user can be assured. 916 3.1.6. Receipt of KRB_ERROR message 918 If the reply message type is KRB_ERROR, then the client interprets it as an 919 error and performs whatever application-specific tasks are necessary to 920 recover. If the client set the CANONICALIZE option and a KDC_ERR_WRONG_REALM 921 error was returned, the AS request should be retried to the realm and client 922 principal name specified in the error message crealm and cname field 923 respectively. 925 3.2. The Client/Server Authentication Exchange 927 Summary 928 Message direction Message type Section 929 Client to Application server KRB_AP_REQ 5.5.1 930 [optional] Application server to client KRB_AP_REP or 5.5.2 931 KRB_ERROR 5.9.1 933 The client/server authentication (CS) exchange is used by network 934 applications to authenticate the client to the server and vice versa. The 935 client must have already acquired credentials for the server using the AS or 936 TGS exchange. 938 3.2.1. The KRB_AP_REQ message 940 The KRB_AP_REQ contains authentication information which should be part of 941 the first message in an authenticated transaction. It contains a ticket, an 942 authenticator, and some additional bookkeeping information (see section 943 5.5.1 for the exact format). The ticket by itself is insufficient to 944 authenticate a client, since tickets are passed across the network in 945 cleartext[3.4], so the authenticator is used to prevent invalid replay of 946 tickets by proving to the server that the client knows the session key of 947 the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is 948 referred to elsewhere as the 'authentication header.' 950 3.2.2. Generation of a KRB_AP_REQ message 952 When a client wishes to initiate authentication to a server, it obtains 953 (either through a credentials cache, the AS exchange, or the TGS exchange) a 954 ticket and session key for the desired service. The client may re-use any 955 tickets it holds until they expire. To use a ticket the client constructs a 956 new Authenticator from the the system time, its name, and optionally an 957 application specific checksum, an initial sequence number to be used in 958 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in 959 negotiations for a session key unique to this particular session. 960 Authenticators may not be re-used and will be rejected if replayed to a 961 server[3.5]. If a sequence number is to be included, it should be randomly 962 chosen so that even after many messages have been exchanged it is not likely 963 to collide with other sequence numbers in use. 965 The client may indicate a requirement of mutual authentication or the use of 966 a session-key based ticket by setting the appropriate flag(s) in the 967 ap-options field of the message. 969 The Authenticator is encrypted in the session key and combined with the 970 ticket to form the KRB_AP_REQ message which is then sent to the end server 971 along with any additional application-specific information. See section A.9 972 for pseudocode. 974 3.2.3. Receipt of KRB_AP_REQ message 976 Authentication is based on the server's current time of day (clocks must be 977 loosely synchronized), the authenticator, and the ticket. Several errors are 978 possible. If an error occurs, the server is expected to reply to the client 979 with a KRB_ERROR message. This message may be encapsulated in the 980 application protocol if its 'raw' form is not acceptable to the protocol. 981 The format of error messages is described in section 5.9.1. 983 The algorithm for verifying authentication information is as follows. If the 984 message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE 985 error. If the key version indicated by the Ticket in the KRB_AP_REQ is not 986 one the server can use (e.g., it indicates an old key, and the server no 987 longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is 988 returned. If the USE-SESSION-KEY flag is set in the ap-options field, it 989 indicates to the server that the ticket is encrypted in the session key from 990 the server's ticket-granting ticket rather than its secret key [3.6]. 992 Since it is possible for the server to be registered in multiple realms, 993 with different keys in each, the srealm field in the unencrypted portion of 994 the ticket in the KRB_AP_REQ is used to specify which secret key the server 995 should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is 996 returned if the server doesn't have the proper key to decipher the ticket. 998 The ticket is decrypted using the version of the server's key specified by 999 the ticket. If the decryption routines detect a modification of the ticket 1000 (each encryption system must provide safeguards to detect modified 1001 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned 1002 (chances are good that different keys were used to encrypt and decrypt). 1004 The authenticator is decrypted using the session key extracted from the 1005 decrypted ticket. If decryption shows it to have been modified, the 1006 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client 1007 from the ticket are compared against the same fields in the authenticator. 1008 If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might 1009 not match, for example, if the wrong session key was used to encrypt the 1010 authenticator). The addresses in the ticket (if any) are then searched for 1011 an address matching the operating-system reported address of the client. If 1012 no match is found or the server insists on ticket addresses but none are 1013 present in the ticket, the KRB_AP_ERR_BADADDR error is returned. If the 1014 local (server) time and the client time in the authenticator differ by more 1015 than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error 1016 is returned. 1018 Unless the application server provides its own suitable means to protect 1019 against replay (for example, a challenge-response sequence initiated by the 1020 server after authentication, or use of a server-generated encryption 1021 subkey), the server must utilize a replay cache to remember any 1022 authenticator presented within the allowable clock skew. Careful analysis of 1023 the application protocol and implementation is recommended before 1024 eliminating this cache. The replay cache will store the server name, along 1025 with the client name, time and microsecond fields from the recently-seen 1026 authenticators and if a matching tuple is found, the KRB_AP_ERR_REPEAT error 1027 is returned [3.7]. If a server loses track of authenticators presented 1028 within the allowable clock skew, it must reject all requests until the clock 1029 skew interval has passed, providing assurance that any lost or re-played 1030 authenticators will fall outside the allowable clock skew and can no longer 1031 be successfully replayed[3.8]. 1033 If a sequence number is provided in the authenticator, the server saves it 1034 for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey 1035 is present, the server either saves it for later use or uses it to help 1036 generate its own choice for a subkey to be returned in a KRB_AP_REP message. 1038 If multiple servers (for example, different services on one machine, or a 1039 single service implemented on multiple machines) share a service principal 1040 (a practice we do not recommend in general, but acknowledge will be used in 1041 some cases), they should also share this replay cache, or the application 1042 protocol should be designed so as to eliminate the need for it. Note that 1043 this applies to all of the services, if any of the application protocols 1044 does not have replay protection built in; an authenticator used with such a 1045 service could later be replayed to a different service with the same service 1046 principal but no replay protection, if the former doesn't record the 1047 authenticator information in the common replay cache. 1049 The server computes the age of the ticket: local (server) time minus the 1050 start time inside the Ticket. If the start time is later than the current 1051 time by more than the allowable clock skew or if the INVALID flag is set in 1052 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the 1053 current time is later than end time by more than the allowable clock skew, 1054 the KRB_AP_ERR_TKT_EXPIRED error is returned. 1056 If all these checks succeed without an error, the server is assured that the 1057 client possesses the credentials of the principal named in the ticket and 1058 thus, the client has been authenticated to the server. See section A.10 for 1059 pseudocode. 1061 Passing these checks provides only authentication of the named principal; it 1062 does not imply authorization to use the named service. Applications must 1063 make a separate authorization decisions based upon the authenticated name of 1064 the user, the requested operation, local access control information such as 1065 that contained in a .k5login or .k5users file, and possibly a separate 1066 distributed authorization service. 1068 3.2.4. Generation of a KRB_AP_REP message 1070 Typically, a client's request will include both the authentication 1071 information and its initial request in the same message, and the server need 1072 not explicitly reply to the KRB_AP_REQ. However, if mutual authentication 1073 (not only authenticating the client to the server, but also the server to 1074 the client) is being performed, the KRB_AP_REQ message will have 1075 MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is 1076 required in response. As with the error message, this message may be 1077 encapsulated in the application protocol if its "raw" form is not acceptable 1078 to the application's protocol. The timestamp and microsecond field used in 1079 the reply must be the client's timestamp and microsecond field (as provided 1080 in the authenticator)[3.9]. If a sequence number is to be included, it 1081 should be randomly chosen as described above for the authenticator. A subkey 1082 may be included if the server desires to negotiate a different subkey. The 1083 KRB_AP_REP message is encrypted in the session key extracted from the 1084 ticket. See section A.11 for pseudocode. 1086 3.2.5. Receipt of KRB_AP_REP message 1088 If a KRB_AP_REP message is returned, the client uses the session key from 1089 the credentials obtained for the server[3.10] to decrypt the message, and 1090 verifies that the timestamp and microsecond fields match those in the 1091 Authenticator it sent to the server. If they match, then the client is 1092 assured that the server is genuine. The sequence number and subkey (if 1093 present) are retained for later use. See section A.12 for pseudocode. 1095 3.2.6. Using the encryption key 1097 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server 1098 share an encryption key which can be used by the application. In some cases, 1099 the use of this session key will be implicit in the protocol; in others the 1100 method of use must be chosen from several alternatives. The 'true session 1101 key' to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses 1102 may be chosen by the application based on the session key from the ticket 1103 and subkeys in the KRB_AP_REP message and the authenticator[3.11]. To 1104 mitigate the effect of failures in random number generation on the client it 1105 is strongly encouraged that any key derived by an application for subsequent 1106 use include the full key entropy derived from the KDC generated session key 1107 carried in the ticket. We leave the protocol negotiations of how to use the 1108 key (e.g. selecting an encryption or checksum type) to the application 1109 programmer; the Kerberos protocol does not constrain the implementation 1110 options, but an example of how this might be done follows. 1112 One way that an application may choose to negotiate a key to be used for 1113 subsequent integrity and privacy protection is for the client to propose a 1114 key in the subkey field of the authenticator. The server can then choose a 1115 key using the proposed key from the client as input, returning the new 1116 subkey in the subkey field of the application reply. This key could then be 1117 used for subsequent communication. 1119 To make this example more concrete, if the communication patterns of an 1120 application dictates the use of encryption modes of operation incompatible 1121 with the encryption system used for the authenticator, then a key compatible 1122 with the required encryption system may be generated by either the client, 1123 the server, or collaboratively by both and exchanged using the subkey field. 1124 This generation might involve the use of a random number as a pre-key, 1125 initially generated by either party, which could then be encrypted using the 1126 session key from the ticket, and the result exchanged and used for 1127 subsequent encryption. By encrypting the pre-key with the session key from 1128 the ticket, randomness from the KDC generated key is assured of being 1129 present in the negotiated key. Application developers must be careful 1130 however, to use a means of introducing this entropy that does not allow an 1131 attacker to learn the session key from the ticket if it learns the key 1132 generated and used for subsequent communication. The reader should note that 1133 this is only an example, and that an analysis of the particular cryptosystem 1134 to be used, must be made before deciding how to generate values for the 1135 subkey fields, and the key to be used for subsequent communication. 1137 With both the one-way and mutual authentication exchanges, the peers should 1138 take care not to send sensitive information to each other without proper 1139 assurances. In particular, applications that require privacy or integrity 1140 should use the KRB_AP_REP response from the server to client to assure both 1141 client and server of their peer's identity. If an application protocol 1142 requires privacy of its messages, it can use the KRB_PRIV message (section 1143 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 1145 3.3. The Ticket-Granting Service (TGS) Exchange 1147 Summary 1148 Message direction Message type Section 1149 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1150 2. Kerberos to client KRB_TGS_REP or 5.4.2 1151 KRB_ERROR 5.9.1 1153 The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1154 initiated by a client when it wishes to obtain authentication credentials 1155 for a given server (which might be registered in a remote realm), when it 1156 wishes to renew or validate an existing ticket, or when it wishes to obtain 1157 a proxy ticket. In the first case, the client must already have acquired a 1158 ticket for the Ticket-Granting Service using the AS exchange (the 1159 ticket-granting ticket is usually obtained when a client initially 1160 authenticates to the system, such as when a user logs in). The message 1161 format for the TGS exchange is almost identical to that for the AS exchange. 1162 The primary difference is that encryption and decryption in the TGS exchange 1163 does not take place under the client's key. Instead, the session key from 1164 the ticket-granting ticket or renewable ticket, or sub-session key from an 1165 Authenticator is used. As is the case for all application servers, expired 1166 tickets are not accepted by the TGS, so once a renewable or ticket-granting 1167 ticket expires, the client must use a separate exchange to obtain valid 1168 tickets. 1170 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1171 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1172 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1173 client plus a request for credentials. The authentication information 1174 consists of the authentication header (KRB_AP_REQ) which includes the 1175 client's previously obtained ticket-granting, renewable, or invalid ticket. 1176 In the ticket-granting ticket and proxy cases, the request may include one 1177 or more of: a list of network addresses, a collection of typed authorization 1178 data to be sealed in the ticket for authorization use by the application 1179 server, or additional tickets (the use of which are described later). The 1180 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1181 session key from the ticket-granting ticket or renewable ticket, or if 1182 present, in the sub-session key from the Authenticator (part of the 1183 authentication header). The KRB_ERROR message contains an error code and 1184 text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1185 KRB_TGS_REP message contains information which can be used to detect 1186 replays, and to associate it with the message to which it replies. The 1187 KRB_ERROR message also contains information which can be used to associate 1188 it with the message to which it replies, but except when an optional 1189 checksum is included in the KRB_ERROR message, it is not possible to detect 1190 replays or fabrications of such messages. 1192 3.3.1. Generation of KRB_TGS_REQ message 1194 Before sending a request to the ticket-granting service, the client must 1195 determine in which realm the application server is believed to be 1196 registered[3.12]. If the client knows the service principal name and realm 1197 and it does not already possess a ticket-granting ticket for the appropriate 1198 realm, then one must be obtained. This is first attempted by requesting a 1199 ticket-granting ticket for the destination realm from a Kerberos server for 1200 which the client possesses a ticket-granting ticket (using the KRB_TGS_REQ 1201 message recursively). The Kerberos server may return a TGT for the desired 1202 realm in which case one can proceed. Alternatively, the Kerberos server may 1203 return a TGT for a realm which is 'closer' to the desired realm (further 1204 along the standard hierarchical path between the client's realm and the 1205 requested realm server's realm). 1207 If the client does not know the realm of the service or the true service 1208 principal name, then the CANONICALIZE option must be used in the request. 1209 This will cause the TGS to locate the service principal based on the target 1210 service name in the ticket and return the service principal name in the 1211 response. This function allows the KDC to inform the user of the registered 1212 Kerberos principal name and registered KDC for a server that may have more 1213 than one host name or whose registered realm can not be determined from the 1214 name of the host, but it is not to be used to locate the application server. 1216 If the server name determined by a TGS supporting name canonicalization is 1217 with a remote KDC, then the response will include the principal name 1218 determined by the KDC, and will include a TGT for the remote realm or a 1219 realm 'closer' to the realm with which the server principal is registered. 1220 In this case, the canonicalization request must be repeated with a Kerberos 1221 server in the realm specified in the returned TGT. If neither are returned, 1222 then the request may be retried with a Kerberos server for a realm higher in 1223 the hierarchy. This request will itself require a ticket-granting ticket for 1224 the higher realm which must be obtained by recursively applying these 1225 directions. 1227 Once the client obtains a ticket-granting ticket for the appropriate realm, 1228 it determines which Kerberos servers serve that realm, and contacts one. The 1229 list might be obtained through a configuration file or network service or it 1230 may be generated from the name of the realm; as long as the secret keys 1231 exchanged by realms are kept secret, only denial of service results from 1232 using a false Kerberos server. 1234 As in the AS exchange, the client may specify a number of options in the 1235 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing 1236 an authentication header as an element of the padata field, and including 1237 the same fields as used in the KRB_AS_REQ message along with several 1238 optional fields: the enc-authorization-data field for application server use 1239 and additional tickets required by some options. 1241 In preparing the authentication header, the client can select a sub-session 1242 key under which the response from the Kerberos server will be 1243 encrypted[3.13]. If the sub-session key is not specified, the session key 1244 from the ticket-granting ticket will be used. If the enc-authorization-data 1245 is present, it must be encrypted in the sub-session key, if present, from 1246 the authenticator portion of the authentication header, or if not present, 1247 using the session key from the ticket-granting ticket. 1249 Once prepared, the message is sent to a Kerberos server for the destination 1250 realm. See section A.5 for pseudocode. 1252 3.3.2. Receipt of KRB_TGS_REQ message 1254 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1255 message, but there are many additional checks to be performed. First, the 1256 Kerberos server must determine which server the accompanying ticket is for 1257 and it must select the appropriate key to decrypt it. For a normal 1258 KRB_TGS_REQ message, it will be for the ticket granting service, and the 1259 TGS's key will be used. If the TGT was issued by another realm, then the 1260 appropriate inter-realm key must be used. If the accompanying ticket is not 1261 a ticket granting ticket for the current realm, but is for an application 1262 server in the current realm, the RENEW, VALIDATE, or PROXY options are 1263 specified in the request, and the server for which a ticket is requested is 1264 the server named in the accompanying ticket, then the KDC will decrypt the 1265 ticket in the authentication header using the key of the server for which it 1266 was issued. If no ticket can be found in the padata field, the 1267 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1269 Once the accompanying ticket has been decrypted, the user-supplied checksum 1270 in the Authenticator must be verified against the contents of the request, 1271 and the message rejected if the checksums do not match (with an error code 1272 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1273 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1274 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1275 returned. If the authorization-data are present, they are decrypted using 1276 the sub-session key from the Authenticator. 1278 If any of the decryptions indicate failed integrity checks, the 1279 KRB_AP_ERR_BAD_INTEGRITY error is returned. If the CANONICALIZE option is 1280 set in the KRB_TGS_REQ, then the requested service name might not be the 1281 true principal name or the service might not be in the TGS realm and the 1282 correct name must be determined. 1284 3.3.3. Generation of KRB_TGS_REP message 1286 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1287 but with its type field set to KRB_TGS_REP. The detailed specification is in 1288 section 5.4.2. 1290 The response will include a ticket for the requested server or for a ticket 1291 granting server of an intermediate KDC to be contacted to obtain the 1292 requested ticket. The Kerberos database is queried to retrieve the record 1293 for the appropriate server (including the key with which the ticket will be 1294 encrypted). If the request is for a ticket granting ticket for a remote 1295 realm, and if no key is shared with the requested realm, then the Kerberos 1296 server will select the realm 'closest' to the requested realm with which it 1297 does share a key, and use that realm instead. If the CANONICALIZE option is 1298 set, the TGS may return a ticket containing the server name of the true 1299 service principal. If the requested server cannot be found in the TGS 1300 database, then a TGT for another trusted realm may be returned instead of a 1301 ticket for the service. This TGT is a referral mechanism to cause the client 1302 to retry the request to the realm of the TGT. These are the only cases where 1303 the response for the KDC will be for a different server than that requested 1304 by the client. 1306 By default, the address field, the client's name and realm, the list of 1307 transited realms, the time of initial authentication, the expiration time, 1308 and the authorization data of the newly-issued ticket will be copied from 1309 the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1310 needs to be updated, but the transited type is not supported, the 1311 KDC_ERR_TRTYPE_NOSUPP error is returned. 1313 If the request specifies an endtime, then the endtime of the new ticket is 1314 set to the minimum of (a) that request, (b) the endtime from the TGT, and 1315 (c) the starttime of the TGT plus the minimum of the maximum life for the 1316 application server and the maximum life for the local realm (the maximum 1317 life for the requesting principal was already applied when the TGT was 1318 issued). If the new ticket is to be a renewal, then the endtime above is 1319 replaced by the minimum of (a) the value of the renew_till field of the 1320 ticket and (b) the starttime for the new ticket plus the life 1321 (endtime-starttime) of the old ticket. 1323 If the FORWARDED option has been requested, then the resulting ticket will 1324 contain the addresses specified by the client. This option will only be 1325 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1326 similar; the resulting ticket will contain the addresses specified by the 1327 client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1328 PROXY option will not be honored on requests for additional ticket-granting 1329 tickets. 1331 If the requested start time is absent, indicates a time in the past, or is 1332 within the window of acceptable clock skew for the KDC and the POSTDATE 1333 option has not been specified, then the start time of the ticket is set to 1334 the authentication server's current time. If it indicates a time in the 1335 future beyond the acceptable clock skew, but the POSTDATED option has not 1336 been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1337 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1338 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1339 postdated and the requested starttime is checked against the policy of the 1340 local realm. If acceptable, the ticket's start time is set as requested, and 1341 the INVALID flag is set. The postdated ticket must be validated before use 1342 by presenting it to the KDC after the starttime has been reached. However, 1343 in no case may the starttime, endtime, or renew-till time of a newly-issued 1344 postdated ticket extend beyond the renew-till time of the ticket-granting 1345 ticket. 1347 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1348 has been included in the request, the KDC will decrypt the additional ticket 1349 using the key for the server to which the additional ticket was issued and 1350 verify that it is a ticket-granting ticket. If the name of the requested 1351 server is missing from the request, the name of the client in the additional 1352 ticket will be used. Otherwise the name of the requested server will be 1353 compared to the name of the client in the additional ticket and if 1354 different, the request will be rejected. If the request succeeds, the 1355 session key from the additional ticket will be used to encrypt the new 1356 ticket that is issued instead of using the key of the server for which the 1357 new ticket will be used. 1359 If the name of the server in the ticket that is presented to the KDC as part 1360 of the authentication header is not that of the ticket-granting server 1361 itself, the server is registered in the realm of the KDC, and the RENEW 1362 option is requested, then the KDC will verify that the RENEWABLE flag is set 1363 in the ticket, that the INVALID flag is not set in the ticket, and that the 1364 renew_till time is still in the future. If the VALIDATE option is requested, 1365 the KDC will check that the starttime has passed and the INVALID flag is 1366 set. If the PROXY option is requested, then the KDC will check that the 1367 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1368 passes the hotlist check described in the next section, the KDC will issue 1369 the appropriate new ticket. 1371 The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1372 in the sub-session key from the Authenticator, if present, or the session 1373 key key from the ticket-granting ticket. It is not encrypted using the 1374 client's secret key. Furthermore, the client's key's expiration date and the 1375 key version number fields are left out since these values are stored along 1376 with the client's database record, and that record is not needed to satisfy 1377 a request based on a ticket-granting ticket. See section A.6 for pseudocode. 1379 3.3.3.1. Checking for revoked tickets 1381 Whenever a request is made to the ticket-granting server, the presented 1382 ticket(s) is(are) checked against a hot-list of tickets which have been 1383 canceled. This hot-list might be implemented by storing a range of issue 1384 timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1385 that range, it would be rejected. In this way, a stolen ticket-granting 1386 ticket or renewable ticket cannot be used to gain additional tickets 1387 (renewals or otherwise) once the theft has been reported to the KDC for the 1388 realm in which the server resides. Any normal ticket obtained before it was 1389 reported stolen will still be valid (because they require no interaction 1390 with the KDC), but only until their normal expiration time. If TGT's have 1391 been issued for cross-realm authentication, use of the cross-realm TGT will 1392 not be affected unless the hot-list is propagated to the KDC's for the 1393 realms for which such cross-realm tickets were issued. 1395 3.3.3.2. Encoding the transited field 1397 If the identity of the server in the TGT that is presented to the KDC as 1398 part of the authentication header is that of the ticket-granting service, 1399 but the TGT was issued from another realm, the KDC will look up the 1400 inter-realm key shared with that realm and use that key to decrypt the 1401 ticket. If the ticket is valid, then the KDC will honor the request, subject 1402 to the constraints outlined above in the section describing the AS exchange. 1403 The realm part of the client's identity will be taken from the 1404 ticket-granting ticket. The name of the realm that issued the 1405 ticket-granting ticket will be added to the transited field of the ticket to 1406 be issued. This is accomplished by reading the transited field from the 1407 ticket-granting ticket (which is treated as an unordered set of realm 1408 names), adding the new realm to the set, then constructing and writing out 1409 its encoded (shorthand) form (this may involve a rearrangement of the 1410 existing encoding). 1412 Note that the ticket-granting service does not add the name of its own 1413 realm. Instead, its responsibility is to add the name of the previous realm. 1414 This prevents a malicious Kerberos server from intentionally leaving out its 1415 own name (it could, however, omit other realms' names). 1417 The names of neither the local realm nor the principal's realm are to be 1418 included in the transited field. They appear elsewhere in the ticket and 1419 both are known to have taken part in authenticating the principal. Since the 1420 endpoints are not included, both local and single-hop inter-realm 1421 authentication result in a transited field that is empty. 1423 Because the name of each realm transited is added to this field, it might 1424 potentially be very long. To decrease the length of this field, its contents 1425 are encoded. The initially supported encoding is optimized for the normal 1426 case of inter-realm communication: a hierarchical arrangement of realms 1427 using either domain or X.500 style realm names. This encoding (called 1428 DOMAIN-X500-COMPRESS) is now described. 1430 Realm names in the transited field are separated by a ",". The ",", "\", 1431 trailing "."s, and leading spaces (" ") are special characters, and if they 1432 are part of a realm name, they must be quoted in the transited field by 1433 preceding them with a "\". 1435 A realm name ending with a "." is interpreted as being prepended to the 1436 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1437 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1439 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1441 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1442 would not be included in this field, and we would have: 1444 "EDU,MIT.,WASHINGTON.EDU" 1446 A realm name beginning with a "/" is interpreted as being appended to the 1447 previous realm[18]. If it is to stand by itself, then it should be preceded 1448 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1449 /COM/HP, /COM, and /COM/DEC as: 1451 "/COM,/HP,/APOLLO, /COM/DEC". 1453 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1454 they would not be included in this field, and we would have: 1456 "/COM,/HP" 1458 A null subfield preceding or following a "," indicates that all realms 1459 between the previous realm and the next realm have been traversed[19]. Thus, 1460 "," means that all realms along the path between the client and the server 1461 have been traversed. ",EDU, /COM," means that that all realms from the 1462 client's realm up to EDU (in a domain style hierarchy) have been traversed, 1463 and that everything from /COM down to the server's realm in an X.500 style 1464 has also been traversed. This could occur if the EDU realm in one hierarchy 1465 shares an inter-realm key directly with the /COM realm in another hierarchy. 1467 3.3.4. Receipt of KRB_TGS_REP message 1469 When the KRB_TGS_REP is received by the client, it is processed in the same 1470 manner as the KRB_AS_REP processing described above. The primary difference 1471 is that the ciphertext part of the response must be decrypted using the 1472 session key from the ticket-granting ticket rather than the client's secret 1473 key. The server name returned in the reply is the true principal name of the 1474 service. See section A.7 for pseudocode. 1476 3.4. The KRB_SAFE Exchange 1478 The KRB_SAFE message may be used by clients requiring the ability to detect 1479 modifications of messages they exchange. It achieves this by including a 1480 keyed collision-proof checksum of the user data and some control 1481 information. The checksum is keyed with an encryption key (usually the last 1482 key negotiated via subkeys, or the session key if no negotiation has 1483 occurred). 1485 3.4.1. Generation of a KRB_SAFE message 1487 When an application wishes to send a KRB_SAFE message, it collects its data 1488 and the appropriate control information and computes a checksum over them. 1489 The checksum algorithm should be a keyed one-way hash function (such as the 1490 RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), 1491 generated using the sub-session key if present, or the session key. 1492 Different algorithms may be selected by changing the checksum type in the 1493 message. Unkeyed or non-collision-proof checksums are not suitable for this 1494 use. 1496 The control information for the KRB_SAFE message includes both a timestamp 1497 and a sequence number. The designer of an application using the KRB_SAFE 1498 message must choose at least one of the two mechanisms. This choice should 1499 be based on the needs of the application protocol. 1501 Sequence numbers are useful when all messages sent will be received by one's 1502 peer. Connection state is presently required to maintain the session key, so 1503 maintaining the next sequence number should not present an additional 1504 problem. 1506 If the application protocol is expected to tolerate lost messages without 1507 them being resent, the use of the timestamp is the appropriate replay 1508 detection mechanism. Using timestamps is also the appropriate mechanism for 1509 multi-cast protocols where all of one's peers share a common sub-session 1510 key, but some messages will be sent to a subset of one's peers. 1512 After computing the checksum, the client then transmits the information and 1513 checksum to the recipient in the message format specified in section 5.6.1. 1515 3.4.2. Receipt of KRB_SAFE message 1517 When an application receives a KRB_SAFE message, it verifies it as follows. 1518 If any error occurs, an error code is reported for use by the application. 1520 The message is first checked by verifying that the protocol version and type 1521 fields match the current version and KRB_SAFE, respectively. A mismatch 1522 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1523 application verifies that the checksum used is a collision-proof keyed 1524 checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If 1525 the sender's address was included in the control information, the recipient 1526 verifies that the operating system's report of the sender's address matches 1527 the sender's address in the message, and (if a recipient address is 1528 specified or the recipient requires an address) that one of the recipient's 1529 addresses appears as the recipient's address in the message. A failed match 1530 for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and 1531 usec and/or the sequence number fields are checked. If timestamp and usec 1532 are expected and not present, or they are present but not current, the 1533 KRB_AP_ERR_SKEW error is generated. If the server name, along with the 1534 client name, time and microsecond fields from the Authenticator match any 1535 recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT 1536 error is generated. If an incorrect sequence number is included, or a 1537 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error 1538 is generated. If neither a time-stamp and usec or a sequence number is 1539 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is 1540 computed over the data and control information, and if it doesn't match the 1541 received checksum, a KRB_AP_ERR_MODIFIED error is generated. 1543 If all the checks succeed, the application is assured that the message was 1544 generated by its peer and was not modified in transit. 1546 3.5. The KRB_PRIV Exchange 1548 The KRB_PRIV message may be used by clients requiring confidentiality and 1549 the ability to detect modifications of exchanged messages. It achieves this 1550 by encrypting the messages and adding control information. 1552 3.5.1. Generation of a KRB_PRIV message 1554 When an application wishes to send a KRB_PRIV message, it collects its data 1555 and the appropriate control information (specified in section 5.7.1) and 1556 encrypts them under an encryption key (usually the last key negotiated via 1557 subkeys, or the session key if no negotiation has occurred). As part of the 1558 control information, the client must choose to use either a timestamp or a 1559 sequence number (or both); see the discussion in section 3.4.1 for 1560 guidelines on which to use. After the user data and control information are 1561 encrypted, the client transmits the ciphertext and some 'envelope' 1562 information to the recipient. 1564 3.5.2. Receipt of KRB_PRIV message 1566 When an application receives a KRB_PRIV message, it verifies it as follows. 1567 If any error occurs, an error code is reported for use by the application. 1569 The message is first checked by verifying that the protocol version and type 1570 fields match the current version and KRB_PRIV, respectively. A mismatch 1571 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1572 application then decrypts the ciphertext and processes the resultant 1573 plaintext. If decryption shows the data to have been modified, a 1574 KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was 1575 included in the control information, the recipient verifies that the 1576 operating system's report of the sender's address matches the sender's 1577 address in the message, and (if a recipient address is specified or the 1578 recipient requires an address) that one of the recipient's addresses appears 1579 as the recipient's address in the message. A failed match for either case 1580 generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1581 sequence number fields are checked. If timestamp and usec are expected and 1582 not present, or they are present but not current, the KRB_AP_ERR_SKEW error 1583 is generated. If the server name, along with the client name, time and 1584 microsecond fields from the Authenticator match any recently-seen such 1585 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 1586 number is included, or a sequence number is expected but not present, the 1587 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1588 a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1590 If all the checks succeed, the application can assume the message was 1591 generated by its peer, and was securely transmitted (without intruders able 1592 to see the unencrypted contents). 1594 3.6. The KRB_CRED Exchange 1596 The KRB_CRED message may be used by clients requiring the ability to send 1597 Kerberos credentials from one host to another. It achieves this by sending 1598 the tickets together with encrypted data containing the session keys and 1599 other information associated with the tickets. 1601 3.6.1. Generation of a KRB_CRED message 1603 When an application wishes to send a KRB_CRED message it first (using the 1604 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1605 constructs a KRB_CRED message using the ticket or tickets so obtained, 1606 placing the session key needed to use each ticket in the key field of the 1607 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1608 message. 1610 Other information associated with each ticket and obtained during the 1611 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1612 the encrypted part of the KRB_CRED message. The current time and, if 1613 specifically required by the application the nonce, s-address, and r-address 1614 fields, are placed in the encrypted part of the KRB_CRED message which is 1615 then encrypted under an encryption key previously exchanged in the KRB_AP 1616 exchange (usually the last key negotiated via subkeys, or the session key if 1617 no negotiation has occurred). 1619 3.6.2. Receipt of KRB_CRED message 1621 When an application receives a KRB_CRED message, it verifies it. If any 1622 error occurs, an error code is reported for use by the application. The 1623 message is verified by checking that the protocol version and type fields 1624 match the current version and KRB_CRED, respectively. A mismatch generates a 1625 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1626 decrypts the ciphertext and processes the resultant plaintext. If decryption 1627 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1628 generated. 1630 If present or required, the recipient verifies that the operating system's 1631 report of the sender's address matches the sender's address in the message, 1632 and that one of the recipient's addresses appears as the recipient's address 1633 in the message. A failed match for either case generates a 1634 KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field 1635 if required) are checked next. If the timestamp and usec are not present, or 1636 they are present but not current, the KRB_AP_ERR_SKEW error is generated. 1638 If all the checks succeed, the application stores each of the new tickets in 1639 its ticket cache together with the session key and other information in the 1640 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1641 message. 1643 4. The Kerberos Database 1645 The Kerberos server must have access to a database containing the principal 1646 identifiers and secret keys of any principals to be authenticated[4.1] using 1647 such secret keys. The keying material in the database must be protected so 1648 that they are only accessible to the Kerberos server and administrative 1649 functions specifically authorized to access such material. Specific 1650 implementations may handle the storage of keying material separate from the 1651 Kerberos database (e.g. in hardware) or by encrypting the keying material 1652 before placing it in the Kerberos database. Some implementations might 1653 provide a means for using long term secret keys, but not for retrieving them 1654 from the Kerberos database. 1656 4.1. Database contents 1658 A database entry will typically contain the following fields, though in some 1659 instances a KDC may obtain these values through other means: 1661 Field Value 1663 name Principal's identifier 1664 key Principal's secret key 1665 p_kvno Principal's key version 1666 max_life Maximum lifetime for Tickets 1667 max_renewable_life Maximum total lifetime for renewable Tickets 1669 The name field is an encoding of the principal's identifier. The key field 1670 contains an encryption key. This key is the principal's secret key. (The key 1671 can be encrypted before storage under a Kerberos "master key" to protect it 1672 in case the database is compromised but the master key is not. In that case, 1673 an extra field must be added to indicate the master key version used, see 1674 below.) The p_kvno field is the key version number of the principal's secret 1675 key. The max_life field contains the maximum allowable lifetime (endtime - 1676 starttime) for any Ticket issued for this principal. The max_renewable_life 1677 field contains the maximum allowable total lifetime for any renewable Ticket 1678 issued for this principal. (See section 3.1 for a description of how these 1679 lifetimes are used in determining the lifetime of a given Ticket.) 1681 A server may provide KDC service to several realms, as long as the database 1682 representation provides a mechanism to distinguish between principal records 1683 with identifiers which differ only in the realm name. 1685 When an application server's key changes, if the change is routine (i.e. not 1686 the result of disclosure of the old key), the old key should be retained by 1687 the server until all tickets that had been issued using that key have 1688 expired. Because of this, it is possible for several keys to be active for a 1689 single principal. Ciphertext encrypted in a principal's key is always tagged 1690 with the version of the key that was used for encryption, to help the 1691 recipient find the proper key for decryption. 1693 When more than one key is active for a particular principal, the principal 1694 will have more than one record in the Kerberos database. The keys and key 1695 version numbers will differ between the records (the rest of the fields may 1696 or may not be the same). Whenever Kerberos issues a ticket, or responds to a 1697 request for initial authentication, the most recent key (known by the 1698 Kerberos server) will be used for encryption. This is the key with the 1699 highest key version number. 1701 4.2. Additional fields 1703 Project Athena's KDC implementation uses additional fields in its database: 1705 Field Value 1707 K_kvno Kerberos' key version 1708 expiration Expiration date for entry 1709 attributes Bit field of attributes 1710 mod_date Timestamp of last modification 1711 mod_name Modifying principal's identifier 1713 The K_kvno field indicates the key version of the Kerberos master key under 1714 which the principal's secret key is encrypted. 1716 After an entry's expiration date has passed, the KDC will return an error to 1717 any client attempting to gain tickets as or for the principal. (A database 1718 may want to maintain two expiration dates: one for the principal, and one 1719 for the principal's current key. This allows password aging to work 1720 independently of the principal's expiration date. However, due to the 1721 limited space in the responses, the KDC combines the key expiration and 1722 principal expiration date into a single value called 'key_exp', which is 1723 used as a hint to the user to take administrative action.) 1725 The attributes field is a bitfield used to govern the operations involving 1726 the principal. This field might be useful in conjunction with user 1727 registration procedures, for site-specific policy implementations (Project 1728 Athena currently uses it for their user registration process controlled by 1729 the system-wide database service, Moira [LGDSR87]), to identify whether a 1730 principal can play the role of a client or server or both, to note whether a 1731 server is appropriately trusted to receive credentials delegated by a 1732 client, or to identify the 'string to key' conversion algorithm used for a 1733 principal's key[4.2]. Other bits are used to indicate that certain ticket 1734 options should not be allowed in tickets encrypted under a principal's key 1735 (one bit each): Disallow issuing postdated tickets, disallow issuing 1736 forwardable tickets, disallow issuing tickets based on TGT authentication, 1737 disallow issuing renewable tickets, disallow issuing proxiable tickets, and 1738 disallow issuing tickets for which the principal is the server. 1740 The mod_date field contains the time of last modification of the entry, and 1741 the mod_name field contains the name of the principal which last modified 1742 the entry. 1744 4.3. Frequently Changing Fields 1746 Some KDC implementations may wish to maintain the last time that a request 1747 was made by a particular principal. Information that might be maintained 1748 includes the time of the last request, the time of the last request for a 1749 ticket-granting ticket, the time of the last use of a ticket-granting 1750 ticket, or other times. This information can then be returned to the user in 1751 the last-req field (see section 5.2). 1753 Other frequently changing information that can be maintained is the latest 1754 expiration time for any tickets that have been issued using each key. This 1755 field would be used to indicate how long old keys must remain valid to allow 1756 the continued use of outstanding tickets. 1758 4.4. Site Constants 1760 The KDC implementation should have the following configurable constants or 1761 options, to allow an administrator to make and enforce policy decisions: 1763 * The minimum supported lifetime (used to determine whether the 1764 KDC_ERR_NEVER_VALID error should be returned). This constant should 1765 reflect reasonable expectations of round-trip time to the KDC, 1766 encryption/decryption time, and processing time by the client and 1767 target server, and it should allow for a minimum 'useful' lifetime. 1768 * The maximum allowable total (renewable) lifetime of a ticket 1769 (renew_till - starttime). 1770 * The maximum allowable lifetime of a ticket (endtime - starttime). 1771 * Whether to allow the issue of tickets with empty address fields 1772 (including the ability to specify that such tickets may only be issued 1773 if the request specifies some authorization_data). 1774 * Whether proxiable, forwardable, renewable or post-datable tickets are 1775 to be issued. 1777 5. Message Specifications 1779 This section (5) still has revisions that are pending based on comments by 1780 Tom Yu. Please see http://www.isi.edu/people/bcn/krb-revisions for the 1781 latest versions. There will be additional updates prior to the San Diego 1782 IETF meeting. 1784 The following sections describe the exact contents and encoding of protocol 1785 messages and objects. The ASN.1 base definitions are presented in the first 1786 subsection. The remaining subsections specify the protocol objects (tickets 1787 and authenticators) and messages. Specification of encryption and checksum 1788 techniques, and the fields related to them, appear in section 6. 1790 Optional field in ASN.1 sequences 1792 For optional integer value and date fields in ASN.1 sequences where a 1793 default value has been specified, certain default values will not be allowed 1794 in the encoding because these values will always be represented through 1795 defaulting by the absence of the optional field. For example, one will not 1796 send a microsecond zero value because one must make sure that there is only 1797 one way to encode this value. 1799 Additional fields in ASN.1 sequences 1801 Implementations receiving Kerberos messages with additional fields present 1802 in ASN.1 sequences should carry those fields through, unmodified, when the 1803 message is forwarded. Implementations should not drop such fields if the 1804 sequence is re-encoded. 1806 5.1. ASN.1 Distinguished Encoding Representation 1808 All uses of ASN.1 in Kerberos shall use the Distinguished Encoding 1809 Representation of the data elements as described in the X.509 specification, 1810 section 8.7 [X509-88]. 1812 5.2. ASN.1 Base Definitions 1814 The following ASN.1 base definitions are used in the rest of this section. 1815 Note that since the underscore character (_) is not permitted in ASN.1 1816 names, the hyphen (-) is used in its place for the purposes of ASN.1 names. 1818 Realm ::= GeneralString 1819 PrincipalName ::= SEQUENCE { 1820 name-type[0] INTEGER, 1821 name-string[1] SEQUENCE OF GeneralString 1822 } 1824 Kerberos realms are encoded as GeneralStrings. Realms shall not contain a 1825 character with the code 0 (the ASCII NUL). Most realms will usually consist 1826 of several components separated by periods (.), in the style of Internet 1827 Domain Names, or separated by slashes (/) in the style of X.500 names. 1828 Acceptable forms for realm names are specified in section 7. A PrincipalName 1829 is a typed sequence of components consisting of the following sub-fields: 1831 name-type 1832 This field specifies the type of name that follows. Pre-defined values 1833 for this field are specified in section 7.2. The name-type should be 1834 treated as a hint. Ignoring the name type, no two names can be the same 1835 (i.e. at least one of the components, or the realm, must be different). 1836 This constraint may be eliminated in the future. 1837 name-string 1838 This field encodes a sequence of components that form a name, each 1839 component encoded as a GeneralString. Taken together, a PrincipalName 1840 and a Realm form a principal identifier. Most PrincipalNames will have 1841 only a few components (typically one or two). 1843 KerberosTime ::= GeneralizedTime 1844 -- Specifying UTC time zone (Z) 1845 The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding 1846 shall specify the UTC time zone (Z) and shall not include any fractional 1847 portions of the seconds. It further shall not include any separators. 1848 Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm 1849 on 6 November 1985 is 19851106210627Z. 1851 HostAddress ::= SEQUENCE { 1852 addr-type[0] INTEGER, 1853 address[1] OCTET STRING 1854 } 1856 HostAddresses ::= SEQUENCE OF HostAddress 1858 The host address encodings consists of two fields: 1860 addr-type 1861 This field specifies the type of address that follows. Pre-defined 1862 values for this field are specified in section 8.1. 1863 address 1864 This field encodes a single address of type addr-type. 1866 The two forms differ slightly. HostAddress contains exactly one address; 1867 HostAddresses contains a sequence of possibly many addresses. 1869 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1870 ad-type[0] INTEGER, 1871 ad-data[1] OCTET STRING 1872 } 1874 ad-data 1875 This field contains authorization data to be interpreted according to 1876 the value of the corresponding ad-type field. 1877 ad-type 1878 This field specifies the format for the ad-data subfield. All negative 1879 values are reserved for local use. Non-negative values are reserved for 1880 registered use. 1882 Each sequence of type and data is referred to as an authorization element. 1883 Elements may be application specific, however, there is a common set of 1884 recursive elements that should be understood by all implementations. These 1885 elements contain other elements embedded within them, and the interpretation 1886 of the encapsulating element determines which of the embedded elements must 1887 be interpreted, and which may be ignored. Definitions for these common 1888 elements may be found in Appendix B. 1890 TicketExtensions ::= SEQUENCE OF SEQUENCE { 1891 te-type[0] INTEGER, 1892 te-data[1] OCTET STRING 1893 } 1895 te-data 1896 This field contains opaque data that must be carried with the ticket to 1897 support extensions to the Kerberos protocol including but not limited 1898 to some forms of inter-realm key exchange and plaintext authorization 1899 data. See appendix C for some common uses of this field. 1901 te-type 1902 This field specifies the format for the te-data subfield. All negative 1903 values are reserved for local use. Non-negative values are reserved for 1904 registered use. 1906 APOptions ::= BIT STRING 1907 -- reserved(0), 1908 -- use-session-key(1), 1909 -- mutual-required(2) 1911 TicketFlags ::= BIT STRING 1912 -- reserved(0), 1913 -- forwardable(1), 1914 -- forwarded(2), 1915 -- proxiable(3), 1916 -- proxy(4), 1917 -- may-postdate(5), 1918 -- postdated(6), 1919 -- invalid(7), 1920 -- renewable(8), 1921 -- initial(9), 1922 -- pre-authent(10), 1923 -- hw-authent(11), 1924 -- transited-policy-checked(12), 1925 -- ok-as-delegate(13) 1927 KDCOptions ::= BIT STRING io 1928 -- reserved(0), 1929 -- forwardable(1), 1930 -- forwarded(2), 1931 -- proxiable(3), 1932 -- proxy(4), 1933 -- allow-postdate(5), 1934 -- postdated(6), 1935 -- unused7(7), 1936 -- renewable(8), 1937 -- unused9(9), 1938 -- unused10(10), 1939 -- unused11(11), 1940 -- unused12(12), 1941 -- unused13(13), 1942 -- requestanonymous(14), 1943 -- canonicalize(15), 1944 -- disable-transited-check(26), 1945 -- renewable-ok(27), 1946 -- enc-tkt-in-skey(28), 1947 -- renew(30), 1948 -- validate(31) 1950 ASN.1 Bit strings have a length and a value. When used in Kerberos for the 1951 APOptions, TicketFlags, and KDCOptions, the length of the bit string on 1952 generated values should be the smallest number of bits needed to include the 1953 highest order bit that is set (1), but in no case less than 32 bits. The 1954 ASN.1 representation of the bit strings uses unnamed bits, with the meaning 1955 of the individual bits defined by the comments in the specification above. 1956 Implementations should accept values of bit strings of any length and treat 1957 the value of flags corresponding to bits beyond the end of the bit string as 1958 if the bit were reset (0). Comparison of bit strings of different length 1959 should treat the smaller string as if it were padded with zeros beyond the 1960 high order bits to the length of the longer string[23]. 1962 LastReq ::= SEQUENCE OF SEQUENCE { 1963 lr-type[0] INTEGER, 1964 lr-value[1] KerberosTime 1965 } 1967 lr-type 1968 This field indicates how the following lr-value field is to be 1969 interpreted. Negative values indicate that the information pertains 1970 only to the responding server. Non-negative values pertain to all 1971 servers for the realm. If the lr-type field is zero (0), then no 1972 information is conveyed by the lr-value subfield. If the absolute value 1973 of the lr-type field is one (1), then the lr-value subfield is the time 1974 of last initial request for a TGT. If it is two (2), then the lr-value 1975 subfield is the time of last initial request. If it is three (3), then 1976 the lr-value subfield is the time of issue for the newest 1977 ticket-granting ticket used. If it is four (4), then the lr-value 1978 subfield is the time of the last renewal. If it is five (5), then the 1979 lr-value subfield is the time of last request (of any type). If it is 1980 (6), then the lr-value subfield is the time when the password will 1981 expire. 1982 lr-value 1983 This field contains the time of the last request. the time must be 1984 interpreted according to the contents of the accompanying lr-type 1985 subfield. 1987 See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, 1988 EncryptionKey, EncryptionType, and KeyType. 1990 5.3. Tickets and Authenticators 1992 This section describes the format and encryption parameters for tickets and 1993 authenticators. When a ticket or authenticator is included in a protocol 1994 message it is treated as an opaque object. 1996 5.3.1. Tickets 1998 A ticket is a record that helps a client authenticate to a service. A Ticket 1999 contains the following information: 2001 Ticket ::= [APPLICATION 1] SEQUENCE { 2002 tkt-vno[0] INTEGER, 2003 realm[1] Realm, 2004 sname[2] PrincipalName, 2005 enc-part[3] EncryptedData, -- EncTicketPart 2006 extensions[4] TicketExtensions OPTIONAL 2007 } 2009 -- Encrypted part of ticket 2010 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2011 flags[0] TicketFlags, 2012 key[1] EncryptionKey, 2013 crealm[2] Realm, 2014 cname[3] PrincipalName, 2015 transited[4] TransitedEncoding, 2016 authtime[5] KerberosTime, 2017 starttime[6] KerberosTime OPTIONAL, 2018 endtime[7] KerberosTime, 2019 renew-till[8] KerberosTime OPTIONAL, 2020 caddr[9] HostAddresses OPTIONAL, 2021 authorization-data[10] AuthorizationData OPTIONAL 2022 } 2023 -- encoded Transited field 2024 TransitedEncoding ::= SEQUENCE { 2025 tr-type[0] INTEGER, -- must be registered 2026 contents[1] OCTET STRING 2027 } 2029 The encoding of EncTicketPart is encrypted in the key shared by Kerberos and 2030 the end server (the server's secret key). See section 6 for the format of 2031 the ciphertext. 2033 tkt-vno 2034 This field specifies the version number for the ticket format. This 2035 document describes version number 5. 2036 realm 2037 This field specifies the realm that issued a ticket. It also serves to 2038 identify the realm part of the server's principal identifier. Since a 2039 Kerberos server can only issue tickets for servers within its realm, 2040 the two will always be identical. 2041 sname 2042 This field specifies all components of the name part of the server's 2043 identity, including those parts that identify a specific instance of a 2044 service. 2045 enc-part 2046 This field holds the encrypted encoding of the EncTicketPart sequence. 2047 extensions 2048 This optional field contains a sequence of extensions that may be used 2049 to carry information that must be carried with the ticket to support 2050 several extensions, including but not limited to plaintext 2051 authorization data, tokens for exchanging inter-realm keys, and other 2052 information that must be associated with a ticket for use by the 2053 application server. See Appendix C for definitions of common 2054 extensions. 2056 Note that some older versions of Kerberos did not support this field. 2057 Because this is an optional field it will not break older clients, but 2058 older clients might strip this field from the ticket before sending it 2059 to the application server. This limits the usefulness of this ticket 2060 field to environments where the ticket will not be parsed and 2061 reconstructed by these older Kerberos clients. 2063 If it is known that the client will strip this field from the ticket, 2064 as an interim measure the KDC may append this field to the end of the 2065 enc-part of the ticket and append a trailer indicating the length of 2066 the appended extensions field. 2067 flags 2068 This field indicates which of various options were used or requested 2069 when the ticket was issued. It is a bit-field, where the selected 2070 options are indicated by the bit being set (1), and the unselected 2071 options and reserved fields being reset (0). Bit 0 is the most 2072 significant bit. The encoding of the bits is specified in section 5.2. 2073 The flags are described in more detail above in section 2. The meanings 2074 of the flags are: 2075 Bits Name Description 2077 0 RESERVED Reserved for future expansion of this 2078 field. 2080 The FORWARDABLE flag is normally only 2081 interpreted by the TGS, and can be 2082 ignored by end servers. When set, this 2083 1 FORWARDABLE flag tells the ticket-granting server 2084 that it is OK to issue a new 2085 ticket-granting ticket with a 2086 different network address based on the 2087 presented ticket. 2089 When set, this flag indicates that the 2090 ticket has either been forwarded or 2091 2 FORWARDED was issued based on authentication 2092 involving a forwarded ticket-granting 2093 ticket. 2095 The PROXIABLE flag is normally only 2096 interpreted by the TGS, and can be 2097 ignored by end servers. The PROXIABLE 2098 flag has an interpretation identical 2099 3 PROXIABLE to that of the FORWARDABLE flag, 2100 except that the PROXIABLE flag tells 2101 the ticket-granting server that only 2102 non-ticket-granting tickets may be 2103 issued with different network 2104 addresses. 2106 4 PROXY When set, this flag indicates that a 2107 ticket is a proxy. 2109 The MAY-POSTDATE flag is normally only 2110 interpreted by the TGS, and can be 2111 5 MAY-POSTDATE ignored by end servers. This flag 2112 tells the ticket-granting server that 2113 a post-dated ticket may be issued 2114 based on this ticket-granting ticket. 2116 This flag indicates that this ticket 2117 has been postdated. The end-service 2118 6 POSTDATED can check the authtime field to see 2119 when the original authentication 2120 occurred. 2122 This flag indicates that a ticket is 2123 invalid, and it must be validated by 2124 7 INVALID the KDC before use. Application 2125 servers must reject tickets which have 2126 this flag set. 2128 The RENEWABLE flag is normally only 2129 interpreted by the TGS, and can 2130 usually be ignored by end servers 2131 8 RENEWABLE (some particularly careful servers may 2132 wish to disallow renewable tickets). A 2133 renewable ticket can be used to obtain 2134 a replacement ticket that expires at a 2135 later date. 2137 This flag indicates that this ticket 2138 9 INITIAL was issued using the AS protocol, and 2139 not issued based on a ticket-granting 2140 ticket. 2142 This flag indicates that during 2143 initial authentication, the client was 2144 authenticated by the KDC before a 2145 10 PRE-AUTHENT ticket was issued. The strength of the 2146 preauthentication method is not 2147 indicated, but is acceptable to the 2148 KDC. 2150 This flag indicates that the protocol 2151 employed for initial authentication 2152 required the use of hardware expected 2153 11 HW-AUTHENT to be possessed solely by the named 2154 client. The hardware authentication 2155 method is selected by the KDC and the 2156 strength of the method is not 2157 indicated. 2159 This flag indicates that the KDC for 2160 the realm has checked the transited 2161 field against a realm defined policy 2162 for trusted certifiers. If this flag 2163 is reset (0), then the application 2164 server must check the transited field 2165 itself, and if unable to do so it must 2166 12 TRANSITED- reject the authentication. If the flag 2167 POLICY-CHECKED 2168 is set (1) then the application server 2169 may skip its own validation of the 2170 transited field, relying on the 2171 validation performed by the KDC. At 2172 its option the application server may 2173 still apply its own validation based 2174 on a separate policy for acceptance. 2176 This flag indicates that the server 2177 (not the client) specified in the 2178 ticket has been determined by policy 2179 of the realm to be a suitable 2180 recipient of delegation. A client can 2181 use the presence of this flag to help 2182 it make a decision whether to delegate 2183 credentials (either grant a proxy or a 2184 13 OK-AS-DELEGATE forwarded ticket granting ticket) to 2185 this server. The client is free to 2186 ignore the value of this flag. When 2187 setting this flag, an administrator 2188 should consider the Security and 2189 placement of the server on which the 2190 service will run, as well as whether 2191 the service requires the use of 2192 delegated credentials. 2194 This flag indicates that the principal 2195 named in the ticket is a generic 2196 principal for the realm and does not 2197 identify the individual using the 2198 ticket. The purpose of the ticket is 2199 only to securely distribute a session 2200 14 ANONYMOUS key, and not to identify the user. 2201 Subsequent requests using the same 2202 ticket and session may be considered 2203 as originating from the same user, but 2204 requests with the same username but a 2205 different ticket are likely to 2206 originate from different users. 2208 15-31 RESERVED Reserved for future use. 2209 key 2210 This field exists in the ticket and the KDC response and is used to 2211 pass the session key from Kerberos to the application server and the 2212 client. The field's encoding is described in section 6.2. 2213 crealm 2214 This field contains the name of the realm in which the client is 2215 registered and in which initial authentication took place. 2216 cname 2217 This field contains the name part of the client's principal identifier. 2219 transited 2220 This field lists the names of the Kerberos realms that took part in 2221 authenticating the user to whom this ticket was issued. It does not 2222 specify the order in which the realms were transited. See section 2223 3.3.3.2 for details on how this field encodes the traversed realms. 2224 When the names of CA's are to be embedded in the transited field (as 2225 specified for some extensions to the protocol), the X.500 names of the 2226 CA's should be mapped into items in the transited field using the 2227 mapping defined by RFC2253. 2228 authtime 2229 This field indicates the time of initial authentication for the named 2230 principal. It is the time of issue for the original ticket on which 2231 this ticket is based. It is included in the ticket to provide 2232 additional information to the end service, and to provide the necessary 2233 information for implementation of a `hot list' service at the KDC. An 2234 end service that is particularly paranoid could refuse to accept 2235 tickets for which the initial authentication occurred "too far" in the 2236 past. This field is also returned as part of the response from the KDC. 2237 When returned as part of the response to initial authentication 2238 (KRB_AS_REP), this is the current time on the Kerberos server[24]. 2239 starttime 2240 This field in the ticket specifies the time after which the ticket is 2241 valid. Together with endtime, this field specifies the life of the 2242 ticket. If it is absent from the ticket, its value should be treated as 2243 that of the authtime field. 2244 endtime 2245 This field contains the time after which the ticket will not be honored 2246 (its expiration time). Note that individual services may place their 2247 own limits on the life of a ticket and may reject tickets which have 2248 not yet expired. As such, this is really an upper bound on the 2249 expiration time for the ticket. 2250 renew-till 2251 This field is only present in tickets that have the RENEWABLE flag set 2252 in the flags field. It indicates the maximum endtime that may be 2253 included in a renewal. It can be thought of as the absolute expiration 2254 time for the ticket, including all renewals. 2255 caddr 2256 This field in a ticket contains zero (if omitted) or more (if present) 2257 host addresses. These are the addresses from which the ticket can be 2258 used. If there are no addresses, the ticket can be used from any 2259 location. The decision by the KDC to issue or by the end server to 2260 accept zero-address tickets is a policy decision and is left to the 2261 Kerberos and end-service administrators; they may refuse to issue or 2262 accept such tickets. The suggested and default policy, however, is that 2263 such tickets will only be issued or accepted when additional 2264 information that can be used to restrict the use of the ticket is 2265 included in the authorization_data field. Such a ticket is a 2266 capability. 2268 Network addresses are included in the ticket to make it harder for an 2269 attacker to use stolen credentials. Because the session key is not sent 2270 over the network in cleartext, credentials can't be stolen simply by 2271 listening to the network; an attacker has to gain access to the session 2272 key (perhaps through operating system security breaches or a careless 2273 user's unattended session) to make use of stolen tickets. 2275 It is important to note that the network address from which a 2276 connection is received cannot be reliably determined. Even if it could 2277 be, an attacker who has compromised the client's workstation could use 2278 the credentials from there. Including the network addresses only makes 2279 it more difficult, not impossible, for an attacker to walk off with 2280 stolen credentials and then use them from a "safe" location. 2281 authorization-data 2282 The authorization-data field is used to pass authorization data from 2283 the principal on whose behalf a ticket was issued to the application 2284 service. If no authorization data is included, this field will be left 2285 out. Experience has shown that the name of this field is confusing, and 2286 that a better name for this field would be restrictions. Unfortunately, 2287 it is not possible to change the name of this field at this time. 2289 This field contains restrictions on any authority obtained on the basis 2290 of authentication using the ticket. It is possible for any principal in 2291 posession of credentials to add entries to the authorization data field 2292 since these entries further restrict what can be done with the ticket. 2293 Such additions can be made by specifying the additional entries when a 2294 new ticket is obtained during the TGS exchange, or they may be added 2295 during chained delegation using the authorization data field of the 2296 authenticator. 2298 Because entries may be added to this field by the holder of 2299 credentials, except when an entry is separately authenticated by 2300 encapsulation in the kdc-issued element, it is not allowable for the 2301 presence of an entry in the authorization data field of a ticket to 2302 amplify the privileges one would obtain from using a ticket. 2304 The data in this field may be specific to the end service; the field 2305 will contain the names of service specific objects, and the rights to 2306 those objects. The format for this field is described in section 5.2. 2307 Although Kerberos is not concerned with the format of the contents of 2308 the sub-fields, it does carry type information (ad-type). 2310 By using the authorization_data field, a principal is able to issue a 2311 proxy that is valid for a specific purpose. For example, a client 2312 wishing to print a file can obtain a file server proxy to be passed to 2313 the print server. By specifying the name of the file in the 2314 authorization_data field, the file server knows that the print server 2315 can only use the client's rights when accessing the particular file to 2316 be printed. 2318 A separate service providing authorization or certifying group 2319 membership may be built using the authorization-data field. In this 2320 case, the entity granting authorization (not the authorized entity), 2321 may obtain a ticket in its own name (e.g. the ticket is issued in the 2322 name of a privilege server), and this entity adds restrictions on its 2323 own authority and delegates the restricted authority through a proxy to 2324 the client. The client would then present this authorization credential 2325 to the application server separately from the authentication exchange. 2326 Alternatively, such authorization credentials may be embedded in the 2327 ticket authenticating the authorized entity, when the authorization is 2328 separately authenticated using the kdc-issued authorization data 2329 element (see B.4). 2331 Similarly, if one specifies the authorization-data field of a proxy and 2332 leaves the host addresses blank, the resulting ticket and session key 2333 can be treated as a capability. See [Neu93] for some suggested uses of 2334 this field. 2336 The authorization-data field is optional and does not have to be 2337 included in a ticket. 2339 5.3.2. Authenticators 2341 An authenticator is a record sent with a ticket to a server to certify the 2342 client's knowledge of the encryption key in the ticket, to help the server 2343 detect replays, and to help choose a "true session key" to use with the 2344 particular session. The encoding is encrypted in the ticket's session key 2345 shared by the client and the server: 2347 -- Unencrypted authenticator 2348 Authenticator ::= [APPLICATION 2] SEQUENCE { 2349 authenticator-vno[0] INTEGER, 2350 crealm[1] Realm, 2351 cname[2] PrincipalName, 2352 cksum[3] Checksum OPTIONAL, 2353 cusec[4] INTEGER, 2354 ctime[5] KerberosTime, 2355 subkey[6] EncryptionKey OPTIONAL, 2356 seq-number[7] INTEGER OPTIONAL, 2357 authorization-data[8] AuthorizationData OPTIONAL 2358 } 2360 authenticator-vno 2361 This field specifies the version number for the format of the 2362 authenticator. This document specifies version 5. 2363 crealm and cname 2364 These fields are the same as those described for the ticket in section 2365 5.3.1. 2366 cksum 2367 This field contains a checksum of the the application data that 2368 accompanies the KRB_AP_REQ. 2369 cusec 2370 This field contains the microsecond part of the client's timestamp. Its 2371 value (before encryption) ranges from 0 to 999999. It often appears 2372 along with ctime. The two fields are used together to specify a 2373 reasonably accurate timestamp. 2374 ctime 2375 This field contains the current time on the client's host. 2376 subkey 2377 This field contains the client's choice for an encryption key which is 2378 to be used to protect this specific application session. Unless an 2379 application specifies otherwise, if this field is left out the session 2380 key from the ticket will be used. 2381 seq-number 2382 This optional field includes the initial sequence number to be used by 2383 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 2384 detect replays (It may also be used by application specific messages). 2385 When included in the authenticator this field specifies the initial 2386 sequence number for messages from the client to the server. When 2387 included in the AP-REP message, the initial sequence number is that for 2388 messages from the server to the client. When used in KRB_PRIV or 2389 KRB_SAFE messages, it is incremented by one after each message is sent. 2390 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to 2391 zero following the value 2^32 - 1. 2393 For sequence numbers to adequately support the detection of replays 2394 they should be non-repeating, even across connection boundaries. The 2395 initial sequence number should be random and uniformly distributed 2396 across the full space of possible sequence numbers, so that it cannot 2397 be guessed by an attacker and so that it and the successive sequence 2398 numbers do not repeat other sequences. 2399 authorization-data 2400 This field is the same as described for the ticket in section 5.3.1. It 2401 is optional and will only appear when additional restrictions are to be 2402 placed on the use of a ticket, beyond those carried in the ticket 2403 itself. 2405 5.4. Specifications for the AS and TGS exchanges 2407 This section specifies the format of the messages used in the exchange 2408 between the client and the Kerberos server. The format of possible error 2409 messages appears in section 5.9.1. 2411 5.4.1. KRB_KDC_REQ definition 2413 The KRB_KDC_REQ message has no type of its own. Instead, its type is one of 2414 KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial 2415 ticket or an additional ticket. In either case, the message is sent from the 2416 client to the Authentication Server to request credentials for a service. 2418 The message fields are: 2420 AS-REQ ::= [APPLICATION 10] KDC-REQ 2421 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2423 KDC-REQ ::= SEQUENCE { 2424 pvno[1] INTEGER, 2425 msg-type[2] INTEGER, 2426 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2427 req-body[4] KDC-REQ-BODY 2428 } 2430 PA-DATA ::= SEQUENCE { 2431 padata-type[1] INTEGER, 2432 padata-value[2] OCTET STRING, 2433 -- might be encoded AP-REQ 2434 } 2436 KDC-REQ-BODY ::= SEQUENCE { 2437 kdc-options[0] KDCOptions, 2438 cname[1] PrincipalName OPTIONAL, 2439 -- Used only in AS-REQ 2440 realm[2] Realm, -- Server's realm 2441 -- Also client's in AS-REQ 2442 sname[3] PrincipalName OPTIONAL, 2443 from[4] KerberosTime OPTIONAL, 2444 till[5] KerberosTime OPTIONAL, 2445 rtime[6] KerberosTime OPTIONAL, 2446 nonce[7] INTEGER, 2447 etype[8] SEQUENCE OF INTEGER, 2448 -- EncryptionType, 2449 -- in preference order 2450 addresses[9] HostAddresses OPTIONAL, 2451 enc-authorization-data[10] EncryptedData OPTIONAL, 2452 -- Encrypted AuthorizationData 2453 -- encoding 2454 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2455 } 2457 The fields in this message are: 2459 pvno 2460 This field is included in each message, and specifies the protocol 2461 version number. This document specifies protocol version 5. 2462 msg-type 2463 This field indicates the type of a protocol message. It will almost 2464 always be the same as the application identifier associated with a 2465 message. It is included to make the identifier more readily accessible 2466 to the application. For the KDC-REQ message, this type will be 2467 KRB_AS_REQ or KRB_TGS_REQ. 2469 padata 2470 The padata (pre-authentication data) field contains a sequence of 2471 authentication information which may be needed before credentials can 2472 be issued or decrypted. In the case of requests for additional tickets 2473 (KRB_TGS_REQ), this field will include an element with padata-type of 2474 PA-TGS-REQ and data of an authentication header (ticket-granting ticket 2475 and authenticator). The checksum in the authenticator (which must be 2476 collision-proof) is to be computed over the KDC-REQ-BODY encoding. In 2477 most requests for initial authentication (KRB_AS_REQ) and most replies 2478 (KDC-REP), the padata field will be left out. 2480 This field may also contain information needed by certain extensions to 2481 the Kerberos protocol. For example, it might be used to initially 2482 verify the identity of a client before any response is returned. When 2483 this field is used to authenticate or pre-authenticate a request, it 2484 should contain a keyed checksum over the KDC-REQ-BODY to bind the 2485 pre-authentication data to rest of the request. The KDC, as a matter of 2486 policy, may decide whether to honor a KDC-REQ which includes any 2487 pre-authentication data that does not contain the checksum field. 2489 PA-ENC-TIMESTAMP defines a pre-authentication data type that is used 2490 for authenticating a client by way of an encrypted timestamp. This is 2491 accomplished with a padata field with padata-type equal to 2492 PA-ENC-TIMESTAMP and padata-value defined as follows (query: the 2493 checksum is new in this definition. If the optional field will break 2494 things we can keep the old PA-ENC-TS-ENC, and define a new alternate 2495 form that includes the checksum). : 2497 padata-type ::= PA-ENC-TIMESTAMP 2498 padata-value ::= EncryptedData -- PA-ENC-TS-ENC 2500 PA-ENC-TS-ENC ::= SEQUENCE { 2501 patimestamp[0] KerberosTime, -- client's time 2502 pausec[1] INTEGER OPTIONAL, 2503 pachecksum[2] checksum OPTIONAL 2504 -- keyed checksum of KDC-REQ-BODY 2505 } 2507 with patimestamp containing the client's time and pausec containing the 2508 microseconds which may be omitted if a client will not generate more 2509 than one request per second. The ciphertext (padata-value) consists of 2510 the PA-ENC-TS-ENC sequence, encrypted using the client's secret key. 2512 It may also be used by the client to specify the version of a key that 2513 is being used for accompanying preauthentication, and/or which should 2514 be used to encrypt the reply from the KDC. 2516 padata-type ::= PA-USE-SPECIFIED-KVNO 2517 padata-value ::= Integer 2518 } 2520 The KDC should only accept and abide by the value of the 2521 use-specified-kvno preauthentication data field when the specified key 2522 is still valid and until use of a new key is confirmed. This situation 2523 is likely to occur primarily during the period during which an updated 2524 key is propagating to other KDC's in a realm. 2526 The padata field can also contain information needed to help the KDC or 2527 the client select the key needed for generating or decrypting the 2528 response. This form of the padata is useful for supporting the use of 2529 certain token cards with Kerberos. The details of such extensions are 2530 specified in separate documents. See [Pat92] for additional uses of 2531 this field. 2532 padata-type 2533 The padata-type element of the padata field indicates the way that the 2534 padata-value element is to be interpreted. Negative values of 2535 padata-type are reserved for unregistered use; non-negative values are 2536 used for a registered interpretation of the element type. 2537 req-body 2538 This field is a placeholder delimiting the extent of the remaining 2539 fields. If a checksum is to be calculated over the request, it is 2540 calculated over an encoding of the KDC-REQ-BODY sequence which is 2541 enclosed within the req-body field. 2542 kdc-options 2543 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2544 KDC and indicates the flags that the client wants set on the tickets as 2545 well as other information that is to modify the behavior of the KDC. 2546 Where appropriate, the name of an option may be the same as the flag 2547 that is set by that option. Although in most case, the bit in the 2548 options field will be the same as that in the flags field, this is not 2549 guaranteed, so it is not acceptable to simply copy the options field to 2550 the flags field. There are various checks that must be made before 2551 honoring an option anyway. 2553 The kdc_options field is a bit-field, where the selected options are 2554 indicated by the bit being set (1), and the unselected options and 2555 reserved fields being reset (0). The encoding of the bits is specified 2556 in section 5.2. The options are described in more detail above in 2557 section 2. The meanings of the options are: 2558 Bits Name Description 2560 0 RESERVED Reserved for future expansion of 2561 this field. 2563 The FORWARDABLE option indicates 2564 that the ticket to be issued is to 2565 have its forwardable flag set. It 2566 1 FORWARDABLE may only be set on the initial 2567 request, or in a subsequent request 2568 if the ticket-granting ticket on 2569 which it is based is also 2570 forwardable. 2572 The FORWARDED option is only 2573 specified in a request to the 2574 ticket-granting server and will only 2575 be honored if the ticket-granting 2576 ticket in the request has its 2577 2 FORWARDED FORWARDABLE bit set. This option 2578 indicates that this is a request for 2579 forwarding. The address(es) of the 2580 host from which the resulting ticket 2581 is to be valid are included in the 2582 addresses field of the request. 2584 The PROXIABLE option indicates that 2585 the ticket to be issued is to have 2586 its proxiable flag set. It may only 2587 3 PROXIABLE be set on the initial request, or in 2588 a subsequent request if the 2589 ticket-granting ticket on which it 2590 is based is also proxiable. 2592 The PROXY option indicates that this 2593 is a request for a proxy. This 2594 option will only be honored if the 2595 ticket-granting ticket in the 2596 4 PROXY request has its PROXIABLE bit set. 2597 The address(es) of the host from 2598 which the resulting ticket is to be 2599 valid are included in the addresses 2600 field of the request. 2602 The ALLOW-POSTDATE option indicates 2603 that the ticket to be issued is to 2604 have its MAY-POSTDATE flag set. It 2605 5 ALLOW-POSTDATE may only be set on the initial 2606 request, or in a subsequent request 2607 if the ticket-granting ticket on 2608 which it is based also has its 2609 MAY-POSTDATE flag set. 2611 The POSTDATED option indicates that 2612 this is a request for a postdated 2613 ticket. This option will only be 2614 honored if the ticket-granting 2615 ticket on which it is based has its 2616 6 POSTDATED MAY-POSTDATE flag set. The resulting 2617 ticket will also have its INVALID 2618 flag set, and that flag may be reset 2619 by a subsequent request to the KDC 2620 after the starttime in the ticket 2621 has been reached. 2623 7 UNUSED This option is presently unused. 2625 The RENEWABLE option indicates that 2626 the ticket to be issued is to have 2627 its RENEWABLE flag set. It may only 2628 be set on the initial request, or 2629 when the ticket-granting ticket on 2630 8 RENEWABLE which the request is based is also 2631 renewable. If this option is 2632 requested, then the rtime field in 2633 the request contains the desired 2634 absolute expiration time for the 2635 ticket. 2637 9 RESERVED Reserved for PK-Cross 2639 10-13 UNUSED These options are presently unused. 2641 The REQUEST-ANONYMOUS option 2642 indicates that the ticket to be 2643 issued is not to identify the user 2644 to which it was issued. Instead, the 2645 principal identifier is to be 2646 generic, as specified by the policy 2647 of the realm (e.g. usually 2648 14 REQUEST-ANONYMOUS anonymous@realm). The purpose of the 2649 ticket is only to securely 2650 distribute a session key, and not to 2651 identify the user. The ANONYMOUS 2652 flag on the ticket to be returned 2653 should be set. If the local realms 2654 policy does not permit anonymous 2655 credentials, the request is to be 2656 rejected. 2658 The CANONICALIZE option indicates 2659 that the client will accept the 2660 return of a true server name instead 2661 of the name specified in the 2662 request. In addition the client will 2663 be able to process any TGT referrals 2664 that will direct the client to 2665 15 CANONICALIZE another realm to locate the 2666 requested server. If a KDC does not 2667 support name- canonicalization, the 2668 option is ignored and the 2669 appropriate 2670 KDC_ERR_C_PRINCIPAL_UNKNOWN or 2671 KDC_ERR_S_PRINCIPAL_UNKNOWN error is 2672 returned. [JBrezak] 2674 16-25 RESERVED Reserved for future use. 2676 By default the KDC will check the 2677 transited field of a 2678 ticket-granting-ticket against the 2679 policy of the local realm before it 2680 will issue derivative tickets based 2681 on the ticket granting ticket. If 2682 this flag is set in the request, 2683 checking of the transited field is 2684 26 DISABLE-TRANSITED-CHECK disabled. Tickets issued without the 2685 performance of this check will be 2686 noted by the reset (0) value of the 2687 TRANSITED-POLICY-CHECKED flag, 2688 indicating to the application server 2689 that the tranisted field must be 2690 checked locally. KDC's are 2691 encouraged but not required to honor 2692 the DISABLE-TRANSITED-CHECK option. 2694 The RENEWABLE-OK option indicates 2695 that a renewable ticket will be 2696 acceptable if a ticket with the 2697 requested life cannot otherwise be 2698 provided. If a ticket with the 2699 requested life cannot be provided, 2700 27 RENEWABLE-OK then a renewable ticket may be 2701 issued with a renew-till equal to 2702 the the requested endtime. The value 2703 of the renew-till field may still be 2704 limited by local limits, or limits 2705 selected by the individual principal 2706 or server. 2708 This option is used only by the 2709 ticket-granting service. The 2710 ENC-TKT-IN-SKEY option indicates 2711 28 ENC-TKT-IN-SKEY that the ticket for the end server 2712 is to be encrypted in the session 2713 key from the additional 2714 ticket-granting ticket provided. 2716 29 RESERVED Reserved for future use. 2718 This option is used only by the 2719 ticket-granting service. The RENEW 2720 option indicates that the present 2721 request is for a renewal. The ticket 2722 provided is encrypted in the secret 2723 key for the server on which it is 2724 30 RENEW valid. This option will only be 2725 honored if the ticket to be renewed 2726 has its RENEWABLE flag set and if 2727 the time in its renew-till field has 2728 not passed. The ticket to be renewed 2729 is passed in the padata field as 2730 part of the authentication header. 2732 This option is used only by the 2733 ticket-granting service. The 2734 VALIDATE option indicates that the 2735 request is to validate a postdated 2736 ticket. It will only be honored if 2737 the ticket presented is postdated, 2738 presently has its INVALID flag set, 2739 31 VALIDATE and would be otherwise usable at 2740 this time. A ticket cannot be 2741 validated before its starttime. The 2742 ticket presented for validation is 2743 encrypted in the key of the server 2744 for which it is valid and is passed 2745 in the padata field as part of the 2746 authentication header. 2747 cname and sname 2748 These fields are the same as those described for the ticket in section 2749 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is 2750 specified. If absent, the name of the server is taken from the name of 2751 the client in the ticket passed as additional-tickets. 2752 enc-authorization-data 2753 The enc-authorization-data, if present (and it can only be present in 2754 the TGS_REQ form), is an encoding of the desired authorization-data 2755 encrypted under the sub-session key if present in the Authenticator, or 2756 alternatively from the session key in the ticket-granting ticket, both 2757 from the padata field in the KRB_AP_REQ. 2758 realm 2759 This field specifies the realm part of the server's principal 2760 identifier. In the AS exchange, this is also the realm part of the 2761 client's principal identifier. If the CANONICALIZE option is set, the 2762 realm is used as a hint to the KDC for its database lookup. 2763 from 2764 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 2765 requests when the requested ticket is to be postdated. It specifies the 2766 desired start time for the requested ticket. If this field is omitted 2767 then the KDC should use the current time instead. 2768 till 2769 This field contains the expiration date requested by the client in a 2770 ticket request. It is optional and if omitted the requested ticket is 2771 to have the maximum endtime permitted according to KDC policy for the 2772 parties to the authentication exchange as limited by expiration date of 2773 the ticket granting ticket or other preauthentication credentials. 2774 rtime 2775 This field is the requested renew-till time sent from a client to the 2776 KDC in a ticket request. It is optional. 2777 nonce 2778 This field is part of the KDC request and response. It it intended to 2779 hold a random number generated by the client. If the same number is 2780 included in the encrypted response from the KDC, it provides evidence 2781 that the response is fresh and has not been replayed by an attacker. 2782 Nonces must never be re-used. Ideally, it should be generated randomly, 2783 but if the correct time is known, it may suffice[25]. 2784 etype 2785 This field specifies the desired encryption algorithm to be used in the 2786 response. 2787 addresses 2788 This field is included in the initial request for tickets, and 2789 optionally included in requests for additional tickets from the 2790 ticket-granting server. It specifies the addresses from which the 2791 requested ticket is to be valid. Normally it includes the addresses for 2792 the client's host. If a proxy is requested, this field will contain 2793 other addresses. The contents of this field are usually copied by the 2794 KDC into the caddr field of the resulting ticket. 2796 additional-tickets 2797 Additional tickets may be optionally included in a request to the 2798 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 2799 specified, then the session key from the additional ticket will be used 2800 in place of the server's key to encrypt the new ticket. When he 2801 ENC-TKT-IN-SKEY option is used for user-to-user authentication, this 2802 addional ticket may be a TGT issued by the local realm or an 2803 inter-realm TGT issued for the current KDC's realm by a remote KDC. If 2804 more than one option which requires additional tickets has been 2805 specified, then the additional tickets are used in the order specified 2806 by the ordering of the options bits (see kdc-options, above). 2808 The application code will be either ten (10) or twelve (12) depending on 2809 whether the request is for an initial ticket (AS-REQ) or for an additional 2810 ticket (TGS-REQ). 2812 The optional fields (addresses, authorization-data and additional-tickets) 2813 are only included if necessary to perform the operation specified in the 2814 kdc-options field. 2816 It should be noted that in KRB_TGS_REQ, the protocol version number appears 2817 twice and two different message types appear: the KRB_TGS_REQ message 2818 contains these fields as does the authentication header (KRB_AP_REQ) that is 2819 passed in the padata field. 2821 5.4.2. KRB_KDC_REP definition 2823 The KRB_KDC_REP message format is used for the reply from the KDC for either 2824 an initial (AS) request or a subsequent (TGS) request. There is no message 2825 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 2826 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 2827 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 2828 the client's secret key, and the client's key version number is included in 2829 the key version number for the encrypted data. For KRB_TGS_REP, the 2830 ciphertext is encrypted in the sub-session key from the Authenticator, or if 2831 absent, the session key from the ticket-granting ticket used in the request. 2832 In that case, no version number will be present in the EncryptedData 2833 sequence. 2835 The KRB_KDC_REP message contains the following fields: 2837 AS-REP ::= [APPLICATION 11] KDC-REP 2838 TGS-REP ::= [APPLICATION 13] KDC-REP 2840 KDC-REP ::= SEQUENCE { 2841 pvno[0] INTEGER, 2842 msg-type[1] INTEGER, 2843 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 2844 crealm[3] Realm, 2845 cname[4] PrincipalName, 2846 ticket[5] Ticket, 2847 enc-part[6] EncryptedData 2848 -- EncASREpPart or EncTGSReoOart 2849 } 2851 EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart 2852 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 2854 EncKDCRepPart ::= SEQUENCE { 2855 key[0] EncryptionKey, 2856 last-req[1] LastReq, 2857 nonce[2] INTEGER, 2858 key-expiration[3] KerberosTime OPTIONAL, 2859 flags[4] TicketFlags, 2860 authtime[5] KerberosTime, 2861 starttime[6] KerberosTime OPTIONAL, 2862 endtime[7] KerberosTime, 2863 renew-till[8] KerberosTime OPTIONAL, 2864 srealm[9] Realm, 2865 sname[10] PrincipalName, 2866 caddr[11] HostAddresses OPTIONAL 2867 } 2869 pvno and msg-type 2870 These fields are described above in section 5.4.1. msg-type is either 2871 KRB_AS_REP or KRB_TGS_REP. 2872 padata 2873 This field is described in detail in section 5.4.1. One possible use 2874 for this field is to encode an alternate "mix-in" string to be used 2875 with a string-to-key algorithm (such as is described in section 6.3.2). 2876 This ability is useful to ease transitions if a realm name needs to 2877 change (e.g. when a company is acquired); in such a case all existing 2878 password-derived entries in the KDC database would be flagged as 2879 needing a special mix-in string until the next password change. 2880 crealm, cname, srealm and sname 2881 These fields are the same as those described for the ticket in section 2882 5.3.1. 2883 ticket 2884 The newly-issued ticket, from section 5.3.1. 2885 enc-part 2886 This field is a place holder for the ciphertext and related information 2887 that forms the encrypted part of a message. The description of the 2888 encrypted part of the message follows each appearance of this field. 2889 The encrypted part is encoded as described in section 6.1. 2890 key 2891 This field is the same as described for the ticket in section 5.3.1. 2893 last-req 2894 This field is returned by the KDC and specifies the time(s) of the last 2895 request by a principal. Depending on what information is available, 2896 this might be the last time that a request for a ticket-granting ticket 2897 was made, or the last time that a request based on a ticket-granting 2898 ticket was successful. It also might cover all servers for a realm, or 2899 just the particular server. Some implementations may display this 2900 information to the user to aid in discovering unauthorized use of one's 2901 identity. It is similar in spirit to the last login time displayed when 2902 logging into timesharing systems. 2903 nonce 2904 This field is described above in section 5.4.1. 2905 key-expiration 2906 The key-expiration field is part of the response from the KDC and 2907 specifies the time that the client's secret key is due to expire. The 2908 expiration might be the result of password aging or an account 2909 expiration. This field will usually be left out of the TGS reply since 2910 the response to the TGS request is encrypted in a session key and no 2911 client information need be retrieved from the KDC database. It is up to 2912 the application client (usually the login program) to take appropriate 2913 action (such as notifying the user) if the expiration time is imminent. 2914 flags, authtime, starttime, endtime, renew-till and caddr 2915 These fields are duplicates of those found in the encrypted portion of 2916 the attached ticket (see section 5.3.1), provided so the client may 2917 verify they match the intended request and to assist in proper ticket 2918 caching. If the message is of type KRB_TGS_REP, the caddr field will 2919 only be filled in if the request was for a proxy or forwarded ticket, 2920 or if the user is substituting a subset of the addresses from the 2921 ticket granting ticket. If the client-requested addresses are not 2922 present or not used, then the addresses contained in the ticket will be 2923 the same as those included in the ticket-granting ticket. 2925 5.5. Client/Server (CS) message specifications 2927 This section specifies the format of the messages used for the 2928 authentication of the client to the application server. 2930 5.5.1. KRB_AP_REQ definition 2932 The KRB_AP_REQ message contains the Kerberos protocol version number, the 2933 message type KRB_AP_REQ, an options field to indicate any options in use, 2934 and the ticket and authenticator themselves. The KRB_AP_REQ message is often 2935 referred to as the 'authentication header'. 2937 AP-REQ ::= [APPLICATION 14] SEQUENCE { 2938 pvno[0] INTEGER, 2939 msg-type[1] INTEGER, 2940 ap-options[2] APOptions, 2941 ticket[3] Ticket, 2942 authenticator[4] EncryptedData 2943 -- Authenticator from 5.3.2 2944 } 2946 APOptions ::= BIT STRING { 2947 reserved(0), 2948 use-session-key(1), 2949 mutual-required(2) 2950 } 2951 pvno and msg-type 2952 These fields are described above in section 5.4.1. msg-type is 2953 KRB_AP_REQ. 2954 ap-options 2955 This field appears in the application request (KRB_AP_REQ) and affects 2956 the way the request is processed. It is a bit-field, where the selected 2957 options are indicated by the bit being set (1), and the unselected 2958 options and reserved fields being reset (0). The encoding of the bits 2959 is specified in section 5.2. The meanings of the options are: 2961 Bit(s) Name Description 2963 0 RESERVED 2964 Reserved for future expansion of this 2965 field. 2967 1 USE-SESSION-KEY 2968 The USE-SESSION-KEY option indicates 2969 that the ticket the client is presenting 2970 to a server is encrypted in the session 2971 key from the server's ticket-granting 2972 ticket. When this option is not speci- 2973 fied, the ticket is encrypted in the 2974 server's secret key. 2976 2 MUTUAL-REQUIRED 2977 The MUTUAL-REQUIRED option tells the 2978 server that the client requires mutual 2979 authentication, and that it must respond 2980 with a KRB_AP_REP message. 2982 3-31 RESERVED 2983 Reserved for future use. 2985 ticket 2986 This field is a ticket authenticating the client to the server. 2987 authenticator 2988 This contains the authenticator, which includes the client's choice of 2989 a subkey. Its encoding is described in section 5.3.2. 2991 5.5.2. KRB_AP_REP definition 2993 The KRB_AP_REP message contains the Kerberos protocol version number, the 2994 message type, and an encrypted time- stamp. The message is sent in in 2995 response to an application request (KRB_AP_REQ) where the mutual 2996 authentication option has been selected in the ap-options field. 2998 AP-REP ::= [APPLICATION 15] SEQUENCE { 2999 pvno[0] INTEGER, 3000 msg-type[1] INTEGER, 3001 enc-part[2] EncryptedData 3002 -- EncAPRepPart 3003 } 3004 EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { 3005 ctime[0] KerberosTime, 3006 cusec[1] INTEGER, 3007 subkey[2] EncryptionKey OPTIONAL, 3008 seq-number[3] INTEGER OPTIONAL 3009 } 3011 The encoded EncAPRepPart is encrypted in the shared session key of the 3012 ticket. The optional subkey field can be used in an application-arranged 3013 negotiation to choose a per association session key. 3015 pvno and msg-type 3016 These fields are described above in section 5.4.1. msg-type is 3017 KRB_AP_REP. 3018 enc-part 3019 This field is described above in section 5.4.2. 3020 ctime 3021 This field contains the current time on the client's host. 3022 cusec 3023 This field contains the microsecond part of the client's timestamp. 3024 subkey 3025 This field contains an encryption key which is to be used to protect 3026 this specific application session. See section 3.2.6 for specifics on 3027 how this field is used to negotiate a key. Unless an application 3028 specifies otherwise, if this field is left out, the sub-session key 3029 from the authenticator, or if also left out, the session key from the 3030 ticket will be used. 3031 seq-number 3032 This field is described above in section 5.3.2. 3034 5.5.3. Error message reply 3036 If an error occurs while processing the application request, the KRB_ERROR 3037 message will be sent in response. See section 5.9.1 for the format of the 3038 error message. The cname and crealm fields may be left out if the server 3039 cannot determine their appropriate values from the corresponding KRB_AP_REQ 3040 message. If the authenticator was decipherable, the ctime and cusec fields 3041 will contain the values from it. 3043 5.6. KRB_SAFE message specification 3045 This section specifies the format of a message that can be used by either 3046 side (client or server) of an application to send a tamper-proof message to 3047 its peer. It presumes that a session key has previously been exchanged (for 3048 example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3050 5.6.1. KRB_SAFE definition 3052 The KRB_SAFE message contains user data along with a collision-proof 3053 checksum keyed with the last encryption key negotiated via subkeys, or the 3054 session key if no negotiation has occurred. The message fields are: 3056 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3057 pvno[0] INTEGER, 3058 msg-type[1] INTEGER, 3059 safe-body[2] KRB-SAFE-BODY, 3060 cksum[3] Checksum 3061 } 3062 KRB-SAFE-BODY ::= SEQUENCE { 3063 user-data[0] OCTET STRING, 3064 timestamp[1] KerberosTime OPTIONAL, 3065 usec[2] INTEGER OPTIONAL, 3066 seq-number[3] INTEGER OPTIONAL, 3067 s-address[4] HostAddress OPTIONAL, 3068 r-address[5] HostAddress OPTIONAL 3069 } 3071 pvno and msg-type 3072 These fields are described above in section 5.4.1. msg-type is 3073 KRB_SAFE. 3074 safe-body 3075 This field is a placeholder for the body of the KRB-SAFE message. 3076 cksum 3077 This field contains the checksum of the application data. Checksum 3078 details are described in section 6.4. The checksum is computed over the 3079 encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the 3080 checksum is computed over the encoding of the KRB-SAFE sequence, then 3081 the checksum is set to the result of that computation, and finally the 3082 KRB-SAFE sequence is encoded again. 3083 user-data 3084 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 3085 the application specific data that is being passed from the sender to 3086 the recipient. 3087 timestamp 3088 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 3089 are the current time as known by the sender of the message. By checking 3090 the timestamp, the recipient of the message is able to make sure that 3091 it was recently generated, and is not a replay. 3092 usec 3093 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 3094 the microsecond part of the timestamp. 3095 seq-number 3096 This field is described above in section 5.3.2. 3097 s-address 3098 This field specifies the address in use by the sender of the message. 3099 It may be omitted if not required by the application protocol. The 3100 application designer considering omission of this field is warned, that 3101 the inclusion of this address prevents some kinds of replay attacks 3102 (e.g., reflection attacks) and that it is only acceptable to omit this 3103 address if there is sufficient information in the integrity protected 3104 part of the application message for the recipient to unambiguously 3105 determine if it was the intended recipient. 3106 r-address 3107 This field specifies the address in use by the recipient of the 3108 message. It may be omitted for some uses (such as broadcast protocols), 3109 but the recipient may arbitrarily reject such messages. This field 3110 along with s-address can be used to help detect messages which have 3111 been incorrectly or maliciously delivered to the wrong recipient. 3113 5.7. KRB_PRIV message specification 3115 This section specifies the format of a message that can be used by either 3116 side (client or server) of an application to securely and privately send a 3117 message to its peer. It presumes that a session key has previously been 3118 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3120 5.7.1. KRB_PRIV definition 3122 The KRB_PRIV message contains user data encrypted in the Session Key. The 3123 message fields are: 3125 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3126 pvno[0] INTEGER, 3127 msg-type[1] INTEGER, 3128 enc-part[3] EncryptedData 3129 -- EncKrbPrivPart 3130 } 3132 EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { 3133 user-data[0] OCTET STRING, 3134 timestamp[1] KerberosTime OPTIONAL, 3135 usec[2] INTEGER OPTIONAL, 3136 seq-number[3] INTEGER OPTIONAL, 3137 s-address[4] HostAddress OPTIONAL, -- sender's addr 3138 r-address[5] HostAddress OPTIONAL -- recip's addr 3139 } 3141 pvno and msg-type 3142 These fields are described above in section 5.4.1. msg-type is 3143 KRB_PRIV. 3144 enc-part 3145 This field holds an encoding of the EncKrbPrivPart sequence encrypted 3146 under the session key[32]. This encrypted encoding is used for the 3147 enc-part field of the KRB-PRIV message. See section 6 for the format of 3148 the ciphertext. 3149 user-data, timestamp, usec, s-address and r-address 3150 These fields are described above in section 5.6.1. 3151 seq-number 3152 This field is described above in section 5.3.2. 3154 5.8. KRB_CRED message specification 3156 This section specifies the format of a message that can be used to send 3157 Kerberos credentials from one principal to another. It is presented here to 3158 encourage a common mechanism to be used by applications when forwarding 3159 tickets or providing proxies to subordinate servers. It presumes that a 3160 session key has already been exchanged perhaps by using the 3161 KRB_AP_REQ/KRB_AP_REP messages. 3163 5.8.1. KRB_CRED definition 3165 The KRB_CRED message contains a sequence of tickets to be sent and 3166 information needed to use the tickets, including the session key from each. 3167 The information needed to use the tickets is encrypted under an encryption 3168 key previously exchanged or transferred alongside the KRB_CRED message. The 3169 message fields are: 3171 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3172 pvno[0] INTEGER, 3173 msg-type[1] INTEGER, -- KRB_CRED 3174 tickets[2] SEQUENCE OF Ticket, 3175 enc-part[3] EncryptedData -- EncKrbCredPart 3176 } 3177 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3178 ticket-info[0] SEQUENCE OF KrbCredInfo, 3179 nonce[1] INTEGER OPTIONAL, 3180 timestamp[2] KerberosTime OPTIONAL, 3181 usec[3] INTEGER OPTIONAL, 3182 s-address[4] HostAddress OPTIONAL, 3183 r-address[5] HostAddress OPTIONAL 3184 } 3186 KrbCredInfo ::= SEQUENCE { 3187 key[0] EncryptionKey, 3188 prealm[1] Realm OPTIONAL, 3189 pname[2] PrincipalName OPTIONAL, 3190 flags[3] TicketFlags OPTIONAL, 3191 authtime[4] KerberosTime OPTIONAL, 3192 starttime[5] KerberosTime OPTIONAL, 3193 endtime[6] KerberosTime OPTIONAL 3194 renew-till[7] KerberosTime OPTIONAL, 3195 srealm[8] Realm OPTIONAL, 3196 sname[9] PrincipalName OPTIONAL, 3197 caddr[10] HostAddresses OPTIONAL 3198 } 3200 pvno and msg-type 3201 These fields are described above in section 5.4.1. msg-type is 3202 KRB_CRED. 3203 tickets 3204 These are the tickets obtained from the KDC specifically for use by the 3205 intended recipient. Successive tickets are paired with the 3206 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3207 message. 3208 enc-part 3209 This field holds an encoding of the EncKrbCredPart sequence encrypted 3210 under the session key shared between the sender and the intended 3211 recipient. This encrypted encoding is used for the enc-part field of 3212 the KRB-CRED message. See section 6 for the format of the ciphertext. 3213 nonce 3214 If practical, an application may require the inclusion of a nonce 3215 generated by the recipient of the message. If the same value is 3216 included as the nonce in the message, it provides evidence that the 3217 message is fresh and has not been replayed by an attacker. A nonce must 3218 never be re-used; it should be generated randomly by the recipient of 3219 the message and provided to the sender of the message in an application 3220 specific manner. 3221 timestamp and usec 3222 These fields specify the time that the KRB-CRED message was generated. 3223 The time is used to provide assurance that the message is fresh. 3224 s-address and r-address 3225 These fields are described above in section 5.6.1. They are used 3226 optionally to provide additional assurance of the integrity of the 3227 KRB-CRED message. 3228 key 3229 This field exists in the corresponding ticket passed by the KRB-CRED 3230 message and is used to pass the session key from the sender to the 3231 intended recipient. The field's encoding is described in section 6.2. 3233 The following fields are optional. If present, they can be associated with 3234 the credentials in the remote ticket file. If left out, then it is assumed 3235 that the recipient of the credentials already knows their value. 3237 prealm and pname 3238 The name and realm of the delegated principal identity. 3239 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3240 These fields contain the values of the corresponding fields from the 3241 ticket found in the ticket field. Descriptions of the fields are 3242 identical to the descriptions in the KDC-REP message. 3244 5.9. Error message specification 3246 This section specifies the format for the KRB_ERROR message. The fields 3247 included in the message are intended to return as much information as 3248 possible about an error. It is not expected that all the information 3249 required by the fields will be available for all types of errors. If the 3250 appropriate information is not available when the message is composed, the 3251 corresponding field will be left out of the message. 3253 Note that since the KRB_ERROR message is only optionally integrity 3254 protected, it is quite possible for an intruder to synthesize or modify such 3255 a message. In particular, this means that unless appropriate integrity 3256 protection mechanisms have been applied to the KRB_ERROR message, the client 3257 should not use any fields in this message for security-critical purposes, 3258 such as setting a system clock or generating a fresh authenticator. The 3259 message can be useful, however, for advising a user on the reason for some 3260 failure. 3262 5.9.1. KRB_ERROR definition 3264 The KRB_ERROR message consists of the following fields: 3266 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3267 pvno[0] INTEGER, 3268 msg-type[1] INTEGER, 3269 ctime[2] KerberosTime OPTIONAL, 3270 cusec[3] INTEGER OPTIONAL, 3271 stime[4] KerberosTime, 3272 susec[5] INTEGER, 3273 error-code[6] INTEGER, 3274 crealm[7] Realm OPTIONAL, 3275 cname[8] PrincipalName OPTIONAL, 3276 realm[9] Realm, -- Correct realm 3277 sname[10] PrincipalName, -- Correct name 3278 e-text[11] GeneralString OPTIONAL, 3279 e-data[12] OCTET STRING OPTIONAL, 3280 e-cksum[13] Checksum OPTIONAL, 3281 } 3283 pvno and msg-type 3284 These fields are described above in section 5.4.1. msg-type is 3285 KRB_ERROR. 3286 ctime 3287 This field is described above in section 5.4.1. 3289 cusec 3290 This field is described above in section 5.5.2. 3291 stime 3292 This field contains the current time on the server. It is of type 3293 KerberosTime. 3294 susec 3295 This field contains the microsecond part of the server's timestamp. Its 3296 value ranges from 0 to 999999. It appears along with stime. The two 3297 fields are used in conjunction to specify a reasonably accurate 3298 timestamp. 3299 error-code 3300 This field contains the error code returned by Kerberos or the server 3301 when a request fails. To interpret the value of this field see the list 3302 of error codes in section 8. Implementations are encouraged to provide 3303 for national language support in the display of error messages. 3304 crealm, cname, srealm and sname 3305 These fields are described above in section 5.3.1. 3306 e-text 3307 This field contains additional text to help explain the error code 3308 associated with the failed request (for example, it might include a 3309 principal name which was unknown). 3310 e-data 3311 This field contains additional data about the error for use by the 3312 application to help it recover from or handle the error. If present, 3313 this field will contain the encoding of a sequence of TypedData 3314 (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, 3315 in which case it will contain the encoding of a sequence of of padata 3316 fields (METHOD-DATA below), each corresponding to an acceptable 3317 pre-authentication method and optionally containing data for the 3318 method: 3320 TYPED-DATA ::= SEQUENCE of TypedData 3321 METHOD-DATA ::= SEQUENCE of PA-DATA 3323 TypedData ::= SEQUENCE { 3324 data-type[0] INTEGER, 3325 data-value[1] OCTET STRING OPTIONAL 3326 } 3328 Note that the padata-type field in the PA-DATA structure and the 3329 data-type field in the TypedData structure share a common range of 3330 allocated values which are coordinated to avoid conflicts. One Kerberos 3331 error message, KDC_ERR_PREAUTH_REQUIRED, embeds elements of type 3332 PA-DATA, while all other error messages embed TypedData. 3334 While preauthentication methods of type PA-DATA should be encapsulated 3335 within a TypedData element of type TD-PADATA, for compatibility with 3336 old clients, the KDC should include PA-DATA types below 22 directly as 3337 method-data. All new implementations interpreting the METHOD-DATA field 3338 for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of 3339 TD-PADATA, extract the typed data field and interpret the use any 3340 elements encapsulated in the TD-PADATA elements as if they were present 3341 in the METHOD-DATA sequence. 3343 Unless otherwise specified, unrecognized TypedData elements within the 3344 KRB-ERROR message MAY be ignored by implementations that do not support 3345 them. Note that all TypedData MAY be bound to the KRB-ERROR message via 3346 the checksum field. 3348 An application may use the TD-APP-DEFINED-ERROR typed data type for 3349 data carried in a Kerberos error message that is specific to the 3350 application. TD-APP-SPECIFIC must set the data-type value of TypedData 3351 to TD-APP-SPECIFIC and the data-value field to 3353 AppSpecificTypedData as follows: 3354 AppSpecificTypedData ::= SEQUENCE { 3355 oid[0] OPTIONAL OBJECT IDENTIFIER, 3356 -- identifies the application 3357 data-value[1] OCTET STRING 3358 -- application 3359 -- specific data 3360 } 3362 The TD-REQ-NONCE TypedData MAY be used to bind a KRB-ERROR to a 3363 KDC-REQ. The data-value is an INTEGER that is equivalent to the 3364 nonce in a KDC-REQ. 3366 The TD-REQ-SEQ TypedData MAY be used for binding a KRB-ERROR to 3367 the sequence number from an authenticator. The data-value is an 3368 INTEGER, and it is identical to sequence number sent in the 3369 authenticator. 3371 The data-value for TD-KRB-PRINCIPAL is the Kerberos-defined 3372 PrincipalName. The data-value for TD-KRB-REALM is the 3373 Kerberos-defined Realm. These TypedData types MAY be used to 3374 indicate principal and realm name when appropriate. 3375 e-cksum 3376 This field contains an optional checksum for the KRB-ERROR message. The 3377 checksum is calculated over the Kerberos ASN.1 encoding of the 3378 KRB-ERROR message with the checksum absent. The checksum is then added 3379 to the KRB-ERROR structure and the message is re-encoded. The Checksum 3380 should be calculated using the session key from the ticket granting 3381 ticket or service ticket, where available. If the error is in response 3382 to a TGS or AP request, the checksum should be calculated using the the 3383 session key from the client's ticket. If the error is in response to an 3384 AS request, then the checksum should be calulated using the client's 3385 secret key ONLY if there has been suitable preauthentication to prove 3386 knowledge of the secret key by the client[33]. If a checksum can not be 3387 computed because the key to be used is not available, no checksum will 3388 be included. 3390 6. Encryption and Checksum Specifications 3392 This section is undergoing major revision to include rijndael support based 3393 on the Internet Draft by Ken Raeburn 3394 (draft-raeburn-krb-rijndael-krb-00.txt). The discussions of 3DES are also 3395 undergoing revision. Please see http://www.isi.edu/people/bcn/krb-revisions 3396 for the latest versions of this section when it becomes available. 3398 7. Naming Constraints 3400 7.1. Realm Names 3402 Although realm names are encoded as GeneralStrings and although a realm can 3403 technically select any name it chooses, interoperability across realm 3404 boundaries requires agreement on how realm names are to be assigned, and 3405 what information they imply. 3407 To enforce these conventions, each realm must conform to the conventions 3408 itself, and it must require that any realms with which inter-realm keys are 3409 shared also conform to the conventions and require the same from its 3410 neighbors. 3412 Kerberos realm names are case sensitive. Realm names that differ only in the 3413 case of the characters are not equivalent. There are presently four styles 3414 of realm names: domain, X500, other, and reserved. Examples of each style 3415 follow: 3417 domain: ATHENA.MIT.EDU (example) 3418 X500: C=US/O=OSF (example) 3419 other: NAMETYPE:rest/of.name=without-restrictions (example) 3420 reserved: reserved, but will not conflict with above 3422 Domain names must look like domain names: they consist of components 3423 separated by periods (.) and they contain neither colons (:) nor slashes 3424 (/). Though domain names themselves are case insensitive, in order for 3425 realms to match, the case must match as well. When establishing a new realm 3426 name based on an internet domain name it is recommended by convention that 3427 the characters be converted to upper case. 3429 X.500 names contain an equal (=) and cannot contain a colon (:) before the 3430 equal. The realm names for X.500 names will be string representations of the 3431 names with components separated by slashes. Leading and trailing slashes 3432 will not be included. Note that the slash separator is consistent with 3433 Kerberos implementations based on RFC1510, but it is different from the 3434 separator recommended in RFC2253. 3436 Names that fall into the other category must begin with a prefix that 3437 contains no equal (=) or period (.) and the prefix must be followed by a 3438 colon (:) and the rest of the name. All prefixes must be assigned before 3439 they may be used. Presently none are assigned. 3441 The reserved category includes strings which do not fall into the first 3442 three categories. All names in this category are reserved. It is unlikely 3443 that names will be assigned to this category unless there is a very strong 3444 argument for not using the 'other' category. 3446 These rules guarantee that there will be no conflicts between the various 3447 name styles. The following additional constraints apply to the assignment of 3448 realm names in the domain and X.500 categories: the name of a realm for the 3449 domain or X.500 formats must either be used by the organization owning (to 3450 whom it was assigned) an Internet domain name or X.500 name, or in the case 3451 that no such names are registered, authority to use a realm name may be 3452 derived from the authority of the parent realm. For example, if there is no 3453 domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 3454 authorize the creation of a realm with that name. 3456 This is acceptable because the organization to which the parent is assigned 3457 is presumably the organization authorized to assign names to its children in 3458 the X.500 and domain name systems as well. If the parent assigns a realm 3459 name without also registering it in the domain name or X.500 hierarchy, it 3460 is the parent's responsibility to make sure that there will not in the 3461 future exist a name identical to the realm name of the child unless it is 3462 assigned to the same entity as the realm name. 3464 7.2. Principal Names 3466 As was the case for realm names, conventions are needed to ensure that all 3467 agree on what information is implied by a principal name. The name-type 3468 field that is part of the principal name indicates the kind of information 3469 implied by the name. The name-type should be treated as a hint. Ignoring the 3470 name type, no two names can be the same (i.e. at least one of the 3471 components, or the realm, must be different). The following name types are 3472 defined: 3474 name-type value meaning 3476 NT-UNKNOWN 0 Name type not known 3477 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal) 3478 NT-SRV-INST 2 Service and other unique instance (krbtgt) 3479 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 3480 NT-SRV-XHST 4 Service with slash-separated host name components 3481 NT-UID 5 Unique ID 3482 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 3483 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 3485 When a name implies no information other than its uniqueness at a particular 3486 time the name type PRINCIPAL should be used. The principal name type should 3487 be used for users, and it might also be used for a unique server. If the 3488 name is a unique machine generated ID that is guaranteed never to be 3489 reassigned then the name type of UID should be used (note that it is 3490 generally a bad idea to reassign names of any type since stale entries might 3491 remain in access control lists). 3493 If the first component of a name identifies a service and the remaining 3494 components identify an instance of the service in a server specified manner, 3495 then the name type of SRV-INST should be used. An example of this name type 3496 is the Kerberos ticket-granting service whose name has a first component of 3497 krbtgt and a second component identifying the realm for which the ticket is 3498 valid. 3500 If instance is a single component following the service name and the 3501 instance identifies the host on which the server is running, then the name 3502 type SRV-HST should be used. This type is typically used for Internet 3503 services such as telnet and the Berkeley R commands. If the separate 3504 components of the host name appear as successive components following the 3505 name of the service, then the name type SRV-XHST should be used. This type 3506 might be used to identify servers on hosts with X.500 names where the slash 3507 (/) might otherwise be ambiguous. 3509 A name type of NT-X500-PRINCIPAL should be used when a name from an X.509 3510 certificate is translated into a Kerberos name. The encoding of the X.509 3511 name as a Kerberos principal shall conform to the encoding rules specified 3512 in RFC 2253. 3514 A name type of SMTP allows a name to be of a form that resembles a SMTP 3515 email name. This name, including an "@" and a domain name, is used as the 3516 one component of the principal name. This name type can be used in 3517 conjunction with name-canonicalization to allow a free-form of email address 3518 to be specified as a client name and allow the KDC to determine the Kerberos 3519 principal name for the requested name. [JBrezak, Raeburn] 3521 A name type of UNKNOWN should be used when the form of the name is not 3522 known. When comparing names, a name of type UNKNOWN will match principals 3523 authenticated with names of any type. A principal authenticated with a name 3524 of type UNKNOWN, however, will only match other names of type UNKNOWN. 3526 Names of any type with an initial component of 'krbtgt' are reserved for the 3527 Kerberos ticket granting service. See section 8.2.3 for the form of such 3528 names. 3530 7.2.1. Name of server principals 3532 The principal identifier for a server on a host will generally be composed 3533 of two parts: (1) the realm of the KDC with which the server is registered, 3534 and (2) a two-component name of type NT-SRV-HST if the host name is an 3535 Internet domain name or a multi-component name of type NT-SRV-XHST if the 3536 name of the host is of a form such as X.500 that allows slash (/) 3537 separators. The first component of the two- or multi-component name will 3538 identify the service and the latter components will identify the host. Where 3539 the name of the host is not case sensitive (for example, with Internet 3540 domain names) the name of the host must be lower case. If specified by the 3541 application protocol for services such as telnet and the Berkeley R commands 3542 which run with system privileges, the first component may be the string 3543 'host' instead of a service specific identifier. When a host has an official 3544 name and one or more aliases and the official name can be reliably 3545 determined, the official name of the host should be used when constructing 3546 the name of the server principal. 3548 8. Constants and other defined values 3550 8.1. Host address types 3552 All negative values for the host address type are reserved for local use. 3553 All non-negative values are reserved for officially assigned type fields and 3554 interpretations. 3556 The values of the types for the following addresses are chosen to match the 3557 defined address family constants in the Berkeley Standard Distributions of 3558 Unix. They can be found in with symbolic names AF_xxx (where xxx is an 3559 abbreviation of the address family name). 3561 Internet (IPv4) Addresses 3563 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB 3564 order. The IPv4 loopback address should not appear in a Kerberos packet. The 3565 type of IPv4 addresses is two (2). 3567 Internet (IPv6) Addresses [Westerlund] 3569 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The 3570 type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The 3571 following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 3573 * the Unspecified Address 3574 * the Loopback Address 3575 * Link-Local addresses 3577 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 3579 CHAOSnet addresses 3581 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order. 3582 The type of CHAOSnet addresses is five (5). 3584 ISO addresses 3586 ISO addresses are variable-length. The type of ISO addresses is seven (7). 3588 Xerox Network Services (XNS) addresses 3590 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The 3591 type of XNS addresses is six (6). 3593 AppleTalk Datagram Delivery Protocol (DDP) addresses 3595 AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network 3596 number. The first octet of the address is the node number; the remaining two 3597 octets encode the network number in MSB order. The type of AppleTalk DDP 3598 addresses is sixteen (16). 3600 DECnet Phase IV addresses 3602 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The 3603 type of DECnet Phase IV addresses is twelve (12). 3605 Netbios addresses 3607 Netbios addresses are 16-octet addresses typically composed of 1 to 15 3608 characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0. 3609 The type of Netbios addresses is 20 (0x14). 3611 8.2. KDC messages 3613 8.2.1. UDP/IP transport 3615 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP 3616 IP transport, the client shall send a UDP datagram containing only an 3617 encoding of the request to port 88 (decimal) at the KDC's IP address; the 3618 KDC will respond with a reply datagram containing only an encoding of the 3619 reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at 3620 the sender's IP address. Kerberos servers supporting IP transport must 3621 accept UDP requests on port 88 (decimal). The response to a request made 3622 through UDP/IP transport must also use UDP/IP transport. 3624 8.2.2. TCP/IP transport [Westerlund,Danielsson] 3626 Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and 3627 clients should support the sending of TCP requests on port 88 (decimal). 3628 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new 3629 connection will be established for each authentication exchange (request and 3630 response). The KRB_KDC_REP or KRB_ERROR message will be returned to the 3631 client on the same TCP stream that was established for the request. The 3632 response to a request made through TCP/IP transport must also use TCP/IP 3633 transport. Implementors should note that some extensions to the Kerberos 3634 protocol will not work if any implementation not supporting the TCP 3635 transport is involved (client or KDC). Implementors are strongly urged to 3636 support the TCP transport on both the client and server and are advised that 3637 the current notation of "should" support will likely change in the future to 3638 must support. The KDC may close the TCP stream after sending a response, but 3639 may leave the stream open if it expects a followup - in which case it may 3640 close the stream at any time if resource constraints or other factors make 3641 it desirable to do so. Care must be taken in managing TCP/IP connections 3642 with the KDC to prevent denial of service attacks based on the number of 3643 TCP/IP connections with the KDC that remain open. If multiple exchanges with 3644 the KDC are needed for certain forms of preauthentication, multiple TCP 3645 connections may be required. A client may close the stream after receiving 3646 response, and should close the stream if it does not expect to send followup 3647 messages. The client must be prepared to have the stream closed by the KDC 3648 at anytime, in which case it must simply connect again when it is ready to 3649 send subsequent messages. 3651 The first four octets of the TCP stream used to transmit the request request 3652 will encode in network byte order the length of the request (KRB_KDC_REQ), 3653 and the length will be followed by the request itself. The response will 3654 similarly be preceded by a 4 octet encoding in network byte order of the 3655 length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by 3656 the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the 3657 integer represented by the first 4 octets, then the next 4 octets will be 3658 read, extending the length of the field by another 4 octets (less the sign 3659 bit of the additional four octets which is reserved for future expansion and 3660 which at present must be zero). 3662 8.2.3. OSI transport 3664 During authentication of an OSI client to an OSI server, the mutual 3665 authentication of an OSI server to an OSI client, the transfer of 3666 credentials from an OSI client to an OSI server, or during exchange of 3667 private or integrity checked messages, Kerberos protocol messages may be 3668 treated as opaque objects and the type of the authentication mechanism will 3669 be: 3671 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} 3673 Depending on the situation, the opaque object will be an authentication 3674 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message 3675 (KRB_SAFE), a private message (KRB_PRIV), or a credentials message 3676 (KRB_CRED). The opaque data contains an application code as specified in the 3677 ASN.1 description for each message. The application code may be used by 3678 Kerberos to determine the message type. 3680 8.2.3. Name of the TGS 3682 The principal identifier of the ticket-granting service shall be composed of 3683 three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part 3684 name of type NT-SRV-INST, with the first part "krbtgt" and the second part 3685 the name of the realm which will accept the ticket-granting ticket. For 3686 example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 3687 used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier 3688 of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 3689 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get 3690 tickets from the MIT.EDU realm has a principal identifier of 3691 "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name). 3693 8.3. Protocol constants and associated values 3695 The following tables list constants used in the protocol and define their 3696 meanings. Ranges are specified in the "specification" section that limit the 3697 values of constants for which values are defined here. This allows 3698 implementations to make assumptions about the maximum values that will be 3699 received for these constants. Implementation receiving values outside the 3700 range specified in the "specification" section may reject the request, but 3701 they must recover cleanly. 3703 Encryption type etype value block size minimum pad size confounder size 3704 NULL 0 1 0 0 3705 des-cbc-crc 1 8 4 8 3706 des-cbc-md4 2 8 0 8 3707 des-cbc-md5 3 8 0 8 3708 [reserved] 4 3709 des3-cbc-md5 5 8 0 8 3710 [reserved] 6 3711 des3-cbc-sha1 7 8 0 8 3712 dsaWithSHA1-CmsOID 9 (pkinit) 3713 md5WithRSAEncryption-CmsOID 10 (pkinit) 3714 sha1WithRSAEncryption-CmsOID 11 (pkinit) 3715 rc2CBC-EnvOID 12 (pkinit) 3716 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 3717 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 3718 des-ede3-cbc-Env-OID 15 (pkinit) 3719 des3-cbc-sha1-kd 16 (Tom Yu) 3720 rc4-hmac 23 (swift) 3721 rc4-hmac-exp 24 (swift) 3722 subkey-keynaterial 65 (opaque mhur) 3724 [reserved] 0x8003 3725 Checksum type sumtype value checksum size 3726 CRC32 1 4 3727 rsa-md4 2 16 3728 rsa-md4-des 3 24 3729 des-mac 4 16 3730 des-mac-k 5 8 3731 rsa-md4-des-k 6 16 (drop rsa ?) 3732 rsa-md5 7 16 (drop rsa ?) 3733 rsa-md5-des 8 24 (drop rsa ?) 3734 rsa-md5-des3 9 24 (drop rsa ?) 3735 hmac-sha1-des3-kd 12 20 3736 hmac-sha1-des3 13 20 3737 sha1 (unkeyed) 14 20 3739 padata and data types padata-type value comment 3741 PA-TGS-REQ 1 3742 PA-ENC-TIMESTAMP 2 3743 PA-PW-SALT 3 3744 [reserved] 4 3745 PA-ENC-UNIX-TIME 5 (depricated) 3746 PA-SANDIA-SECUREID 6 3747 PA-SESAME 7 3748 PA-OSF-DCE 8 3749 PA-CYBERSAFE-SECUREID 9 3750 PA-AFS3-SALT 10 3751 PA-ETYPE-INFO 11 3752 PA-SAM-CHALLENGE 12 (sam/otp) 3753 PA-SAM-RESPONSE 13 (sam/otp) 3754 PA-PK-AS-REQ 14 (pkinit) 3755 PA-PK-AS-REP 15 (pkinit) 3756 PA-USE-SPECIFIED-KVNO 20 3757 PA-SAM-REDIRECT 21 (sam/otp) 3758 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 3759 TD-PADATA 22 (embeds padata) 3760 PA-SAM-ETYPE-INFO 23 (sam/otp) 3761 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 3762 TD-KRB-PRINCIPAL 102 PrincipalName (see Sec.5.9.1) 3763 TD-KRB-REALM 103 Realm (see Sec.5.9.1) 3764 TD-TRUSTED-CERTIFIERS 104 from PKINIT 3765 TD-CERTIFICATE-INDEX 105 from PKINIT 3766 TD-APP-DEFINED-ERROR 106 application specific (see Sec.5.9.1) 3767 TD-REQ-NONCE 107 INTEGER (see Sec.5.9.1) 3768 TD-REQ-SEQ 108 INTEGER (see Sec.5.9.1) 3770 authorization data type ad-type value 3771 AD-IF-RELEVANT 1 3772 AD-INTENDED-FOR-SERVER 2 3773 AD-INTENDED-FOR-APPLICATION-CLASS 3 3774 AD-KDC-ISSUED 4 3775 AD-OR 5 3776 AD-MANDATORY-TICKET-EXTENSIONS 6 3777 AD-IN-TICKET-EXTENSIONS 7 3778 reserved values 8-63 3779 OSF-DCE 64 3780 SESAME 65 3781 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 3782 AD-WIN200-PAC 128 (jbrezak@exchange.microsoft.com) 3783 Ticket Extension Types 3785 TE-TYPE-NULL 0 Null ticket extension 3786 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 3787 [reserved] 2 TE-TYPE-PKCROSS-KDC (I have reservations) 3788 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 3789 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 3790 [reserved] 5 TE-TYPE-DEST-HOST (I have reservations) 3792 alternate authentication type method-type value 3793 reserved values 0-63 3794 ATT-CHALLENGE-RESPONSE 64 3796 transited encoding type tr-type value 3797 DOMAIN-X500-COMPRESS 1 3798 reserved values all others 3800 Label Value Meaning or MIT code 3802 pvno 5 current Kerberos protocol version number 3804 message types 3806 KRB_AS_REQ 10 Request for initial authentication 3807 KRB_AS_REP 11 Response to KRB_AS_REQ request 3808 KRB_TGS_REQ 12 Request for authentication based on TGT 3809 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 3810 KRB_AP_REQ 14 application request to server 3811 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 3812 KRB_SAFE 20 Safe (checksummed) application message 3813 KRB_PRIV 21 Private (encrypted) application message 3814 KRB_CRED 22 Private (encrypted) message to forward credentials 3815 KRB_ERROR 30 Error response 3817 name types 3819 KRB_NT_UNKNOWN 0 Name type not known 3820 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 3821 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 3822 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 3823 KRB_NT_SRV_XHST 4 Service with host as remaining components 3824 KRB_NT_UID 5 Unique ID 3825 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 3826 error codes 3828 KDC_ERR_NONE 0 No error 3829 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 3830 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 3831 KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported 3832 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 3833 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 3834 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 3835 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 3836 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 3837 KDC_ERR_NULL_KEY 9 The client or server has a null key 3838 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 3839 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 3840 KDC_ERR_POLICY 12 KDC policy rejects request 3841 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 3842 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 3843 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 3844 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 3845 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 3846 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 3847 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 3848 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 3849 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 3850 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 3851 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset 3852 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 3853 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 3854 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 3855 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 3856 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 3857 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 3858 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 3859 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 3860 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 3861 KRB_AP_ERR_REPEAT 34 Request is a replay 3862 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 3863 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 3864 KRB_AP_ERR_SKEW 37 Clock skew too great 3865 KRB_AP_ERR_BADADDR 38 Incorrect net address 3866 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 3867 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 3868 KRB_AP_ERR_MODIFIED 41 Message stream modified 3869 KRB_AP_ERR_BADORDER 42 Message out of order 3870 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 3871 KRB_AP_ERR_NOKEY 45 Service key not available 3872 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 3873 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 3874 KRB_AP_ERR_METHOD 48 Alternative authentication method required 3875 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 3876 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 3877 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 3878 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 3879 KRB_ERR_GENERIC 60 Generic error (description in e-text) 3880 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 3881 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 3882 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 3883 KDC_ERROR_INVALID_SIG 64 (pkinit) 3884 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 3885 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 3886 KRB_AP_ERR_NO_TGT 67 (user-to-user) 3887 KDC_ERR_WRONG_REALM 68 (user-to-user) 3888 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 3889 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 3890 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 3891 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 3892 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 3893 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 3894 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 3895 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 3896 9. Interoperability requirements 3898 Version 5 of the Kerberos protocol supports a myriad of options. Among these 3899 are multiple encryption and checksum types, alternative encoding schemes for 3900 the transited field, optional mechanisms for pre-authentication, the 3901 handling of tickets with no addresses, options for mutual authentication, 3902 user to user authentication, support for proxies, forwarding, postdating, 3903 and renewing tickets, the format of realm names, and the handling of 3904 authorization data. 3906 In order to ensure the interoperability of realms, it is necessary to define 3907 a minimal configuration which must be supported by all implementations. This 3908 minimal configuration is subject to change as technology does. For example, 3909 if at some later date it is discovered that one of the required encryption 3910 or checksum algorithms is not secure, it will be replaced. 3912 9.1. Specification 2 3914 This section defines the second specification of these options. 3915 Implementations which are configured in this way can be said to support 3916 Kerberos Version 5 Specification 2 (5.1). Specification 1 (deprecated) may 3917 be found in RFC1510. 3919 Transport 3921 TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance 3922 to specification 2. Kerberos clients claiming conformance to specification 2 3923 must support UDP/IP transport for messages with the KDC and should support 3924 TCP/IP transport. 3926 Encryption and checksum methods 3928 The following encryption and checksum mechanisms must be supported. 3929 Implementations may support other mechanisms as well, but the additional 3930 mechanisms may only be used when communicating with principals known to also 3931 support them: This list is to be determined. 3933 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD, RIJNDAEL(decide identifier) 3934 Checksums: CRC-32, DES-MAC, DES-MAC-K, DES-MD5, HMAC-SHA1-DES3-KD 3936 Realm Names 3938 All implementations must understand hierarchical realms in both the Internet 3939 Domain and the X.500 style. When a ticket granting ticket for an unknown 3940 realm is requested, the KDC must be able to determine the names of the 3941 intermediate realms between the KDCs realm and the requested realm. 3943 Transited field encoding 3945 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 3946 Alternative encodings may be supported, but they may be used only when that 3947 encoding is supported by ALL intermediate realms. 3949 Pre-authentication methods 3951 The TGS-REQ method must be supported. The TGS-REQ method is not used on the 3952 initial request. The PA-ENC-TIMESTAMP method must be supported by clients 3953 but whether it is enabled by default may be determined on a realm by realm 3954 basis. If not used in the initial request and the error 3955 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 3956 acceptable method, the client should retry the initial request using the 3957 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 3958 PA-ENC-TIMESTAMP method, but if not supported the server should ignore the 3959 presence of PA-ENC-TIMESTAMP pre-authentication in a request. 3961 Mutual authentication 3963 Mutual authentication (via the KRB_AP_REP message) must be supported. 3965 Ticket addresses and flags 3967 All KDC's must pass through tickets that carry no addresses (i.e. if a TGT 3968 contains no addresses, the KDC will return derivative tickets), but each 3969 realm may set its own policy for issuing such tickets, and each application 3970 server will set its own policy with respect to accepting them. 3972 Proxies and forwarded tickets must be supported. Individual realms and 3973 application servers can set their own policy on when such tickets will be 3974 accepted. 3976 All implementations must recognize renewable and postdated tickets, but need 3977 not actually implement them. If these options are not supported, the 3978 starttime and endtime in the ticket shall specify a ticket's entire useful 3979 life. When a postdated ticket is decoded by a server, all implementations 3980 shall make the presence of the postdated flag visible to the calling server. 3982 User-to-user authentication 3984 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option) 3985 must be provided by implementations, but individual realms may decide as a 3986 matter of policy to reject such requests on a per-principal or realm-wide 3987 basis. 3989 Authorization data 3991 Implementations must pass all authorization data subfields from 3992 ticket-granting tickets to any derivative tickets unless directed to 3993 suppress a subfield as part of the definition of that registered subfield 3994 type (it is never incorrect to pass on a subfield, and no registered 3995 subfield types presently specify suppression at the KDC). 3997 Implementations must make the contents of any authorization data subfields 3998 available to the server when a ticket is used. Implementations are not 3999 required to allow clients to specify the contents of the authorization data 4000 fields. 4002 Constant ranges 4004 All protocol constants are constrained to 32 bit (signed) values unless 4005 further constrained by the protocol definition. This limit is provided to 4006 allow implementations to make assumptions about the maximum values that will 4007 be received for these constants. Implementation receiving values outside 4008 this range may reject the request, but they must recover cleanly. 4010 9.2. Recommended KDC values 4012 Following is a list of recommended values for a KDC implementation, based on 4013 the list of suggested configuration constants (see section 4.4). 4015 minimum lifetime 5 minutes 4016 maximum renewable lifetime 1 week 4017 maximum ticket lifetime 1 day 4018 empty addresses only when suitable restrictions appear 4019 in authorization data 4020 proxiable, etc. Allowed. 4022 10. REFERENCES 4024 [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- 4025 cation Service for Computer Networks," IEEE Communica- 4026 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). 4028 [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 4029 Saltzer, Section E.2.1: Kerberos Authentication and 4030 Authorization System, M.I.T. Project Athena, Cambridge, 4031 Massachusetts (December 21, 1987). 4033 [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 4034 beros: An Authentication Service for Open Network Sys- 4035 tems," pp. 191-202 in Usenix Conference Proceedings, 4036 Dallas, Texas (February, 1988). 4038 [NS78] Roger M. Needham and Michael D. Schroeder, "Using 4039 Encryption for Authentication in Large Networks of Com- 4040 puters," Communications of the ACM, Vol. 21(12), 4041 pp. 993-999 (December, 1978). 4043 [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- 4044 stamps in Key Distribution Protocols," Communications 4045 of the ACM, Vol. 24(8), pp. 533-536 (August 1981). 4047 [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 4048 "The Evolution of the Kerberos Authentication Service," 4049 in an IEEE Computer Society Text soon to be published 4050 (June 1992). 4052 [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and 4053 Accounting for Distributed Systems," in Proceedings of 4054 the 13th International Conference on Distributed Com- 4055 puting Systems, Pittsburgh, PA (May, 1993). 4057 [DS90] Don Davis and Ralph Swick, "Workstation Services and 4058 Kerberos Authentication at Project Athena," Technical 4059 Memorandum TM-424, MIT Laboratory for Computer Science 4060 (February 1990). 4062 [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 4063 merfeld, and K. Raeburn, Section E.1: Service Manage- 4064 ment System, M.I.T. Project Athena, Cambridge, Mas- 4065 sachusetts (1987). 4067 [X509-88] CCITT, Recommendation X.509: The Directory Authentica- 4068 tion Framework, December 1988. 4070 [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password 4071 Guessing Attacks, Open Software Foundation DCE Request 4072 for Comments 26 (December 1992). 4074 [DES77] National Bureau of Standards, U.S. Department of Com- 4075 merce, "Data Encryption Standard," Federal Information 4076 Processing Standards Publication 46, Washington, DC 4077 (1977). 4079 [DESM80] National Bureau of Standards, U.S. Department of Com- 4080 merce, "DES Modes of Operation," Federal Information 4081 Processing Standards Publication 81, Springfield, VA 4082 (December 1980). 4084 [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message 4085 Integrity in Cryptographic Protocols," in Proceedings 4086 of the IEEE Symposium on Research in Security and 4087 Privacy, Oakland, California (May 1992). 4089 [IS3309] International Organization for Standardization, "ISO 4090 Information Processing Systems - Data Communication - 4091 High-Level Data Link Control Procedure - Frame Struc- 4092 ture," IS 3309 (October 1984). 3rd Edition. 4094 [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC 4095 1320, MIT Laboratory for Computer Science (April 4096 1992). 4098 [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC 4099 1321, MIT Laboratory for Computer Science (April 4100 1992). 4102 [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- 4103 Hashing for Message Authentication," Working Draft 4104 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 4106 [Horowitz96] Horowitz, M., "Key Derivation for Authentication, 4107 Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, 4108 August 1998. 4110 [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- 4111 horowitz-kerb-key-derivation-01.txt, September 1998. 4113 [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: 4114 Keyed-Hashing for Message Authentication", = 4115 draft-ietf-ipsec-hmac- 4116 md5-01.txt, August, 1996. 4118 A. Pseudo-code for protocol processing 4120 This appendix provides pseudo-code describing how the messages are to be 4121 constructed and interpreted by clients and servers. 4123 A.1. KRB_AS_REQ generation 4125 request.pvno :=3D protocol version; /* pvno =3D 5 */ 4126 request.msg-type :=3D message type; /* type =3D KRB_AS_REQ */ 4128 if(pa_enc_timestamp_required) then 4129 request.padata.padata-type =3D PA-ENC-TIMESTAMP; 4130 get system_time; 4131 padata-body.patimestamp,pausec =3D system_time; 4132 encrypt padata-body into request.padata.padata-value 4133 using client.key; /* derived from password */ 4134 endif 4136 body.kdc-options :=3D users's preferences; 4137 body.cname :=3D user's name; 4138 body.realm :=3D user's realm; 4139 body.sname :=3D service's name; /* usually "krbtgt", = 4140 "localrealm" */ 4141 if (body.kdc-options.POSTDATED is set) then 4142 body.from :=3D requested starting time; 4143 else 4144 omit body.from; 4145 endif 4146 body.till :=3D requested end time; 4147 if (body.kdc-options.RENEWABLE is set) then 4148 body.rtime :=3D requested final renewal time; 4149 endif 4150 body.nonce :=3D random_nonce(); 4151 body.etype :=3D requested etypes; 4152 if (user supplied addresses) then 4153 body.addresses :=3D user's addresses; 4154 else 4155 omit body.addresses; 4156 endif 4157 omit body.enc-authorization-data; 4158 request.req-body :=3D body; 4160 kerberos :=3D lookup(name of local kerberos server (or = 4161 servers)); 4162 send(packet,kerberos); 4164 wait(for response); 4165 if (timed_out) then 4166 retry or use alternate server; 4167 endif 4169 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 4171 decode message into req; 4173 client :=3D lookup(req.cname,req.realm); 4174 server :=3D lookup(req.sname,req.realm); 4175 get system_time; 4176 kdc_time :=3D system_time.seconds; 4178 if (!client) then 4179 /* no client in Database */ 4180 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 4181 endif 4182 if (!server) then 4183 /* no server in Database */ 4184 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 4185 endif 4187 if(client.pa_enc_timestamp_required and 4188 pa_enc_timestamp not present) then 4189 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 4190 endif 4192 if(pa_enc_timestamp present) then 4193 decrypt req.padata-value into decrypted_enc_timestamp 4194 using client.key; 4195 using auth_hdr.authenticator.subkey; 4196 if (decrypt_error()) then 4197 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4198 if(decrypted_enc_timestamp is not within allowable skew) = 4199 then 4200 error_out(KDC_ERR_PREAUTH_FAILED); 4201 endif 4202 if(decrypted_enc_timestamp and usec is replay) 4203 error_out(KDC_ERR_PREAUTH_FAILED); 4204 endif 4205 add decrypted_enc_timestamp and usec to replay cache; 4206 endif 4208 use_etype :=3D first supported etype in req.etypes; 4210 if (no support for req.etypes) then 4211 error_out(KDC_ERR_ETYPE_NOSUPP); 4212 endif 4214 new_tkt.vno :=3D ticket version; /* =3D 5 */ 4215 new_tkt.sname :=3D req.sname; 4216 new_tkt.srealm :=3D req.srealm; 4217 reset all flags in new_tkt.flags; 4219 /* It should be noted that local policy may affect the */ 4220 /* processing of any of these flags. For example, some */ 4221 /* realms may refuse to issue renewable tickets */ 4223 if (req.kdc-options.FORWARDABLE is set) then 4224 set new_tkt.flags.FORWARDABLE; 4225 endif 4226 if (req.kdc-options.PROXIABLE is set) then 4227 set new_tkt.flags.PROXIABLE; 4228 endif 4230 if (req.kdc-options.ALLOW-POSTDATE is set) then 4231 set new_tkt.flags.MAY-POSTDATE; 4232 endif 4233 if ((req.kdc-options.RENEW is set) or 4234 (req.kdc-options.VALIDATE is set) or 4235 (req.kdc-options.PROXY is set) or 4236 (req.kdc-options.FORWARDED is set) or 4237 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 4238 error_out(KDC_ERR_BADOPTION); 4239 endif 4241 new_tkt.session :=3D random_session_key(); 4242 new_tkt.cname :=3D req.cname; 4243 new_tkt.crealm :=3D req.crealm; 4244 new_tkt.transited :=3D empty_transited_field(); 4246 new_tkt.authtime :=3D kdc_time; 4248 if (req.kdc-options.POSTDATED is set) then 4249 if (against_postdate_policy(req.from)) then 4250 error_out(KDC_ERR_POLICY); 4251 endif 4252 set new_tkt.flags.POSTDATED; 4253 set new_tkt.flags.INVALID; 4254 new_tkt.starttime :=3D req.from; 4255 else 4256 omit new_tkt.starttime; /* treated as authtime when omitted = 4257 */ 4258 endif 4259 if (req.till =3D 0) then 4260 till :=3D infinity; 4261 else 4262 till :=3D req.till; 4263 endif 4265 new_tkt.endtime :=3D min(till, 4266 new_tkt.starttime+client.max_life, 4267 new_tkt.starttime+server.max_life, 4268 new_tkt.starttime+max_life_for_realm); 4270 if ((req.kdc-options.RENEWABLE-OK is set) and 4271 (new_tkt.endtime < req.till)) then 4272 /* we set the RENEWABLE option for later processing */ 4273 set req.kdc-options.RENEWABLE; 4274 req.rtime :=3D req.till; 4275 endif 4277 if (req.rtime =3D 0) then 4278 rtime :=3D infinity; 4279 else 4280 rtime :=3D req.rtime; 4281 endif 4283 if (req.kdc-options.RENEWABLE is set) then 4284 set new_tkt.flags.RENEWABLE; 4285 new_tkt.renew-till :=3D min(rtime, 4286 new_tkt.starttime+client.max_rlife, 4287 new_tkt.starttime+server.max_rlife, 4288 new_tkt.starttime+max_rlife_for_realm); 4289 else 4290 omit new_tkt.renew-till; /* only present if RENEWABLE */ 4291 endif 4293 if (req.addresses) then 4294 new_tkt.caddr :=3D req.addresses; 4295 else 4296 omit new_tkt.caddr; 4297 endif 4299 new_tkt.authorization_data :=3D empty_authorization_data(); 4301 encode to-be-encrypted part of ticket into OCTET STRING; 4302 new_tkt.enc-part :=3D encrypt OCTET STRING 4303 using etype_for_key(server.key), server.key, = 4304 server.p_kvno; 4306 /* Start processing the response */ 4308 resp.pvno :=3D 5; 4309 resp.msg-type :=3D KRB_AS_REP; 4310 resp.cname :=3D req.cname; 4311 resp.crealm :=3D req.realm; 4312 resp.ticket :=3D new_tkt; 4314 resp.key :=3D new_tkt.session; 4315 resp.last-req :=3D fetch_last_request_info(client); 4316 resp.nonce :=3D req.nonce; 4317 resp.key-expiration :=3D client.expiration; 4318 resp.flags :=3D new_tkt.flags; 4320 resp.authtime :=3D new_tkt.authtime; 4321 resp.starttime :=3D new_tkt.starttime; 4322 resp.endtime :=3D new_tkt.endtime; 4324 if (new_tkt.flags.RENEWABLE) then 4325 resp.renew-till :=3D new_tkt.renew-till; 4326 endif 4328 resp.realm :=3D new_tkt.realm; 4329 resp.sname :=3D new_tkt.sname; 4331 resp.caddr :=3D new_tkt.caddr; 4333 encode body of reply into OCTET STRING; 4335 resp.enc-part :=3D encrypt OCTET STRING 4336 using use_etype, client.key, client.p_kvno; 4337 send(resp); 4338 A.3. KRB_AS_REP verification 4340 decode response into resp; 4342 if (resp.msg-type =3D KRB_ERROR) then 4343 if(error =3D KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) = 4344 then 4345 set pa_enc_timestamp_required; 4346 goto KRB_AS_REQ; 4347 endif 4348 process_error(resp); 4349 return; 4350 endif 4352 /* On error, discard the response, and zero the session key */ 4353 /* from the response immediately */ 4355 key =3D get_decryption_key(resp.enc-part.kvno, = 4356 resp.enc-part.etype, 4357 resp.padata); 4358 unencrypted part of resp :=3D decode of decrypt of resp.enc-part 4359 using resp.enc-part.etype and key; 4360 zero(key); 4362 if (common_as_rep_tgs_rep_checks fail) then 4363 destroy resp.key; 4364 return error; 4365 endif 4367 if near(resp.princ_exp) then 4368 print(warning message); 4369 endif 4370 save_for_later(ticket,session,client,server,times,flags); 4372 A.4. KRB_AS_REP and KRB_TGS_REP common checks 4374 if (decryption_error() or 4375 (req.cname !=3D resp.cname) or 4376 (req.realm !=3D resp.crealm) or 4377 (req.sname !=3D resp.sname) or 4378 (req.realm !=3D resp.realm) or 4379 (req.nonce !=3D resp.nonce) or 4380 (req.addresses !=3D resp.caddr)) then 4381 destroy resp.key; 4382 return KRB_AP_ERR_MODIFIED; 4383 endif 4385 /* make sure no flags are set that shouldn't be, and that all = 4386 that */ 4387 /* should be are set = 4388 */ 4389 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) = 4390 then 4391 destroy resp.key; 4392 return KRB_AP_ERR_MODIFIED; 4393 endif 4394 if ((req.from =3D 0) and 4395 (resp.starttime is not within allowable skew)) then 4396 destroy resp.key; 4397 return KRB_AP_ERR_SKEW; 4398 endif 4399 if ((req.from !=3D 0) and (req.from !=3D resp.starttime)) then 4400 destroy resp.key; 4401 return KRB_AP_ERR_MODIFIED; 4402 endif 4403 if ((req.till !=3D 0) and (resp.endtime > req.till)) then 4404 destroy resp.key; 4405 return KRB_AP_ERR_MODIFIED; 4406 endif 4408 if ((req.kdc-options.RENEWABLE is set) and 4409 (req.rtime !=3D 0) and (resp.renew-till > req.rtime)) then 4410 destroy resp.key; 4411 return KRB_AP_ERR_MODIFIED; 4412 endif 4413 if ((req.kdc-options.RENEWABLE-OK is set) and 4414 (resp.flags.RENEWABLE) and 4415 (req.till !=3D 0) and 4416 (resp.renew-till > req.till)) then 4417 destroy resp.key; 4418 return KRB_AP_ERR_MODIFIED; 4419 endif 4421 A.5. KRB_TGS_REQ generation 4423 /* Note that make_application_request might have to recursivly = 4424 */ 4425 /* call this routine to get the appropriate ticket-granting = 4426 ticket */ 4428 request.pvno :=3D protocol version; /* pvno =3D 5 */ 4429 request.msg-type :=3D message type; /* type =3D KRB_TGS_REQ */ 4431 body.kdc-options :=3D users's preferences; 4432 /* If the TGT is not for the realm of the end-server */ 4433 /* then the sname will be for a TGT for the end-realm */ 4434 /* and the realm of the requested ticket (body.realm) */ 4435 /* will be that of the TGS to which the TGT we are */ 4436 /* sending applies */ 4437 body.sname :=3D service's name; 4438 body.realm :=3D service's realm; 4440 if (body.kdc-options.POSTDATED is set) then 4441 body.from :=3D requested starting time; 4442 else 4443 omit body.from; 4444 endif 4445 body.till :=3D requested end time; 4446 if (body.kdc-options.RENEWABLE is set) then 4447 body.rtime :=3D requested final renewal time; 4448 endif 4449 body.nonce :=3D random_nonce(); 4450 body.etype :=3D requested etypes; 4451 if (user supplied addresses) then 4452 body.addresses :=3D user's addresses; 4453 else 4454 omit body.addresses; 4455 endif 4457 body.enc-authorization-data :=3D user-supplied data; 4458 if (body.kdc-options.ENC-TKT-IN-SKEY) then 4459 body.additional-tickets_ticket :=3D second TGT; 4460 endif 4462 request.req-body :=3D body; 4463 check :=3D generate_checksum (req.body,checksumtype); 4465 request.padata[0].padata-type :=3D PA-TGS-REQ; 4466 request.padata[0].padata-value :=3D create a KRB_AP_REQ using 4467 the TGT and checksum 4469 /* add in any other padata as required/supplied */ 4471 kerberos :=3D lookup(name of local kerberose server (or = 4472 servers)); 4473 send(packet,kerberos); 4475 wait(for response); 4476 if (timed_out) then 4477 retry or use alternate server; 4478 endif 4480 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 4482 /* note that reading the application request requires first 4483 determining the server for which a ticket was issued, and = 4484 choosing the 4485 correct key for decryption. The name of the server appears in = 4486 the 4487 plaintext part of the ticket. */ 4489 if (no KRB_AP_REQ in req.padata) then 4490 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 4491 endif 4492 verify KRB_AP_REQ in req.padata; 4494 /* Note that the realm in which the Kerberos server is operating = 4495 is 4496 determined by the instance from the ticket-granting ticket. The = 4497 realm 4498 in the ticket-granting ticket is the realm under which the = 4499 ticket 4500 granting ticket was issued. It is possible for a single = 4501 Kerberos 4502 server to support more than one realm. */ 4504 auth_hdr :=3D KRB_AP_REQ; 4505 tgt :=3D auth_hdr.ticket; 4506 if (tgt.sname is not a TGT for local realm and is not req.sname) = 4507 then 4508 error_out(KRB_AP_ERR_NOT_US); 4510 realm :=3D realm_tgt_is_for(tgt); 4512 decode remainder of request; 4514 if (auth_hdr.authenticator.cksum is missing) then 4515 error_out(KRB_AP_ERR_INAPP_CKSUM); 4516 endif 4518 if (auth_hdr.authenticator.cksum type is not supported) then 4519 error_out(KDC_ERR_SUMTYPE_NOSUPP); 4520 endif 4521 if (auth_hdr.authenticator.cksum is not both collision-proof and = 4522 keyed) then 4523 error_out(KRB_AP_ERR_INAPP_CKSUM); 4524 endif 4526 set computed_checksum :=3D checksum(req); 4527 if (computed_checksum !=3D auth_hdr.authenticatory.cksum) then 4528 error_out(KRB_AP_ERR_MODIFIED); 4529 endif 4531 server :=3D lookup(req.sname,realm); 4533 if (!server) then 4534 if (is_foreign_tgt_name(req.sname)) then 4535 server :=3D best_intermediate_tgs(req.sname); 4536 else 4537 /* no server in Database */ 4538 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 4539 endif 4540 endif 4542 session :=3D generate_random_session_key(); 4544 use_etype :=3D first supported etype in req.etypes; 4546 if (no support for req.etypes) then 4547 error_out(KDC_ERR_ETYPE_NOSUPP); 4548 endif 4550 new_tkt.vno :=3D ticket version; /* =3D 5 */ 4551 new_tkt.sname :=3D req.sname; 4552 new_tkt.srealm :=3D realm; 4553 reset all flags in new_tkt.flags; 4555 /* It should be noted that local policy may affect the */ 4556 /* processing of any of these flags. For example, some */ 4557 /* realms may refuse to issue renewable tickets */ 4558 new_tkt.caddr :=3D tgt.caddr; 4559 resp.caddr :=3D NULL; /* We only include this if they change */ 4560 if (req.kdc-options.FORWARDABLE is set) then 4561 if (tgt.flags.FORWARDABLE is reset) then 4562 error_out(KDC_ERR_BADOPTION); 4563 endif 4564 set new_tkt.flags.FORWARDABLE; 4565 endif 4566 if (req.kdc-options.FORWARDED is set) then 4567 if (tgt.flags.FORWARDABLE is reset) then 4568 error_out(KDC_ERR_BADOPTION); 4569 endif 4570 set new_tkt.flags.FORWARDED; 4571 new_tkt.caddr :=3D req.addresses; 4572 resp.caddr :=3D req.addresses; 4573 endif 4574 if (tgt.flags.FORWARDED is set) then 4575 set new_tkt.flags.FORWARDED; 4576 endif 4578 if (req.kdc-options.PROXIABLE is set) then 4579 if (tgt.flags.PROXIABLE is reset) 4580 error_out(KDC_ERR_BADOPTION); 4581 endif 4582 set new_tkt.flags.PROXIABLE; 4583 endif 4584 if (req.kdc-options.PROXY is set) then 4585 if (tgt.flags.PROXIABLE is reset) then 4586 error_out(KDC_ERR_BADOPTION); 4587 endif 4588 set new_tkt.flags.PROXY; 4589 new_tkt.caddr :=3D req.addresses; 4590 resp.caddr :=3D req.addresses; 4591 endif 4593 if (req.kdc-options.ALLOW-POSTDATE is set) then 4594 if (tgt.flags.MAY-POSTDATE is reset) 4595 error_out(KDC_ERR_BADOPTION); 4596 endif 4597 set new_tkt.flags.MAY-POSTDATE; 4598 endif 4599 if (req.kdc-options.POSTDATED is set) then 4600 if (tgt.flags.MAY-POSTDATE is reset) then 4601 error_out(KDC_ERR_BADOPTION); 4602 endif 4603 set new_tkt.flags.POSTDATED; 4604 set new_tkt.flags.INVALID; 4605 if (against_postdate_policy(req.from)) then 4606 error_out(KDC_ERR_POLICY); 4607 endif 4608 new_tkt.starttime :=3D req.from; 4609 endif 4610 if (req.kdc-options.VALIDATE is set) then 4611 if (tgt.flags.INVALID is reset) then 4612 error_out(KDC_ERR_POLICY); 4613 endif 4614 if (tgt.starttime > kdc_time) then 4615 error_out(KRB_AP_ERR_NYV); 4616 endif 4617 if (check_hot_list(tgt)) then 4618 error_out(KRB_AP_ERR_REPEAT); 4619 endif 4620 tkt :=3D tgt; 4621 reset new_tkt.flags.INVALID; 4622 endif 4624 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 4625 and those already processed) is set) then 4626 error_out(KDC_ERR_BADOPTION); 4627 endif 4629 new_tkt.authtime :=3D tgt.authtime; 4631 if (req.kdc-options.RENEW is set) then 4632 /* Note that if the endtime has already passed, the ticket = 4633 would */ 4634 /* have been rejected in the initial authentication stage, so = 4635 */ 4636 /* there is no need to check again here = 4637 */ 4638 if (tgt.flags.RENEWABLE is reset) then 4639 error_out(KDC_ERR_BADOPTION); 4640 endif 4641 if (tgt.renew-till < kdc_time) then 4642 error_out(KRB_AP_ERR_TKT_EXPIRED); 4643 endif 4644 tkt :=3D tgt; 4645 new_tkt.starttime :=3D kdc_time; 4646 old_life :=3D tgt.endttime - tgt.starttime; 4647 new_tkt.endtime :=3D min(tgt.renew-till, 4648 new_tkt.starttime + old_life); 4649 else 4650 new_tkt.starttime :=3D kdc_time; 4651 if (req.till =3D 0) then 4652 till :=3D infinity; 4653 else 4654 till :=3D req.till; 4655 endif 4656 new_tkt.endtime :=3D min(till, 4657 = 4658 new_tkt.starttime+client.max_life, 4659 = 4660 new_tkt.starttime+server.max_life, 4661 = 4662 new_tkt.starttime+max_life_for_realm, 4663 tgt.endtime); 4664 if ((req.kdc-options.RENEWABLE-OK is set) and 4665 (new_tkt.endtime < req.till) and 4666 (tgt.flags.RENEWABLE is set) then 4667 /* we set the RENEWABLE option for later = 4668 processing */ 4669 set req.kdc-options.RENEWABLE; 4670 req.rtime :=3D min(req.till, tgt.renew-till); 4671 endif 4672 endif 4674 if (req.rtime =3D 0) then 4675 rtime :=3D infinity; 4676 else 4677 rtime :=3D req.rtime; 4678 endif 4680 if ((req.kdc-options.RENEWABLE is set) and 4681 (tgt.flags.RENEWABLE is set)) then 4682 set new_tkt.flags.RENEWABLE; 4683 new_tkt.renew-till :=3D min(rtime, 4684 = 4685 new_tkt.starttime+client.max_rlife, 4686 = 4687 new_tkt.starttime+server.max_rlife, 4688 = 4689 new_tkt.starttime+max_rlife_for_realm, 4690 tgt.renew-till); 4691 else 4692 new_tkt.renew-till :=3D OMIT; /* leave the renew-till = 4693 field out */ 4694 endif 4695 if (req.enc-authorization-data is present) then 4696 decrypt req.enc-authorization-data into = 4697 decrypted_authorization_data 4698 using auth_hdr.authenticator.subkey; 4699 if (decrypt_error()) then 4700 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4701 endif 4702 endif 4703 new_tkt.authorization_data :=3D = 4704 req.auth_hdr.ticket.authorization_data + 4705 decrypted_authorization_data; 4707 new_tkt.key :=3D session; 4708 new_tkt.crealm :=3D tgt.crealm; 4709 new_tkt.cname :=3D req.auth_hdr.ticket.cname; 4711 if (realm_tgt_is_for(tgt) :=3D tgt.realm) then 4712 /* tgt issued by local realm */ 4713 new_tkt.transited :=3D tgt.transited; 4714 else 4715 /* was issued for this realm by some other realm */ 4716 if (tgt.transited.tr-type not supported) then 4717 error_out(KDC_ERR_TRTYPE_NOSUPP); 4718 endif 4719 new_tkt.transited :=3D compress_transited(tgt.transited = 4720 + tgt.realm) 4721 /* Don't check tranited field if TGT for foreign realm,=20 4722 * or requested not to check */ 4723 if (is_not_foreign_tgt_name(new_tkt.server)=20 4724 && req.kdc-options.DISABLE-TRANSITED-CHECK not set) = 4725 then 4726 /* Check it, so end-server does not have to=20 4727 * but don't fail, end-server may still accept = 4728 it */ 4729 if (check_transited_field(new_tkt.transited) = 4730 =3D=3D OK) 4731 set = 4732 new_tkt.flags.TRANSITED-POLICY-CHECKED; 4733 endif 4734 endif 4735 endif 4737 encode encrypted part of new_tkt into OCTET STRING; 4738 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 4739 if (server not specified) then 4740 server =3D req.second_ticket.client; 4741 endif 4742 if ((req.second_ticket is not a TGT) or 4743 (req.second_ticket.client !=3D server)) then 4744 error_out(KDC_ERR_POLICY); 4745 endif 4747 new_tkt.enc-part :=3D encrypt OCTET STRING using 4748 using etype_for_key(second-ticket.key), = 4749 second-ticket.key; 4750 else 4751 new_tkt.enc-part :=3D encrypt OCTET STRING 4752 using etype_for_key(server.key), server.key, = 4753 server.p_kvno; 4754 endif 4756 resp.pvno :=3D 5; 4757 resp.msg-type :=3D KRB_TGS_REP; 4758 resp.crealm :=3D tgt.crealm; 4759 resp.cname :=3D tgt.cname; 4760 resp.ticket :=3D new_tkt; 4762 resp.key :=3D session; 4763 resp.nonce :=3D req.nonce; 4764 resp.last-req :=3D fetch_last_request_info(client); 4765 resp.flags :=3D new_tkt.flags; 4767 resp.authtime :=3D new_tkt.authtime; 4768 resp.starttime :=3D new_tkt.starttime; 4769 resp.endtime :=3D new_tkt.endtime; 4771 omit resp.key-expiration; 4773 resp.sname :=3D new_tkt.sname; 4774 resp.realm :=3D new_tkt.realm; 4776 if (new_tkt.flags.RENEWABLE) then 4777 resp.renew-till :=3D new_tkt.renew-till; 4778 endif 4779 encode body of reply into OCTET STRING; 4781 if (req.padata.authenticator.subkey) 4782 resp.enc-part :=3D encrypt OCTET STRING using use_etype, 4783 req.padata.authenticator.subkey; 4784 else resp.enc-part :=3D encrypt OCTET STRING using use_etype, = 4785 tgt.key; 4787 send(resp); 4789 =09 4791 A.7. KRB_TGS_REP verification 4793 decode response into resp; 4795 if (resp.msg-type =3D KRB_ERROR) then 4796 process_error(resp); 4797 return; 4798 endif 4800 /* On error, discard the response, and zero the session key from 4801 the response immediately */ 4803 if (req.padata.authenticator.subkey) 4804 unencrypted part of resp :=3D decode of decrypt of = 4805 resp.enc-part 4806 using resp.enc-part.etype and subkey; 4807 else unencrypted part of resp :=3D decode of decrypt of = 4808 resp.enc-part 4809 using resp.enc-part.etype and tgt's = 4810 session key; 4811 if (common_as_rep_tgs_rep_checks fail) then 4812 destroy resp.key; 4813 return error; 4814 endif 4816 check authorization_data as necessary; 4817 save_for_later(ticket,session,client,server,times,flags); 4819 A.8. Authenticator generation 4821 body.authenticator-vno :=3D authenticator vno; /* =3D 5 */ 4822 body.cname, body.crealm :=3D client name; 4823 if (supplying checksum) then 4824 body.cksum :=3D checksum; 4825 endif 4826 get system_time; 4827 body.ctime, body.cusec :=3D system_time; 4828 if (selecting sub-session key) then 4829 select sub-session key; 4830 body.subkey :=3D sub-session key; 4831 endif 4832 if (using sequence numbers) then 4833 select initial sequence number; 4834 body.seq-number :=3D initial sequence; 4835 endif 4836 A.9. KRB_AP_REQ generation 4838 obtain ticket and session_key from cache; 4840 packet.pvno :=3D protocol version; /* 5 */ 4841 packet.msg-type :=3D message type; /* KRB_AP_REQ */ 4843 if (desired(MUTUAL_AUTHENTICATION)) then 4844 set packet.ap-options.MUTUAL-REQUIRED; 4845 else 4846 reset packet.ap-options.MUTUAL-REQUIRED; 4847 endif 4848 if (using session key for ticket) then 4849 set packet.ap-options.USE-SESSION-KEY; 4850 else 4851 reset packet.ap-options.USE-SESSION-KEY; 4852 endif 4853 packet.ticket :=3D ticket; /* ticket */ 4854 generate authenticator; 4855 encode authenticator into OCTET STRING; 4856 encrypt OCTET STRING into packet.authenticator using = 4857 session_key; 4859 A.10. KRB_AP_REQ verification 4861 receive packet; 4862 if (packet.pvno !=3D 5) then 4863 either process using other protocol spec 4864 or error_out(KRB_AP_ERR_BADVERSION); 4865 endif 4866 if (packet.msg-type !=3D KRB_AP_REQ) then 4867 error_out(KRB_AP_ERR_MSG_TYPE); 4868 endif 4869 if (packet.ticket.tkt_vno !=3D 5) then 4870 either process using other protocol spec 4871 or error_out(KRB_AP_ERR_BADVERSION); 4872 endif 4873 if (packet.ap_options.USE-SESSION-KEY is set) then 4874 retrieve session key from ticket-granting ticket for 4875 packet.ticket.{sname,srealm,enc-part.etype}; 4876 else 4877 retrieve service key for 4878 = 4879 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 4880 endif 4881 if (no_key_available) then 4882 if (cannot_find_specified_skvno) then 4883 error_out(KRB_AP_ERR_BADKEYVER); 4884 else 4885 error_out(KRB_AP_ERR_NOKEY); 4886 endif 4887 endif 4888 decrypt packet.ticket.enc-part into decr_ticket using retrieved = 4889 key; 4890 if (decryption_error()) then 4891 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4892 endif 4893 decrypt packet.authenticator into decr_authenticator 4894 using decr_ticket.key; 4895 if (decryption_error()) then 4896 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4897 endif 4898 if (decr_authenticator.{cname,crealm} !=3D 4899 decr_ticket.{cname,crealm}) then 4900 error_out(KRB_AP_ERR_BADMATCH); 4901 endif 4902 if (decr_ticket.caddr is present) then 4903 if (sender_address(packet) is not in decr_ticket.caddr) = 4904 then 4905 error_out(KRB_AP_ERR_BADADDR); 4906 endif 4907 elseif (application requires addresses) then 4908 error_out(KRB_AP_ERR_BADADDR); 4909 endif 4910 if (not in_clock_skew(decr_authenticator.ctime, 4911 decr_authenticator.cusec)) then 4912 error_out(KRB_AP_ERR_SKEW); 4913 endif 4914 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) = 4915 then 4916 error_out(KRB_AP_ERR_REPEAT); 4917 endif 4918 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 4919 get system_time; 4920 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 4921 (decr_ticket.flags.INVALID is set)) then 4922 /* it hasn't yet become valid */ 4923 error_out(KRB_AP_ERR_TKT_NYV); 4924 endif 4925 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 4926 error_out(KRB_AP_ERR_TKT_EXPIRED); 4927 endif 4928 if (decr_ticket.transited) then 4929 /* caller may ignore the TRANSITED-POLICY-CHECKED and do 4930 * check anyway */ 4931 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then 4932 if (check_transited_field(decr_ticket.transited) then 4933 error_out(KDC_AP_PATH_NOT_ACCPETED); 4934 endif 4935 endif 4936 endif 4937 /* caller must check decr_ticket.flags for any pertinent details = 4938 */ 4939 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 4941 A.11. KRB_AP_REP generation 4943 packet.pvno :=3D protocol version; /* 5 */ 4944 packet.msg-type :=3D message type; /* KRB_AP_REP */ 4946 body.ctime :=3D packet.ctime; 4947 body.cusec :=3D packet.cusec; 4948 if (selecting sub-session key) then 4949 select sub-session key; 4950 body.subkey :=3D sub-session key; 4951 endif 4952 if (using sequence numbers) then 4953 select initial sequence number; 4954 body.seq-number :=3D initial sequence; 4955 endif 4957 encode body into OCTET STRING; 4959 select encryption type; 4960 encrypt OCTET STRING into packet.enc-part; 4962 A.12. KRB_AP_REP verification 4964 receive packet; 4965 if (packet.pvno !=3D 5) then 4966 either process using other protocol spec 4967 or error_out(KRB_AP_ERR_BADVERSION); 4968 endif 4969 if (packet.msg-type !=3D KRB_AP_REP) then 4970 error_out(KRB_AP_ERR_MSG_TYPE); 4971 endif 4972 cleartext :=3D decrypt(packet.enc-part) using ticket's session = 4973 key; 4974 if (decryption_error()) then 4975 error_out(KRB_AP_ERR_BAD_INTEGRITY); 4976 endif 4977 if (cleartext.ctime !=3D authenticator.ctime) then 4978 error_out(KRB_AP_ERR_MUT_FAIL); 4979 endif 4980 if (cleartext.cusec !=3D authenticator.cusec) then 4981 error_out(KRB_AP_ERR_MUT_FAIL); 4982 endif 4983 if (cleartext.subkey is present) then 4984 save cleartext.subkey for future use; 4985 endif 4986 if (cleartext.seq-number is present) then 4987 save cleartext.seq-number for future verifications; 4988 endif 4989 return(AUTHENTICATION_SUCCEEDED); 4991 A.13. KRB_SAFE generation 4993 collect user data in buffer; 4995 /* assemble packet: */ 4996 packet.pvno :=3D protocol version; /* 5 */ 4997 packet.msg-type :=3D message type; /* KRB_SAFE */ 4999 body.user-data :=3D buffer; /* DATA */ 5000 if (using timestamp) then 5001 get system_time; 5002 body.timestamp, body.usec :=3D system_time; 5003 endif 5004 if (using sequence numbers) then 5005 body.seq-number :=3D sequence number; 5006 endif 5007 body.s-address :=3D sender host addresses; 5008 if (only one recipient) then 5009 body.r-address :=3D recipient host address; 5010 endif 5011 checksum.cksumtype :=3D checksum type; 5012 compute checksum over body; 5013 checksum.checksum :=3D checksum value; /* checksum.checksum */ 5014 packet.cksum :=3D checksum; 5015 packet.safe-body :=3D body; 5017 A.14. KRB_SAFE verification 5019 receive packet; 5020 if (packet.pvno !=3D 5) then 5021 either process using other protocol spec 5022 or error_out(KRB_AP_ERR_BADVERSION); 5023 endif 5024 if (packet.msg-type !=3D KRB_SAFE) then 5025 error_out(KRB_AP_ERR_MSG_TYPE); 5026 endif 5027 if (packet.checksum.cksumtype is not both collision-proof and = 5028 keyed) then 5029 error_out(KRB_AP_ERR_INAPP_CKSUM); 5030 endif 5031 if (safe_priv_common_checks_ok(packet)) then 5032 set computed_checksum :=3D checksum(packet.body); 5033 if (computed_checksum !=3D packet.checksum) then 5034 error_out(KRB_AP_ERR_MODIFIED); 5035 endif 5036 return (packet, PACKET_IS_GENUINE); 5037 else 5038 return common_checks_error; 5039 endif 5041 A.15. KRB_SAFE and KRB_PRIV common checks 5043 if (packet.s-address !=3D O/S_sender(packet)) then 5044 /* O/S report of sender not who claims to have sent it = 5045 */ 5046 error_out(KRB_AP_ERR_BADADDR); 5047 endif 5048 if ((packet.r-address is present) and 5049 (packet.r-address !=3D local_host_address)) then 5050 /* was not sent to proper place */ 5051 error_out(KRB_AP_ERR_BADADDR); 5052 endif 5053 if (((packet.timestamp is present) and 5054 (not in_clock_skew(packet.timestamp,packet.usec))) or 5055 (packet.timestamp is not present and timestamp expected)) = 5056 then 5057 error_out(KRB_AP_ERR_SKEW); 5058 endif 5059 if (repeated(packet.timestamp,packet.usec,packet.s-address)) = 5060 then 5061 error_out(KRB_AP_ERR_REPEAT); 5062 endif 5064 if (((packet.seq-number is present) and 5065 ((not in_sequence(packet.seq-number)))) or 5066 (packet.seq-number is not present and sequence expected)) = 5067 then 5068 error_out(KRB_AP_ERR_BADORDER); 5069 endif 5070 if (packet.timestamp not present and packet.seq-number not = 5071 present) then 5072 error_out(KRB_AP_ERR_MODIFIED); 5073 endif 5075 save_identifier(packet.{timestamp,usec,s-address}, 5076 sender_principal(packet)); 5078 return PACKET_IS_OK; 5080 A.16. KRB_PRIV generation 5082 collect user data in buffer; 5084 /* assemble packet: */ 5085 packet.pvno :=3D protocol version; /* 5 */ 5086 packet.msg-type :=3D message type; /* KRB_PRIV */ 5088 packet.enc-part.etype :=3D encryption type; 5090 body.user-data :=3D buffer; 5091 if (using timestamp) then 5092 get system_time; 5093 body.timestamp, body.usec :=3D system_time; 5094 endif 5095 if (using sequence numbers) then 5096 body.seq-number :=3D sequence number; 5097 endif 5098 body.s-address :=3D sender host addresses; 5099 if (only one recipient) then 5100 body.r-address :=3D recipient host address; 5101 endif 5103 encode body into OCTET STRING; 5105 select encryption type; 5106 encrypt OCTET STRING into packet.enc-part.cipher; 5108 A.17. KRB_PRIV verification 5110 receive packet; 5111 if (packet.pvno !=3D 5) then 5112 either process using other protocol spec 5113 or error_out(KRB_AP_ERR_BADVERSION); 5114 endif 5115 if (packet.msg-type !=3D KRB_PRIV) then 5116 error_out(KRB_AP_ERR_MSG_TYPE); 5117 endif 5119 cleartext :=3D decrypt(packet.enc-part) using negotiated key; 5120 if (decryption_error()) then 5121 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5122 endif 5124 if (safe_priv_common_checks_ok(cleartext)) then 5125 return(cleartext.DATA, = 5126 PACKET_IS_GENUINE_AND_UNMODIFIED); 5127 else 5128 return common_checks_error; 5129 endif 5130 A.18. KRB_CRED generation 5132 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 5134 /* assemble packet: */ 5135 packet.pvno :=3D protocol version; /* 5 */ 5136 packet.msg-type :=3D message type; /* KRB_CRED */ 5138 for (tickets[n] in tickets to be forwarded) do 5139 packet.tickets[n] =3D tickets[n].ticket; 5140 done 5142 packet.enc-part.etype :=3D encryption type; 5144 for (ticket[n] in tickets to be forwarded) do 5145 body.ticket-info[n].key =3D tickets[n].session; 5146 body.ticket-info[n].prealm =3D tickets[n].crealm; 5147 body.ticket-info[n].pname =3D tickets[n].cname; 5148 body.ticket-info[n].flags =3D tickets[n].flags; 5149 body.ticket-info[n].authtime =3D tickets[n].authtime; 5150 body.ticket-info[n].starttime =3D tickets[n].starttime; 5151 body.ticket-info[n].endtime =3D tickets[n].endtime; 5152 body.ticket-info[n].renew-till =3D = 5153 tickets[n].renew-till; 5154 body.ticket-info[n].srealm =3D tickets[n].srealm; 5155 body.ticket-info[n].sname =3D tickets[n].sname; 5156 body.ticket-info[n].caddr =3D tickets[n].caddr; 5157 done 5159 get system_time; 5160 body.timestamp, body.usec :=3D system_time; 5162 if (using nonce) then 5163 body.nonce :=3D nonce; 5164 endif 5166 if (using s-address) then 5167 body.s-address :=3D sender host addresses; 5168 endif 5169 if (limited recipients) then 5170 body.r-address :=3D recipient host address; 5171 endif 5173 encode body into OCTET STRING; 5175 select encryption type; 5176 encrypt OCTET STRING into packet.enc-part.cipher 5177 using negotiated encryption key; 5178 A.19. KRB_CRED verification 5180 receive packet; 5181 if (packet.pvno !=3D 5) then 5182 either process using other protocol spec 5183 or error_out(KRB_AP_ERR_BADVERSION); 5184 endif 5185 if (packet.msg-type !=3D KRB_CRED) then 5186 error_out(KRB_AP_ERR_MSG_TYPE); 5187 endif 5189 cleartext :=3D decrypt(packet.enc-part) using negotiated key; 5190 if (decryption_error()) then 5191 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5192 endif 5193 if ((packet.r-address is present or required) and 5194 (packet.s-address !=3D O/S_sender(packet)) then 5195 /* O/S report of sender not who claims to have sent it = 5196 */ 5197 error_out(KRB_AP_ERR_BADADDR); 5198 endif 5199 if ((packet.r-address is present) and 5200 (packet.r-address !=3D local_host_address)) then 5201 /* was not sent to proper place */ 5202 error_out(KRB_AP_ERR_BADADDR); 5203 endif 5204 if (not in_clock_skew(packet.timestamp,packet.usec)) then 5205 error_out(KRB_AP_ERR_SKEW); 5206 endif 5207 if (repeated(packet.timestamp,packet.usec,packet.s-address)) = 5208 then 5209 error_out(KRB_AP_ERR_REPEAT); 5210 endif 5211 if (packet.nonce is required or present) and 5212 (packet.nonce !=3D expected-nonce) then 5213 error_out(KRB_AP_ERR_MODIFIED); 5214 endif 5216 for (ticket[n] in tickets that were forwarded) do 5217 save_for_later(ticket[n],key[n],principal[n], 5218 server[n],times[n],flags[n]); 5219 return 5221 A.20. KRB_ERROR generation 5223 /* assemble packet: */ 5224 packet.pvno :=3D protocol version; /* 5 */ 5225 packet.msg-type :=3D message type; /* KRB_ERROR */ 5227 get system_time; 5228 packet.stime, packet.susec :=3D system_time; 5229 packet.realm, packet.sname :=3D server name; 5231 if (client time available) then 5232 packet.ctime, packet.cusec :=3D client_time; 5233 endif 5234 packet.error-code :=3D error code; 5235 if (client name available) then 5236 packet.cname, packet.crealm :=3D client name; 5237 endif 5238 if (error text available) then 5239 packet.e-text :=3D error text; 5240 endif 5241 if (error data available) then 5242 packet.e-data :=3D error data; 5243 endif 5244 B. Definition of common authorization data elements 5246 This appendix contains the definitions of common authorization data 5247 elements. These common authorization data elements are recursivly defined, 5248 meaning the ad-data for these types will itself contain a sequence of 5249 authorization data whose interpretation is affected by the encapsulating 5250 element. Depending on the meaning of the encapsulating element, the 5251 encapsulated elements may be ignored, might be interpreted as issued 5252 directly by the KDC, or they might be stored in a separate plaintext part of 5253 the ticket. The types of the encapsulating elements are specified as part of 5254 the Kerberos specification because the behavior based on these values should 5255 be understood across implementations whereas other elements need only be 5256 understood by the applications which they affect. 5258 In the definitions that follow, the value of the ad-type for the element 5259 will be specified in the subsection number, and the value of the ad-data 5260 will be as shown in the ASN.1 structure that follows the subsection heading. 5262 B.1. If relevant 5264 AD-IF-RELEVANT AuthorizationData 5266 AD elements encapsulated within the if-relevant element are intended for 5267 interpretation only by application servers that understand the particular 5268 ad-type of the embedded element. Application servers that do not understand 5269 the type of an element embedded within the if-relevant element may ignore 5270 the uninterpretable element. This element promotes interoperability across 5271 implementations which may have local extensions for authorization. 5273 B.2. Intended for server 5275 AD-INTENDED-FOR-SERVER SEQUENCE { 5276 intended-server[0] SEQUENCE OF PrincipalName 5277 elements[1] AuthorizationData 5278 } 5280 AD elements encapsulated within the intended-for-server element may be 5281 ignored if the application server is not in the list of principal names of 5282 intended servers. Further, a KDC issuing a ticket for an application server 5283 can remove this element if the application server is not in the list of 5284 intended servers. 5286 Application servers should check for their principal name in the 5287 intended-server field of this element. If their principal name is not found, 5288 this element should be ignored. If found, then the encapsulated elements 5289 should be evaluated in the same manner as if they were present in the top 5290 level authorization data field. Applications and application servers that do 5291 not implement this element should reject tickets that contain authorization 5292 data elements of this type. 5294 B.3. Intended for application class 5296 AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] 5297 SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements 5298 encapsulated within the intended-for-application-class element may be 5299 ignored if the application server is not in one of the named classes of 5300 application servers. Examples of application server classes include 5301 "FILESYSTEM", and other kinds of servers.=20 5303 This element and the elements it encapulates may be safely ignored by 5304 applications, application servers, and KDCs that do not implement this 5305 element. 5307 B.4. KDC Issued 5309 AD-KDCIssued SEQUENCE { 5310 ad-checksum[0] Checksum, 5311 i-realm[1] Realm OPTIONAL, 5312 i-sname[2] PrincipalName OPTIONAL, 5313 elements[3] AuthorizationData. 5314 } 5316 ad-checksum 5317 A checksum over the elements field using a cryptographic checksum 5318 method that is identical to the checksum used to protect the ticket 5319 itself (i.e. using the same hash function and the same encryption 5320 algorithm used to encrypt the ticket) and using a key derived from the 5321 same key used to protect the ticket. 5322 i-realm, i-sname 5323 The name of the issuing principal if different from the KDC itself. 5324 This field would be used when the KDC can verify the authenticity of 5325 elements signed by the issuing principal and it allows this KDC to 5326 notify the application server of the validity of those elements. 5327 elements 5328 A sequence of authorization data elements issued by the KDC. 5330 The KDC-issued ad-data field is intended to provide a means for Kerberos 5331 principal credentials to embed within themselves privilege attributes and 5332 other mechanisms for positive authorization, amplifying the priveleges of 5333 the principal beyond what can be done using a credentials without such an 5334 a-data element. 5336 This can not be provided without this element because the definition of the 5337 authorization-data field allows elements to be added at will by the bearer 5338 of a TGT at the time that they request service tickets and elements may also 5339 be added to a delegated ticket by inclusion in the authenticator. 5341 For KDC-issued elements this is prevented because the elements are signed by 5342 the KDC by including a checksum encrypted using the server's key (the same 5343 key used to encrypt the ticket - or a key derived from that key). Elements 5344 encapsulated with in the KDC-issued element will be ignored by the 5345 application server if this "signature" is not present. Further, elements 5346 encapsulated within this element from a ticket granting ticket may be 5347 interpreted by the KDC, and used as a basis according to policy for 5348 including new signed elements within derivative tickets, but they will not 5349 be copied to a derivative ticket directly. If they are copied directly to a 5350 derivative ticket by a KDC that is not aware of this element, the signature 5351 will not be correct for the application ticket elements, and the field will 5352 be ignored by the application server. 5354 This element and the elements it encapulates may be safely ignored by 5355 applications, application servers, and KDCs that do not implement this 5356 element. 5358 B.5. And-Or 5360 AD-AND-OR SEQUENCE { 5361 condition-count[0] INTEGER, 5362 elements[1] AuthorizationData 5363 }=20 5365 When restrictive AD elements encapsulated within the and-or element are 5366 encountered, only the number specified in condition-count of the 5367 encapsulated conditions must be met in order to satisfy this element. This 5368 element may be used to implement an "or" operation by setting the 5369 condition-count field to 1, and it may specify an "and" operation by setting 5370 the condition count to the number of embedded elements. Application servers 5371 that do not implement this element must reject tickets that contain 5372 authorization data elements of this type. 5374 B.6. Mandatory ticket extensions 5376 AD-Mandatory-Ticket-Extensions SEQUENCE { 5377 te-type[0] INTEGER, 5378 te-checksum[0] Checksum 5379 }=20 5381 An authorization data element of type mandatory-ticket-extensions specifies 5382 the type and a collision-proof checksum using the same hash algorithm used 5383 to protect the integrity of the ticket itself. This checksum will be 5384 calculated over an individual extension field of the type indicated. If 5385 there are more than one extension, multiple Mandatory-Ticket-Extensions 5386 authorization data elements may be present, each with a checksum for a 5387 different extension field. This restriction indicates that the ticket should 5388 not be accepted if a ticket extension is not present in the ticket for which 5389 the type and checksum do not match that checksum specified in the 5390 authorization data element. Note that although the type is redundant for the 5391 purposes of the comparison, it makes the comparison easier when multiple 5392 extensions are present. Application servers that do not implement this 5393 element must reject tickets that contain authorization data elements of this 5394 type. 5396 B.7. Authorization Data in ticket extensions 5398 AD-IN-Ticket-Extensions Checksum 5400 An authorization data element of type in-ticket-extensions specifies a 5401 collision-proof checksum using the same hash algorithm used to protect the 5402 integrity of the ticket itself. This checksum is calculated over a separate 5403 external AuthorizationData field carried in the ticket extensions. 5404 Application servers that do not implement this element must reject tickets 5405 that contain authorization data elements of this type. Application servers 5406 that do implement this element will search the ticket extensions for 5407 authorization data fields, calculate the specified checksum over each 5408 authorization data field and look for one matching the checksum in this 5409 in-ticket-extensions element. If not found, then the ticket must be 5410 rejected. If found, the corresponding authorization data elements will be 5411 interpreted in the same manner as if they were contained in the top level 5412 authorization data field. 5414 Note that if multiple external authorization data fields are present in a 5415 ticket, each will have a corresponding element of type in-ticket-extensions 5416 in the top level authorization data field, and the external entries will be 5417 linked to the corresponding element by their checksums. 5419 C. Definition of common ticket extensions 5421 This appendix contains the definitions of common ticket extensions. Support 5422 for these extensions is optional. However, certain extensions have 5423 associated authorization data elements that may require rejection of a 5424 ticket containing an extension by application servers that do not implement 5425 the particular extension. Other extensions have been defined beyond those 5426 described in this specification. Such extensions are described elswhere and 5427 for some of those extensions the reserved number may be found in the list of 5428 constants. 5430 It is known that older versions of Kerberos did not support this field, and 5431 that some clients will strip this field from a ticket when they parse and 5432 then reassemble a ticket as it is passed to the application servers. The 5433 presence of the extension will not break such clients, but any functionaly 5434 dependent on the extensions will not work when such tickets are handled by 5435 old clients. In such situations, some implementation may use alternate 5436 methods to transmit the information in the extensions field. 5438 C.1. Null ticket extension 5440 TE-NullExtension OctetString -- The empty Octet String 5442 The te-data field in the null ticket extension is an octet string of lenght 5443 zero. This extension may be included in a ticket granting ticket so that the 5444 KDC can determine on presentation of the ticket granting ticket whether the 5445 client software will strip the extensions field. =20 5447 C.2. External Authorization Data 5449 TE-ExternalAuthorizationData AuthorizationData 5451 The te-data field in the external authorization data ticket extension is 5452 field of type AuthorizationData containing one or more authorization data 5453 elements. If present, a corresponding authorization data element will be 5454 present in the primary authorization data for the ticket and that element 5455 will contain a checksum of the external authorization data ticket extension. 5457 D. Significant changes since RFC 1510 5459 Commentary 5461 Section 1: The preamble and introduction does not define the protocol, 5462 mention is made in the introduction regarding the ability to rely on the KDC 5463 to check the transited field, and on the inclusion of a flag in a ticket 5464 indicating that this check has occurred. This is a new capability not 5465 present in RFC1510. Pre-existing implementation may ignore or not set this 5466 flag without negative security implications. 5468 The definition of the secret key says that in the case of a user the key may 5469 be derived from a password. In 1510, it said that the key was derived from 5470 the password. This change was made to accommodate situations where the user 5471 key might be stored on a smart-card, or otherwise obtained independent of a 5472 password. 5474 The introduction also mentions the use of public key for initial 5475 authentication in Kerberos by reference. RFC1510 did not include such a 5476 reference. 5478 Section 1.2 was added to explain that while Kerberos provides authentication 5479 of a named principal, it is still the responsibility of the application to 5480 ensure that the authenticated name is the entity with which the application 5481 wishes to communicate. Because section 1.2 is completely new, I am 5482 particularly interested in suggestions to improve the wording of this 5483 section. Sections 1.2-4 were renumbered. 5485 Section 2: No changes were made to existing options and flags specified in 5486 RFC1510, though some of the sections in the specification were renumbered, 5487 and text was revised to make the description and intent of existing options 5488 clearer, especially with respect to the ENC-TKT-IN-SKEY option (now section 5489 2.9.3) which is used for user-to-user authentication. New options and ticket 5490 flags added since RFC1510 include transited policy checking (section 2.7), 5491 anonymous tickets (section 2.8) and name canonicalization (section 2.9.1). 5493 Section 3: Added mention of the optional checksum field in the KRB-ERROR 5494 message. Added mention of name canonicalization and anonymous tickets in 5495 exposition on KDC options. Mention of the name canonicalization case is 5496 included in the description of the KDC reply (3.1.3). A warning regarding 5497 generation of session keys for application use was added, urging the 5498 inclusion of key entropy from the KDC generated session key in the ticket. 5499 An example regarding use of the subsession key was added to section 3.2.6. 5500 Descriptions of the pa-etype-info, and pa-pw-salt preauthentication data 5501 items were added. 5503 Changes to section 4: Added language about who has access to the keys in the 5504 Kerberos database. Also made it clear that KDC's may obtain the information 5505 from some database field through other means - for example, one form of 5506 pkinit may extract some of these fields from a certificate. 5508 Regarding the discussion on the list regarding the use of tamper resistant 5509 hardware to store keys, I was not able to determine specific suggested 5510 changes to the text in the RFC regarding this. Much of this discussion 5511 centers around particular implementations. I did however loosen the wording 5512 about the database so as not to preclude keys that can not be extracted in 5513 the clear from such hardware. 5515 Section 5: A statement regarding the carrying of unrecognized additional 5516 fields in ASN.1 encoding through in tickets was added (still waiting on some 5517 better text regarding this). 5519 Ticket flags and KDC options were added to support the new functions 5520 described elsewhere in this document. The encoding of the options flags are 5521 now described to be no less than 32 bits, and the smallest number of bits 5522 beyond 32 needed to encode any set bits. It also describes the encoding of 5523 the bitstring as using "unnamed" bits. 5525 An optional ticket extensions field was added to support the carrying of 5526 auxiliary data that allows the passing of auxiliary that is to accompany a 5527 ticket to the verifier. 5529 (I would like to drop the part about optionally appending it of the opaque 5530 part of the ciphertext. We are still waiting on some text regarding how to 5531 assure backward compatibility). 5533 (Still pending, Tom Yu's request to change the application codes on KDC 5534 message to indicate which minor rev of the protocol - I think this might 5535 break things, but am not sure). 5537 Definition of the PA-USE-SPECIFIED-KVNO preauthentication data field was 5538 added. 5540 The optional e-cksum field was added to the KRB-ERROR message and the e-data 5541 filed was generalized for use in other than the KDC_ERR_PREAUTH_REQUIRED 5542 error. The TypedData structure was defined. Type tags for TypedData are 5543 defined in the same sequence as the PA-DATA type space to avoid confusion 5544 with the use of the PA-DATA namespace previously used for the e-data field 5545 for the KDC_ERR_PREAUTH_REQUIRED error. 5547 Section 7: Words were added describing the convention that domain based 5548 realm names for newly created realms should be specified as upper case. This 5549 recommendation does not make lower case realm names illegal. Words were 5550 added highlighting that the slash separated components in the X500 style of 5551 realm names is consistent with existing RFC1510 based implementations, but 5552 that it conflicts with the general recommendation of X.500 name 5553 representation specified in RFC2253. 5555 There were suggestions on the list regarding extensions to or new name 5556 types. These require discussion at the IETF meeting. My own feeling at this 5557 point is that in the absence of a strong consensus for for adding new types 5558 at this time, I would rather not add new name types in the current draft, 5559 but leave things open for additions later. 5561 Section 8: Since RFC1510, the definition of the TCP transport for Kerberos 5562 messages was added. 5564 Section 9: Requirements for supporting DES3-CBC-SHA1-KD encryption and 5565 HMAC-SHA1-DES3-KD checksums were added. 5567 I would like to make support for Rijndael mandatory and for us to have a 5568 SINGLE standard for use of Rijndale in these revisions. 5570 ------------------------------------------------------------------------ 5572 Discussion 5574 Section 8: Regarding the suggestion of weakening the requirement for use of 5575 port 88 for cases where the port can be looked up elsewhere - I did not 5576 incorporate this suggestion because cross realm authentication requires the 5577 ability to contact the appropriate KDC, and unless ALL implementations of 5578 Kerberos include support for finding such alternate port numbers, use of 5579 such KDC's would be non-interoperable. 5581 ------------------------------------------------------------------------ 5582 [TM] Project Athena, Athena, and Kerberos are trademarks of the 5583 Massachusetts Institute of Technology (MIT). No commercial use of these 5584 trademarks may be made without prior written permission of MIT. 5586 [1.1] Note, however, that many applications use Kerberos' functions only 5587 upon the initiation of a stream-based network connection. Unless an 5588 application subsequently provides integrity protection for the data stream, 5589 the identity verification applies only to the initiation of the connection, 5590 and does not guarantee that subsequent messages on the connection originate 5591 from the same principal. 5593 [1.2] Secret and private are often used interchangeably in the literature. 5594 In our usage, it takes two (or more) to share a secret, thus a shared DES 5595 key is a secret key. Something is only private when no one but its owner 5596 knows it. Thus, in public key cryptosystems, one has a public and a private 5597 key. 5599 [1.3] Of course, with appropriate permission the client could arrange 5600 registration of a separately-named prin- cipal in a remote realm, and engage 5601 in normal exchanges with that realm's services. However, for even small 5602 numbers of clients this becomes cumbersome, and more automatic methods as 5603 described here are necessary. 5605 [2.1] Though it is permissible to request or issue tick- ets with no network 5606 addresses specified. 5608 [2.2] It is important that the KDC be sent the name as typed by the user, 5609 and not only the canonical form of the name. If the domain name system was 5610 used to find the canonical name on the client side, the mapping is 5611 vulnerable. [3.1] The password-changing request must not be honored unless 5612 the requester can provide the old password (the user's current secret key). 5613 Otherwise, it would be possible for someone to walk up to an unattended 5614 session and change another user's password. 5616 [3.2] To authenticate a user logging on to a local system, the credentials 5617 obtained in the AS exchange may first be used in a TGS exchange to obtain 5618 credentials for a local server. Those credentials must then be verified by a 5619 local server through successful completion of the Client/Server exchange. 5621 [3.3] "Random" means that, among other things, it should be impossible to 5622 guess the next session key based on knowledge of past session keys. This can 5623 only be achieved in a pseudo-random number generator if it is based on 5624 cryptographic principles. It is more desirable to use a truly random number 5625 generator, such as one based on measurements of random physical phenomena. 5627 [3.4] Tickets contain both an encrypted and unencrypted portion, so 5628 cleartext here refers to the entire unit, which can be copied from one 5629 message and replayed in another without any cryptographic skill. 5631 [3.5] Note that this can make applications based on unreliable transports 5632 difficult to code correctly. If the transport might deliver duplicated 5633 messages, either a new authenticator must be generated for each retry, or 5634 the application server must match requests and replies and replay the first 5635 reply in response to a detected duplicate. 5637 [3.6] This allows easy implementation of user-to-user authentication [8], 5638 which uses ticket-granting ticket session keys in lieu of secret server keys 5639 in situations where such secret keys could be easily compromised. 5641 [3.7]Note also that the rejection here is restricted to authenticators from 5642 the same principal to the same server. Other client principals communicating 5643 with the same server principal should not be have their authenticators 5644 rejected if the time and microsecond fields happen to match some other 5645 client's authenticator. 5647 [3.8] If this is not done, an attacker could subvert the authentication by 5648 recording the ticket and authenticator sent over the network to a server and 5649 replaying them following an event that caused the server to lose track of 5650 recently seen authenticators. 5652 [3.9] In the Kerberos version 4 protocol, the timestamp in the reply was the 5653 client's timestamp plus one. This is not necessary in version 5 because 5654 version 5 messages are formatted in such a way that it is not possible to 5655 create the reply by judicious message surgery (even in encrypted form) 5656 without knowledge of the appropriate encryption keys. 5658 [3.10] Note that for encrypting the KRB_AP_REP message, the sub-session key 5659 is not used, even if present in the Authenticator. 5661 [3.11] Implementations of the protocol may wish to provide routines to 5662 choose subkeys based on session keys and random numbers and to generate a 5663 negotiated key to be returned in the KRB_AP_REP message. 5665 [3.12]This can be accomplished in several ways. It might be known beforehand 5666 (since the realm is part of the principal identifier), it might be stored in 5667 a nameserver, or it might be obtained from a configuration file. If the 5668 realm to be used is obtained from a nameserver, there is a danger of being 5669 spoofed if the nameservice providing the realm name is not authenticated. 5670 This might result in the use of a realm which has been compromised, and 5671 would result in an attacker's ability to compromise the authentication of 5672 the application server to the client. 5674 [3.13] If the client selects a sub-session key, care must be taken to ensure 5675 the randomness of the selected sub-session key. One approach would be to 5676 generate a random number and XOR it with the session key from the 5677 ticket-granting ticket. 5679 [4.1] The implementation of the Kerberos server need not combine the 5680 database and the server on the same machine; it is feasible to store the 5681 principal database in, say, a network name service, as long as the entries 5682 stored therein are protected from disclosure to and modification by 5683 unauthorized parties. However, we recommend against such strategies, as they 5684 can make system management and threat analysis quite complex. 5686 [4.2] See the discussion of the padata field in section 5.4.2 for details on 5687 why this can be useful.