idnits 2.17.1 draft-ietf-cat-kerberos-revisions-08.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-08.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-cat-kerberos-revisions-08.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-cat-kerberos-revisions-08.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-08.txt.', but the file name used is 'draft-ietf-cat-kerberos-revisions-08' ** 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 90 longer pages, the longest (page 32) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2032 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 1868: '...ncodings that are marked OPTIONAL, but...' RFC 2119 keyword, line 2102: '... pausec[1] Microseconds OPTIONAL...' RFC 2119 keyword, line 2109: '... pausec[1] Microseconds OPTIONAL,...' RFC 2119 keyword, line 2110: '... pachecksum[2] Checksum OPTIONAL...' RFC 2119 keyword, line 2208: '... kvno[1] INTEGER OPTIONAL,...' (89 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 3297 has weird spacing: '...ion-key serve...' == Line 3303 has weird spacing: '...equired that ...' == Line 4438 has weird spacing: '...chanism rsa-m...' == Line 4569 has weird spacing: '...chanism rsa-m...' == Line 4595 has weird spacing: '...chanism rsa-m...' == (7 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The type of IPv6 addresses is twenty-four (24). [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 (March 2, 2001) is 8453 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 4930, but not defined -- Looks like a reference, but probably isn't: '18' on line 1449 -- Looks like a reference, but probably isn't: '19' on line 1461 -- Looks like a reference, but probably isn't: '20' on line 1537 == Missing Reference: 'RFC1510' is mentioned on line 1812, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Missing Reference: 'RFC1964' is mentioned on line 1812, but not defined == Missing Reference: 'UNIVERSAL 27' is mentioned on line 1926, but not defined -- Looks like a reference, but probably isn't: '0' on line 6740 -- Looks like a reference, but probably isn't: '1' on line 6724 -- Looks like a reference, but probably isn't: '2' on line 6674 == Missing Reference: 'APPLICATION 1' is mentioned on line 2281, but not defined -- Looks like a reference, but probably isn't: '3' on line 6675 == Missing Reference: 'APPLICATION 4' is mentioned on line 2287, but not defined -- Looks like a reference, but probably isn't: '4' on line 3719 == Missing Reference: 'APPLICATION 3' is mentioned on line 2297, but not defined -- Looks like a reference, but probably isn't: '5' on line 3720 -- Looks like a reference, but probably isn't: '6' on line 3721 -- Looks like a reference, but probably isn't: '7' on line 3722 -- Looks like a reference, but probably isn't: '8' on line 6990 -- Looks like a reference, but probably isn't: '9' on line 3724 -- Looks like a reference, but probably isn't: '10' on line 3725 -- Looks like a reference, but probably isn't: '24' on line 2559 == Missing Reference: 'APPLICATION 2' is mentioned on line 2672, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2746, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2747, but not defined -- Looks like a reference, but probably isn't: '11' on line 3703 -- Looks like a reference, but probably isn't: '25' on line 3069 == Missing Reference: 'APPLICATION 11' is mentioned on line 3123, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 3124, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 3152, but not defined == Missing Reference: 'APPLICATION 9' is mentioned on line 3153, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 3155, but not defined -- Looks like a reference, but probably isn't: '27' on line 3155 == Missing Reference: 'APPLICATION 26' is mentioned on line 3156, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 3266, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 3321, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 3328, but not defined -- Looks like a reference, but probably isn't: '29' on line 3328 == Missing Reference: 'APPLICATION 20' is mentioned on line 3385, but not defined == Missing Reference: 'APPLICATION 18' is mentioned on line 3400, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 3493, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 3500, but not defined -- Looks like a reference, but probably isn't: '31' on line 3500 == Missing Reference: 'APPLICATION 19' is mentioned on line 3509, but not defined == Missing Reference: 'APPLICATION 24' is mentioned on line 3516, but not defined -- Looks like a reference, but probably isn't: '32' on line 3532 == Missing Reference: 'APPLICATION 22' is mentioned on line 3557, but not defined == Missing Reference: 'APPLICATION 17' is mentioned on line 3564, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 3577, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 3651, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 3691, but not defined -- Looks like a reference, but probably isn't: '12' on line 3704 == Missing Reference: 'APPLICATION 23' is mentioned on line 3707, but not defined -- Looks like a reference, but probably isn't: '33' on line 3830 == Missing Reference: 'K' is mentioned on line 4080, but not defined == Missing Reference: 'Horowitz' is mentioned on line 4205, but not defined -- Looks like a reference, but probably isn't: '35' on line 4503 == Missing Reference: 'MD492' is mentioned on line 4586, but not defined == Missing Reference: 'ISO3309' is mentioned on line 4613, but not defined -- Looks like a reference, but probably isn't: '39' on line 4727 == Missing Reference: 'RFC 1779' is mentioned on line 4893, but not defined ** Obsolete undefined reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) == Missing Reference: 'Raeburn' is mentioned on line 4930, but not defined == Missing Reference: 'Westerlund' is mentioned on line 5035, but not defined == Missing Reference: 'RFC1883' is mentioned on line 4981, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Missing Reference: 'RFC1884' is mentioned on line 4982, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Missing Reference: 'Danielsson' is mentioned on line 5035, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 5236, 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 5265 == Unused Reference: 'DS90' is defined on line 5469, but no explicit reference was found in the text == Unused Reference: 'Horowitz96' is defined on line 5473, but no explicit reference was found in the text == Unused Reference: 'HorowitzB96' is defined on line 5476, but no explicit reference was found in the text == Unused Reference: 'IS3309' is defined on line 5479, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 5483, but no explicit reference was found in the text == Unused Reference: 'X509-88' is defined on line 5534, but no explicit reference was found in the text == Unused Reference: 'TM' is defined on line 6935, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dolev91' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS90' -- Possible downref: Normative reference to a draft: ref. 'Horowitz96' -- No information found for draft-horowitz-kerb-key-derivation - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HorowitzB96' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS3309' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. (However, the state information for draft-horowitz-kerb-key-derivation is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'KNT92' -- No information found for draft-ietf-ipsec-hmac- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Krawczyk96' -- Possible downref: Non-RFC (?) normative reference: ref. 'LGDSR87' ** Obsolete normative reference: RFC 1320 (ref. 'MD4-92') (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5-92') -- Possible downref: Non-RFC (?) normative reference: ref. 'MNSS87' -- Possible downref: Non-RFC (?) normative reference: ref. 'Neu93' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'NT94' ** Downref: Normative reference to an Not Issued RFC: RFC 26 (ref. 'Pat92') -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-88' -- Possible downref: Non-RFC (?) normative reference: ref. 'TM' Summary: 20 errors (**), 1 flaw (~~), 62 warnings (==), 53 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 John Kohl 3 Theodore Ts'o 4 Ken Raeburn 5 Tom Yu 6 March 2, 2001 7 Expires 2 September, 2001 9 The Kerberos Network Authentication Service (V5) 10 draft-ietf-cat-kerberos-revisions-08.txt. 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC 2026. Internet-Drafts are working documents 16 of the Internet Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months and 21 may be updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet-Drafts as reference material or to cite them 23 other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 34 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 36 The distribution of this memo is unlimited. It is filed as 37 draft-ietf-cat-kerberos-revisions-08.txt, and expires September 2, 2001. 38 Please send comments to: ietf-krb-wg@anl.gov 40 ABSTRACT 42 This document provides an overview and specification of Version 5 of the 43 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 44 and its intended use that require more detailed or clearer explanation than 45 was provided in RFC1510. This document is intended to provide a detailed 46 description of the protocol, suitable for implementation, together with 47 descriptions of the appropriate use of protocol messages and fields within 48 those messages. 50 This document is not intended to describe Kerberos to the end user, system 51 administrator, or application developer. Higher level papers describing 52 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 53 are available elsewhere. 55 OVERVIEW 57 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 58 network authentication system is based. It also specifies Version 5 of the 59 Kerberos protocol. 61 The motivations, goals, assumptions, and rationale behind most design 62 decisions are treated cursorily; they are more fully described in a paper 63 available in IEEE communications [NT94] and earlier in the Kerberos portion 64 of the Athena Technical Plan [MNSS87]. The protocols have been a proposed 65 standard and are being considered for advancement for draft standard through 66 the IETF standard process. Comments are encouraged on the presentation, but 67 only minor refinements to the protocol as implemented or extensions that fit 68 within current protocol framework will be considered at this time. 70 Requests for addition to an electronic mailing list for discussion of 71 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. 72 This mailing list is gatewayed onto the Usenet as the group 73 comp.protocols.kerberos. Requests for further information, including 74 documents and code availability, may be sent to info-kerberos@MIT.EDU. 76 BACKGROUND 78 The Kerberos model is based in part on Needham and Schroeder's trusted 79 third-party authentication protocol [NS78] and on modifications suggested by 80 Denning and Sacco [DS81]. The original design and implementation of Kerberos 81 Versions 1 through 4 was the work of two former Project Athena staff 82 members, Steve Miller of Digital Equipment Corporation and Clifford Neuman 83 (now at the Information Sciences Institute of the University of Southern 84 California), along with Jerome Saltzer, Technical Director of Project 85 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members 86 of Project Athena have also contributed to the work on Kerberos. 88 Version 5 of the Kerberos protocol (described in this document) has evolved 89 from Version 4 based on new requirements and desires for features not 90 available in Version 4. The design of Version 5 of the Kerberos protocol was 91 led by Clifford Neuman and John Kohl with much input from the community. The 92 development of the MIT reference implementation was led at MIT by John Kohl 93 and Theodore T'so, with help and contributed code from many others. Since 94 RFC1510 was issued, extensions and revisions to the protocol have been 95 proposed by many individuals. Some of these proposals are reflected in this 96 document. Where such changes involved significant effort, the document cites 97 the contribution of the proposer. 99 Reference implementations of both version 4 and version 5 of Kerberos are 100 publicly available and commercial implementations have been developed and 101 are widely used. Details on the differences between Kerberos Versions 4 and 102 5 can be found in [KNT92]. 104 1. Introduction 106 Kerberos provides a means of verifying the identities of principals, (e.g. a 107 workstation user or a network server) on an open (unprotected) network. This 108 is accomplished without relying on assertions by the host operating system, 109 without basing trust on host addresses, without requiring physical security 110 of all the hosts on the network, and under the assumption that packets 111 traveling along the network can be read, modified, and inserted at 112 will[1.1]. Kerberos performs authentication under these conditions as a 113 trusted third-party authentication service by using conventional (shared 114 secret key [1.2]) cryptography. Kerberos extensions described in [PKINIT 115 reference as RFC] provide for the use of public key cryptography during 116 certain phases of the authentication protocol. These extensions allow 117 authentication of users registered with public key certification 118 authorities, and provide certain benefits of public key cryptography in 119 situations where they are needed. 121 The basic Kerberos authentication process proceeds as follows: A client 122 sends a request to the authentication server (AS) requesting 'credentials' 123 for a given server. The AS responds with these credentials, encrypted in the 124 client's key. The credentials consist of 1) a 'ticket' for the server and 2) 125 a temporary encryption key (often called a "session key"). The client 126 transmits the ticket (which contains the client's identity and a copy of the 127 session key, all encrypted in the server's key) to the server. The session 128 key (now shared by the client and server) is used to authenticate the 129 client, and may optionally be used to authenticate the server. It may also 130 be used to encrypt further communication between the two parties or to 131 exchange a separate sub-session key to be used to encrypt further 132 communication. 134 Implementation of the basic protocol consists of one or more authentication 135 servers running on physically secure hosts. The authentication servers 136 maintain a database of principals (i.e., users and servers) and their secret 137 keys. Code libraries provide encryption and implement the Kerberos protocol. 138 In order to add authentication to its transactions, a typical network 139 application adds one or two calls to the Kerberos library directly or 140 through the Generic Security Services Application Programming Interface, 141 GSSAPI, described in separate document [ref to GSSAPI RFC]. These calls 142 result in the transmission of the necessary messages to achieve 143 authentication. 145 The Kerberos protocol consists of several sub-protocols (or exchanges). 146 There are two basic methods by which a client can ask a Kerberos server for 147 credentials. In the first approach, the client sends a cleartext request for 148 a ticket for the desired server to the AS. The reply is sent encrypted in 149 the client's secret key. Usually this request is for a ticket-granting 150 ticket (TGT) which can later be used with the ticket-granting server (TGS). 151 In the second method, the client sends a request to the TGS. The client uses 152 the TGT to authenticate itself to the TGS in the same manner as if it were 153 contacting any other application server that requires Kerberos 154 authentication. The reply is encrypted in the session key from the TGT. 155 Though the protocol specification describes the AS and the TGS as separate 156 servers, they are implemented in practice as different protocol entry points 157 within a single Kerberos server. 159 Once obtained, credentials may be used to verify the identity of the 160 principals in a transaction, to ensure the integrity of messages exchanged 161 between them, or to preserve privacy of the messages. The application is 162 free to choose whatever protection may be necessary. 164 To verify the identities of the principals in a transaction, the client 165 transmits the ticket to the application server. Since the ticket is sent "in 166 the clear" (parts of it are encrypted, but this encryption doesn't thwart 167 replay) and might be intercepted and reused by an attacker, additional 168 information is sent to prove that the message originated with the principal 169 to whom the ticket was issued. This information (called the authenticator) 170 is encrypted in the session key, and includes a timestamp. The timestamp 171 proves that the message was recently generated and is not a replay. 172 Encrypting the authenticator in the session key proves that it was generated 173 by a party possessing the session key. Since no one except the requesting 174 principal and the server know the session key (it is never sent over the 175 network in the clear) this guarantees the identity of the client. 177 The integrity of the messages exchanged between principals can also be 178 guaranteed using the session key (passed in the ticket and contained in the 179 credentials). This approach provides detection of both replay attacks and 180 message stream modification attacks. It is accomplished by generating and 181 transmitting a collision-proof checksum (elsewhere called a hash or digest 182 function) of the client's message, keyed with the session key. Privacy and 183 integrity of the messages exchanged between principals can be secured by 184 encrypting the data to be passed using the session key contained in the 185 ticket or the sub-session key found in the authenticator. 187 The authentication exchanges mentioned above require read-only access to the 188 Kerberos database. Sometimes, however, the entries in the database must be 189 modified, such as when adding new principals or changing a principal's key. 190 This is done using a protocol between a client and a third Kerberos server, 191 the Kerberos Administration Server (KADM). There is also a protocol for 192 maintaining multiple copies of the Kerberos database. Neither of these 193 protocols are described in this document. 195 1.1. Cross-realm operation 197 The Kerberos protocol is designed to operate across organizational 198 boundaries. A client in one organization can be authenticated to a server in 199 another. Each organization wishing to run a Kerberos server establishes its 200 own 'realm'. The name of the realm in which a client is registered is part 201 of the client's name, and can be used by the end-service to decide whether 202 to honor a request. 204 By establishing 'inter-realm' keys, the administrators of two realms can 205 allow a client authenticated in the local realm to prove its identity to 206 servers in other realms[1.3]. The exchange of inter-realm keys (a separate 207 key may be used for each direction) registers the ticket-granting service of 208 each realm as a principal in the other realm. A client is then able to 209 obtain a ticket-granting ticket for the remote realm's ticket-granting 210 service from its local realm. When that ticket-granting ticket is used, the 211 remote ticket-granting service uses the inter-realm key (which usually 212 differs from its own normal TGS key) to decrypt the ticket-granting ticket, 213 and is thus certain that it was issued by the client's own TGS. Tickets 214 issued by the remote ticket-granting service will indicate to the 215 end-service that the client was authenticated from another realm. 217 A realm is said to communicate with another realm if the two realms share an 218 inter-realm key, or if the local realm shares an inter-realm key with an 219 intermediate realm that communicates with the remote realm. An 220 authentication path is the sequence of intermediate realms that are 221 transited in communicating from one realm to another. 223 Realms are typically organized hierarchically. Each realm shares a key with 224 its parent and a different key with each child. If an inter-realm key is not 225 directly shared by two realms, the hierarchical organization allows an 226 authentication path to be easily constructed. If a hierarchical organization 227 is not used, it may be necessary to consult a database in order to construct 228 an authentication path between realms. 230 Although realms are typically hierarchical, intermediate realms may be 231 bypassed to achieve cross-realm authentication through alternate 232 authentication paths (these might be established to make communication 233 between two realms more efficient). It is important for the end-service to 234 know which realms were transited when deciding how much faith to place in 235 the authentication process. To facilitate this decision, a field in each 236 ticket contains the names of the realms that were involved in authenticating 237 the client. 239 The application server is ultimately responsible for accepting or rejecting 240 authentication and should check the transited field. The application server 241 may choose to rely on the KDC for the application server's realm to check 242 the transited field. The application server's KDC will set the 243 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 244 realms may also check the transited field as they issue 245 ticket-granting-tickets for other realms, but they are encouraged not to do 246 so. A client may request that the KDC's not check the transited field by 247 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 248 required to honor this flag. 250 1.2. Choosing a principal with which to communicate 252 The Kerberos protocol provides the means for verifying (subject to the 253 assumptions in 1.4) that the entity with which one communicates is the same 254 entity that was registered with the KDC using the claimed identity 255 (principal name). It is still necessary to determine whether that identity 256 corresponds to the entity with which one intends to communicate. 258 When appropriate data has been exchanged in advance, this determination may 259 be performed syntactically by the application based on the application 260 protocol specification, information provided by the user, and configuration 261 files. For example, the server principal name (including realm) for a telnet 262 server might be derived from the user specified host name (from the telnet 263 command line), the "host/" prefix specified in the application protocol 264 specification, and a mapping to a Kerberos realm derived syntactically from 265 the domain part of the specified hostname and information from the local 266 Kerberos realms database. 268 One can also rely on trusted third parties to make this determination, but 269 only when the data obtained from the third party is suitably integrity 270 protected wile resident on the third party server and when transmitted. 271 Thus, for example, one should not rely on an unprotected domain name system 272 record to map a host alias to the primary name of a server, accepting the 273 primary name as the party one intends to contact, since an attacker can 274 modify the mapping and impersonate the party with which one intended to 275 communicate. 277 (this paragraph for decision to include, include only first sentence, or 278 omit) If a Kerberos server supports name canonicalization, it may be relied 279 upon as a third party to aid in this determination. When utilizing the name 280 canonicalization function provided by the Kerberos server, a client, having 281 already located the instance of a service it wishes to contact, makes a 282 request to the KDC using the server's name information as specified by the 283 user. The Kerberos server will attempt to locate a service principal in its 284 database that corresponds to the requested name and return a ticket for the 285 appropriate server principal to the client. If the KDC determines that the 286 correct server principal is registered in another realm, the KDC will 287 provide a referral to the Kerberos realm that is known to contain the 288 requested service principal. The name canonicalization function supports 289 identity mapping only, and it may not be used as a general name service to 290 locate service instances. There is no guarantee that the returned server 291 principal name (identity) will embed the name of the host on which the 292 server resides. 294 1.3. Authorization 296 As an authentication service, Kerberos provides a means of verifying the 297 identity of principals on a network. Authentication is usually useful 298 primarily as a first step in the process of authorization, determining 299 whether a client may use a service, which objects the client is allowed to 300 access, and the type of access allowed for each. Kerberos does not, by 301 itself, provide authorization. Possession of a client ticket for a service 302 provides only for authentication of the client to that service, and in the 303 absence of a separate authorization procedure, it should not be considered 304 by an application as authorizing the use of that service. 306 Such separate authorization methods may be implemented as application 307 specific access control functions and may utilize files on the application 308 server, or on separately issued authorization credentials such as those 309 based on proxies [Neu93], or on other authorization services. Separately 310 authenticated authorization credentials may be embedded in a tickets 311 authorization data when encapsulated by the kdc-issued authorization data 312 element. 314 Applications should not accept the mere issuance of a service ticket by the 315 Kerberos server (even by a modified Kerberos server) as granting authority 316 to use the service, since such applications may become vulnerable to the 317 bypass of this authorization check in an environment if they interoperate 318 with other KDCs or where other options for application authentication (e.g. 319 the PKTAPP proposal) are provided. 321 1.4. Environmental assumptions 323 Kerberos imposes a few assumptions on the environment in which it can 324 properly function: 326 * 'Denial of service' attacks are not solved with Kerberos. There are 327 places in the protocols where an intruder can prevent an application 328 from participating in the proper authentication steps. Detection and 329 solution of such attacks (some of which can appear to be not-uncommon 330 'normal' failure modes for the system) is usually best left to the 331 human administrators and users. 332 * Principals must keep their secret keys secret. If an intruder somehow 333 steals a principal's key, it will be able to masquerade as that 334 principal or impersonate any server to the legitimate principal. 336 * 'Password guessing' attacks are not solved by Kerberos. If a user 337 chooses a poor password, it is possible for an attacker to successfully 338 mount an offline dictionary attack by repeatedly attempting to decrypt, 339 with successive entries from a dictionary, messages obtained which are 340 encrypted under a key derived from the user's password. 341 * Each host on the network must have a clock which is 'loosely 342 synchronized' to the time of the other hosts; this synchronization is 343 used to reduce the bookkeeping needs of application servers when they 344 do replay detection. The degree of "looseness" can be configured on a 345 per-server basis, but is typically on the order of 5 minutes. If the 346 clocks are synchronized over the network, the clock synchronization 347 protocol must itself be secured from network attackers. 348 * Principal identifiers are not recycled on a short-term basis. A typical 349 mode of access control will use access control lists (ACLs) to grant 350 permissions to particular principals. If a stale ACL entry remains for 351 a deleted principal and the principal identifier is reused, the new 352 principal will inherit rights specified in the stale ACL entry. By not 353 re-using principal identifiers, the danger of inadvertent access is 354 removed. 356 1.5. Glossary of terms 358 Below is a list of terms used throughout this document. 360 Authentication 361 Verifying the claimed identity of a principal. 362 Authentication header 363 A record containing a Ticket and an Authenticator to be presented to a 364 server as part of the authentication process. 365 Authentication path 366 A sequence of intermediate realms transited in the authentication 367 process when communicating from one realm to another. 368 Authenticator 369 A record containing information that can be shown to have been recently 370 generated using the session key known only by the client and server. 371 Authorization 372 The process of determining whether a client may use a service, which 373 objects the client is allowed to access, and the type of access allowed 374 for each. 375 Capability 376 A token that grants the bearer permission to access an object or 377 service. In Kerberos, this might be a ticket whose use is restricted by 378 the contents of the authorization data field, but which lists no 379 network addresses, together with the session key necessary to use the 380 ticket. 381 Ciphertext 382 The output of an encryption function. Encryption transforms plaintext 383 into ciphertext. 384 Client 385 A process that makes use of a network service on behalf of a user. Note 386 that in some cases a Server may itself be a client of some other server 387 (e.g. a print server may be a client of a file server). 388 Credentials 389 A ticket plus the secret session key necessary to successfully use that 390 ticket in an authentication exchange. 392 KDC 393 Key Distribution Center, a network service that supplies tickets and 394 temporary session keys; or an instance of that service or the host on 395 which it runs. The KDC services both initial ticket and ticket-granting 396 ticket requests. The initial ticket portion is sometimes referred to as 397 the Authentication Server (or service). The ticket-granting ticket 398 portion is sometimes referred to as the ticket-granting server (or 399 service). 400 Kerberos 401 Aside from the 3-headed dog guarding Hades, the name given to Project 402 Athena's authentication service, the protocol used by that service, or 403 the code used to implement the authentication service. 404 Plaintext 405 The input to an encryption function or the output of a decryption 406 function. Decryption transforms ciphertext into plaintext. 407 Principal 408 A named client or server entity that participates in a network 409 communication, with one name that is considered canonical. 410 Principal identifier 411 The canonical name used to uniquely identify each different principal. 412 Seal 413 To encipher a record containing several fields in such a way that the 414 fields cannot be individually replaced without either knowledge of the 415 encryption key or leaving evidence of tampering. 416 Secret key 417 An encryption key shared by a principal and the KDC, distributed 418 outside the bounds of the system, with a long lifetime. In the case of 419 a human user's principal, the secret key may be derived from a 420 password. 421 Server 422 A particular Principal which provides a resource to network clients. 423 The server is sometimes referred to as the Application Server. 424 Service 425 A resource provided to network clients; often provided by more than one 426 server (for example, remote file service). 427 Session key 428 A temporary encryption key used between two principals, with a lifetime 429 limited to the duration of a single login "session". 430 Sub-session key 431 A temporary encryption key used between two principals, selected and 432 exchanged by the principals using the session key, and with a lifetime 433 limited to the duration of a single association. 434 Ticket 435 A record that helps a client authenticate itself to a server; it 436 contains the client's identity, a session key, a timestamp, and other 437 information, all sealed using the server's secret key. It only serves 438 to authenticate a client when presented along with a fresh 439 Authenticator. 441 2. Ticket flag uses and requests 443 Each Kerberos ticket contains a set of flags which are used to indicate 444 attributes of that ticket. Most flags may be requested by a client when the 445 ticket is obtained; some are automatically turned on and off by a Kerberos 446 server as required. The following sections explain what the various flags 447 mean, and gives examples of reasons to use such a flag. With the excepttion 448 of the ANONYMOUS and INVALID flags clients may ignore ticket flags that are 449 not recognized. 451 2.1. Initial, pre-authenticated, and hardware authenticated tickets 453 The INITIAL flag indicates that a ticket was issued using the AS protocol 454 and not issued based on a ticket-granting ticket. Application servers that 455 want to require the demonstrated knowledge of a client's secret key (e.g. a 456 password-changing program) can insist that this flag be set in any tickets 457 they accept, and thus be assured that the client's key was recently 458 presented to the application client. 460 The PRE-AUTHENT and HW-AUTHENT flags provide additional information about 461 the initial authentication, regardless of whether the current ticket was 462 issued directly (in which case INITIAL will also be set) or issued on the 463 basis of a ticket-granting ticket (in which case the INITIAL flag is clear, 464 but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 465 ticket-granting ticket). 467 2.2. Invalid tickets 469 The INVALID flag indicates that a ticket is invalid. Application servers 470 must reject tickets which have this flag set. A postdated ticket will 471 usually be issued in this form. Invalid tickets must be validated by the KDC 472 before use, by presenting them to the KDC in a TGS request with the VALIDATE 473 option specified. The KDC will only validate tickets after their starttime 474 has passed. The validation is required so that postdated tickets which have 475 been stolen before their starttime can be rendered permanently invalid 476 (through a hot-list mechanism) (see section 3.3.3.1). 478 2.3. Renewable tickets 480 Applications may desire to hold tickets which can be valid for long periods 481 of time. However, this can expose their credentials to potential theft for 482 equally long periods, and those stolen credentials would be valid until the 483 expiration time of the ticket(s). Simply using short-lived tickets and 484 obtaining new ones periodically would require the client to have long-term 485 access to its secret key, an even greater risk. Renewable tickets can be 486 used to mitigate the consequences of theft. Renewable tickets have two 487 "expiration times": the first is when the current instance of the ticket 488 expires, and the second is the latest permissible value for an individual 489 expiration time. An application client must periodically (i.e. before it 490 expires) present a renewable ticket to the KDC, with the RENEW option set in 491 the KDC request. The KDC will issue a new ticket with a new session key and 492 a later expiration time. All other fields of the ticket are left unmodified 493 by the renewal process. When the latest permissible expiration time arrives, 494 the ticket expires permanently. At each renewal, the KDC may consult a 495 hot-list to determine if the ticket had been reported stolen since its last 496 renewal; it will refuse to renew such stolen tickets, and thus the usable 497 lifetime of stolen tickets is reduced. 499 The RENEWABLE flag in a ticket is normally only interpreted by the 500 ticket-granting service (discussed below in section 3.3). It can usually be 501 ignored by application servers. However, some particularly careful 502 application servers may wish to disallow renewable tickets. 504 If a renewable ticket is not renewed by its expiration time, the KDC will 505 not renew the ticket. The RENEWABLE flag is reset by default, but a client 506 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 507 message. If it is set, then the renew-till field in the ticket contains the 508 time after which the ticket may not be renewed. 510 2.4. Postdated tickets 512 Applications may occasionally need to obtain tickets for use much later, 513 e.g. a batch submission system would need tickets to be valid at the time 514 the batch job is serviced. However, it is dangerous to hold valid tickets in 515 a batch queue, since they will be on-line longer and more prone to theft. 516 Postdated tickets provide a way to obtain these tickets from the KDC at job 517 submission time, but to leave them "dormant" until they are activated and 518 validated by a further request of the KDC. If a ticket theft were reported 519 in the interim, the KDC would refuse to validate the ticket, and the thief 520 would be foiled. 522 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 523 ticket-granting service. It can be ignored by application servers. This flag 524 must be set in a ticket-granting ticket in order to issue a postdated ticket 525 based on the presented ticket. It is reset by default; it may be requested 526 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 527 This flag does not allow a client to obtain a postdated ticket-granting 528 ticket; postdated ticket-granting tickets can only by obtained by requesting 529 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 530 postdated ticket will be the remaining life of the ticket-granting ticket at 531 the time of the request, unless the RENEWABLE option is also set, in which 532 case it can be the full life (endtime-starttime) of the ticket-granting 533 ticket. The KDC may limit how far in the future a ticket may be postdated. 535 The POSTDATED flag indicates that a ticket has been postdated. The 536 application server can check the authtime field in the ticket to see when 537 the original authentication occurred. Some services may choose to reject 538 postdated tickets, or they may only accept them within a certain period 539 after the original authentication. When the KDC issues a POSTDATED ticket, 540 it will also be marked as INVALID, so that the application client must 541 present the ticket to the KDC to be validated before use. 543 2.5. Proxiable and proxy tickets 545 At times it may be necessary for a principal to allow a service to perform 546 an operation on its behalf. The service must be able to take on the identity 547 of the client, but only for a particular purpose. A principal can allow a 548 service to take on the principal's identity for a particular purpose by 549 granting it a proxy. 551 The process of granting a proxy using the proxy and proxiable flags is used 552 to provide credentials for use with specific services. Though conceptually 553 also a proxy, user's wishing to delegate their identity for ANY purpose must 554 use the ticket forwarding mechanism described in the next section to forward 555 a ticket granting ticket. 557 The PROXIABLE flag in a ticket is normally only interpreted by the 558 ticket-granting service. It can be ignored by application servers. When set, 559 this flag tells the ticket-granting server that it is OK to issue a new 560 ticket (but not a ticket-granting ticket) with a different network address 561 based on this ticket. This flag is set if requested by the client on initial 562 authentication. By default, the client will request that it be set when 563 requesting a ticket granting ticket, and reset when requesting any other 564 ticket. 566 This flag allows a client to pass a proxy to a server to perform a remote 567 request on its behalf, e.g. a print service client can give the print server 568 a proxy to access the client's files on a particular file server in order to 569 satisfy a print request. 571 In order to complicate the use of stolen credentials, Kerberos tickets are 572 usually valid from only those network addresses specifically included in the 573 ticket[2.1]. When granting a proxy, the client must specify the new network 574 address from which the proxy is to be used, or indicate that the proxy is to 575 be issued for use from any address. 577 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 578 Application servers may check this flag and at their option they may require 579 additional authentication from the agent presenting the proxy in order to 580 provide an audit trail. 582 2.6. Forwardable tickets 584 Authentication forwarding is an instance of a proxy where the service 585 granted is complete use of the client's identity. An example where it might 586 be used is when a user logs in to a remote system and wants authentication 587 to work from that system as if the login were local. 589 The FORWARDABLE flag in a ticket is normally only interpreted by the 590 ticket-granting service. It can be ignored by application servers. The 591 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 592 flag, except ticket-granting tickets may also be issued with different 593 network addresses. This flag is reset by default, but users may request that 594 it be set by setting the FORWARDABLE option in the AS request when they 595 request their initial ticket-granting ticket. 597 This flag allows for authentication forwarding without requiring the user to 598 enter a password again. If the flag is not set, then authentication 599 forwarding is not permitted, but the same result can still be achieved if 600 the user engages in the AS exchange specifying the requested network 601 addresses and supplies a password. 603 The FORWARDED flag is set by the TGS when a client presents a ticket with 604 the FORWARDABLE flag set and requests a forwarded ticket by specifying the 605 FORWARDED KDC option and supplying a set of addresses for the new ticket. It 606 is also set in all tickets issued based on tickets with the FORWARDED flag 607 set. Application servers may choose to process FORWARDED tickets differently 608 than non-FORWARDED tickets. 610 2.7 Transited Policy Checking 612 While the application server is ultimately responsible for accepting or 613 rejecting authentication and should check the transited field, a KDC may 614 apply a realm specific policy for validating the transited field and 615 accepting credentials for cross-realm authentication. When the KDC applies 616 such checks and accepts such cross-realm authentication it will set the 617 TRANSITED-POLICY-CHECKED flag in the service tickets it issues based on the 618 cross-realm TGT. A client may request that the KDC's not check the transited 619 field by setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but 620 not required to honor this flag. 622 2.8 Anonymous Tickets 624 When policy allows, a KDC may issue anonymous tickets for the purpose of 625 enabling encrypted communication between a client and server without 626 identifying the client to the server. Such anonymous tickets are issued with 627 a generic principal name configured on the KDC (e.g. "anonymous@") and will 628 have the ANONYMOUS flag set. A server accepting such a ticket may assume 629 that subsequent requests using the same ticket and session key originate 630 from the same user. Requests with the same username but different tickets 631 are likely to originate from different users. Users request anonymous ticket 632 by setting the REQUEST-ANONYMOUS option in an AS or TGS request. 634 2.9. Other KDC options 636 There are three additional options which may be set in a client's request of 637 the KDC. 639 2.9.1 Name canonicalization [JBrezak] 641 (To decide whether to leave in, already changed for server only 642 cannicalization, can change back to San Diego version be open to client name 643 canonicalization was well without specifically mentioning client side (by 644 deleting the work server in a few places) 646 The NAME-CANONICALIZATION option allows the KDC to replace the name of the 647 server requested by the client with the canonical form of the server's name, 648 if known, or to refer the client to a KDC for the realm with which the 649 requested server principal is registered. 651 Where name cannonicalization is supported a client who can identify a server 652 principal but does not know the full canonical form of the name can request 653 that the Kerberos server attempt to lookup the name in its database and use 654 the canonical name of the requested server principal or return a referral to 655 a realm that has the requested principal in its namespace. Use of name 656 canonicalization supports the case where a principal has multiple common 657 names (names typed by a user[2.2]), all of which are known to the KDC, but 658 only one Kerberos identity (the canonical name is the Kerberos principal 659 name). Name canonicalization is intended solely to provide a secure mapping 660 from the name known by a user to its principal identifier. It is not 661 intended for use as a general purpose nameserver or to identify instances of 662 a service. 664 The CANONICALIZE flag in a ticket request is used to indicate to the 665 Kerberos server that the client will accept an alternative name to the 666 principal in the request or a referral to another realm. When name 667 cannonicalization is supported in a realm, all instances of the AS and TGS 668 for the realm must be able to interpret requests with this flag. In realms 669 where name cannonicalization is not supported, this flag may be ignored. By 670 using this flag, the client can avoid extensive configuration needed to map 671 specific host names to a particular realm. 673 2.9.2 Renewable-OK 675 The RENEWABLE-OK option indicates that the client will accept a renewable 676 ticket if a ticket with the requested life cannot otherwise be provided. If 677 a ticket with the requested life cannot be provided, then the KDC may issue 678 a renewable ticket with a renew-till equal to the the requested endtime. The 679 value of the renew-till field may still be adjusted by site-determined 680 limits or limits imposed by the individual principal or server. 682 2.9.3 ENC-TKT-IN-SKEY 684 The ENC-TKT-IN-SKEY option supports user-to-user authentication. It allows 685 the KDC to issue a service ticket encrypted using the session key from a 686 ticket granting ticket issued to another user. This is needed to support 687 peer-to-peer authentication since the long term key of the user does not 688 remain on the workstation after initial login. The ENC-TKT-IN-SKEY option is 689 honored only by the ticket-granting service. It indicates that the ticket to 690 be issued for the end server is to be encrypted in the session key from the 691 additional second ticket-granting ticket provided with the request. See 692 section 3.3.3 for specific details. 694 3. Message Exchanges 696 The following sections describe the interactions between network clients and 697 servers and the messages involved in those exchanges. 699 3.1. The Authentication Service Exchange 701 Summary 702 Message direction Message type Section 703 1. Client to Kerberos KRB_AS_REQ 5.4.1 704 2. Kerberos to client KRB_AS_REP or 5.4.2 705 KRB_ERROR 5.9.1 707 The Authentication Service (AS) Exchange between the client and the Kerberos 708 Authentication Server is initiated by a client when it wishes to obtain 709 authentication credentials for a given server but currently holds no 710 credentials. In its basic form, the client's secret key is used for 711 encryption and decryption. This exchange is typically used at the initiation 712 of a login session to obtain credentials for a Ticket-Granting Server which 713 will subsequently be used to obtain credentials for other servers (see 714 section 3.3) without requiring further use of the client's secret key. This 715 exchange is also used to request credentials for services which must not be 716 mediated through the Ticket-Granting Service, but rather require a 717 principal's secret key, such as the password-changing service[3.1]. This 718 exchange does not by itself provide any assurance of the the identity of the 719 user[3.2]. 721 The exchange consists of two messages: KRB_AS_REQ from the client to 722 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 723 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 725 In the request, the client sends (in cleartext) its own identity and the 726 identity of the server for which it is requesting credentials. The response, 727 KRB_AS_REP, contains a ticket for the client to present to the server, and a 728 session key that will be shared by the client and the server. The session 729 key and additional information are encrypted in the client's secret key. The 730 KRB_AS_REP message contains information which can be used to detect replays, 731 and to associate it with the message to which it replies. 733 Without pre-authentication, the authentication server does not know whether 734 the client is actually the principal named in the request. It simply sends a 735 reply without knowing or caring whether they are the same. This is 736 acceptable because nobody but the principal whose identity was given in the 737 request will be able to use the reply. Its critical information is encrypted 738 in that principal's key. The initial request supports an optional field that 739 can be used to pass additional information that might be needed for the 740 initial exchange. This field may be used for pre-authentication as described 741 in section 3.1.1. 743 Various errors can occur; these are indicated by an error response 744 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not 745 encrypted. The KRB_ERROR message contains information which can be used to 746 associate it with the message to which it replies. If suitable 747 preauthentication has occurred, an optional checksum may be included in the 748 KRB_ERROR message to prevent fabrication or modification of the KRB_ERROR 749 message. When a checksum is not present, the lack of integrity protection 750 precludes the ability to detect replays, fabrications, or modifications of 751 the message, and the client must not depend on information in the KRB_ERROR 752 message for security critical operations. 754 3.1.1. Generation of KRB_AS_REQ message 756 The client may specify a number of options in the initial request. Among 757 these options are whether pre-authentication is to be performed; whether the 758 requested ticket is to be renewable, proxiable, or forwardable; whether it 759 should be postdated or allow postdating of derivative tickets; whether the 760 client requests name-canonicalization or an anonymous ticket; and whether a 761 renewable ticket will be accepted in lieu of a non-renewable ticket if the 762 requested ticket expiration date cannot be satisfied by a non-renewable 763 ticket (due to configuration constraints; see section 4). See section A.1 764 for pseudocode. 766 The client prepares the KRB_AS_REQ message and sends it to the KDC. 768 3.1.2. Receipt of KRB_AS_REQ message 770 If all goes well, processing the KRB_AS_REQ message will result in the 771 creation of a ticket for the client to present to the server. The format for 772 the ticket is described in section 5.3.1. The contents of the ticket are 773 determined as follows. 775 3.1.3. Generation of KRB_AS_REP message 777 The authentication server looks up the client and server principals named in 778 the KRB_AS_REQ in its database, extracting their respective keys. If the 779 requested client principal named in the request is not known because it 780 doesn't exist in the KDC's principal database and if an acceptable canonical 781 name of the client is not known, then an error message with a 782 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 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. 1125 This generation might involve the use of a random number as a pre-key, 1126 initially generated by either party, which could then be encrypted using the 1127 session key from the ticket, and the result exchanged and used for 1128 subsequent encryption. By encrypting the pre-key with the session key from 1129 the ticket, randomness from the KDC generated key is assured of being 1130 present in the negotiated key. Application developers must be careful 1131 however, to use a means of introducing this entropy that does not allow an 1132 attacker to learn the session key from the ticket if it learns the key 1133 generated and used for subsequent communication. The reader should note that 1134 this is only an example, and that an analysis of the particular cryptosystem 1135 to be used, must be made before deciding how to generate values for the 1136 subkey fields, and the key to be used for subsequent communication. 1138 With both the one-way and mutual authentication exchanges, the peers should 1139 take care not to send sensitive information to each other without proper 1140 assurances. In particular, applications that require privacy or integrity 1141 should use the KRB_AP_REP response from the server to client to assure both 1142 client and server of their peer's identity. If an application protocol 1143 requires privacy of its messages, it can use the KRB_PRIV message (section 1144 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 1146 3.3. The Ticket-Granting Service (TGS) Exchange 1148 Summary 1149 Message direction Message type Section 1150 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1151 2. Kerberos to client KRB_TGS_REP or 5.4.2 1152 KRB_ERROR 5.9.1 1154 The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1155 initiated by a client when it wishes to obtain authentication credentials 1156 for a given server (which might be registered in a remote realm), when it 1157 wishes to renew or validate an existing ticket, or when it wishes to obtain 1158 a proxy ticket. In the first case, the client must already have acquired a 1159 ticket for the Ticket-Granting Service using the AS exchange (the 1160 ticket-granting ticket is usually obtained when a client initially 1161 authenticates to the system, such as when a user logs in). The message 1162 format for the TGS exchange is almost identical to that for the AS exchange. 1163 The primary difference is that encryption and decryption in the TGS exchange 1164 does not take place under the client's key. Instead, the session key from 1165 the ticket-granting ticket or renewable ticket, or sub-session key from an 1166 Authenticator is used. As is the case for all application servers, expired 1167 tickets are not accepted by the TGS, so once a renewable or ticket-granting 1168 ticket expires, the client must use a separate exchange to obtain valid 1169 tickets. 1171 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1172 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1173 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1174 client plus a request for credentials. The authentication information 1175 consists of the authentication header (KRB_AP_REQ) which includes the 1176 client's previously obtained ticket-granting, renewable, or invalid ticket. 1177 In the ticket-granting ticket and proxy cases, the request may include one 1178 or more of: a list of network addresses, a collection of typed authorization 1179 data to be sealed in the ticket for authorization use by the application 1180 server, or additional tickets (the use of which are described later). The 1181 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1182 session key from the ticket-granting ticket or renewable ticket, or if 1183 present, in the sub-session key from the Authenticator (part of the 1184 authentication header). The KRB_ERROR message contains an error code and 1185 text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1186 KRB_TGS_REP message contains information which can be used to detect 1187 replays, and to associate it with the message to which it replies. The 1188 KRB_ERROR message also contains information which can be used to associate 1189 it with the message to which it replies, but except when an optional 1190 checksum is included in the KRB_ERROR message, it is not possible to detect 1191 replays or fabrications of such messages. 1193 3.3.1. Generation of KRB_TGS_REQ message 1195 Before sending a request to the ticket-granting service, the client must 1196 determine in which realm the application server is believed to be 1197 registered[3.12]. If the client knows the service principal name and realm 1198 and it does not already possess a ticket-granting ticket for the appropriate 1199 realm, then one must be obtained. This is first attempted by requesting a 1200 ticket-granting ticket for the destination realm from a Kerberos server for 1201 which the client possesses a ticket-granting ticket (using the KRB_TGS_REQ 1202 message recursively). The Kerberos server may return a TGT for the desired 1203 realm in which case one can proceed. Alternatively, the Kerberos server may 1204 return a TGT for a realm which is 'closer' to the desired realm (further 1205 along the standard hierarchical path between the client's realm and the 1206 requested realm server's realm). 1208 (To decide whether to leave, this and next paragraph) If the client does not 1209 know the realm of the service or the true service principal name, then the 1210 CANONICALIZE option must be used in the request. This will cause the TGS to 1211 locate the service principal based on the target service name in the ticket 1212 and return the service principal name in the response. This function allows 1213 the KDC to inform the user of the registered Kerberos principal name and 1214 registered KDC for a server that may have more than one host name or whose 1215 registered realm can not be determined from the name of the host, but it is 1216 not to be used to locate the application server. 1218 If the server name determined by a TGS supporting name canonicalization is 1219 with a remote KDC, then the response will include the principal name 1220 determined by the KDC, and will include a TGT for the remote realm or a 1221 realm 'closer' to the realm with which the server principal is registered. 1222 In this case, the canonicalization request must be repeated with a Kerberos 1223 server in the realm specified in the returned TGT. If neither are returned, 1224 then the request may be retried with a Kerberos server for a realm higher in 1225 the hierarchy. This request will itself require a ticket-granting ticket for 1226 the higher realm which must be obtained by recursively applying these 1227 directions. 1229 Once the client obtains a ticket-granting ticket for the appropriate realm, 1230 it determines which Kerberos servers serve that realm, and contacts one. The 1231 list might be obtained through a configuration file or network service or it 1232 may be generated from the name of the realm; as long as the secret keys 1233 exchanged by realms are kept secret, only denial of service results from 1234 using a false Kerberos server. 1236 As in the AS exchange, the client may specify a number of options in the 1237 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing 1238 an authentication header as an element of the padata field, and including 1239 the same fields as used in the KRB_AS_REQ message along with several 1240 optional fields: the enc-authorization-data field for application server use 1241 and additional tickets required by some options. 1243 In preparing the authentication header, the client can select a sub-session 1244 key under which the response from the Kerberos server will be 1245 encrypted[3.13]. If the sub-session key is not specified, the session key 1246 from the ticket-granting ticket will be used. If the enc-authorization-data 1247 is present, it must be encrypted in the sub-session key, if present, from 1248 the authenticator portion of the authentication header, or if not present, 1249 using the session key from the ticket-granting ticket. 1251 Once prepared, the message is sent to a Kerberos server for the destination 1252 realm. See section A.5 for pseudocode. 1254 3.3.2. Receipt of KRB_TGS_REQ message 1256 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1257 message, but there are many additional checks to be performed. First, the 1258 Kerberos server must determine which server the accompanying ticket is for 1259 and it must select the appropriate key to decrypt it. For a normal 1260 KRB_TGS_REQ message, it will be for the ticket granting service, and the 1261 TGS's key will be used. If the TGT was issued by another realm, then the 1262 appropriate inter-realm key must be used. If the accompanying ticket is not 1263 a ticket granting ticket for the current realm, but is for an application 1264 server in the current realm, the RENEW, VALIDATE, or PROXY options are 1265 specified in the request, and the server for which a ticket is requested is 1266 the server named in the accompanying ticket, then the KDC will decrypt the 1267 ticket in the authentication header using the key of the server for which it 1268 was issued. If no ticket can be found in the padata field, the 1269 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1271 Once the accompanying ticket has been decrypted, the user-supplied checksum 1272 in the Authenticator must be verified against the contents of the request, 1273 and the message rejected if the checksums do not match (with an error code 1274 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1275 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1276 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1277 returned. If the authorization-data are present, they are decrypted using 1278 the sub-session key from the Authenticator. 1280 If any of the decryptions indicate failed integrity checks, the 1281 KRB_AP_ERR_BAD_INTEGRITY error is returned. If the CANONICALIZE option is 1282 set in the KRB_TGS_REQ, then the requested service name might not be the 1283 true principal name or the service might not be in the TGS realm and the 1284 correct name must be determined. 1286 3.3.3. Generation of KRB_TGS_REP message 1288 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1289 but with its type field set to KRB_TGS_REP. The detailed specification is in 1290 section 5.4.2. 1292 (Decide if to keep sentence on canonicalize below) The response will include 1293 a ticket for the requested server or for a ticket granting server of an 1294 intermediate KDC to be contacted to obtain the requested ticket. The 1295 Kerberos database is queried to retrieve the record for the appropriate 1296 server (including the key with which the ticket will be encrypted). If the 1297 request is for a ticket granting ticket for a remote realm, and if no key is 1298 shared with the requested realm, then the Kerberos server will select the 1299 realm 'closest' to the requested realm with which it does share a key, and 1300 use that realm instead. If the CANONICALIZE option is set, the TGS may 1301 return a ticket containing the server name of the true service principal. If 1302 the requested server cannot be found in the TGS database, then a TGT for 1303 another trusted realm may be returned instead of a ticket for the service. 1304 This TGT is a referral mechanism to cause the client to retry the request to 1305 the realm of the TGT. These are the only cases where the response for the 1306 KDC will be for a different server than that requested by the client. 1308 By default, the address field, the client's name and realm, the list of 1309 transited realms, the time of initial authentication, the expiration time, 1310 and the authorization data of the newly-issued ticket will be copied from 1311 the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1312 needs to be updated, but the transited type is not supported, the 1313 KDC_ERR_TRTYPE_NOSUPP error is returned. 1315 If the request specifies an endtime, then the endtime of the new ticket is 1316 set to the minimum of (a) that request, (b) the endtime from the TGT, and 1317 (c) the starttime of the TGT plus the minimum of the maximum life for the 1318 application server and the maximum life for the local realm (the maximum 1319 life for the requesting principal was already applied when the TGT was 1320 issued). If the new ticket is to be a renewal, then the endtime above is 1321 replaced by the minimum of (a) the value of the renew_till field of the 1322 ticket and (b) the starttime for the new ticket plus the life 1323 (endtime-starttime) of the old ticket. 1325 If the FORWARDED option has been requested, then the resulting ticket will 1326 contain the addresses specified by the client. This option will only be 1327 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1328 similar; the resulting ticket will contain the addresses specified by the 1329 client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1330 PROXY option will not be honored on requests for additional ticket-granting 1331 tickets. 1333 If the requested start time is absent, indicates a time in the past, or is 1334 within the window of acceptable clock skew for the KDC and the POSTDATE 1335 option has not been specified, then the start time of the ticket is set to 1336 the authentication server's current time. If it indicates a time in the 1337 future beyond the acceptable clock skew, but the POSTDATED option has not 1338 been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1339 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1340 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1341 postdated and the requested starttime is checked against the policy of the 1342 local realm. If acceptable, the ticket's start time is set as requested, and 1343 the INVALID flag is set. The postdated ticket must be validated before use 1344 by presenting it to the KDC after the starttime has been reached. However, 1345 in no case may the starttime, endtime, or renew-till time of a newly-issued 1346 postdated ticket extend beyond the renew-till time of the ticket-granting 1347 ticket. 1349 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1350 has been included in the request, the KDC will decrypt the additional ticket 1351 using the key for the server to which the additional ticket was issued and 1352 verify that it is a ticket-granting ticket. If the name of the requested 1353 server is missing from the request, the name of the client in the additional 1354 ticket will be used. Otherwise the name of the requested server will be 1355 compared to the name of the client in the additional ticket and if 1356 different, the request will be rejected. If the request succeeds, the 1357 session key from the additional ticket will be used to encrypt the new 1358 ticket that is issued instead of using the key of the server for which the 1359 new ticket will be used. 1361 If the name of the server in the ticket that is presented to the KDC as part 1362 of the authentication header is not that of the ticket-granting server 1363 itself, the server is registered in the realm of the KDC, and the RENEW 1364 option is requested, then the KDC will verify that the RENEWABLE flag is set 1365 in the ticket, that the INVALID flag is not set in the ticket, and that the 1366 renew_till time is still in the future. If the VALIDATE option is requested, 1367 the KDC will check that the starttime has passed and the INVALID flag is 1368 set. If the PROXY option is requested, then the KDC will check that the 1369 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1370 passes the hotlist check described in the next section, the KDC will issue 1371 the appropriate new ticket. 1373 The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1374 in the sub-session key from the Authenticator, if present, or the session 1375 key key from the ticket-granting ticket. It is not encrypted using the 1376 client's secret key. Furthermore, the client's key's expiration date and the 1377 key version number fields are left out since these values are stored along 1378 with the client's database record, and that record is not needed to satisfy 1379 a request based on a ticket-granting ticket. See section A.6 for pseudocode. 1381 3.3.3.1. Checking for revoked tickets 1383 Whenever a request is made to the ticket-granting server, the presented 1384 ticket(s) is(are) checked against a hot-list of tickets which have been 1385 canceled. This hot-list might be implemented by storing a range of issue 1386 timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1387 that range, it would be rejected. In this way, a stolen ticket-granting 1388 ticket or renewable ticket cannot be used to gain additional tickets 1389 (renewals or otherwise) once the theft has been reported to the KDC for the 1390 realm in which the server resides. Any normal ticket obtained before it was 1391 reported stolen will still be valid (because they require no interaction 1392 with the KDC), but only until their normal expiration time. If TGT's have 1393 been issued for cross-realm authentication, use of the cross-realm TGT will 1394 not be affected unless the hot-list is propagated to the KDC's for the 1395 realms for which such cross-realm tickets were issued. 1397 3.3.3.2. Encoding the transited field 1399 If the identity of the server in the TGT that is presented to the KDC as 1400 part of the authentication header is that of the ticket-granting service, 1401 but the TGT was issued from another realm, the KDC will look up the 1402 inter-realm key shared with that realm and use that key to decrypt the 1403 ticket. If the ticket is valid, then the KDC will honor the request, subject 1404 to the constraints outlined above in the section describing the AS exchange. 1405 The realm part of the client's identity will be taken from the 1406 ticket-granting ticket. The name of the realm that issued the 1407 ticket-granting ticket will be added to the transited field of the ticket to 1408 be issued. This is accomplished by reading the transited field from the 1409 ticket-granting ticket (which is treated as an unordered set of realm 1410 names), adding the new realm to the set, then constructing and writing out 1411 its encoded (shorthand) form (this may involve a rearrangement of the 1412 existing encoding). 1414 Note that the ticket-granting service does not add the name of its own 1415 realm. Instead, its responsibility is to add the name of the previous realm. 1416 This prevents a malicious Kerberos server from intentionally leaving out its 1417 own name (it could, however, omit other realms' names). 1419 The names of neither the local realm nor the principal's realm are to be 1420 included in the transited field. They appear elsewhere in the ticket and 1421 both are known to have taken part in authenticating the principal. Since the 1422 endpoints are not included, both local and single-hop inter-realm 1423 authentication result in a transited field that is empty. 1425 Because the name of each realm transited is added to this field, it might 1426 potentially be very long. To decrease the length of this field, its contents 1427 are encoded. The initially supported encoding is optimized for the normal 1428 case of inter-realm communication: a hierarchical arrangement of realms 1429 using either domain or X.500 style realm names. This encoding (called 1430 DOMAIN-X500-COMPRESS) is now described. 1432 Realm names in the transited field are separated by a ",". The ",", "\", 1433 trailing "."s, and leading spaces (" ") are special characters, and if they 1434 are part of a realm name, they must be quoted in the transited field by 1435 preceding them with a "\". 1437 A realm name ending with a "." is interpreted as being prepended to the 1438 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1439 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1441 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1443 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1444 would not be included in this field, and we would have: 1446 "EDU,MIT.,WASHINGTON.EDU" 1448 A realm name beginning with a "/" is interpreted as being appended to the 1449 previous realm[18]. If it is to stand by itself, then it should be preceded 1450 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1451 /COM/HP, /COM, and /COM/DEC as: 1453 "/COM,/HP,/APOLLO, /COM/DEC". 1455 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1456 they would not be included in this field, and we would have: 1458 "/COM,/HP" 1460 A null subfield preceding or following a "," indicates that all realms 1461 between the previous realm and the next realm have been traversed[19]. Thus, 1462 "," means that all realms along the path between the client and the server 1463 have been traversed. ",EDU, /COM," means that that all realms from the 1464 client's realm up to EDU (in a domain style hierarchy) have been traversed, 1465 and that everything from /COM down to the server's realm in an X.500 style 1466 has also been traversed. This could occur if the EDU realm in one hierarchy 1467 shares an inter-realm key directly with the /COM realm in another hierarchy. 1469 3.3.4. Receipt of KRB_TGS_REP message 1471 When the KRB_TGS_REP is received by the client, it is processed in the same 1472 manner as the KRB_AS_REP processing described above. The primary difference 1473 is that the ciphertext part of the response must be decrypted using the 1474 session key from the ticket-granting ticket rather than the client's secret 1475 key. The server name returned in the reply is the true principal name of the 1476 service. See section A.7 for pseudocode. 1478 3.4. The KRB_SAFE Exchange 1480 The KRB_SAFE message may be used by clients requiring the ability to detect 1481 modifications of messages they exchange. It achieves this by including a 1482 keyed collision-proof checksum of the user data and some control 1483 information. The checksum is keyed with an encryption key (usually the last 1484 key negotiated via subkeys, or the session key if no negotiation has 1485 occurred). 1487 3.4.1. Generation of a KRB_SAFE message 1489 When an application wishes to send a KRB_SAFE message, it collects its data 1490 and the appropriate control information and computes a checksum over them. 1491 The checksum algorithm should be a keyed one-way hash function (such as the 1492 RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), 1493 generated using the sub-session key if present, or the session key. 1494 Different algorithms may be selected by changing the checksum type in the 1495 message. Unkeyed or non-collision-proof checksums are not suitable for this 1496 use. 1498 The control information for the KRB_SAFE message includes both a timestamp 1499 and a sequence number. The designer of an application using the KRB_SAFE 1500 message must choose at least one of the two mechanisms. This choice should 1501 be based on the needs of the application protocol. 1503 Sequence numbers are useful when all messages sent will be received by one's 1504 peer. Connection state is presently required to maintain the session key, so 1505 maintaining the next sequence number should not present an additional 1506 problem. 1508 If the application protocol is expected to tolerate lost messages without 1509 them being resent, the use of the timestamp is the appropriate replay 1510 detection mechanism. Using timestamps is also the appropriate mechanism for 1511 multi-cast protocols where all of one's peers share a common sub-session 1512 key, but some messages will be sent to a subset of one's peers. 1514 After computing the checksum, the client then transmits the information and 1515 checksum to the recipient in the message format specified in section 5.6.1. 1517 3.4.2. Receipt of KRB_SAFE message 1519 When an application receives a KRB_SAFE message, it verifies it as follows. 1520 If any error occurs, an error code is reported for use by the application. 1522 The message is first checked by verifying that the protocol version and type 1523 fields match the current version and KRB_SAFE, respectively. A mismatch 1524 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1525 application verifies that the checksum used is a collision-proof keyed 1526 checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If 1527 the sender's address was included in the control information, the recipient 1528 verifies that the operating system's report of the sender's address matches 1529 the sender's address in the message, and (if a recipient address is 1530 specified or the recipient requires an address) that one of the recipient's 1531 addresses appears as the recipient's address in the message. A failed match 1532 for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and 1533 usec and/or the sequence number fields are checked. If timestamp and usec 1534 are expected and not present, or they are present but not current, the 1535 KRB_AP_ERR_SKEW error is generated. If the server name, along with the 1536 client name, time and microsecond fields from the Authenticator match any 1537 recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT 1538 error is generated. If an incorrect sequence number is included, or a 1539 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error 1540 is generated. If neither a time-stamp and usec or a sequence number is 1541 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is 1542 computed over the data and control information, and if it doesn't match the 1543 received checksum, a KRB_AP_ERR_MODIFIED error is generated. 1545 If all the checks succeed, the application is assured that the message was 1546 generated by its peer and was not modified in transit. 1548 3.5. The KRB_PRIV Exchange 1550 The KRB_PRIV message may be used by clients requiring confidentiality and 1551 the ability to detect modifications of exchanged messages. It achieves this 1552 by encrypting the messages and adding control information. 1554 3.5.1. Generation of a KRB_PRIV message 1556 When an application wishes to send a KRB_PRIV message, it collects its data 1557 and the appropriate control information (specified in section 5.7.1) and 1558 encrypts them under an encryption key (usually the last key negotiated via 1559 subkeys, or the session key if no negotiation has occurred). As part of the 1560 control information, the client must choose to use either a timestamp or a 1561 sequence number (or both); see the discussion in section 3.4.1 for 1562 guidelines on which to use. After the user data and control information are 1563 encrypted, the client transmits the ciphertext and some 'envelope' 1564 information to the recipient. 1566 3.5.2. Receipt of KRB_PRIV message 1568 When an application receives a KRB_PRIV message, it verifies it as follows. 1569 If any error occurs, an error code is reported for use by the application. 1571 The message is first checked by verifying that the protocol version and type 1572 fields match the current version and KRB_PRIV, respectively. A mismatch 1573 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1574 application then decrypts the ciphertext and processes the resultant 1575 plaintext. If decryption shows the data to have been modified, a 1576 KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was 1577 included in the control information, the recipient verifies that the 1578 operating system's report of the sender's address matches the sender's 1579 address in the message, and (if a recipient address is specified or the 1580 recipient requires an address) that one of the recipient's addresses appears 1581 as the recipient's address in the message. A failed match for either case 1582 generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1583 sequence number fields are checked. If timestamp and usec are expected and 1584 not present, or they are present but not current, the KRB_AP_ERR_SKEW error 1585 is generated. If the server name, along with the client name, time and 1586 microsecond fields from the Authenticator match any recently-seen such 1587 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 1588 number is included, or a sequence number is expected but not present, the 1589 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1590 a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1592 If all the checks succeed, the application can assume the message was 1593 generated by its peer, and was securely transmitted (without intruders able 1594 to see the unencrypted contents). 1596 3.6. The KRB_CRED Exchange 1598 The KRB_CRED message may be used by clients requiring the ability to send 1599 Kerberos credentials from one host to another. It achieves this by sending 1600 the tickets together with encrypted data containing the session keys and 1601 other information associated with the tickets. 1603 3.6.1. Generation of a KRB_CRED message 1605 When an application wishes to send a KRB_CRED message it first (using the 1606 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1607 constructs a KRB_CRED message using the ticket or tickets so obtained, 1608 placing the session key needed to use each ticket in the key field of the 1609 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1610 message. 1612 Other information associated with each ticket and obtained during the 1613 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1614 the encrypted part of the KRB_CRED message. The current time and, if 1615 specifically required by the application the nonce, s-address, and r-address 1616 fields, are placed in the encrypted part of the KRB_CRED message which is 1617 then encrypted under an encryption key previously exchanged in the KRB_AP 1618 exchange (usually the last key negotiated via subkeys, or the session key if 1619 no negotiation has occurred). 1621 3.6.2. Receipt of KRB_CRED message 1623 When an application receives a KRB_CRED message, it verifies it. If any 1624 error occurs, an error code is reported for use by the application. The 1625 message is verified by checking that the protocol version and type fields 1626 match the current version and KRB_CRED, respectively. A mismatch generates a 1627 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1628 decrypts the ciphertext and processes the resultant plaintext. If decryption 1629 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1630 generated. 1632 If present or required, the recipient verifies that the operating system's 1633 report of the sender's address matches the sender's address in the message, 1634 and that one of the recipient's addresses appears as the recipient's address 1635 in the message. A failed match for either case generates a 1636 KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field 1637 if required) are checked next. If the timestamp and usec are not present, or 1638 they are present but not current, the KRB_AP_ERR_SKEW error is generated. 1640 If all the checks succeed, the application stores each of the new tickets in 1641 its ticket cache together with the session key and other information in the 1642 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1643 message. 1645 4. The Kerberos Database 1647 The Kerberos server must have access to a database containing the principal 1648 identifiers and secret keys of any principals to be authenticated[4.1] using 1649 such secret keys. The keying material in the database must be protected so 1650 that they are only accessible to the Kerberos server and administrative 1651 functions specifically authorized to access such material. Specific 1652 implementations may handle the storage of keying material separate from the 1653 Kerberos database (e.g. in hardware) or by encrypting the keying material 1654 before placing it in the Kerberos database. Some implementations might 1655 provide a means for using long term secret keys, but not for retrieving them 1656 from the Kerberos database. 1658 4.1. Database contents 1660 A database entry will typically contain the following fields, though in some 1661 instances a KDC may obtain these values through other means: 1663 Field Value 1665 name Principal's identifier 1666 key Principal's secret key 1667 p_kvno Principal's key version 1668 max_life Maximum lifetime for Tickets 1669 max_renewable_life Maximum total lifetime for renewable Tickets 1671 The name field is an encoding of the principal's identifier. The key field 1672 contains an encryption key. This key is the principal's secret key. (The key 1673 can be encrypted before storage under a Kerberos "master key" to protect it 1674 in case the database is compromised but the master key is not. In that case, 1675 an extra field must be added to indicate the master key version used, see 1676 below.) The p_kvno field is the key version number of the principal's secret 1677 key. The max_life field contains the maximum allowable lifetime (endtime - 1678 starttime) for any Ticket issued for this principal. The max_renewable_life 1679 field contains the maximum allowable total lifetime for any renewable Ticket 1680 issued for this principal. (See section 3.1 for a description of how these 1681 lifetimes are used in determining the lifetime of a given Ticket.) 1683 A server may provide KDC service to several realms, as long as the database 1684 representation provides a mechanism to distinguish between principal records 1685 with identifiers which differ only in the realm name. 1687 When an application server's key changes, if the change is routine (i.e. not 1688 the result of disclosure of the old key), the old key should be retained by 1689 the server until all tickets that had been issued using that key have 1690 expired. Because of this, it is possible for several keys to be active for a 1691 single principal. Ciphertext encrypted in a principal's key is always tagged 1692 with the version of the key that was used for encryption, to help the 1693 recipient find the proper key for decryption. 1695 When more than one key is active for a particular principal, the principal 1696 will have more than one record in the Kerberos database. The keys and key 1697 version numbers will differ between the records (the rest of the fields may 1698 or may not be the same). Whenever Kerberos issues a ticket, or responds to a 1699 request for initial authentication, the most recent key (known by the 1700 Kerberos server) will be used for encryption. This is the key with the 1701 highest key version number. 1703 4.2. Additional fields 1705 Project Athena's KDC implementation uses additional fields in its database: 1707 Field Value 1708 K_kvno Kerberos' key version 1709 expiration Expiration date for entry 1710 attributes Bit field of attributes 1711 mod_date Timestamp of last modification 1712 mod_name Modifying principal's identifier 1714 The K_kvno field indicates the key version of the Kerberos master key under 1715 which the principal's secret key is encrypted. 1717 After an entry's expiration date has passed, the KDC will return an error to 1718 any client attempting to gain tickets as or for the principal. (A database 1719 may want to maintain two expiration dates: one for the principal, and one 1720 for the principal's current key. This allows password aging to work 1721 independently of the principal's expiration date. However, due to the 1722 limited space in the responses, the KDC combines the key expiration and 1723 principal expiration date into a single value called 'key_exp', which is 1724 used as a hint to the user to take administrative action.) 1726 The attributes field is a bitfield used to govern the operations involving 1727 the principal. This field might be useful in conjunction with user 1728 registration procedures, for site-specific policy implementations (Project 1729 Athena currently uses it for their user registration process controlled by 1730 the system-wide database service, Moira [LGDSR87]), to identify whether a 1731 principal can play the role of a client or server or both, to note whether a 1732 server is appropriately trusted to receive credentials delegated by a 1733 client, or to identify the 'string to key' conversion algorithm used for a 1734 principal's key[4.2]. Other bits are used to indicate that certain ticket 1735 options should not be allowed in tickets encrypted under a principal's key 1736 (one bit each): Disallow issuing postdated tickets, disallow issuing 1737 forwardable tickets, disallow issuing tickets based on TGT authentication, 1738 disallow issuing renewable tickets, disallow issuing proxiable tickets, and 1739 disallow issuing tickets for which the principal is the server. 1741 The mod_date field contains the time of last modification of the entry, and 1742 the mod_name field contains the name of the principal which last modified 1743 the entry. 1745 4.3. Frequently Changing Fields 1747 Some KDC implementations may wish to maintain the last time that a request 1748 was made by a particular principal. Information that might be maintained 1749 includes the time of the last request, the time of the last request for a 1750 ticket-granting ticket, the time of the last use of a ticket-granting 1751 ticket, or other times. This information can then be returned to the user in 1752 the last-req field (see section 5.2). 1754 Other frequently changing information that can be maintained is the latest 1755 expiration time for any tickets that have been issued using each key. This 1756 field would be used to indicate how long old keys must remain valid to allow 1757 the continued use of outstanding tickets. 1759 4.4. Site Constants 1761 The KDC implementation should have the following configurable constants or 1762 options, to allow an administrator to make and enforce policy decisions: 1764 * The minimum supported lifetime (used to determine whether the 1765 KDC_ERR_NEVER_VALID error should be returned). This constant should 1766 reflect reasonable expectations of round-trip time to the KDC, 1767 encryption/decryption time, and processing time by the client and 1768 target server, and it should allow for a minimum 'useful' lifetime. 1769 * The maximum allowable total (renewable) lifetime of a ticket 1770 (renew_till - starttime). 1771 * The maximum allowable lifetime of a ticket (endtime - starttime). 1772 * Whether to allow the issue of tickets with empty address fields 1773 (including the ability to specify that such tickets may only be issued 1774 if the request specifies some authorization_data). 1775 * Whether proxiable, forwardable, renewable or post-datable tickets are 1776 to be issued. 1778 5. Message Specifications 1780 The Kerberos protocol is defined here in terms of Abstract Syntax Notation 1781 One (ASN.1), which provides a syntax for specifying both the abstract layout 1782 of protocol messages as well as their encodings. Implementors not utilizing 1783 an existing ASN.1 compiler or support library are cautioned to thoroughly 1784 understand the actual ASN.1 specification to ensure correct implementation 1785 behavior, as there is more complexity in the notation than is immediately 1786 obvious, and some tutorials and guides to ASN.1 are misleading or erroneous. 1788 Note that in several places, the use of ASN.1 by Kerberos violates the 1789 actual ASN.1 specification in minor ways. These will be clearly flagged when 1790 they occur. In addition, changes have been made to the data types defined in 1791 RFC1510 that are not strictly permitted by the type extension model of 1792 ASN.1. These changes can cause incomptabile encodings to be emitted when 1793 certain encoding rules, e.g. the Packed Encoding Rules (PER). In all places 1794 where these sorts of changes have been made, with very few exceptions, the 1795 encodings emitted by the Distinguished Encoding Rules (DER), which are the 1796 only encodings permitted by this document and RFC1510, remain identical. 1798 The type definitions in this section assume an ASN.1 module definition of 1799 the following form: 1801 Kerberos5 { 1802 iso (1), org(3), dod(6), internet(1), security(5), kerberosV5(2) 1803 } DEFINITIONS ::= BEGIN 1805 -- rest of definitions here 1807 END 1809 This specifies an explicit non-automatic tagging for the ASN.1 type 1810 definitions. 1812 Note that in some other publications [RFC1510] [RFC1964], the "dod" portion 1813 of the object identifier is erroneously specified as having the value "5". 1815 Note that elsewhere in this document, nomenclature for various message types 1816 is inconsistent, but seems to largely follow C language conventions, 1817 including use of underscore (_) characters and all-caps spelling of names 1818 intended to be numeric constants. Also, in some places, identifiers 1819 (especially ones refering to constants) are written in all-caps in order to 1820 distinguish them from surrounding explanatory text. 1822 The ASN.1 notation does not permit underscores in identifiers, so in actual 1823 ASN.1 definitions of data types, underscores are replaced with hyphens (-). 1824 Additionally, structure member names and defined values in ASN.1 must begin 1825 with a lowercase letter, while type names must begin with an uppercase 1826 letter. 1828 5.1. Specific Compatibility Notes on ASN.1 1830 For compatibility purposes, implementors should heed the following specific 1831 notes regarding the use of ASN.1 in Kerberos. 1833 5.1.1. ASN.1 Distinguished Encoding Rules 1835 The encoding of Kerberos protocol messages shall obey the Distinguished 1836 Encoding Rules (DER) of ASN.1 as described in X.690 (1997). Some 1837 implementations (believed to be primarly ones derived from DCE 1.1 and 1838 earlier) are known to use the more general Basic Encoding Rules (BER); in 1839 particular, these implementations send indefinite encodings of lengths. 1840 Implementations may accept such encodings in the interests of backwards 1841 compatibility, though implementors are warned that decoding fully-general 1842 BER is fraught with peril. 1844 5.1.2. Optional Fields in ASN.1 Sequences 1846 Some implementations behave as if certain default values are equivalent to 1847 omission of an optional value. Implementations should handle this case 1848 gracefully. For example, the seq-number field in an Authenticator is 1849 optional, but some implementations use an internal value of zero to indicate 1850 that the field is to be omitted upon encoding. [While it is possible to use 1851 the DEFAULT qualifier for the ASN.1 notation of a SEQUENCE member in order 1852 to mandate this behavior, the result would be that the member would be 1853 mandatory to omit if the value intended is that specified by the DEFAULT 1854 keyword. This limits the possible semantics of the protocol.] 1856 5.1.3. Extension Fields in ASN.1 Sequences 1858 In types where the extension marker (the "..." component) is used to 1859 indicate possible extensions to a message, an implementation must retain any 1860 unrecognized fields for re-encoding, as required by the ASN.1 specification. 1862 5.1.4. Zero-length SEQUENCE Types 1864 There are places in the protocol where a message contains a SEQUENCE OF type 1865 as an optional member, or a SEQUENCE type where all members are optional. 1866 This can result in an encoding that contains an zero-length SEQUENCE or 1867 SEQUENCE OF encoding. In general, implementations should not send 1868 zero-length SEQUENCE OF or SEQUENCE encodings that are marked OPTIONAL, but 1869 should accept them. [XXX there may be cases where an empty SEQUENCE type has 1870 useful semantics, though] 1872 5.1.5. Unrecognized Tag Numbers 1874 Future revisions to this protocol may include new message types with 1875 different APPLICATION class tag numbers. Such revisions should protect older 1876 implementations by only sending the message types to parties that are known 1877 to understand them, e.g. by means of a flag bit set by the receiver in a 1878 preceding request, but in the interest of robust error handling, 1879 implementations should gracefully handle receiving an unrecognized tag 1880 anyway, and return an error message if appropriate. 1882 5.1.5. Tag Numbers Greater Than 30 1884 A naive implementation of a DER ASN.1 decoder may experience problems with 1885 ASN.1 tag numbers greater than 30, due such tag numbers being encoded using 1886 more than one byte. Future revisions of this protocol may utilize tag 1887 numbers greater than 30, and implementations should be prepared to 1888 gracefully return an appropriate error if they do not recognize the tag. 1890 5.2. Basic Kerberos Types 1892 This section defines a number of basic types that are potentially used in 1893 multiple Kerberos protocol messages. 1895 5.2.1. KerberosString 1897 [XXX The following paragraphs may need some editing, or maybe they want to 1898 live in a footnote] 1900 The original specification of the Kerberos protocol in RFC 1510 uses 1901 GeneralString in numerous places for human-readable string data. Historical 1902 implementations of Kerberos cannot utilize the full power of GeneralString. 1903 This ASN.1 type requires the use of designation and invocation escape 1904 sequences as specified in ISO 2022 to switch character sets, and the default 1905 character set that is designated for G0 is basically US ASCII, which mostly 1906 works. In practice, many implementations end up treating GeneralStrings as 1907 if they were ISO 8859-1 (Latin-1) strings. It is arguably technically 1908 incorrect to include Latin-1 charcters in a GeneralString without an 1909 invocation escape sequence for the G1 character set of the encoding. 1911 Also, DER prohibits the invocation of character sets into any but the G0 and 1912 C0 sets, which seems to outright prohibit the encoding of characters with 1913 the high bit set. Unfortunately this seems to have the side effect of 1914 prohibiting the transmission of Latin-1 characters at all, since the 1915 character set defined in ISO 8859-1 is a 96-character set and cannot be 1916 invoked into G0. Some inconclusive discussion has taken place within the 1917 ASN.1 community on this subject. 1919 The least objectionable method of resolving this difficulty seems to be to 1920 encode strings as UTF8String, but to tag them as GeneralString. This 1921 reflects current practice, and permits additional internationalization with 1922 less difficulty. We declare here a KerberosString type that cannot be 1923 represented in fully compliant ASN.1 notation, but which comes closest to 1924 the intended effect: 1926 KerberosString ::= [UNIVERSAL 27] IMPLICIT UTF8String 1927 -- illegal use of ASN.1 notation 1928 -- to best illustrate desired encoding 1929 -- UNIVERSAL 27 is the tag of a GeneralString 1931 This is illegal ASN.1; the ASN.1 specification forbids the use of the 1932 UNIVERSAL class tag outside of the ASN.1 specification itself. If the ASN.1 1933 compiler and utilities to be used by the implementation do not permit the 1934 use of the UNIVERSAL class tag in an application's syntax, the following 1935 definition may be used: 1937 KerberosString ::= GeneralString 1938 Declaring KerberosString to be a GeneralString must be done with caution, as 1939 ASN.1 compilers and utilities may do some processing of values on their way 1940 to the encoder and from the decoder if the ASN.1 compliers and utilities 1941 actually handle transformations between different character string types. 1943 5.2.2. Realm and PrincipalName 1945 Realm ::= KerberosString 1946 PrincipalName ::= SEQUENCE { 1947 name-type[0] Int32, 1948 name-string[1] SEQUENCE OF KerberosString 1949 } 1951 Kerberos realm names are encoded as KerberosStrings. Realms shall not 1952 contain a character with the code 0 (the ASCII NUL). Most realms will 1953 usually consist of several components separated by periods (.), in the style 1954 of Internet Domain Names, or separated by slashes (/) in the style of X.500 1955 names. Acceptable forms for realm names are specified in section 7. A 1956 PrincipalName is a typed sequence of components consisting of the following 1957 sub-fields: 1959 name-type 1960 This field specifies the type of name that follows. Pre-defined values 1961 for this field are specified in section 7.2. The name-type should be 1962 treated as a hint. Ignoring the name type, no two names can be the same 1963 (i.e. at least one of the components, or the realm, must be different). 1964 This constraint may be eliminated in the future. 1965 name-string 1966 This field encodes a sequence of components that form a name, each 1967 component encoded as a KerberosString. Taken together, a PrincipalName 1968 and a Realm form a principal identifier. Most PrincipalNames will have 1969 only a few components (typically one or two). 1971 5.2.3. KerberosTime 1973 KerberosTime ::= GeneralizedTime 1974 -- with no fractional seconds 1976 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 1977 KerberosTime value shall not include any fractional portions of the seconds. 1978 As required by the DER, it further shall not include any separators, and it 1979 shall specify the UTC time zone (Z). Example: The only valid format for UTC 1980 time 6 minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z. 1982 5.2.4. Constrained Integer types 1984 Some integer members of types should be constrained to values representable 1985 in 32 bits, for compatibility with reasonable implementation limits. 1987 Int32 ::= INTEGER (-2147483648..2147483647) 1988 -- signed values representable in 32 bits 1990 UInt32 :: = INTEGER (0..4294967295) 1991 -- unsigned 32 bit values 1993 Microseconds ::= INTEGER (0..99999) 1994 -- microseconds 1995 Note that it may not be strictly conforming ASN.1 for some of the changes 1996 from the RFC1510 version of the data type definitions to change from INTEGER 1997 to one of the above-defined constrained integer types, the encoding in DER 1998 should be unaltered. Historical implementations were typically limited to 1999 32-bit integer values anyway, and assigned numbers should fall in the space 2000 of integer values representable in 32 bits in order to promote 2001 interoperability anyway. 2003 5.2.5. HostAddress and HostAddresses 2005 HostAddress ::= SEQUENCE { 2006 addr-type[0] Int32, 2007 address[1] OCTET STRING 2008 } 2010 HostAddresses ::= SEQUENCE OF HostAddress 2012 The host address encodings consists of two fields: 2014 addr-type 2015 This field specifies the type of address that follows. Pre-defined 2016 values for this field are specified in section 8.1. 2017 address 2018 This field encodes a single address of type addr-type. 2020 The two forms differ slightly. HostAddress contains exactly one address; 2021 HostAddresses contains a sequence of possibly many addresses. 2023 5.2.6. AuthorizationData 2025 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2026 ad-type[0] Int32, 2027 ad-data[1] OCTET STRING 2028 } 2030 ad-data 2031 This field contains authorization data to be interpreted according to 2032 the value of the corresponding ad-type field. 2033 ad-type 2034 This field specifies the format for the ad-data subfield. All negative 2035 values are reserved for local use. Non-negative values are reserved for 2036 registered use. 2038 Each sequence of type and data is referred to as an authorization element. 2039 Elements may be application specific, however, there is a common set of 2040 recursive elements that should be understood by all implementations. These 2041 elements contain other elements embedded within them, and the interpretation 2042 of the encapsulating element determines which of the embedded elements must 2043 be interpreted, and which may be ignored. Definitions for these common 2044 elements may be found in Appendix B. 2046 5.2.7. PA-DATA 2048 Historically, PA-DATA have been known as "pre-authentication data", meaning 2049 that they were used to augment the initial authentication with the KDC. 2050 Since that time, they have also been used as a typed hole with which to 2051 extend protocol exchanges with the KDC. 2053 PA-DATA ::= SEQUENCE { 2054 padata-type[1] Int32, 2055 padata-value[2] OCTET STRING 2056 -- might be encoded AP-REQ 2057 } 2059 padata-type 2060 The padata-type element of the padata field indicates the way that the 2061 padata-value element is to be interpreted. Negative values of 2062 padata-type are reserved for unregistered use; non-negative values are 2063 used for a registered interpretation of the element type. 2064 padata-value 2065 Usually contains the DER encoding of another type; the padata-type 2066 field identifies which type is encoded here. 2068 padata-type Type Encoded in padata-value 2070 1 AP-REQ -- PA-TGS-REQ 2072 2 PA-ENC-TIMESTAMP 2074 20 INTEGER -- PA-USE-SPECIFIED KVNO 2076 5.2.7.1. PA-TGS-REQ 2078 In the case of requests for additional tickets (KRB_TGS_REQ), padata-value 2079 will contain an encoded AP-REQ. The checksum in the authenticator (which 2080 must be collision-proof) is to be computed over the KDC-REQ-BODY encoding. 2082 This field may also contain information needed by certain extensions to the 2083 Kerberos protocol. For example, it might be used to initially verify the 2084 identity of a client before any response is returned. When this field is 2085 used to authenticate or pre-authenticate a request, it should contain a 2086 keyed checksum over the KDC-REQ-BODY to bind the pre-authentication data to 2087 rest of the request. The KDC, as a matter of policy, may decide whether to 2088 honor a KDC-REQ which includes any pre-authentication data that does not 2089 contain the checksum field. 2091 5.2.7.2. Encrypted Timestamp Pre-authentication 2093 There are pre-authentication types that may be used to pre-authenticate a 2094 client by means of an encrypted timestamp. The original PA-ENC-TIMESTAMP 2095 does not contain a checksum of the KDC-REQ-BODY, while the PA-ENC-TIMESTAMP2 2096 does. 2098 PA-ENC-TIMESTAMP ::= EncryptedData -- encrypted PA-ENC-TS-ENC 2100 PA-ENC-TS-ENC ::= SEQUENCE { 2101 patimestamp[0] KerberosTime, -- client's time 2102 pausec[1] Microseconds OPTIONAL 2103 } 2105 PA-ENC-TIMESTAMP2 ::= EncryptedData -- encrypted PA-ENC-TS2-ENC 2107 PA-ENC-TS2-ENC ::= SEQUENCE { 2108 patimestamp[0] KerberosTime, -- client's time 2109 pausec[1] Microseconds OPTIONAL, 2110 pachecksum[2] Checksum OPTIONAL 2111 -- keyed checksum of KDC-REQ-BODY 2112 } 2113 Patimestamp contains the client's time, and pausec contains the 2114 microseconds, which may be omitted if a client will not generate more than 2115 one request per second. The ciphertext (padata-value) consists of the 2116 PA-ENC-TS-ENC or PA-ENC-TS2-ENC encoding, encrypted using the client's 2117 secret key. 2119 It may also be used by the client to specify the version of a key that is 2120 being used for accompanying preauthentication, and/or which should be used 2121 to encrypt the reply from the KDC. 2123 5.2.7.3. PA-USE-SPECIFIED-KVNO 2125 The KDC should only accept and abide by the value of the use-specified-kvno 2126 preauthentication data field when the specified key is still valid and until 2127 use of a new key is confirmed. This situation is likely to occur primarily 2128 during the period during which an updated key is propagating to other KDC's 2129 in a realm. 2131 [XXX the following paragraph should apply perhaps to PA-DATA in general] 2133 The padata field can also contain information needed to help the KDC or the 2134 client select the key needed for generating or decrypting the response. This 2135 form of the padata is useful for supporting the use of certain token cards 2136 with Kerberos. The details of such extensions are specified in separate 2137 documents. See [Pat92] for additional uses of this field. 2139 5.2.8. KerberosFlags 2141 For several message types, a specific constrained bit string type, 2142 KerberosFlags, is used. 2144 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) 2146 Compatibility note: the following paragraphs describe a change from the 2147 RFC1510 description of bit strings that would result in incompatility in the 2148 case of an implementation that strictly conformed to ASN.1 DER and RFC1510. 2150 ASN.1 bit strings have multiple uses. The simplest use of a bit string is to 2151 contain a vector of bits, with no particular meaning attached to individual 2152 bits. This vector of bits is not necessarily a multiple of eight bits long. 2153 The use in Kerberos of a bit string as a compact boolean vector wherein each 2154 element has a distinct meaning poses some problems. The natural notation for 2155 a compact boolean vector is the ASN.1 "NamedBit" notation, and the DER 2156 require that encodings of a bit string using "NamedBit" notation exclude any 2157 trailing zero bits. This truncation is easy to neglect, especially given C 2158 language implementations that may naturally choose to store boolean vectors 2159 as 32 bit integers. 2161 For example, if the notation for KDCOptions were to include the "NamedBit" 2162 notation, as in RFC 1510, and a KDCOptions value to be encoded had only the 2163 "forwardable" (bit number one) bit set, the DER encoding must only include 2164 two bits: the first reserved bit ("reserved", bit number zero, value zero) 2165 and the one-valued bit (bit number one) for "forwardable". 2167 Most existing implementations of Kerberos unconditionally send 32 bits on 2168 the wire when encoding bit strings used as boolean vectors. This behavior 2169 violates the ASN.1 syntax used for flag values in RFC 1510, but occurs on 2170 such a widely installed base that the protocol description is being modified 2171 to accomodate it. 2173 Consequently, this document removes the "NamedBit" notations for individual 2174 bits, relegating them to comments. The size constraint on the KerberosFlags 2175 type requires that at least 32 bits be encoded at all times, though a 2176 lenient implementation may choose to accept fewer than 32 bits and to treat 2177 the missing bits as set to zero. 2179 Currently, no uses of KerberosFlags specify more than 32 bits worth of 2180 flags, although future revisions of this document may do so. When more than 2181 32 bits are to be transmitted in a KerberosFlags value, future revisions to 2182 this document will likely specify that the smallest number of bits needed to 2183 encode the highest-numbered one-valued bit should be sent. This is somewhat 2184 similar to the DER encoding of a bit string that is declared with the 2185 "NamedBit" notation. 2187 5.2.9. Direction 2189 Some new messages, such as KRB-SAFE2 and KRB-PRIV2, permit total omission of 2190 address information from the message. To prevent reflection attacks, an 2191 indicator of the direction of the message should be used when no address 2192 information is contained in the message. 2194 Direction ::= INTEGER { 2195 from-client(0), 2196 from-server(1) 2197 } 2199 5.2.10. Cryptosystem-related Types 2201 Many Kerberos protocol messages contain an EncryptedData as a container for 2202 arbitrary encrypted data, which is often the encrypted encoding of another 2203 data type. Fields within EncryptedData assist the recipient in selecting a 2204 key with which to decrypt the enclosed data. 2206 EncryptedData ::= SEQUENCE { 2207 etype[0] Int32, -- EncryptionType 2208 kvno[1] INTEGER OPTIONAL, 2209 cipher[2] OCTET STRING -- ciphertext 2210 } 2212 etype 2213 This field identifies which encryption algorithm was used to encipher 2214 the cipher. Detailed specifications for selected encryption types 2215 appear in section 6. 2216 kvno 2217 This field contains the version number of the key under which data is 2218 encrypted. It is only present in messages encrypted under long lasting 2219 keys, such as principals' secret keys. 2220 cipher 2221 This field contains the enciphered text, encoded as an OCTET STRING. 2223 The EncryptionKey type is the means by which cryptographic keys used for 2224 encryption are transfered. 2226 EncryptionKey ::= SEQUENCE { 2227 keytype[0] Int32, -- actually encryption type 2228 keyvalue[1] OCTET STRING 2229 } 2230 keytype 2231 This field specifies the encryption type of the encryption key that 2232 follows in the keyvalue field. While its name is "keytype", it actually 2233 specifies an encryption type. Previously, multiple cryptosystems that 2234 performed encryption differently but were capable of using keys with 2235 the same characteristics were permitted to share an assigned number to 2236 designate the type of key; this usage is now deprecated. 2237 keyvalue 2238 This field contains the key itself, encoded as an octet string. 2240 All negative values for the encryption key type are reserved for local 2241 use. All non-negative values are reserved for officially assigned type 2242 fields and interpretations. 2244 Messages containing cleartext data to be authenticated will usually do so by 2245 using a member of type Checksum. Most instances of Checksum use a keyed 2246 hash, though exceptions will be noted. 2248 Checksum ::= SEQUENCE { 2249 cksumtype[0] Int32, 2250 checksum[1] OCTET STRING 2251 } 2253 cksumtype 2254 This field indicates the algorithm used to generate the accompanying 2255 checksum. 2256 checksum 2257 This field contains the checksum itself, encoded as an octet string. 2259 Detailed specification of selected checksum types appear in section 6. 2260 Negative values for the checksum type are reserved for local use. All 2261 non-negative values are reserved for officially assigned type fields 2262 and interpretations. 2264 5.3. Tickets and Authenticators 2266 This section describes the format and encryption parameters for tickets and 2267 authenticators. When a ticket or authenticator is included in a protocol 2268 message it is treated as an opaque object. 2270 5.3.1. Tickets 2272 A ticket is a record that helps a client authenticate to a service. A Ticket 2273 contains the following information: 2275 Ticket ::= CHOICE { 2276 ticket1 Ticket1, -- RFC1510 Ticket 2277 ticket2 Ticket2 2278 } 2280 -- RFC1510 Ticket 2281 Ticket1 ::= [APPLICATION 1] SEQUENCE { 2282 tkt-vno[0] INTEGER, 2283 realm[1] Realm, 2284 sname[2] PrincipalName, 2285 enc-part[3] EncryptedData --EncTicketPart 2286 } 2287 Ticket2 ::= [APPLICATION 4] SEQUENCE { 2288 tkt-vno[0] INTEGER, 2289 realm[1] Realm, 2290 sname[2] PrincipalName, 2291 enc-part[3] EncryptedData, --EncTicketPart 2292 extensions[4] TicketExtensions OPTIONAL, 2293 ... 2294 } 2296 -- Encrypted part of ticket 2297 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2298 flags[0] TicketFlags, 2299 key[1] EncryptionKey, 2300 crealm[2] Realm, 2301 cname[3] PrincipalName, 2302 transited[4] TransitedEncoding, 2303 authtime[5] KerberosTime, 2304 starttime[6] KerberosTime OPTIONAL, 2305 endtime[7] KerberosTime, 2306 renew-till[8] KerberosTime OPTIONAL, 2307 caddr[9] HostAddresses OPTIONAL, 2308 authorization-data[10] AuthorizationData OPTIONAL 2309 } 2311 -- encoded Transited field 2312 TransitedEncoding ::= SEQUENCE { 2313 tr-type[0] Int32, -- must be registered 2314 contents[1] OCTET STRING 2315 } 2317 -- ticket extensions: for Ticket2 only 2318 TicketExtensions ::= SEQUENCE OF SEQUENCE { 2319 te-type[0] Int32, 2320 te-data[1] OCTET STRING 2321 } 2323 TicketFlags ::= KerberosFlags 2324 -- reserved(0), 2325 -- forwardable(1), 2326 -- forwarded(2), 2327 -- proxiable(3), 2328 -- proxy(4), 2329 -- may-postdate(5), 2330 -- postdated(6), 2331 -- invalid(7), 2332 -- renewable(8), 2333 -- initial(9), 2334 -- pre-authent(10), 2335 -- hw-authent(11), 2336 -- transited-policy-checked(12), 2337 -- ok-as-delegate(13) 2338 -- anonymous(14) 2340 The encoding of EncTicketPart is encrypted in the key shared by Kerberos and 2341 the end server (the server's secret key). See section 6 for the format of 2342 the ciphertext. 2344 The Ticket is a CHOICE type, containing either the RFC1510 version ticket or 2345 the newer version ticket, which has the type name "Ticket2". The different 2346 application tag number appears on "Ticket2" to prevent its confusion with 2347 the RFC1510 "Ticket" in the unlikely event that an implementation receives 2348 the incorrect type. The KDC should not issue a "Ticket2" to a client that 2349 does not understand it, nor should it issue a "Ticket2" for a service that 2350 does not understand it. The client may indicate via the [XXX insert flag 2351 name here] flag that it understands the new "Ticket2" type. For service 2352 principals used by multiple application protocols, like the "host" 2353 principal, this may mean that all such application servers must understand a 2354 "Ticket2" before the KDC may issue such a ticket. 2356 Note that the DER encoding of the "Ticket1" alternative of the "Ticket" type 2357 will be identical to that of the equivalent RFC1510 "Ticket". 2359 tkt-vno 2360 This field specifies the version number for the ticket format. This 2361 document describes version number 5. 2362 realm 2363 This field specifies the realm that issued a ticket. It also serves to 2364 identify the realm part of the server's principal identifier. Since a 2365 Kerberos server can only issue tickets for servers within its realm, 2366 the two will always be identical. 2367 sname 2368 This field specifies all components of the name part of the server's 2369 identity, including those parts that identify a specific instance of a 2370 service. 2371 enc-part 2372 This field holds the encrypted encoding of the EncTicketPart sequence. 2373 extensions 2374 This optional field, only present in the "Ticket2" alternative, 2375 contains a sequence of extensions that may be used to carry unencrypted 2376 information that must be carried with the ticket to support several 2377 extensions, including but not limited to plaintext authorization data, 2378 tokens for exchanging inter-realm keys, and other information that must 2379 be associated with a ticket for use by the application server. See 2380 Appendix C for definitions of common extensions. 2381 te-data 2382 This field contains opaque data that must be carried with the 2383 ticket to support extensions to the Kerberos protocol including 2384 but not limited to some forms of inter-realm key exchange and 2385 plaintext authorization data. See appendix C for some common uses 2386 of this field. 2387 te-type 2388 This field specifies the format for the te-data subfield. All 2389 negative values are reserved for local use. Non-negative values 2390 are reserved for registered use. 2391 flags 2392 This field indicates which of various options were used or requested 2393 when the ticket was issued. It is a bit-field, where the selected 2394 options are indicated by the bit being set (1), and the unselected 2395 options and reserved fields being reset (0). [XXX X.690 ref and notes 2396 on pitfalls?] The meanings of the flags are: 2397 Bit(s) Name Description 2399 0 reserved Reserved for future expansion of this 2400 field. 2402 The FORWARDABLE flag is normally only 2403 interpreted by the TGS, and can be 2404 ignored by end servers. When set, this 2405 1 forwardable flag tells the ticket-granting server 2406 that it is OK to issue a new 2407 ticket-granting ticket with a 2408 different network address based on the 2409 presented ticket. 2411 When set, this flag indicates that the 2412 ticket has either been forwarded or 2413 2 forwarded was issued based on authentication 2414 involving a forwarded ticket-granting 2415 ticket. 2417 The PROXIABLE flag is normally only 2418 interpreted by the TGS, and can be 2419 ignored by end servers. The PROXIABLE 2420 flag has an interpretation identical 2421 3 proxiable to that of the FORWARDABLE flag, 2422 except that the PROXIABLE flag tells 2423 the ticket-granting server that only 2424 non-ticket-granting tickets may be 2425 issued with different network 2426 addresses. 2428 4 proxy When set, this flag indicates that a 2429 ticket is a proxy. 2431 The MAY-POSTDATE flag is normally only 2432 interpreted by the TGS, and can be 2433 5 may-postdate ignored by end servers. This flag 2434 tells the ticket-granting server that 2435 a post-dated ticket may be issued 2436 based on this ticket-granting ticket. 2438 This flag indicates that this ticket 2439 has been postdated. The end-service 2440 6 postdated can check the authtime field to see 2441 when the original authentication 2442 occurred. 2444 This flag indicates that a ticket is 2445 invalid, and it must be validated by 2446 7 invalid the KDC before use. Application 2447 servers must reject tickets which have 2448 this flag set. 2450 The RENEWABLE flag is normally only 2451 interpreted by the TGS, and can 2452 usually be ignored by end servers 2453 8 renewable (some particularly careful servers may 2454 wish to disallow renewable tickets). A 2455 renewable ticket can be used to obtain 2456 a replacement ticket that expires at a 2457 later date. 2459 This flag indicates that this ticket 2460 9 initial was issued using the AS protocol, and 2461 not issued based on a ticket-granting 2462 ticket. 2464 This flag indicates that during 2465 initial authentication, the client was 2466 authenticated by the KDC before a 2467 10 pre-authent ticket was issued. The strength of the 2468 preauthentication method is not 2469 indicated, but is acceptable to the 2470 KDC. 2472 This flag indicates that the protocol 2473 employed for initial authentication 2474 required the use of hardware expected 2475 11 hw-authent to be possessed solely by the named 2476 client. The hardware authentication 2477 method is selected by the KDC and the 2478 strength of the method is not 2479 indicated. 2481 This flag indicates that the KDC for 2482 the realm has checked the transited 2483 field against a realm defined policy 2484 for trusted certifiers. If this flag 2485 is reset (0), then the application 2486 server must check the transited field 2487 itself, and if unable to do so it must 2488 12 transited- reject the authentication. If the flag 2489 policy-checked 2490 is set (1) then the application server 2491 may skip its own validation of the 2492 transited field, relying on the 2493 validation performed by the KDC. At 2494 its option the application server may 2495 still apply its own validation based 2496 on a separate policy for acceptance. 2498 This flag indicates that the server 2499 (not the client) specified in the 2500 ticket has been determined by policy 2501 of the realm to be a suitable 2502 recipient of delegation. A client can 2503 use the presence of this flag to help 2504 it make a decision whether to delegate 2505 credentials (either grant a proxy or a 2506 13 ok-as-delegate forwarded ticket granting ticket) to 2507 this server. The client is free to 2508 ignore the value of this flag. When 2509 setting this flag, an administrator 2510 should consider the Security and 2511 placement of the server on which the 2512 service will run, as well as whether 2513 the service requires the use of 2514 delegated credentials. 2516 This flag indicates that the principal 2517 named in the ticket is a generic 2518 principal for the realm and does not 2519 identify the individual using the 2520 ticket. The purpose of the ticket is 2521 only to securely distribute a session 2522 14 anonymous key, and not to identify the user. 2523 Subsequent requests using the same 2524 ticket and session may be considered 2525 as originating from the same user, but 2526 requests with the same username but a 2527 different ticket are likely to 2528 originate from different users. 2530 15-31 reserved Reserved for future use. 2531 key 2532 This field exists in the ticket and the KDC response and is used to 2533 pass the session key from Kerberos to the application server and the 2534 client. The field's encoding is described in section 6.2. 2535 crealm 2536 This field contains the name of the realm in which the client is 2537 registered and in which initial authentication took place. 2538 cname 2539 This field contains the name part of the client's principal identifier. 2540 transited 2541 This field lists the names of the Kerberos realms that took part in 2542 authenticating the user to whom this ticket was issued. It does not 2543 specify the order in which the realms were transited. See section 2544 3.3.3.2 for details on how this field encodes the traversed realms. 2545 When the names of CA's are to be embedded in the transited field (as 2546 specified for some extensions to the protocol), the X.500 names of the 2547 CA's should be mapped into items in the transited field using the 2548 mapping defined by RFC2253. 2549 authtime 2550 This field indicates the time of initial authentication for the named 2551 principal. It is the time of issue for the original ticket on which 2552 this ticket is based. It is included in the ticket to provide 2553 additional information to the end service, and to provide the necessary 2554 information for implementation of a `hot list' service at the KDC. An 2555 end service that is particularly paranoid could refuse to accept 2556 tickets for which the initial authentication occurred "too far" in the 2557 past. This field is also returned as part of the response from the KDC. 2558 When returned as part of the response to initial authentication 2559 (KRB_AS_REP), this is the current time on the Kerberos server[24]. 2560 starttime 2561 This field in the ticket specifies the time after which the ticket is 2562 valid. Together with endtime, this field specifies the life of the 2563 ticket. If it is absent from the ticket, its value should be treated as 2564 that of the authtime field. 2565 endtime 2566 This field contains the time after which the ticket will not be honored 2567 (its expiration time). Note that individual services may place their 2568 own limits on the life of a ticket and may reject tickets which have 2569 not yet expired. As such, this is really an upper bound on the 2570 expiration time for the ticket. 2572 renew-till 2573 This field is only present in tickets that have the RENEWABLE flag set 2574 in the flags field. It indicates the maximum endtime that may be 2575 included in a renewal. It can be thought of as the absolute expiration 2576 time for the ticket, including all renewals. 2577 caddr 2578 This field in a ticket contains zero (if omitted) or more (if present) 2579 host addresses. These are the addresses from which the ticket can be 2580 used. If there are no addresses, the ticket can be used from any 2581 location. The decision by the KDC to issue or by the end server to 2582 accept zero-address tickets is a policy decision and is left to the 2583 Kerberos and end-service administrators; they may refuse to issue or 2584 accept such tickets. The suggested and default policy, however, is that 2585 such tickets will only be issued or accepted when additional 2586 information that can be used to restrict the use of the ticket is 2587 included in the authorization_data field. Such a ticket is a 2588 capability. 2590 Network addresses are included in the ticket to make it harder for an 2591 attacker to use stolen credentials. Because the session key is not sent 2592 over the network in cleartext, credentials can't be stolen simply by 2593 listening to the network; an attacker has to gain access to the session 2594 key (perhaps through operating system security breaches or a careless 2595 user's unattended session) to make use of stolen tickets. 2597 It is important to note that the network address from which a 2598 connection is received cannot be reliably determined. Even if it could 2599 be, an attacker who has compromised the client's workstation could use 2600 the credentials from there. Including the network addresses only makes 2601 it more difficult, not impossible, for an attacker to walk off with 2602 stolen credentials and then use them from a "safe" location. 2604 authorization-data 2605 The authorization-data field is used to pass authorization data from 2606 the principal on whose behalf a ticket was issued to the application 2607 service. If no authorization data is included, this field will be left 2608 out. Experience has shown that the name of this field is confusing, and 2609 that a better name for this field would be restrictions. Unfortunately, 2610 it is not possible to change the name of this field at this time. 2612 This field contains restrictions on any authority obtained on the basis 2613 of authentication using the ticket. It is possible for any principal in 2614 posession of credentials to add entries to the authorization data field 2615 since these entries further restrict what can be done with the ticket. 2616 Such additions can be made by specifying the additional entries when a 2617 new ticket is obtained during the TGS exchange, or they may be added 2618 during chained delegation using the authorization data field of the 2619 authenticator. 2621 Because entries may be added to this field by the holder of 2622 credentials, except when an entry is separately authenticated by 2623 encapsulation in the kdc-issued element, it is not allowable for the 2624 presence of an entry in the authorization data field of a ticket to 2625 amplify the privileges one would obtain from using a ticket. 2627 The data in this field may be specific to the end service; the field 2628 will contain the names of service specific objects, and the rights to 2629 those objects. The format for this field is described in section 5.2. 2631 Although Kerberos is not concerned with the format of the contents of 2632 the sub-fields, it does carry type information (ad-type). 2634 By using the authorization_data field, a principal is able to issue a 2635 proxy that is valid for a specific purpose. For example, a client 2636 wishing to print a file can obtain a file server proxy to be passed to 2637 the print server. By specifying the name of the file in the 2638 authorization_data field, the file server knows that the print server 2639 can only use the client's rights when accessing the particular file to 2640 be printed. 2642 A separate service providing authorization or certifying group 2643 membership may be built using the authorization-data field. In this 2644 case, the entity granting authorization (not the authorized entity), 2645 may obtain a ticket in its own name (e.g. the ticket is issued in the 2646 name of a privilege server), and this entity adds restrictions on its 2647 own authority and delegates the restricted authority through a proxy to 2648 the client. The client would then present this authorization credential 2649 to the application server separately from the authentication exchange. 2650 Alternatively, such authorization credentials may be embedded in the 2651 ticket authenticating the authorized entity, when the authorization is 2652 separately authenticated using the kdc-issued authorization data 2653 element (see B.4). 2655 Similarly, if one specifies the authorization-data field of a proxy and 2656 leaves the host addresses blank, the resulting ticket and session key 2657 can be treated as a capability. See [Neu93] for some suggested uses of 2658 this field. 2660 The authorization-data field is optional and does not have to be 2661 included in a ticket. 2663 5.3.2. Authenticators 2665 An authenticator is a record sent with a ticket to a server to certify the 2666 client's knowledge of the encryption key in the ticket, to help the server 2667 detect replays, and to help choose a "true session key" to use with the 2668 particular session. The encoding is encrypted in the ticket's session key 2669 shared by the client and the server: 2671 -- Unencrypted authenticator 2672 Authenticator ::= [APPLICATION 2] SEQUENCE { 2673 authenticator-vno[0] INTEGER, 2674 crealm[1] Realm, 2675 cname[2] PrincipalName, 2676 cksum[3] Checksum OPTIONAL, 2677 cusec[4] Microseconds, 2678 ctime[5] KerberosTime, 2679 subkey[6] EncryptionKey OPTIONAL, 2680 seq-number[7] UInt32 OPTIONAL, 2681 authorization-data[8] AuthorizationData OPTIONAL 2682 } 2684 authenticator-vno 2685 This field specifies the version number for the format of the 2686 authenticator. This document specifies version 5. 2688 crealm and cname 2689 These fields are the same as those described for the ticket in section 2690 5.3.1. 2691 cksum 2692 This field contains a checksum of the the application data that 2693 accompanies the KRB_AP_REQ. 2694 cusec 2695 This field contains the microsecond part of the client's timestamp. Its 2696 value (before encryption) ranges from 0 to 999999. It often appears 2697 along with ctime. The two fields are used together to specify a 2698 reasonably accurate timestamp. 2699 ctime 2700 This field contains the current time on the client's host. 2701 subkey 2702 This field contains the client's choice for an encryption key which is 2703 to be used to protect this specific application session. Unless an 2704 application specifies otherwise, if this field is left out the session 2705 key from the ticket will be used. 2706 seq-number 2707 This optional field includes the initial sequence number to be used by 2708 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 2709 detect replays (It may also be used by application specific messages). 2710 When included in the authenticator this field specifies the initial 2711 sequence number for messages from the client to the server. When 2712 included in the AP-REP message, the initial sequence number is that for 2713 messages from the server to the client. When used in KRB_PRIV or 2714 KRB_SAFE messages, it is incremented by one after each message is sent. 2715 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to 2716 zero following the value 2^32 - 1. 2718 For sequence numbers to adequately support the detection of replays 2719 they should be non-repeating, even across connection boundaries. The 2720 initial sequence number should be random and uniformly distributed 2721 across the full space of possible sequence numbers, so that it cannot 2722 be guessed by an attacker and so that it and the successive sequence 2723 numbers do not repeat other sequences. 2725 authorization-data 2726 This field is the same as described for the ticket in section 5.3.1. It 2727 is optional and will only appear when additional restrictions are to be 2728 placed on the use of a ticket, beyond those carried in the ticket 2729 itself. 2731 5.4. Specifications for the AS and TGS exchanges 2733 This section specifies the format of the messages used in the exchange 2734 between the client and the Kerberos server. The format of possible error 2735 messages appears in section 5.9.1. 2737 5.4.1. KRB_KDC_REQ definition 2739 The KRB_KDC_REQ message has no type of its own. Instead, its type is one of 2740 KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial 2741 ticket or an additional ticket. In either case, the message is sent from the 2742 client to the Authentication Server to request credentials for a service. 2744 The message fields are: 2746 AS-REQ ::= [APPLICATION 10] KDC-REQ 2747 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2749 KDC-REQ ::= SEQUENCE { 2750 pvno[1] INTEGER, 2751 msg-type[2] INTEGER, 2752 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2753 req-body[4] KDC-REQ-BODY 2754 } 2756 KDC-REQ-BODY ::= SEQUENCE { 2757 kdc-options[0] KDCOptions, 2758 cname[1] PrincipalName OPTIONAL, 2759 -- Used only in AS-REQ 2760 realm[2] Realm, -- Server's realm 2761 -- Also client's in AS-REQ 2762 sname[3] PrincipalName OPTIONAL, 2763 from[4] KerberosTime OPTIONAL, 2764 till[5] KerberosTime, 2765 rtime[6] KerberosTime OPTIONAL, 2766 nonce[7] INTEGER, 2767 etype[8] SEQUENCE OF Int32, 2768 -- EncryptionType, 2769 -- in preference order 2770 addresses[9] HostAddresses OPTIONAL, 2771 enc-authorization-data[10] EncryptedData OPTIONAL, 2772 -- Encrypted AuthorizationData 2773 -- encoding 2774 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2775 } 2777 KDCOptions ::= KerberosFlags 2778 -- reserved(0), 2779 -- forwardable(1), 2780 -- forwarded(2), 2781 -- proxiable(3), 2782 -- proxy(4), 2783 -- allow-postdate(5), 2784 -- postdated(6), 2785 -- unused7(7), 2786 -- renewable(8), 2787 -- unused9(9), 2788 -- unused10(10), 2789 -- unused11(11), 2790 -- unused12(12), 2791 -- unused13(13), 2792 -- requestanonymous(14), 2793 -- canonicalize(15), 2794 -- disable-transited-check(26), 2795 -- renewable-ok(27), 2796 -- enc-tkt-in-skey(28), 2797 -- renew(30), 2798 -- validate(31) 2799 The fields in this message are: 2801 pvno 2802 This field is included in each message, and specifies the protocol 2803 version number. This document specifies protocol version 5. 2804 msg-type 2805 This field indicates the type of a protocol message. It will almost 2806 always be the same as the application identifier associated with a 2807 message. It is included to make the identifier more readily accessible 2808 to the application. For the KDC-REQ message, this type will be 2809 KRB_AS_REQ or KRB_TGS_REQ. 2810 padata 2811 Contains pre-authentication data. Requests for additional tickets 2812 (KRB_TGS_REQ) must contain a padata of PA-TGS-REQ. 2814 The padata (pre-authentication data) field contains a sequence of 2815 authentication information which may be needed before credentials can 2816 be issued or decrypted. In most requests for initial authentication 2817 (KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left 2818 out. 2820 req-body 2821 This field is a placeholder delimiting the extent of the remaining 2822 fields. If a checksum is to be calculated over the request, it is 2823 calculated over an encoding of the KDC-REQ-BODY sequence which is 2824 enclosed within the req-body field. 2825 kdc-options 2826 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2827 KDC and indicates the flags that the client wants set on the tickets as 2828 well as other information that is to modify the behavior of the KDC. 2829 Where appropriate, the name of an option may be the same as the flag 2830 that is set by that option. Although in most case, the bit in the 2831 options field will be the same as that in the flags field, this is not 2832 guaranteed, so it is not acceptable to simply copy the options field to 2833 the flags field. There are various checks that must be made before 2834 honoring an option anyway. 2836 The kdc_options field is a bit-field, where the selected options are 2837 indicated by the bit being set (1), and the unselected options and 2838 reserved fields being reset (0). The encoding of the bits is specified 2839 in section 5.2. The options are described in more detail above in 2840 section 2. The meanings of the options are: 2841 Bits Name Description 2843 0 RESERVED Reserved for future expansion of 2844 this field. 2846 The FORWARDABLE option indicates 2847 that the ticket to be issued is to 2848 have its forwardable flag set. It 2849 1 FORWARDABLE may only be set on the initial 2850 request, or in a subsequent request 2851 if the ticket-granting ticket on 2852 which it is based is also 2853 forwardable. 2855 The FORWARDED option is only 2856 specified in a request to the 2857 ticket-granting server and will only 2858 be honored if the ticket-granting 2859 ticket in the request has its 2860 2 FORWARDED FORWARDABLE bit set. This option 2861 indicates that this is a request for 2862 forwarding. The address(es) of the 2863 host from which the resulting ticket 2864 is to be valid are included in the 2865 addresses field of the request. 2867 The PROXIABLE option indicates that 2868 the ticket to be issued is to have 2869 its proxiable flag set. It may only 2870 3 PROXIABLE be set on the initial request, or in 2871 a subsequent request if the 2872 ticket-granting ticket on which it 2873 is based is also proxiable. 2875 The PROXY option indicates that this 2876 is a request for a proxy. This 2877 option will only be honored if the 2878 ticket-granting ticket in the 2879 4 PROXY request has its PROXIABLE bit set. 2880 The address(es) of the host from 2881 which the resulting ticket is to be 2882 valid are included in the addresses 2883 field of the request. 2885 The ALLOW-POSTDATE option indicates 2886 that the ticket to be issued is to 2887 have its MAY-POSTDATE flag set. It 2888 5 ALLOW-POSTDATE may only be set on the initial 2889 request, or in a subsequent request 2890 if the ticket-granting ticket on 2891 which it is based also has its 2892 MAY-POSTDATE flag set. 2894 The POSTDATED option indicates that 2895 this is a request for a postdated 2896 ticket. This option will only be 2897 honored if the ticket-granting 2898 ticket on which it is based has its 2899 6 POSTDATED MAY-POSTDATE flag set. The resulting 2900 ticket will also have its INVALID 2901 flag set, and that flag may be reset 2902 by a subsequent request to the KDC 2903 after the starttime in the ticket 2904 has been reached. 2906 7 UNUSED This option is presently unused. 2908 The RENEWABLE option indicates that 2909 the ticket to be issued is to have 2910 its RENEWABLE flag set. It may only 2911 be set on the initial request, or 2912 when the ticket-granting ticket on 2913 8 RENEWABLE which the request is based is also 2914 renewable. If this option is 2915 requested, then the rtime field in 2916 the request contains the desired 2917 absolute expiration time for the 2918 ticket. 2920 9 RESERVED Reserved for PK-Cross 2922 10-13 UNUSED These options are presently unused. 2924 The REQUEST-ANONYMOUS option 2925 indicates that the ticket to be 2926 issued is not to identify the user 2927 to which it was issued. Instead, the 2928 principal identifier is to be 2929 generic, as specified by the policy 2930 of the realm (e.g. usually 2931 14 REQUEST-ANONYMOUS anonymous@realm). The purpose of the 2932 ticket is only to securely 2933 distribute a session key, and not to 2934 identify the user. The ANONYMOUS 2935 flag on the ticket to be returned 2936 should be set. If the local realms 2937 policy does not permit anonymous 2938 credentials, the request is to be 2939 rejected. 2941 The CANONICALIZE option indicates 2942 that the client will accept the 2943 return of a true server name instead 2944 of the name specified in the 2945 request. In addition the client will 2946 be able to process any TGT referrals 2947 that will direct the client to 2948 15 CANONICALIZE another realm to locate the 2949 requested server. If a KDC does not 2950 support name- canonicalization, the 2951 option is ignored and the 2952 appropriate 2953 KDC_ERR_C_PRINCIPAL_UNKNOWN or 2954 KDC_ERR_S_PRINCIPAL_UNKNOWN error is 2955 returned. [JBrezak] 2957 16-25 RESERVED Reserved for future use. 2959 By default the KDC will check the 2960 transited field of a 2961 ticket-granting-ticket against the 2962 policy of the local realm before it 2963 will issue derivative tickets based 2964 on the ticket granting ticket. If 2965 this flag is set in the request, 2966 checking of the transited field is 2967 26 DISABLE-TRANSITED-CHECK disabled. Tickets issued without the 2968 performance of this check will be 2969 noted by the reset (0) value of the 2970 TRANSITED-POLICY-CHECKED flag, 2971 indicating to the application server 2972 that the tranisted field must be 2973 checked locally. KDC's are 2974 encouraged but not required to honor 2975 the DISABLE-TRANSITED-CHECK option. 2977 The RENEWABLE-OK option indicates 2978 that a renewable ticket will be 2979 acceptable if a ticket with the 2980 requested life cannot otherwise be 2981 provided. If a ticket with the 2982 requested life cannot be provided, 2983 27 RENEWABLE-OK then a renewable ticket may be 2984 issued with a renew-till equal to 2985 the the requested endtime. The value 2986 of the renew-till field may still be 2987 limited by local limits, or limits 2988 selected by the individual principal 2989 or server. 2991 This option is used only by the 2992 ticket-granting service. The 2993 ENC-TKT-IN-SKEY option indicates 2994 28 ENC-TKT-IN-SKEY that the ticket for the end server 2995 is to be encrypted in the session 2996 key from the additional 2997 ticket-granting ticket provided. 2999 29 RESERVED Reserved for future use. 3001 This option is used only by the 3002 ticket-granting service. The RENEW 3003 option indicates that the present 3004 request is for a renewal. The ticket 3005 provided is encrypted in the secret 3006 key for the server on which it is 3007 30 RENEW valid. This option will only be 3008 honored if the ticket to be renewed 3009 has its RENEWABLE flag set and if 3010 the time in its renew-till field has 3011 not passed. The ticket to be renewed 3012 is passed in the padata field as 3013 part of the authentication header. 3015 This option is used only by the 3016 ticket-granting service. The 3017 VALIDATE option indicates that the 3018 request is to validate a postdated 3019 ticket. It will only be honored if 3020 the ticket presented is postdated, 3021 presently has its INVALID flag set, 3022 31 VALIDATE and would be otherwise usable at 3023 this time. A ticket cannot be 3024 validated before its starttime. The 3025 ticket presented for validation is 3026 encrypted in the key of the server 3027 for which it is valid and is passed 3028 in the padata field as part of the 3029 authentication header. 3031 cname and sname 3032 These fields are the same as those described for the ticket in section 3033 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is 3034 specified. If absent, the name of the server is taken from the name of 3035 the client in the ticket passed as additional-tickets. 3036 enc-authorization-data 3037 The enc-authorization-data, if present (and it can only be present in 3038 the TGS_REQ form), is an encoding of the desired authorization-data 3039 encrypted under the sub-session key if present in the Authenticator, or 3040 alternatively from the session key in the ticket-granting ticket, both 3041 from the padata field in the KRB_AP_REQ. 3042 realm 3043 This field specifies the realm part of the server's principal 3044 identifier. In the AS exchange, this is also the realm part of the 3045 client's principal identifier. If the CANONICALIZE option is set, the 3046 realm is used as a hint to the KDC for its database lookup. 3047 from 3048 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3049 requests when the requested ticket is to be postdated. It specifies the 3050 desired start time for the requested ticket. If this field is omitted 3051 then the KDC should use the current time instead. 3052 till 3053 This field contains the expiration date requested by the client in a 3054 ticket request. [XXX This was optional in kerberos-revisions, but 3055 required in 1510. we should make it required and specify semantics for 3056 19700101000000Z] It is optional and if omitted the requested ticket is 3057 to have the maximum endtime permitted according to KDC policy for the 3058 parties to the authentication exchange as limited by expiration date of 3059 the ticket granting ticket or other preauthentication credentials. 3060 rtime 3061 This field is the requested renew-till time sent from a client to the 3062 KDC in a ticket request. It is optional. 3063 nonce 3064 This field is part of the KDC request and response. It it intended to 3065 hold a random number generated by the client. If the same number is 3066 included in the encrypted response from the KDC, it provides evidence 3067 that the response is fresh and has not been replayed by an attacker. 3068 Nonces must never be re-used. Ideally, it should be generated randomly, 3069 but if the correct time is known, it may suffice[25]. 3070 etype 3071 This field specifies the desired encryption algorithm to be used in the 3072 response. 3074 addresses 3075 This field is included in the initial request for tickets, and 3076 optionally included in requests for additional tickets from the 3077 ticket-granting server. It specifies the addresses from which the 3078 requested ticket is to be valid. Normally it includes the addresses for 3079 the client's host. If a proxy is requested, this field will contain 3080 other addresses. The contents of this field are usually copied by the 3081 KDC into the caddr field of the resulting ticket. 3082 additional-tickets 3083 Additional tickets may be optionally included in a request to the 3084 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 3085 specified, then the session key from the additional ticket will be used 3086 in place of the server's key to encrypt the new ticket. When the 3087 ENC-TKT-IN-SKEY option is used for user-to-user authentication, this 3088 addional ticket may be a TGT issued by the local realm or an 3089 inter-realm TGT issued for the current KDC's realm by a remote KDC. If 3090 more than one option which requires additional tickets has been 3091 specified, then the additional tickets are used in the order specified 3092 by the ordering of the options bits (see kdc-options, above). 3094 The application tag number will be either ten (10) or twelve (12) depending 3095 on whether the request is for an initial ticket (AS-REQ) or for an 3096 additional ticket (TGS-REQ). 3098 The optional fields (addresses, authorization-data and additional-tickets) 3099 are only included if necessary to perform the operation specified in the 3100 kdc-options field. 3102 It should be noted that in KRB_TGS_REQ, the protocol version number appears 3103 twice and two different message types appear: the KRB_TGS_REQ message 3104 contains these fields as does the authentication header (KRB_AP_REQ) that is 3105 passed in the padata field. 3107 5.4.2. KRB_KDC_REP definition 3109 The KRB_KDC_REP message format is used for the reply from the KDC for either 3110 an initial (AS) request or a subsequent (TGS) request. There is no message 3111 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 3112 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 3113 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 3114 the client's secret key, and the client's key version number is included in 3115 the key version number for the encrypted data. For KRB_TGS_REP, the 3116 ciphertext is encrypted in the sub-session key from the Authenticator, or if 3117 absent, the session key from the ticket-granting ticket used in the request. 3118 In that case, no version number will be present in the EncryptedData 3119 sequence. 3121 The KRB_KDC_REP message contains the following fields: 3123 AS-REP ::= [APPLICATION 11] KDC-REP 3124 TGS-REP ::= [APPLICATION 13] KDC-REP 3126 KDC-REP ::= SEQUENCE { 3127 pvno[0] INTEGER, 3128 msg-type[1] INTEGER, 3129 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 3130 crealm[3] Realm, 3131 cname[4] PrincipalName, 3132 ticket[5] Ticket, 3133 enc-part[6] EncryptedData 3134 -- EncASREpPart or EncTGSReoOart 3135 } 3137 KDC-REP2 ::= SEQUENCE { 3138 pvno[0] INTEGER, 3139 msg-type[1] INTEGER, 3140 kdc-rep2-clear[2] KDC-REP2-CLEAR, 3141 cksum[3] Checksum -- computed over kdc-rep2-clear 3142 } 3144 KDC-REP2-CLEAR ::= SEQUENCE { 3145 padata[0] SEQUENCE OF PA-DATA OPTIONAL, 3146 crealm[1] Realm, 3147 cname[2] PrincipalName, 3148 ticket[3] Ticket, 3149 enc-part[4] EncryptedData 3150 } 3152 AS-REP2 ::= [APPLICATION 8] KDC-REP2 3153 TGS-REP2 ::= [APPLICATION 9] KDC-REP2 3155 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart -- note [27] 3156 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 3158 EncKDCRepPart ::= SEQUENCE { 3159 key[0] EncryptionKey, 3160 last-req[1] LastReq, 3161 nonce[2] INTEGER, 3162 key-expiration[3] KerberosTime OPTIONAL, 3163 flags[4] TicketFlags, 3164 authtime[5] KerberosTime, 3165 starttime[6] KerberosTime OPTIONAL, 3166 endtime[7] KerberosTime, 3167 renew-till[8] KerberosTime OPTIONAL, 3168 srealm[9] Realm, 3169 sname[10] PrincipalName, 3170 caddr[11] HostAddresses OPTIONAL 3171 } 3172 LastReq ::= SEQUENCE OF SEQUENCE { 3173 lr-type[0] Int32, 3174 lr-value[1] KerberosTime 3175 } 3176 pvno and msg-type 3177 These fields are described above in section 5.4.1. msg-type is either 3178 KRB_AS_REP or KRB_TGS_REP. 3179 padata 3180 This field is described in detail in section 5.4.1. One possible use 3181 for this field is to encode an alternate "mix-in" string to be used 3182 with a string-to-key algorithm (such as is described in section 6.3.2). 3183 This ability is useful to ease transitions if a realm name needs to 3184 change (e.g. when a company is acquired); in such a case all existing 3185 password-derived entries in the KDC database would be flagged as 3186 needing a special mix-in string until the next password change. 3187 crealm, cname, srealm and sname 3188 These fields are the same as those described for the ticket in section 3189 5.3.1. 3190 ticket 3191 The newly-issued ticket, from section 5.3.1. 3192 enc-part 3193 This field is a place holder for the ciphertext and related information 3194 that forms the encrypted part of a message. The description of the 3195 encrypted part of the message follows each appearance of this field. 3196 The encrypted part is encoded as described in section 6.1. 3197 key 3198 This field is the same as described for the ticket in section 5.3.1. 3199 last-req 3200 This field is returned by the KDC and specifies the time(s) of the last 3201 request by a principal. Depending on what information is available, 3202 this might be the last time that a request for a ticket-granting ticket 3203 was made, or the last time that a request based on a ticket-granting 3204 ticket was successful. It also might cover all servers for a realm, or 3205 just the particular server. Some implementations may display this 3206 information to the user to aid in discovering unauthorized use of one's 3207 identity. It is similar in spirit to the last login time displayed when 3208 logging into timesharing systems. 3209 lr-type 3210 This field indicates how the following lr-value field is to be 3211 interpreted. Negative values indicate that the information 3212 pertains only to the responding server. Non-negative values 3213 pertain to all servers for the realm. 3215 If the lr-type field is zero (0), then no information is conveyed 3216 by the lr-value subfield. If the absolute value of the lr-type 3217 field is one (1), then the lr-value subfield is the time of last 3218 initial request for a TGT. If it is two (2), then the lr-value 3219 subfield is the time of last initial request. If it is three (3), 3220 then the lr-value subfield is the time of issue for the newest 3221 ticket-granting ticket used. If it is four (4), then the lr-value 3222 subfield is the time of the last renewal. If it is five (5), then 3223 the lr-value subfield is the time of last request (of any type). 3224 If it is (6), then the lr-value subfield is the time when the 3225 password will expire. 3227 lr-value 3228 This field contains the time of the last request. the time must be 3229 interpreted according to the contents of the accompanying lr-type 3230 subfield. 3231 nonce 3232 This field is described above in section 5.4.1. 3234 key-expiration 3235 The key-expiration field is part of the response from the KDC and 3236 specifies the time that the client's secret key is due to expire. The 3237 expiration might be the result of password aging or an account 3238 expiration. This field will usually be left out of the TGS reply since 3239 the response to the TGS request is encrypted in a session key and no 3240 client information need be retrieved from the KDC database. It is up to 3241 the application client (usually the login program) to take appropriate 3242 action (such as notifying the user) if the expiration time is imminent. 3243 flags, authtime, starttime, endtime, renew-till and caddr 3244 These fields are duplicates of those found in the encrypted portion of 3245 the attached ticket (see section 5.3.1), provided so the client may 3246 verify they match the intended request and to assist in proper ticket 3247 caching. If the message is of type KRB_TGS_REP, the caddr field will 3248 only be filled in if the request was for a proxy or forwarded ticket, 3249 or if the user is substituting a subset of the addresses from the 3250 ticket granting ticket. If the client-requested addresses are not 3251 present or not used, then the addresses contained in the ticket will be 3252 the same as those included in the ticket-granting ticket. 3254 5.5. Client/Server (CS) message specifications 3256 This section specifies the format of the messages used for the 3257 authentication of the client to the application server. 3259 5.5.1. KRB_AP_REQ definition 3261 The KRB_AP_REQ message contains the Kerberos protocol version number, the 3262 message type KRB_AP_REQ, an options field to indicate any options in use, 3263 and the ticket and authenticator themselves. The KRB_AP_REQ message is often 3264 referred to as the 'authentication header'. 3266 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3267 pvno[0] INTEGER, 3268 msg-type[1] INTEGER, 3269 ap-options[2] APOptions, 3270 ticket[3] Ticket, 3271 authenticator[4] EncryptedData 3272 -- Authenticator from 5.3.2 3273 } 3275 APOptions ::= KerberosFlags 3276 -- reserved(0), 3277 -- use-session-key(1), 3278 -- mutual-required(2) 3280 pvno and msg-type 3281 These fields are described above in section 5.4.1. msg-type is 3282 KRB_AP_REQ. 3284 ap-options 3285 This field appears in the application request (KRB_AP_REQ) and affects 3286 the way the request is processed. It is a bit-field, where the selected 3287 options are indicated by the bit being set (1), and the unselected 3288 options and reserved fields being reset (0). The encoding of the bits 3289 is specified in section 5.2. The meanings of the options are: 3290 Bit(s) Name Description 3292 0 reserved Reserved for future expansion of this 3293 field. 3295 The USE-SESSION-KEY option indicates that 3296 the ticket the client is presenting to a 3297 1 use-session-key server is encrypted in the session key from 3298 the server's ticket-granting ticket. When 3299 this option is not specified, the ticket is 3300 encrypted in the server's secret key. 3302 The MUTUAL-REQUIRED option tells the server 3303 2 mutual-required that the client requires mutual 3304 authentication, and that it must respond 3305 with a KRB_AP_REP message. 3307 3-31 reserved Reserved for future use. 3308 ticket 3309 This field is a ticket authenticating the client to the server. 3310 authenticator 3311 This contains the authenticator, which includes the client's choice of 3312 a subkey. Its encoding is described in section 5.3.2. 3314 5.5.2. KRB_AP_REP definition 3316 The KRB_AP_REP message contains the Kerberos protocol version number, the 3317 message type, and an encrypted time- stamp. The message is sent in in 3318 response to an application request (KRB_AP_REQ) where the mutual 3319 authentication option has been selected in the ap-options field. 3321 AP-REP ::= [APPLICATION 15] SEQUENCE { 3322 pvno[0] INTEGER, 3323 msg-type[1] INTEGER, 3324 enc-part[2] EncryptedData 3325 -- EncAPRepPart 3326 } 3328 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { -- note [29] 3329 ctime[0] KerberosTime, 3330 cusec[1] Microseconds, 3331 subkey[2] EncryptionKey OPTIONAL, 3332 seq-number[3] UInt32 OPTIONAL 3333 } 3335 The encoded EncAPRepPart is encrypted in the shared session key of the 3336 ticket. The optional subkey field can be used in an application-arranged 3337 negotiation to choose a per association session key. 3339 pvno and msg-type 3340 These fields are described above in section 5.4.1. msg-type is 3341 KRB_AP_REP. 3343 enc-part 3344 This field is described above in section 5.4.2. 3345 ctime 3346 This field contains the current time on the client's host. 3347 cusec 3348 This field contains the microsecond part of the client's timestamp. 3349 subkey 3350 This field contains an encryption key which is to be used to protect 3351 this specific application session. See section 3.2.6 for specifics on 3352 how this field is used to negotiate a key. Unless an application 3353 specifies otherwise, if this field is left out, the sub-session key 3354 from the authenticator, or if also left out, the session key from the 3355 ticket will be used. 3356 seq-number 3357 This field is described above in section 5.3.2. 3359 5.5.3. Error message reply 3361 If an error occurs while processing the application request, the KRB_ERROR 3362 message will be sent in response. See section 5.9.1 for the format of the 3363 error message. The cname and crealm fields may be left out if the server 3364 cannot determine their appropriate values from the corresponding KRB_AP_REQ 3365 message. If the authenticator was decipherable, the ctime and cusec fields 3366 will contain the values from it. 3368 5.6. KRB_SAFE message specification 3370 This section specifies the format of a message that can be used by either 3371 side (client or server) of an application to send a tamper-proof message to 3372 its peer. It presumes that a session key has previously been exchanged (for 3373 example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3375 There are two KRB_SAFE messages; the KRB-SAFE message is the one specified 3376 in RFC 1510. The KRB-SAFE2 message is new with this document, and shares a 3377 number of fields with the old KRB-SAFE message. 3379 5.6.1. KRB_SAFE definition 3381 The KRB_SAFE message contains user data along with a collision-proof 3382 checksum keyed with the last encryption key negotiated via subkeys, or the 3383 session key if no negotiation has occurred. The message fields are: 3385 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3386 pvno[0] INTEGER, 3387 msg-type[1] INTEGER, 3388 safe-body[2] KRB-SAFE-BODY, 3389 cksum[3] Checksum 3390 } 3392 KRB-SAFE-BODY ::= SEQUENCE { 3393 user-data[0] OCTET STRING, 3394 timestamp[1] KerberosTime OPTIONAL, 3395 usec[2] Microseconds OPTIONAL, 3396 seq-number[3] UInt32 OPTIONAL, 3397 s-address[4] HostAddress, 3398 r-address[5] HostAddress OPTIONAL 3399 } 3400 KRB-SAFE2 ::= [APPLICATION 18] SEQUENCE { 3401 pvno[0] INTEGER, 3402 msg-type[1] INTEGER, 3403 safe-body[2] KRB-SAFE2-BODY, 3404 cksum[3] Checksum, 3405 ... 3406 } 3408 KRB-SAFE2-BODY ::= SEQUENCE { 3409 id[0] KRB-SAFE2-BODY-ID, 3410 user-data[1] OCTET STRING OPTIONAL, 3411 ... 3412 } 3414 KRB-SAFE2-BODY-ID ::= SEQUENCE { 3415 timestamp[1] KerberosTime OPTIONAL, 3416 usec[2] Microseconds OPTIONAL, 3417 seq-number[3] UInt32 OPTIONAL, 3418 s-address[4] HostAddress OPTIONAL, 3419 r-address[5] HostAddress OPTIONAL, 3420 direction[6] Direction OPTIONAL, 3421 ... 3422 } 3424 pvno and msg-type 3425 These fields are described above in section 5.4.1. msg-type is KRB_SAFE 3426 or KRB_SAFE2, respectively, for the KRB-SAFE and KRB-SAFE2 messages. 3427 safe-body 3428 This field is a placeholder for the body of the KRB-SAFE message. 3429 cksum 3430 This field contains the checksum of the application data. Checksum 3431 details are described in section 6.4. 3433 For KRB-SAFE only, the checksum is computed over the encoding of the 3434 KRB-SAFE sequence. First, the cksum is set to a type zero, zero-length 3435 value and the checksum is computed over the encoding of the KRB-SAFE 3436 sequence, then the checksum is set to the result of that computation, 3437 and finally the KRB-SAFE sequence is encoded again. This method, while 3438 different than the one specified in RFC 1510, corresponds to existing 3439 practice. 3441 For KRB-SAFE2, the checksum is computed over the encoding of safe-body 3442 only. The encoded safe-body may have the user-data field omitted during 3443 transmission, but the encoding used for the checksum must contain the 3444 user-data field. This method permits the use of a KRB-SAFE2 message as 3445 a MIC token in a GSSAPI context. 3447 user-data 3448 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 3449 the application specific data that is being passed from the sender to 3450 the recipient. 3451 timestamp 3452 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 3453 are the current time as known by the sender of the message. By checking 3454 the timestamp, the recipient of the message is able to make sure that 3455 it was recently generated, and is not a replay. 3457 usec 3458 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 3459 the microsecond part of the timestamp. 3460 seq-number 3461 This field is described above in section 5.3.2. 3462 s-address 3463 This field is required in KRB-SAFE but optional in KRB-SAFE2. 3465 This field specifies the address in use by the sender of the message. 3466 It may be omitted if not required by the application protocol. The 3467 application designer considering omission of this field is warned, that 3468 the inclusion of this address prevents some kinds of replay attacks 3469 (e.g., reflection attacks) and that it is only acceptable to omit this 3470 address if there is sufficient information in the integrity protected 3471 part of the application message for the recipient to unambiguously 3472 determine if it was the intended recipient. 3474 r-address 3475 This field specifies the address in use by the recipient of the 3476 message. It may be omitted for some uses (such as broadcast protocols), 3477 but the recipient may arbitrarily reject such messages. This field 3478 along with s-address can be used to help detect messages which have 3479 been incorrectly or maliciously delivered to the wrong recipient. 3481 5.7. KRB_PRIV message specification 3483 This section specifies the format of a message that can be used by either 3484 side (client or server) of an application to securely and privately send a 3485 message to its peer. It presumes that a session key has previously been 3486 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3488 5.7.1. KRB_PRIV definition 3490 The KRB_PRIV message contains user data encrypted in the Session Key. The 3491 message fields are: 3493 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3494 pvno[0] INTEGER, 3495 msg-type[1] INTEGER, 3496 enc-part[3] EncryptedData 3497 -- EncKrbPrivPart 3498 } 3500 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { --note [31] 3501 user-data[0] OCTET STRING, 3502 timestamp[1] KerberosTime OPTIONAL, 3503 usec[2] Microseconds OPTIONAL, 3504 seq-number[3] UInt32 OPTIONAL, 3505 s-address[4] HostAddress, -- sender's addr 3506 r-address[5] HostAddress OPTIONAL -- recip's addr 3507 } 3509 KRB-PRIV2 ::= [APPLICATION 19] SEQUENCE { 3510 pvno[0] INTEGER, 3511 msg-type[1] INTEGER, 3512 enc-part[3] EncryptedData, 3513 -- EncKrbPrivPart2 3514 ... 3515 } 3516 EncKrbPrivPart2 ::= [APPLICATION 24] SEQUENCE { 3517 user-data[0] OCTET STRING, 3518 timestamp[1] KerberosTime OPTIONAL, 3519 usec[2] Microseconds OPTIONAL, 3520 seq-number[3] UInt32 OPTIONAL, 3521 s-address[4] HostAddress OPTIONAL, -- sender's addr 3522 r-address[5] HostAddress OPTIONAL, -- recip's addr 3523 direction[6] Direction OPTIONAL, 3524 ... 3525 } 3527 pvno and msg-type 3528 These fields are described above in section 5.4.1. msg-type is 3529 KRB_PRIV. 3530 enc-part 3531 This field holds an encoding of the EncKrbPrivPart sequence encrypted 3532 under the session key[32]. This encrypted encoding is used for the 3533 enc-part field of the KRB-PRIV message. See section 6 for the format of 3534 the ciphertext. 3535 user-data, timestamp, usec, s-address and r-address 3536 These fields are described above in section 5.6.1. 3537 seq-number 3538 This field is described above in section 5.3.2. 3540 5.8. KRB_CRED message specification 3542 This section specifies the format of a message that can be used to send 3543 Kerberos credentials from one principal to another. It is presented here to 3544 encourage a common mechanism to be used by applications when forwarding 3545 tickets or providing proxies to subordinate servers. It presumes that a 3546 session key has already been exchanged perhaps by using the 3547 KRB_AP_REQ/KRB_AP_REP messages. 3549 5.8.1. KRB_CRED definition 3551 The KRB_CRED message contains a sequence of tickets to be sent and 3552 information needed to use the tickets, including the session key from each. 3553 The information needed to use the tickets is encrypted under an encryption 3554 key previously exchanged or transferred alongside the KRB_CRED message. The 3555 message fields are: 3557 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3558 pvno[0] INTEGER, 3559 msg-type[1] INTEGER, -- KRB_CRED 3560 tickets[2] SEQUENCE OF Ticket, 3561 enc-part[3] EncryptedData -- EncKrbCredPart 3562 } 3564 KRB-CRED2 ::= [APPLICATION 17] SEQUENCE { 3565 pvno[0] INTEGER, 3566 msg-type[1] INTEGER, -- KRB_CRED2 3567 krb-cred2-clear[2] KRB-CRED2-CLEAR, 3568 cksum[3] Checksum, -- over krb-cred2-clear 3569 ... 3570 } 3571 KRB-CRED2-CLEAR ::= SEQUENCE { 3572 tickets[0] SEQUENCE OF Ticket, 3573 enc-part[1] EncryptedData, -- EncKrbCredPart 3574 ... 3575 } 3577 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3578 ticket-info[0] SEQUENCE OF KrbCredInfo, 3579 nonce[1] INTEGER OPTIONAL, 3580 timestamp[2] KerberosTime OPTIONAL, 3581 usec[3] Microseconds OPTIONAL, 3582 s-address[4] HostAddress OPTIONAL, 3583 r-address[5] HostAddress OPTIONAL 3584 } 3586 KrbCredInfo ::= SEQUENCE { 3587 key[0] EncryptionKey, 3588 prealm[1] Realm OPTIONAL, 3589 pname[2] PrincipalName OPTIONAL, 3590 flags[3] TicketFlags OPTIONAL, 3591 authtime[4] KerberosTime OPTIONAL, 3592 starttime[5] KerberosTime OPTIONAL, 3593 endtime[6] KerberosTime OPTIONAL 3594 renew-till[7] KerberosTime OPTIONAL, 3595 srealm[8] Realm OPTIONAL, 3596 sname[9] PrincipalName OPTIONAL, 3597 caddr[10] HostAddresses OPTIONAL 3598 } 3600 pvno and msg-type 3601 These fields are described above in section 5.4.1. msg-type is 3602 KRB_CRED. 3603 tickets 3604 These are the tickets obtained from the KDC specifically for use by the 3605 intended recipient. Successive tickets are paired with the 3606 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3607 message. 3608 enc-part 3609 This field holds an encoding of the EncKrbCredPart sequence encrypted 3610 under the session key shared between the sender and the intended 3611 recipient. This encrypted encoding is used for the enc-part field of 3612 the KRB-CRED message. See section 6 for the format of the ciphertext. 3613 nonce 3614 If practical, an application may require the inclusion of a nonce 3615 generated by the recipient of the message. If the same value is 3616 included as the nonce in the message, it provides evidence that the 3617 message is fresh and has not been replayed by an attacker. A nonce must 3618 never be re-used; it should be generated randomly by the recipient of 3619 the message and provided to the sender of the message in an application 3620 specific manner. 3621 timestamp and usec 3622 These fields specify the time that the KRB-CRED message was generated. 3623 The time is used to provide assurance that the message is fresh. 3624 s-address and r-address 3625 These fields are described above in section 5.6.1. They are used 3626 optionally to provide additional assurance of the integrity of the 3627 KRB-CRED message. 3629 key 3630 This field exists in the corresponding ticket passed by the KRB-CRED 3631 message and is used to pass the session key from the sender to the 3632 intended recipient. The field's encoding is described in section 6.2. 3634 The following fields are optional. If present, they can be associated with 3635 the credentials in the remote ticket file. If left out, then it is assumed 3636 that the recipient of the credentials already knows their value. 3638 prealm and pname 3639 The name and realm of the delegated principal identity. 3640 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3641 These fields contain the values of the corresponding fields from the 3642 ticket found in the ticket field. Descriptions of the fields are 3643 identical to the descriptions in the KDC-REP message. 3645 5.9. TGT-REQ 3647 The TGT-REQ message may be used by a user-to-user client to request the 3648 ticket-granting-ticket from a server that it is communicating with. The 3649 application server will then usually respond with its ticket-granting ticket 3651 TGT-REQ ::= [APPLICATION 16] SEQUENCE { 3652 pvno [0] INTEGER, 3653 msg-type [1] INTEGER, 3654 sname [2] PrincipalName OPTIONAL, 3655 srealm [3] Realm OPTIONAL 3656 } 3658 pvno and msg-type 3659 The protocol version number and message type. msg-type is 16 for this 3660 message. 3661 sname and srealm 3662 The server's principal name and realm name. The actual ticket expected 3663 to be returned would be have its client principal be sname, its client 3664 realm be srealm, and its server principal and realm correspond to the a 3665 ticket-granting service. These fields are named sname and srealm 3666 because they correspond to the user-to-user client's concept of what 3667 the server principal is. 3669 5.10. Error message specification 3671 This section specifies the format for the KRB_ERROR message. The fields 3672 included in the message are intended to return as much information as 3673 possible about an error. It is not expected that all the information 3674 required by the fields will be available for all types of errors. If the 3675 appropriate information is not available when the message is composed, the 3676 corresponding field will be left out of the message. 3678 Note that since the KRB_ERROR message is only optionally integrity 3679 protected, it is quite possible for an intruder to synthesize or modify such 3680 a message. In particular, this means that unless appropriate integrity 3681 protection mechanisms have been applied to the KRB_ERROR message, the client 3682 should not use any fields in this message for security-critical purposes, 3683 such as setting a system clock or generating a fresh authenticator. The 3684 message can be useful, however, for advising a user on the reason for some 3685 failure. 3687 5.10.1. KRB_ERROR definition 3689 The KRB_ERROR message consists of the following fields: 3691 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3692 pvno[0] INTEGER, 3693 msg-type[1] INTEGER, 3694 ctime[2] KerberosTime OPTIONAL, 3695 cusec[3] Microseconds OPTIONAL, 3696 stime[4] KerberosTime, 3697 susec[5] Microseconds, 3698 error-code[6] Int32, 3699 crealm[7] Realm OPTIONAL, 3700 cname[8] PrincipalName OPTIONAL, 3701 realm[9] Realm, -- Correct realm 3702 sname[10] PrincipalName, -- Correct name 3703 e-text[11] KerberosString OPTIONAL, 3704 e-data[12] OCTET STRING OPTIONAL 3705 } 3707 KRB-ERROR2 ::= [APPLICATION 23] SEQUENCE { 3708 pvno[0] INTEGER, 3709 msg-type[1] INTEGER, 3710 krb-error2-clear[2] KRB-ERROR2-CLEAR, 3711 cksum[3] Checksum -- over krb-error2-clear 3712 } 3714 KRB-ERROR2-CLEAR ::= SEQUENCE { 3715 ctime[0] KerberosTime OPTIONAL, 3716 cusec[1] Microseconds OPTIONAL, 3717 stime[2] KerberosTime, 3718 susec[3] Microseconds, 3719 error-code[4] Int32, 3720 crealm[5] Realm OPTIONAL, 3721 cname[6] PrincipalName OPTIONAL, 3722 realm[7] Realm, -- Correct realm 3723 sname[8] PrincipalName, -- Correct name 3724 e-text[9] KerberosString OPTIONAL, 3725 e-data[10] OCTET STRING OPTIONAL 3726 } 3728 pvno and msg-type 3729 These fields are described above in section 5.4.1. msg-type is 3730 KRB_ERROR. 3731 ctime 3732 This field is described above in section 5.4.1. 3733 cusec 3734 This field is described above in section 5.5.2. 3735 stime 3736 This field contains the current time on the server. It is of type 3737 KerberosTime. 3738 susec 3739 This field contains the microsecond part of the server's timestamp. Its 3740 value ranges from 0 to 999999. It appears along with stime. The two 3741 fields are used in conjunction to specify a reasonably accurate 3742 timestamp. 3744 error-code 3745 This field contains the error code returned by Kerberos or the server 3746 when a request fails. To interpret the value of this field see the list 3747 of error codes in section 8. Implementations are encouraged to provide 3748 for national language support in the display of error messages. 3749 crealm, cname, srealm and sname 3750 These fields are described above in section 5.3.1. 3751 e-text 3752 This field contains additional text to help explain the error code 3753 associated with the failed request (for example, it might include a 3754 principal name which was unknown). 3755 e-data 3756 This field contains additional data about the error for use by the 3757 application to help it recover from or handle the error. If present, 3758 this field will contain the encoding of a sequence of TypedData 3759 (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, 3760 in which case it will contain the encoding of a sequence of of padata 3761 fields (METHOD-DATA below), each corresponding to an acceptable 3762 pre-authentication method and optionally containing data for the 3763 method: 3765 TYPED-DATA ::= SEQUENCE of TypedData 3766 METHOD-DATA ::= SEQUENCE of PA-DATA 3768 TypedData ::= SEQUENCE { 3769 data-type[0] Int32, 3770 data-value[1] OCTET STRING OPTIONAL 3771 } 3773 Note that the padata-type field in the PA-DATA structure and the 3774 data-type field in the TypedData structure share a common range of 3775 allocated values which are coordinated to avoid conflicts. One Kerberos 3776 error message, KDC_ERR_PREAUTH_REQUIRED, embeds elements of type 3777 PA-DATA, while all other error messages embed TypedData. 3779 While preauthentication methods of type PA-DATA should be encapsulated 3780 within a TypedData element of type TD-PADATA, for compatibility with 3781 old clients, the KDC should include PA-DATA types below 22 directly as 3782 method-data. All new implementations interpreting the METHOD-DATA field 3783 for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of 3784 TD-PADATA, extract the typed data field and interpret the use any 3785 elements encapsulated in the TD-PADATA elements as if they were present 3786 in the METHOD-DATA sequence. 3788 Unless otherwise specified, unrecognized TypedData elements within the 3789 KRB-ERROR message MAY be ignored by implementations that do not support 3790 them. Note that all TypedData MAY be bound to the KRB-ERROR message via 3791 the checksum field. 3793 An application may use the TD-APP-DEFINED-ERROR typed data type for 3794 data carried in a Kerberos error message that is specific to the 3795 application. TD-APP-SPECIFIC must set the data-type value of TypedData 3796 to TD-APP-SPECIFIC and the data-value field to 3797 AppSpecificTypedData as follows: 3798 AppSpecificTypedData ::= SEQUENCE { 3799 oid[0] OPTIONAL OBJECT IDENTIFIER, 3800 -- identifies the application 3801 data-value[1] OCTET STRING 3802 -- application 3803 -- specific data 3804 } 3806 o The TD-REQ-NONCE TypedData MAY be used to bind a KRB-ERROR to a 3807 KDC-REQ. The data-value is an INTEGER that is equivalent to the 3808 nonce in a KDC-REQ. 3810 o The TD-REQ-SEQ TypedData MAY be used for binding a KRB-ERROR to 3811 the sequence number from an authenticator. The data-value is an 3812 INTEGER, and it is identical to sequence number sent in the 3813 authenticator. 3815 o The data-value for TD-KRB-PRINCIPAL is the Kerberos-defined 3816 PrincipalName. The data-value for TD-KRB-REALM is the 3817 Kerberos-defined Realm. These TypedData types MAY be used to 3818 indicate principal and realm name when appropriate. 3819 e-cksum 3820 This field contains an optional checksum for the KRB-ERROR message. The 3821 checksum is calculated over the Kerberos ASN.1 encoding of the 3822 KRB-ERROR message with the checksum absent. The checksum is then added 3823 to the KRB-ERROR structure and the message is re-encoded. The Checksum 3824 should be calculated using the session key from the ticket granting 3825 ticket or service ticket, where available. If the error is in response 3826 to a TGS or AP request, the checksum should be calculated using the the 3827 session key from the client's ticket. If the error is in response to an 3828 AS request, then the checksum should be calulated using the client's 3829 secret key ONLY if there has been suitable preauthentication to prove 3830 knowledge of the secret key by the client[33]. If a checksum can not be 3831 computed because the key to be used is not available, no checksum will 3832 be included. 3834 5.11. Application Tag Numbers 3836 The following table lists the application class tag numbers used by various 3837 data types defined in this section. 3838 Tag Number(s) Type Name Comments 3840 0 unused 3841 1 Ticket 3842 2 Authenticator 3843 3 EncTicketPart 3844 4 Ticket2 new in this revision 3845 5-7 unused 3846 8 AS-REP2 new in this revision 3847 9 TGS-REP2 new in this revision 3848 10 AS-REQ 3849 11 AS-REP 3850 12 TGS-REQ 3851 13 TGS-REP 3852 14 AP-REQ 3853 15 AP-REP 3854 16 TGT-REQ 3855 17 KRB-CRED2 new in this revision 3856 18 KRB-SAFE2 new in this revision 3857 19 KRB-PRIV2 new in this revision 3858 20 KRB-SAFE 3859 21 KRB-PRIV 3860 22 KRB-PRIV 3861 23 KRB-ERROR2 new in this revision 3862 24 EncKrbPrivPart2 new in this revision 3863 25 EncASRepPart 3864 26 EncTGSRepPart 3865 27 EncApRepPart 3866 28 EncKrbPrivPart 3867 29 EncKrbCredPart 3868 30 KRB-ERROR 3869 6. Encryption and Checksum Specifications 3871 The Kerberos protocols described in this document are designed to use stream 3872 encryption ciphers, which can be simulated using commonly available block 3873 encryption ciphers, such as the Data Encryption Standard [DES77], and triple 3874 DES variants, in conjunction with block chaining and checksum methods 3875 [DESM80]. Encryption is used to prove the identities of the network entities 3876 participating in message exchanges. The Key Distribution Center for each 3877 realm is trusted by all principals registered in that realm to store a 3878 secret key in confidence. Proof of knowledge of this secret key is used to 3879 verify the authenticity of a principal. 3881 The KDC uses the principal's secret key (in the AS exchange) or a shared 3882 session key (in the TGS exchange) to encrypt responses to ticket requests; 3883 the ability to obtain the secret key or session key implies the knowledge of 3884 the appropriate keys and the identity of the KDC. The ability of a principal 3885 to decrypt the KDC response and present a Ticket and a properly formed 3886 Authenticator (generated with the session key from the KDC response) to a 3887 service verifies the identity of the principal; likewise the ability of the 3888 service to extract the session key from the Ticket and prove its knowledge 3889 thereof in a response verifies the identity of the service. 3891 The Kerberos protocols generally assume that the encryption used is secure 3892 from cryptanalysis; however, in some cases, the order of fields in the 3893 encrypted portions of messages are arranged to minimize the effects of 3894 poorly chosen keys. It is still important to choose good keys. If keys are 3895 derived from user-typed passwords, those passwords need to be well chosen to 3896 make brute force attacks more difficult. Poorly chosen keys still make easy 3897 targets for intruders. 3899 A checksum algorithm must provide proof of the integrity of the associated 3900 message, and must preserve the confidentiality of the message in case it is 3901 not sent in the clear. It should be infeasible to find two plaintexts which 3902 have the same checksum. It is NOT required that an eavesdropper be unable to 3903 determine if two checksums are for the same message; it is assumed that the 3904 messages themselves will be visible to any such eavesdropper. 3906 The following sections specify the encryption and checksum mechanisms 3907 currently defined for Kerberos, as well as a framework for defining future 3908 mechanisms. The encodings, chaining, padding and other requirements for each 3909 are described. 3911 6.1. Concepts 3913 Both encryption and checksum mechanism are defined in terms of profiles, 3914 detailed in later sections. Each specifies a collection of operations and 3915 attributes that must be defined for a mechanism. A Kerberos encryption or 3916 checksum mechanism is not complete if it does not specify all of these 3917 operations and attributes. 3919 An encryption mechanism must provide for confidentiality and integrity of 3920 the original plaintext. (Integrity checking may be achieved by incorporating 3921 a checksum, if the encryption mode does not provide an integrity check 3922 itself.) It must also provide non-malleability [Bellare98, Dolev91]. Use of 3923 a random confounder prepended to the plaintext is recommended. It should not 3924 be possible to determine if two ciphertexts correspond to the same 3925 plaintext, without knowledge of the key. A checksum mechanism must provide 3926 for verification of a message's integrity, and must preserve the 3927 confidentiality of the original message. It should also be resistant to 3928 collisions; even given the key, it must be infeasible to find two plaintexts 3929 that produce the same checksum. 3931 Due to advances in cryptography, it is considered unwise by some 3932 cryptographers to use the same key for multiple purposes [@@ref??]. Since 3933 keys are used in performing a number of different functions in Kerberos, it 3934 is desirable to use different keys for each of these purposes, even though 3935 we start with a single long-term or session key. 3937 We do this by enumerating the different uses of keys within Kerberos, and 3938 making the "usage number" an input to the encryption or checksum mechanisms. 3939 Later sections define simplified profile templates for encryption and 3940 checksum mechanisms that use a key derivation function applied to a CBC mode 3941 (or similar) cipher and a checksum or hash algorithm. 3943 We distinguish the "base key" used in the EncryptedKey object from the 3944 "specific key" to be used for a particular instance of encryption or 3945 checksum operations. It is expected but not required that the specific key 3946 will be one or more separate keys derived from the original protocol key and 3947 the key usage number. The specific key is not explicitly referenced outside 3948 of section 6 in this document; when other sections mention encrypting or 3949 decrypting data with a given key, that key is the "base key", and the 3950 "specific key" generation and use is implicit. 3952 Key Usage Values 3954 This is a list of key usage number definitions and reserved ranges, 3955 including values for all places keys are used in the Kerberos protocol and 3956 associated section numbers. 3958 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 3959 client key (section 5.4.1) 3960 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or 3961 application session key), encrypted with the service key 3962 (section 5.4.2) 3963 3. AS-REP encrypted part (includes tgs session key or application 3964 session key), encrypted with the client key (section 5.4.2) 3965 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 3966 session key (section 5.4.1) 3967 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 3968 authenticator subkey (section 5.4.1) 3969 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed with 3970 the tgs session key (sections 5.3.2, 5.4.1) 3971 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs 3972 authenticator subkey), encrypted with the tgs session key 3973 (section 5.3.2) 3974 8. TGS-REP encrypted part (includes application session key), 3975 encrypted with the tgs session key (section 5.4.2) 3976 9. TGS-REP encrypted part (includes application session key), 3977 encrypted with the tgs authenticator subkey (section 5.4.2) 3978 10. AP-REQ Authenticator cksum, keyed with the application session 3979 key (section 5.3.2) 3980 11. AP-REQ Authenticator (includes application authenticator 3981 subkey), encrypted with the application session key (section 3982 5.3.2) 3983 12. AP-REP encrypted part (includes application session subkey), 3984 encrypted with the application session key (section 5.5.2) 3985 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 3986 application (section 5.7.1) 3987 14. KRB-CRED encrypted part, encrypted with a key chosen by the 3988 application (section 5.6.1) 3989 15. KRB-SAVE cksum, keyed with a key chosen by the application 3990 (section 5.8.1) 3991 18. KRB-ERROR checksum (e-cksum in section 5.9.1) 3992 19. AD-KDCIssued checksum (ad-checksum in appendix B.4) 3993 20. Checksum for Mandatory Ticket Extensions (appendix B.6) 3994 21. Checksum in Authorization Data in Ticket Extensions (appendix 3995 B.7) 3996 22-24. Reserved for use in GSSAPI mechanisms derived from RFC 1964. 3997 (raeburn/MIT) 3998 512-1023. Reserved for uses internal to a Kerberos implementation. For 3999 example, a pseudo-random number generator may be seeded with 4000 output from data encrypted or hashed using these usage numbers, 4001 to protect the original key from any accidental weakness in the 4002 PRNG. 4004 A few of these key usages need a little clarification. A service which 4005 receives an AP-REQ has no way to know if the enclosed Ticket was part of an 4006 AS-REP or TGS-REP. Therefore, key usage 2 must always be used for generating 4007 a Ticket, whether it is in response to an AS-REQ or TGS-REQ. 4009 Key usage values between 1024 and 2047 (inclusive) are reserved for 4010 application use. Applications should use even values for encryption and odd 4011 values for checksums within this range. 4013 There might exist other documents which define protocols in terms of the 4014 RFC1510 encryption types or checksum types. Such documents would not know 4015 about key usages. In order that these documents continue to be meaningful 4016 until they are updated, key usages 1024 and 1025 must be used to derive keys 4017 for encryption and checksums, respectively. New protocols defined in terms 4018 of the Kerberos encryption and checksum types should use their own key 4019 usages. Key usages may be registered with IANA to avoid conflicts. Key 4020 usages must be unsigned 32 bit integers. Zero is not permitted. 4022 6.2. Encryption mechanism attributes 4024 An encryption mechanism profile must define the following attributes and 4025 operations: 4027 protocol key format 4028 This describes what OCTET STRING values represent valid keys. For 4029 encryption mechanisms that don't have perfectly dense key spaces, this 4030 will describe the representation used for encoding keys. It need not 4031 describe specific values that are not valid or desirable for use; such 4032 values should be avoid by all key generation routines. 4033 specific key structure 4034 This is not a protocol format at all, but a description of the keying 4035 material derived from the chosen key and used to encrypt or decrypt 4036 data or compute or verify a checksum. It may be a single key, a set of 4037 keys, or a combination of the original key with additional data. The 4038 authors recommend using one or more keys derived from the original key 4039 via one-way functions. 4040 required checksum mechanism 4041 This indicates a checksum mechanism that must be available when this 4042 encryption mechanism is used. Since Kerberos has no built in mechanism 4043 for negotiating checksum mechanisms, once an encryption mechanism has 4044 been decided upon, the corresponding checksum mechanism can simply be 4045 used. 4046 key-generation seed length, K 4047 This is the length of the random bitstring needed to generate a key 4048 with the encryption scheme's random-to-key function (described below). 4049 This must be a fixed value so that various techniques for producing a 4050 random bitstring of a given length may be used with key generation 4051 functions. 4052 key generation functions 4053 Keys must be generated in a number of cases, from different types of 4054 inputs. All function specifications must indicate how to generate keys 4055 in the proper wire format, and must avoid generation of "weak" keys if 4056 the cryptosystem has such. Entropy from each source should be preserved 4057 as much as possible. Many of the inputs, while unknown, may be at least 4058 partly predictable (e.g., a password string is likely to be entirely in 4059 the ASCII subset and of fairly short length in many environments; a 4060 semi-random string may include timestamps); the benefit of such 4061 predictability to an attacker must be minimized. 4063 string-to-key (UTF8String, UTF8String, integer)->(protocol-key) 4064 This function generates a key from two UTF-8 strings and an 4065 integer. One of the strings is normally the principal's password, 4066 but is in general merely a secret string. The other string is a 4067 "salt" intended to produce different keys from the same password 4068 for different users or realms. The integer is known for historical 4069 reasons as the "salt type", but may be used for selection between 4070 multiple string-to-key algorithms. The salt string and type may be 4071 altered by preauth data from the KDC; in the default case, the 4072 salt string is simply a concatenation of the principal's realm and 4073 name components, with no separators, and the salt type is zero. 4075 This should be a one-way function, so that compromising a user's 4076 key in one realm does not compromise the user's key in another 4077 realm, even if the same password (but a different salt string) is 4078 used. 4080 random-to-key (bitstring[K])->(protocol-key) 4081 This function generates a key from a random bit string of a 4082 specific size. It may be assumed that all the bits of the input 4083 string are equally random, even though the entropy present in the 4084 random source may be limited. 4085 combine-keys (protocol-key, protocol-key)->(protocol-key) 4086 This function takes two input keys and produces a new key. This 4087 function is not used in this RFC, but may be used by 4088 preauthentication methods or other applications to be defined 4089 later. This operation must be commutative; this requirement lets 4090 us specify "combine keys A and B" in other documents without 4091 worrying about ordering. 4092 key-derivation (protocol-key, bytestring)->(specific-key) 4093 In this function, the byte string input is based on the key usage 4094 values specified above; the usage values must be assumed to be 4095 known to an attacker. For cryptosystems with dense key spaces, 4096 this function should be the key derivation function outlined in 4097 section 6.1. 4098 cipher state 4099 initial cipher state (specific-key)->(state) 4100 This describes any initial state setup needed before encrypting 4101 arbitrary amounts of data with a given specific key; the specific key 4102 should be the only input needed for this initialization. For example, a 4103 block cipher used in CBC mode must specify an initial vector. (For 4104 security reasons, the key itself should not be used as the IVEC.) This 4105 data may be carried over from one encryption or decryption operation to 4106 another. Unless otherwise specified, however, each encryption or 4107 decryption operation in this RFC uses a freshly initialized state and 4108 is thus independent of all other encryptions and decryptions. 4109 encrypt (specific-key, state, bytestring)->(state, bytestring) 4110 This function takes the specific key, cipher state, and plaintext as 4111 input, and generates ciphertext and a new cipher state as outputs. If 4112 the basic encryption algorithm itself does not provide for integrity 4113 protection (as DES in CBC mode does not do), then some form of MAC or 4114 checksum must be included that can be verified by the receiver. Some 4115 random factor such as a confounder should be included so that an 4116 observer cannot know if two messages contain the same plaintext, even 4117 if the cipher state and specific keys are the same. The exact length of 4118 the plaintext need not be encoded, but if it is not and if padding is 4119 required, the padding must be added at the end of the string so that 4120 the decrypted version may be parsed from the beginning. 4122 The output will be used as the OCTET STRING in the EncryptedData type, 4123 defined in section 5.1. 4125 decrypt (specific-key, state, bytestring)->(state, bytestring) 4126 This function takes the specific key, cipher state, and ciphertext as 4127 inputs, and verifies the integrity of the supplied ciphertext. If the 4128 ciphertext's integrity is intact, this function produces the plaintext 4129 and a new cipher state as outputs; otherwise, an error indication must 4130 be returned, and the data discarded. 4132 This function's byte string input is the OCTET STRING from the 4133 EncryptedData type, defined in section 5.1. 4135 The result of the decryption may be longer than the original plaintext, 4136 if the encryption mode requires padding to a multiple of a block size. 4137 If this is the case, any extra padding will be after the decoded 4138 plaintext. An application protocol which needs to know the exact length 4139 of the message must encode a length or recognizable "end of message" 4140 marker within the plaintext. 4142 These operations and attributes are all that should be required to support 4143 Kerberos and various proposed preauthentication schemes. 4145 The reader is reminded that cryptography is a complex and growing field, and 4146 proof of the security of an algorithm is often difficult, even for those 4147 with extensive training in the field. Merely making an algorithm complicated 4148 is more likely to make it hard to analyze than it is to make it secure. This 4149 should be kept in mind when defining functions for new cryptosystems; simple 4150 applications of existing, trusted algorithms are more likely to be secure 4151 than a complicated home-grown scheme. 4153 6.3. Checksum attributes 4155 A checksum mechanism profile must define the following attributes and 4156 operations: 4158 associated encryption algorithm(s) 4159 This essentially indicates the type of encryption key this checksum 4160 mechanism can be used with. A single checksum mechanism may have more 4161 than one associated encryption algorithm if they share the same wire 4162 key format, string-to-key function, and key derivation function. (This 4163 combination means that, for example, a checksum type and password are 4164 adequate to get the specific key used to compute a checksum.) 4165 get_mic function 4166 This function generates a MIC token for a given specific key (see 4167 section 6.2), and message (represented as an octet string), that may be 4168 used to verify the integrity of the associated message. This function 4169 is not required to return the same deterministic result on every use; 4170 it need only generate a token that the verify_mic routine can check. 4172 The output of this function will also dictate the size of the checksum. 4173 It must be a fixed size. 4175 verify_mic function 4176 Given a specific key, message, and MIC, this function ascertains 4177 whether the message integrity has been compromised. For a deterministic 4178 get_mic routine, the corresponding verify_mic may simply generate 4179 another checksum and compare them. 4181 The get_mic and verify_mic operations must be able to handle inputs of 4182 arbitrary length; if any padding is needed, the padding scheme must be 4183 specified as part of these functions. 4185 These operations and attributes are all that should be required to support 4186 Kerberos and various proposed preauthentication schemes. 4188 6.4. A simplified profile for cryptosystems using CBC-mode and similar block 4189 ciphers and standard key derivation 4191 The profile outlines in section 6.2 and 6.3 describes a large number of 4192 operations that must be defined for encryption and checksum algorithms to be 4193 used with Kerberos. We describe here a simpler profile from which both 4194 encryption and checksum mechanism definitions can be generated, filling in 4195 uses of key derivation in appropriate places, providing integrity 4196 protection, and defining multiple operations for the cryptosystem profile 4197 based on a smaller set of operations given in the simplified profile. Not 4198 all of the existing cryptosystems for Kerberos fit into this simplified 4199 profile, but we recommend that future cryptosystems use it or something 4200 based on it. 4202 Not all of the operations in the complete profiles are defined through this 4203 mechanism; several must still be defined for each new algorithm pair. 4205 A key derivation function [Horowitz] 4207 Rather than define some scheme by which a "protocol key" is composed of a 4208 large number of encryption keys, we use keys derived from a base key to 4209 perform cryptographic operations. The base key must be used only for 4210 generating the derived keys, and this derivation must be non-invertible and 4211 entropy-preserving. Given these restrictions, compromise of one derived key 4212 does not compromise the other subkeys. Attack of the base key is limited, 4213 since it is only used for derivation, and is not exposed to any user data. 4215 Since the derived key has as much entropy as the base keys (if the 4216 cryptosystem is good), password-derived keys have the full benefit of all 4217 the entropy in the password. 4219 To generate a derived key from a base key, we generate a pseudorandom byte 4220 string, using an algorithm DR described below, and generate a key from that 4221 byte string using a function dependent on the encryption algorithm; the 4222 input length needed for that function, which is also dependent on the 4223 encryption algorithm, dictates the length of the string to be generated by 4224 the DR algorithm (the value "k" below). 4226 Derived Key = DK(Base Key, Well-Known Constant) 4228 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 4230 DR(Key, Constant) = k-truncate(E(Key, Constant)) 4232 Here DR is the random-byte generation function described below, and DK is 4233 the key-derivation function produced from it. In this construction, E(Key, 4234 Plaintext) is a block cipher, Constant is a well-known constant determined 4235 by the specific usage of this function, and k-truncate truncates its 4236 argument by taking the first k bits. Here, k is the key generation seed 4237 length needed for the encryption system. 4239 The output of the DR function is a string of bits; the actual key is 4240 produced by applying the cryptosystem's random-to-key operation on this 4241 bitstring. 4243 If the output of E is shorter than k bits, then some entropy in the key will 4244 be lost. If the Constant is smaller than the block size of E, then it must 4245 be padded so it may be encrypted. 4247 In either of these situations, a variation of the above construction is 4248 used, where the folded Constant is encrypted, and the resulting output is 4249 fed back into the encryption as necessary (the | indicates concatentation): 4251 K1 = E(Key, n-fold(Constant)) 4252 K2 = E(Key, K1) 4253 K3 = E(Key, K2) 4254 K4 = ... 4256 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 4258 n-fold is an algorithm which takes m input bits and ``stretches'' them to 4259 form n output bits with equal contribution from each input bit to the 4260 output, as described in [Blumenthal96]. In this document, n-fold is always 4261 used to produce n bits of output, where n is the block size of E. 4263 We first define a primitive called n-folding, which takes a 4264 variable-length input block and produces a fixed-length output 4265 sequence. The intent is to give each input bit approximately equal 4266 weight in determining the value of each output bit. Note that 4267 whenever we need to treat a string of bytes as a number, the 4268 assumed representation is Big-Endian -- Most Significant Byte 4269 first. 4271 To n-fold a number X, replicate the input value to a length that 4272 is the least common multiple of n and the length of X. Before each 4273 repetition, the input is rotated to the right by 13 bit positions. 4274 The successive n-bit chunks are added together using 4275 1's-complement addition (that is, with end-around carry) to yield 4276 a n-bit result.... 4278 It should be noted that the sample vector in Appendix B.2 of the original 4279 paper appears to be incorrect. Two independent implementations from the 4280 specification (one in C by Marc Horowitz, and another in Scheme by Bill 4281 Sommerfeld) agree on a value different from that in [Blumenthal96]. See 4282 Appendix @@TESTVECTORS for test vectors. 4284 The size of the Constant must not be larger than the block size of E, 4285 because chaining affects the distribution of entropy, and reducing the 4286 length of the Constant by n-folding can cause collisions. 4288 If the size of the Constant is smaller than the block size of E, then the 4289 Constant must be n-folded to the block size of E. This string is used as 4290 input to E. If the block size of E is less than the key size, then the 4291 output from E is taken as input to a second invocation of E. This process is 4292 repeated until the number of bits accumulated is greater than or equal to 4293 the key size of E. When enough bits have been computed, the first k are 4294 taken as the derived key. 4296 Since the derived key is the result of one or more encryptions in the base 4297 key, deriving the base key from the derived key is equivalent to determining 4298 the key from a very small number of plaintext/ciphertext pairs. Thus, this 4299 construction is as strong as the cryptosystem itself. 4301 6.4.1. Simplified profile 4303 These are the operations and attributes that must be defined: 4305 protocol key format 4306 string-to-key function 4307 key-generation seed length, k 4308 random-to-key function 4309 As above. 4310 unkeyed hash algorithm, H 4311 This should be a collision-resistant hash algorithm such as SHA-1, 4312 suitable for use in an HMAC. 4313 block size, n 4314 encryption/decryption functions, E and D 4315 These are basic encryption and decryption functions for messages of 4316 sizes that are multiples of the block size. No integrity checking or 4317 confounder should be included here. If the encryption function doesn't 4318 use CBC mode, it should be similar to CBC mode in that prepending a 4319 confounder to the plaintext should alter the entire ciphertext. They 4320 take as input the IV or similar data, a protocol-format key, and a byte 4321 string, returning a new IV and byte string. 4323 While there are still a number of properties to specify, they are fewer and 4324 simpler than in the full profile. 4326 6.4.2. Cryptosystem profile based on simplified profile 4328 protocol key As given. 4329 format 4330 specific key Three protocol-format keys: { Kc, Ke, Ki }. 4331 structure 4332 key-generation As given. 4333 seed length 4334 required The checksum mechanism defined by the simplified checksum 4335 checksum profile given later. 4336 mechanism 4337 cipher state Initial vector, initialized to all zero. 4338 encryption The ciphertext output is the concatenation of the output of 4339 function the basic encryption function E and an HMAC using the 4340 specified hash function H, both applied to the padded 4341 plaintext with a confounder: 4343 ciphertext = E(Ke, confounder | plaintext | padding) | 4344 HMAC(Ki, confounder | plaintext | padding) 4345 HMAC(K,M) = H(K | H(K | M)) 4347 One block of random confounder data is prepended to the 4348 plaintext, and padding added to the end to bring the length 4349 to a multiple of the encryption algorithm's block size. The 4350 initial vector for encryption is supplied by the cipher 4351 state, and the last block of the output of E is the new 4352 IVEC for the new cipher state. 4353 decryption Decryption is performed by extracting the encrypted portion 4354 function of the ciphertext, decrypting using key Ke from the 4355 specific key, and verifying the HMAC. If the HMAC is 4356 incorrect, an error must be reported. Otherwise, the 4357 confounder and padding are discarded and the remaining 4358 plaintext returned. As with encryption, the cipher state 4359 input indicates the IVEC to use, and the last block of the 4360 encrypted portion of the ciphertext is put into the new 4361 cipher state to be used as the next IVEC. 4362 key generation 4363 functions: 4364 string-to-key As given. 4365 function 4366 random-to-key As given. 4367 function 4368 combine-keys @@ Needs to be specified. How about: 4369 function 4370 combine-keys(K1,K2) 4371 /* First, protect original keys against exposure 4372 with DK. */ 4373 T1 = DK(K1, CombineConstant) 4374 T2 = DK(K2, CombineConstant) 4375 /* Now generate random bytes, using encryption under 4376 both keys. */ 4377 R1 = DR(T1, T2) /* length k */ 4378 R2 = DR(T2, T1) /* length k */ 4379 /* Using k-fold on length 2k means just add with 4380 wrap-around carry. */ 4381 key = random-to-key(k-fold(R1 | R2)) 4382 @@ This should be commutative, which keeps the 4383 specifications simpler, and I think should protect each 4384 key's contribution from exposure of the other key. Or 4385 should we just go with an XOR combination of the random 4386 bytes? (But that works poorly should the two keys happen to 4387 be the same due to sloppy or weird protocol specs, or 4388 parallel construction of contributed keys.) 4390 Here CombineConstant is the byte string {0x63 0x6f 0x6d 4391 0x62 0x69 0x6e 0x65} corresponding to the ASCII encoding of 4392 the string "combine". 4393 key-derivation Three keys are generated, using the DK function described 4394 function above, and the key usage number, represented as a 32-bit 4395 integer in big-endian byte order. One is used for 4396 generating checksums only; the other two are used for 4397 encrypting and integrity protection for ciphertext. These 4398 keys are generated as follows (with "|" indicating 4399 concatenation): 4401 Kc = DK(base-key, usage|0x99)); 4402 Ke = DK(base-key, usage|0xAA); 4403 Ki = DK(base-key, usage|0x55); 4405 6.4.3. Checksum profiles based on simplified profile 4407 When an encryption system is defined using the simplified profile given in 4408 section 6.4.1, a checksum algorithm may be defined for it as follows: 4410 associated cryptosystem as defined above 4411 get_mic HMAC(Kc, message) 4412 verify_mic get_mic and compare 4414 The HMAC function and key Kc are as described in section 6.4.2. 4416 6.5. Profiles for Kerberos encryption systems 4418 These are the currently defined encryption systems for Kerberos. The astute 4419 reader will notice that some of them do not fulfill all of the requirements 4420 outlined above. These weaker encryption systems are defined for backwards 4421 compatibility; newer implementations should attempt to make use of the 4422 stronger encryption systems when possible. 4424 6.5.1. null 4426 If no encryption is in use, the encryption system is said to be the NULL 4427 encryption system. In the NULL encryption system there is no checksum, 4428 confounder or padding. The ciphertext is simply the plaintext. The NULL Key 4429 is used by the null encryption system and is zero octets in length, with 4430 keytype zero (0). 4432 This encryption system should not be used for protection of data. It exists 4433 primarily to associate with the rsa-md5 checksum type, but may also be 4434 useful for testing protocol implementations. 4436 protocol key format zero-length bit string 4437 specific key structure empty 4438 required checksum mechanism rsa-md5 4439 key-generation seed length 0 4440 cipher state none 4441 initial cipher state none 4442 encryption function identity 4443 decryption function identity, no integrity check 4444 key generation functions: 4445 string-to-key empty string 4446 random-to-key empty string 4447 combine-keys empty string 4448 key-derivation empty string 4450 6.5.2. des-cbc-md5 4452 The des-cbc-md5 encryption mode encrypts information under the Data 4453 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 4454 An MD5 checksum (described in [MD5-92]) is applied to the confounder and 4455 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 4456 bytes. As a result, the data to be encrypted (the concatenation of 4457 confounder, checksum, and message) must be padded to an 8 byte boundary 4458 before encryption. 4460 Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are 4461 concatenated to make the 64-bit inputs for the DES algorithms. The first 4462 octet supplies the 8 most significant bits (with the octet's MSbit used as 4463 the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., 4464 and the eighth octet supplies the 8 least significant bits. 4466 Encryption under DES using cipher block chaining requires an additional 4467 input in the form of an initialization vector. Unless otherwise specified, 4468 zero should be used as the initialization vector. Kerberos' use of DES 4469 requires an 8 octet confounder. 4471 The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 4472 shall not be used for encrypting messages for use in Kerberos. Additionally, 4473 because of the way that keys are derived for the encryption of checksums, 4474 keys shall not be used that yield 'weak' or 'semi-weak' keys when 4475 eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0. 4477 A DES key is 8 octets of data, with keytype one (1). This consists of 56 4478 bits of key, and 8 parity bits (one per octet). The key is encoded as a 4479 series of 8 octets written in MSB-first order. The bits within the key are 4480 also encoded in MSB order. For example, if the encryption key is 4481 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where 4482 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity 4483 bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the 4484 MSbit). [See the FIPS 81 introduction for reference.] 4486 Encryption data format 4488 The format for the data to be encrypted includes a one-block confounder, a 4489 checksum, the encoded plaintext, and any necessary padding, as described in 4490 the following diagram. The msg-seq field contains the part of the protocol 4491 message described in section 5 which is to be encrypted. The confounder, 4492 checksum, and padding are all untagged and untyped. 4494 +-----------+----------+-------------+-----+ 4495 |confounder | check | msg-seq | pad | 4496 +-----------+----------+-------------+-----+ 4498 The format cannot be described in ASN.1, but for those who prefer an 4499 ASN.1-like notation: 4501 CipherText ::= ENCRYPTED SEQUENCE { 4502 confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL, 4503 -- [35] 4504 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 4505 msg-seq[2] MsgSequence, 4506 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 4507 } 4509 One generates a random confounder of one block, placing it in confounder; 4510 zeroes out check; calculates the appropriate checksum over confounder, 4511 check, and msg-seq, placing the result in check; adds the necessary padding; 4512 then encrypts using the specified encryption type and the appropriate key. 4514 String to key transformation 4516 To generate a DES key from a UTF-8 text string (password), a "salt" is 4517 concatenated to the text string, and then padded with ASCII nulls to an 8 4518 byte boundary. 4520 This string is then fan-folded and eXclusive-ORed with itself to form an 8 4521 byte DES key. Before eXclusive-ORing a block, every byte is shifted one bit 4522 to the left to leave the lowest bit zero. The key is the "corrected" by 4523 correcting the parity on the key, and if the key matches a 'weak' or 4524 'semi-weak' key as described in the DES specification, it is eXclusive-ORed 4525 with the constant 00000000000000F0. This key is then used to generate a DES 4526 CBC checksum on the initial string (with the salt appended). The result of 4527 the CBC checksum is the "corrected" as described above to form the result 4528 which is return as the key. 4530 Pseudocode follows: 4532 key_correction(key) { 4533 fixparity(key); 4534 if (is_weak_key_key(key)) 4535 key = key XOR 0xF0; 4536 return(key); 4537 } 4539 mit_des_string_to_key(string,salt) { 4540 odd = 1; 4541 s = string + salt; 4542 tempkey = NULL; 4543 pad(s); /* with nulls to 8 byte boundary */ 4544 for (8byteblock in s) { 4545 if (odd == 0) { 4546 odd = 1; 4547 reverse(8byteblock) 4548 } 4549 else odd = 0; 4550 left shift every byte in 8byteblock one bit; 4551 tempkey = tempkey XOR 8byteblock; 4552 } 4553 tempkey = key_correction(tempkey); 4554 key = key_correction(DES-CBC-check(s,tempkey)); 4555 return(key); 4556 } 4558 des_string_to_key(type,string,salt) { 4559 if (type == 0) 4560 mit_des_string_to_key(string,salt); 4561 else if (type == 1) 4562 afs_des_string_to_key(string,salt); 4563 } 4565 The encryption system parameters for des-cbc-md5 are: 4567 protocol key format 8 bytes, parity in low bit of each 4568 specific key structure copy of original key 4569 required checksum mechanism rsa-md5-des 4570 key-generation seed length 8 bytes 4571 cipher state 8 bytes (CBC initial vector) 4572 initial cipher state all-zero 4573 encryption function des-cbc(confounder | checksum | msg | pad) 4575 with checksum computed as described above 4576 decryption function decrypt encrypted text and verify checksum 4577 key generation functions: 4578 string-to-key des_string_to_key 4579 random-to-key fix parity bits 4580 combine-keys bitwise XOR, then fix parity bits 4581 key-derivation identity 4582 6.5.3. des-cbc-md4 4584 The des-cbc-md4 encryption mode encrypts information under the Data 4585 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 4586 An MD4 checksum (described in [MD492]) is applied to the confounder and 4587 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 4588 bytes. As a result, the data to be encrypted (the concatenation of 4589 confounder, checksum, and message) must be padded to an 8 byte boundary 4590 before encryption. The details of the encryption of this data are identical 4591 to those for the des-cbc-md5 encryption mode. 4593 protocol key format 8 bytes, parity in low bit of each 4594 specific key structure copy of original key 4595 required checksum mechanism rsa-md4-des 4596 key-generation seed length 8 bytes 4597 cipher state 8 bytes (CBC initial vector) 4598 initial cipher state all-zero 4599 encryption function des-cbc(confounder | checksum | msg | pad) 4601 with checksum computed as described above 4602 decryption function decrypt encrypted text and verify checksum 4603 key generation functions: 4604 string-to-key des_string_to_key 4605 random-to-key fix parity bits 4606 combine-keys bitwise XOR, then fix parity bits 4607 key-derivation identity 4609 6.5.4. des-cbc-crc 4611 The des-cbc-crc encryption mode encrypts information under the Data 4612 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A 4613 4-octet CRC-32 checksum (described in ISO 3309 [ISO3309]) is computed over 4614 the confounder and message sequence (msg-seq) and placed in the cksum field. 4615 DES blocks are 8 bytes. As a result, the data to be encrypted (the 4616 concatenation of confounder, checksum, and message) must be padded to an 8 4617 byte boundary before encryption. Unless otherwise specified, the key should 4618 be used as the initialization vector, unlike for the other Kerberos DES 4619 encryption schemes. The other details of the encryption of this data are 4620 identical to those for the des-cbc-md5 encryption mode. 4622 Note that, since the CRC-32 checksum is not collision-proof, an attacker 4623 could use a probabilistic chosen-plaintext attack to generate a valid 4624 message even if a confounder is used [SG92]. The use of collision-proof 4625 checksums is recommended for environments where such attacks represent a 4626 significant threat. The use of the CRC-32 as the checksum for ticket or 4627 authenticator is no longer mandated as an interoperability requirement for 4628 Kerberos Version 5 Specification 1 (See section 9.1 for specific details). 4630 protocol key format 8 bytes, parity in low bit of each 4631 specific key structure copy of original key 4632 required checksum mechanism rsa-md5-des 4633 key-generation seed length 8 bytes 4634 cipher state 8 bytes (CBC initial vector) 4635 initial cipher state copy of original key 4636 encryption function des-cbc(confounder | checksum | msg | pad) 4638 with checksum computed as described above 4639 decryption function decrypt encrypted text and verify checksum 4640 key generation functions: 4641 string-to-key des_string_to_key 4642 random-to-key fix parity bits 4643 combine-keys bitwise XOR, then fix parity bits 4644 key-derivation identity 4646 6.5.5. des3-cbc-hmac-sha1-kd 4648 This encryption type is based on the Triple DES cryptosystem in Outer-CBC 4649 mode, and the HMAC-SHA1 [Krawczyk96] message authentication algorithm. 4651 A Triple DES key is the concatenation of three DES keys as described above 4652 for des-cbc-md5. A Triple DES key is generated from random data by creating 4653 three DES keys from separate sequences of random data. 4655 EncryptedData using this type must be generated as described in section 4656 6.4.2. If the length of the input data is not a multiple of the block size, 4657 zero octets must be used to pad the plaintext to the next eight-octet 4658 boundary. The counfounder must be eight random octets (one block). 4660 The simplified profile for Triple DES, with key derivation as defined in 4661 section 6.4, is as follows: 4663 protocol key format 24 bytes, parity in low bit of each 4664 key-generation seed length 21 bytes 4665 hash function SHA-1 4666 block size 8 bytes 4667 encryption, decryption functions triple-DES EDE in outer CBC mode 4668 key generation functions: 4669 random-to-key see below 4670 string-to-key DES3string-to-key (see below) 4672 Algorithm Identifiers 4674 The des3-cbc-hmac-sha1-kd encryption type has been assigned the value 16. 4676 Triple DES Key Production (random-to-key, string-to-key) 4677 The 168 bits of random key data are converted to a protocol key value as 4678 follows. First, the 168 bits are divided into three groups of 56 bits, which 4679 are expanded individually into 64 bits as follows: 4681 1 2 3 4 5 6 7 p 4682 9 10 11 12 13 14 15 p 4683 17 18 19 20 21 22 23 p 4684 25 26 27 28 29 30 31 p 4685 33 34 35 36 37 38 39 p 4686 41 42 43 44 45 46 47 p 4687 49 50 51 52 53 54 55 p 4688 56 48 40 32 24 16 8 p 4690 The "p" bits are parity bits computed over the data bits. The output of the 4691 three expansions are concatenated to form the protocol key value. 4693 When the HMAC-SHA1 of a string is computed, the key is used in the protocol 4694 key form. 4696 The string-to-key function is used to tranform UTF-8 passwords into DES3 4697 keys. The DES3 string-to-key function relies on the "N-fold" algorithm and 4698 DK function, described in section 6.4. 4700 The n-fold algorithm is applied to the password string concatenated with a 4701 salt value. For 3-key triple DES, the operation will involve a 168-fold of 4702 the input password string, to generate an intermediate key, from which the 4703 user's long-term key will be derived with the DK function. The DES3 4704 string-to-key function is shown here in pseudocode: 4706 DES3string-to-key(passwordString, salt, key) 4708 s = passwordString + salt 4709 tmpKey = random-to-key(168-fold(s)) 4710 key = DK (tmpKey, KerberosConstant) 4712 No weak-key checking is performed. The KerberosConstant value is the byte 4713 string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to 4714 the ASCII encoding for the string "kerberos". 4716 6.6. Profiles for Kerberos checksums 4718 These are the checksum types currently defined for Kerberos. 4720 6.6.1. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) 4722 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by 4723 prepending an 8 octet confounder before the text, applying the RSA MD4 4724 checksum algorithm [MD4-92], and encrypting the confounder and the checksum 4725 using DES in cipher-block-chaining (CBC) mode using a variant of the key, 4726 where the variant is computed by eXclusive-ORing the key with the constant 4727 F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The 4728 resulting checksum is 24 octets long. This checksum is tamper-proof and 4729 believed to be collision-proof. 4731 The DES specifications identify some weak keys' and 'semi-weak keys'; those 4732 keys shall not be used for generating RSA-MD4 checksums for use in Kerberos. 4734 The format for the checksum is described in the following diagram: 4736 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4737 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 4738 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4740 The format cannot be described in ASN.1, but for those who prefer an 4741 ASN.1-like notation: 4743 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4744 confounder[0] UNTAGGED OCTET STRING(8), 4745 check[1] UNTAGGED OCTET STRING(16) 4746 } 4748 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 4749 get_mic des-cbc(key XOR F0F0F0F0F0F0F0F0, 4750 confounder | rsa-md4(confounder | msg)) 4752 verify_mic decrypt and verify rsa-md4 sum 4754 6.6.2. The RSA MD5 Checksum (rsa-md5) 4756 The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm 4757 [MD5-92]. The algorithm takes as input an input message of arbitrary length 4758 and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to 4759 be collision-proof. However, since it is unkeyed, it must be used with 4760 caution. Currently it is used by some implementations in places where the 4761 checksum itself is part of a larger message that will be encrypted. Its use 4762 is not recommended. 4764 associated cryptosystem null 4765 get_mic rsa-md5(msg) 4766 verify_mic get_mic and compare 4768 6.6.3. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) 4770 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by 4771 prepending an 8 octet confounder before the text, applying the RSA MD5 4772 checksum algorithm, and encrypting the confounder and the checksum using DES 4773 in cipher-block-chaining (CBC) mode using a variant of the key, where the 4774 variant is computed by eXclusive-ORing the key with the hexadecimal constant 4775 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 4776 checksum is 24 octets long. This checksum is tamper-proof and believed to be 4777 collision-proof. 4779 The DES specifications identify some 'weak keys' and 'semi-weak keys'; those 4780 keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos. 4782 The format for the checksum is described in the following diagram: 4784 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4785 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 4786 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4787 The format cannot be described in ASN.1, but for those who prefer an 4788 ASN.1-like notation: 4790 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4791 confounder[0] UNTAGGED OCTET STRING(8), 4792 check[1] UNTAGGED OCTET STRING(16) 4793 } 4795 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 4796 get_mic des-cbc(key XOR F0F0F0F0F0F0F0F0, 4797 confounder | rsa-md5(confounder | msg)) 4799 verify_mic get_mic and compare 4801 6.6.4. The HMAC-SHA1-DES3-KD Checksum (hmac-sha1-des3-kd) 4803 This checksum type is defined as outlined in section 6.3 above, using the 4804 des3-hmac-sha1-kd encryption algorithm definition. The checksum is thus a 4805 SHA-1 HMAC using the computed key Kc over the message to be protected. 4807 It has a checksum type number of 12. 4809 7. Naming Constraints 4811 7.1. Realm Names 4813 Although realm names are encoded as GeneralStrings and although a realm can 4814 technically select any name it chooses, interoperability across realm 4815 boundaries requires agreement on how realm names are to be assigned, and 4816 what information they imply. 4818 To enforce these conventions, each realm must conform to the conventions 4819 itself, and it must require that any realms with which inter-realm keys are 4820 shared also conform to the conventions and require the same from its 4821 neighbors. 4823 Kerberos realm names are case sensitive. Realm names that differ only in the 4824 case of the characters are not equivalent. There are presently four styles 4825 of realm names: domain, X500, other, and reserved. Examples of each style 4826 follow: 4828 domain: ATHENA.MIT.EDU (example) 4829 X500: C=US/O=OSF (example) 4830 other: NAMETYPE:rest/of.name=without-restrictions (example) 4831 reserved: reserved, but will not conflict with above 4833 Domain names must look like domain names: they consist of components 4834 separated by periods (.) and they contain neither colons (:) nor slashes 4835 (/). Though domain names themselves are case insensitive, in order for 4836 realms to match, the case must match as well. When establishing a new realm 4837 name based on an internet domain name it is recommended by convention that 4838 the characters be converted to upper case. 4840 X.500 names contain an equal (=) and cannot contain a colon (:) before the 4841 equal. The realm names for X.500 names will be string representations of the 4842 names with components separated by slashes. Leading and trailing slashes 4843 will not be included. Note that the slash separator is consistent with 4844 Kerberos implementations based on RFC1510, but it is different from the 4845 separator recommended in RFC2253. 4847 Names that fall into the other category must begin with a prefix that 4848 contains no equal (=) or period (.) and the prefix must be followed by a 4849 colon (:) and the rest of the name. All prefixes must be assigned before 4850 they may be used. Presently none are assigned. 4852 The reserved category includes strings which do not fall into the first 4853 three categories. All names in this category are reserved. It is unlikely 4854 that names will be assigned to this category unless there is a very strong 4855 argument for not using the 'other' category. 4857 These rules guarantee that there will be no conflicts between the various 4858 name styles. The following additional constraints apply to the assignment of 4859 realm names in the domain and X.500 categories: the name of a realm for the 4860 domain or X.500 formats must either be used by the organization owning (to 4861 whom it was assigned) an Internet domain name or X.500 name, or in the case 4862 that no such names are registered, authority to use a realm name may be 4863 derived from the authority of the parent realm. For example, if there is no 4864 domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4865 authorize the creation of a realm with that name. 4867 This is acceptable because the organization to which the parent is assigned 4868 is presumably the organization authorized to assign names to its children in 4869 the X.500 and domain name systems as well. If the parent assigns a realm 4870 name without also registering it in the domain name or X.500 hierarchy, it 4871 is the parent's responsibility to make sure that there will not in the 4872 future exist a name identical to the realm name of the child unless it is 4873 assigned to the same entity as the realm name. 4875 7.2. Principal Names 4877 As was the case for realm names, conventions are needed to ensure that all 4878 agree on what information is implied by a principal name. The name-type 4879 field that is part of the principal name indicates the kind of information 4880 implied by the name. The name-type should be treated as a hint. Ignoring the 4881 name type, no two names can be the same (i.e. at least one of the 4882 components, or the realm, must be different). The following name types are 4883 defined: 4885 name-type value meaning 4887 NT-UNKNOWN 0 Name type not known 4888 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE) 4889 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4890 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4891 NT-SRV-XHST 4 Service with slash-separated host name components 4892 NT-UID 5 Unique ID 4893 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4894 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4896 When a name implies no information other than its uniqueness at a particular 4897 time the name type PRINCIPAL should be used. The principal name type should 4898 be used for users, and it might also be used for a unique server. If the 4899 name is a unique machine generated ID that is guaranteed never to be 4900 reassigned then the name type of UID should be used (note that it is 4901 generally a bad idea to reassign names of any type since stale entries might 4902 remain in access control lists). 4904 If the first component of a name identifies a service and the remaining 4905 components identify an instance of the service in a server specified manner, 4906 then the name type of SRV-INST should be used. An example of this name type 4907 is the Kerberos ticket-granting service whose name has a first component of 4908 krbtgt and a second component identifying the realm for which the ticket is 4909 valid. 4911 If instance is a single component following the service name and the 4912 instance identifies the host on which the server is running, then the name 4913 type SRV-HST should be used. This type is typically used for Internet 4914 services such as telnet and the Berkeley R commands. If the separate 4915 components of the host name appear as successive components following the 4916 name of the service, then the name type SRV-XHST should be used. This type 4917 might be used to identify servers on hosts with X.500 names where the slash 4918 (/) might otherwise be ambiguous. 4920 A name type of NT-X500-PRINCIPAL should be used when a name from an X.509 4921 certificate is translated into a Kerberos name. The encoding of the X.509 4922 name as a Kerberos principal shall conform to the encoding rules specified 4923 in RFC 2253. 4925 A name type of SMTP allows a name to be of a form that resembles a SMTP 4926 email name. This name, including an "@" and a domain name, is used as the 4927 one component of the principal name. This name type can be used in 4928 conjunction with name-canonicalization to allow a free-form of email address 4929 to be specified as a client name and allow the KDC to determine the Kerberos 4930 principal name for the requested name. [JBrezak, Raeburn] 4932 A name type of UNKNOWN should be used when the form of the name is not 4933 known. When comparing names, a name of type UNKNOWN will match principals 4934 authenticated with names of any type. A principal authenticated with a name 4935 of type UNKNOWN, however, will only match other names of type UNKNOWN. 4937 Names of any type with an initial component of 'krbtgt' are reserved for the 4938 Kerberos ticket granting service. See section 8.2.3 for the form of such 4939 names. 4941 7.2.1. Name of server principals 4943 The principal identifier for a server on a host will generally be composed 4944 of two parts: (1) the realm of the KDC with which the server is registered, 4945 and (2) a two-component name of type NT-SRV-HST if the host name is an 4946 Internet domain name or a multi-component name of type NT-SRV-XHST if the 4947 name of the host is of a form such as X.500 that allows slash (/) 4948 separators. The first component of the two- or multi-component name will 4949 identify the service and the latter components will identify the host. Where 4950 the name of the host is not case sensitive (for example, with Internet 4951 domain names) the name of the host must be lower case. If specified by the 4952 application protocol for services such as telnet and the Berkeley R commands 4953 which run with system privileges, the first component may be the string 4954 'host' instead of a service specific identifier. When a host has an official 4955 name and one or more aliases and the official name can be reliably 4956 determined, the official name of the host should be used when constructing 4957 the name of the server principal. 4959 8. Constants and other defined values 4961 8.1. Host address types 4963 All negative values for the host address type are reserved for local use. 4964 All non-negative values are reserved for officially assigned type fields and 4965 interpretations. 4967 The values of the types for the following addresses are chosen to match the 4968 defined address family constants in the Berkeley Standard Distributions of 4969 Unix. They can be found in with symbolic names AF_xxx (where xxx is an 4970 abbreviation of the address family name). 4972 Internet (IPv4) Addresses 4974 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB 4975 order. The IPv4 loopback address should not appear in a Kerberos packet. The 4976 type of IPv4 addresses is two (2). 4978 Internet (IPv6) Addresses [Westerlund] 4980 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The 4981 type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The 4982 following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 4984 * the Unspecified Address 4985 * the Loopback Address 4986 * Link-Local addresses 4988 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 4990 CHAOSnet addresses 4992 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order. 4993 The type of CHAOSnet addresses is five (5). 4995 ISO addresses 4997 ISO addresses are variable-length. The type of ISO addresses is seven (7). 4999 Xerox Network Services (XNS) addresses 5001 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The 5002 type of XNS addresses is six (6). 5004 AppleTalk Datagram Delivery Protocol (DDP) addresses 5006 AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network 5007 number. The first octet of the address is the node number; the remaining two 5008 octets encode the network number in MSB order. The type of AppleTalk DDP 5009 addresses is sixteen (16). 5011 DECnet Phase IV addresses 5013 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The 5014 type of DECnet Phase IV addresses is twelve (12). 5016 Netbios addresses 5018 Netbios addresses are 16-octet addresses typically composed of 1 to 15 5019 characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0. 5020 The type of Netbios addresses is 20 (0x14). 5022 8.2. KDC messages 5024 8.2.1. UDP/IP transport 5026 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP 5027 IP transport, the client shall send a UDP datagram containing only an 5028 encoding of the request to port 88 (decimal) at the KDC's IP address; the 5029 KDC will respond with a reply datagram containing only an encoding of the 5030 reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at 5031 the sender's IP address. Kerberos servers supporting IP transport must 5032 accept UDP requests on port 88 (decimal). The response to a request made 5033 through UDP/IP transport must also use UDP/IP transport. 5035 8.2.2. TCP/IP transport [Westerlund,Danielsson] 5037 Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and 5038 clients should support the sending of TCP requests on port 88 (decimal). 5039 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new 5040 connection will be established for each authentication exchange (request and 5041 response). The KRB_KDC_REP or KRB_ERROR message will be returned to the 5042 client on the same TCP stream that was established for the request. The 5043 response to a request made through TCP/IP transport must also use TCP/IP 5044 transport. Implementors should note that some extensions to the Kerberos 5045 protocol will not work if any implementation not supporting the TCP 5046 transport is involved (client or KDC). Implementors are strongly urged to 5047 support the TCP transport on both the client and server and are advised that 5048 the current notation of "should" support will likely change in the future to 5049 must support. The KDC may close the TCP stream after sending a response, but 5050 may leave the stream open if it expects a followup - in which case it may 5051 close the stream at any time if resource constraints or other factors make 5052 it desirable to do so. Care must be taken in managing TCP/IP connections 5053 with the KDC to prevent denial of service attacks based on the number of 5054 TCP/IP connections with the KDC that remain open. If multiple exchanges with 5055 the KDC are needed for certain forms of preauthentication, multiple TCP 5056 connections may be required. A client may close the stream after receiving 5057 response, and should close the stream if it does not expect to send followup 5058 messages. The client must be prepared to have the stream closed by the KDC 5059 at anytime, in which case it must simply connect again when it is ready to 5060 send subsequent messages. 5062 The first four octets of the TCP stream used to transmit the request request 5063 will encode in network byte order the length of the request (KRB_KDC_REQ), 5064 and the length will be followed by the request itself. The response will 5065 similarly be preceded by a 4 octet encoding in network byte order of the 5066 length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by 5067 the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the 5068 integer represented by the first 4 octets, then the next 4 octets will be 5069 read, extending the length of the field by another 4 octets (less the sign 5070 bit of the additional four octets which is reserved for future expansion and 5071 which at present must be zero). 5073 8.2.3. OSI transport 5075 During authentication of an OSI client to an OSI server, the mutual 5076 authentication of an OSI server to an OSI client, the transfer of 5077 credentials from an OSI client to an OSI server, or during exchange of 5078 private or integrity checked messages, Kerberos protocol messages may be 5079 treated as opaque objects and the type of the authentication mechanism will 5080 be: 5082 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} 5084 Depending on the situation, the opaque object will be an authentication 5085 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message 5086 (KRB_SAFE), a private message (KRB_PRIV), or a credentials message 5087 (KRB_CRED). The opaque data contains an application code as specified in the 5088 ASN.1 description for each message. The application code may be used by 5089 Kerberos to determine the message type. 5091 8.2.3. Name of the TGS 5093 The principal identifier of the ticket-granting service shall be composed of 5094 three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part 5095 name of type NT-SRV-INST, with the first part "krbtgt" and the second part 5096 the name of the realm which will accept the ticket-granting ticket. For 5097 example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 5098 used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier 5099 of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 5100 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get 5101 tickets from the MIT.EDU realm has a principal identifier of 5102 "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name). 5104 8.3. Protocol constants and associated values 5106 The following tables list constants used in the protocol and define their 5107 meanings. Ranges are specified in the "specification" section that limit the 5108 values of constants for which values are defined here. This allows 5109 implementations to make assumptions about the maximum values that will be 5110 received for these constants. Implementation receiving values outside the 5111 range specified in the "specification" section may reject the request, but 5112 they must recover cleanly. 5114 Encryption type etype value block size minimum pad size confounder size 5115 NULL 0 1 0 0 5116 des-cbc-crc 1 8 4 8 5117 des-cbc-md4 2 8 0 8 5118 des-cbc-md5 3 8 0 8 5119 [reserved] 4 5120 des3-cbc-md5 5 8 0 8 5121 [reserved] 6 5122 des3-cbc-sha1 7 8 0 8 5123 dsaWithSHA1-CmsOID 9 (pkinit) 5124 md5WithRSAEncryption-CmsOID 10 (pkinit) 5125 sha1WithRSAEncryption-CmsOID 11 (pkinit) 5126 rc2CBC-EnvOID 12 (pkinit) 5127 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 5128 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 5129 des-ede3-cbc-Env-OID 15 (pkinit) 5130 des3-cbc-sha1-kd 16 (Tom Yu) 5131 rc4-hmac 23 (swift) 5132 rc4-hmac-exp 24 (swift) 5133 subkey-keynaterial 65 (opaque mhur) 5135 [reserved] 0x8003 5137 Checksum type sumtype value checksum size 5138 CRC32 1 4 5139 rsa-md4 2 16 5140 rsa-md4-des 3 24 5141 des-mac 4 16 5142 des-mac-k 5 8 5143 rsa-md4-des-k 6 16 (drop rsa ?) 5144 rsa-md5 7 16 (drop rsa ?) 5145 rsa-md5-des 8 24 (drop rsa ?) 5146 rsa-md5-des3 9 24 (drop rsa ?) 5147 hmac-sha1-des3-kd 12 20 5148 hmac-sha1-des3 13 20 5149 sha1 (unkeyed) 14 20 5150 padata and data types padata-type value comment 5152 PA-TGS-REQ 1 5153 PA-ENC-TIMESTAMP 2 5154 PA-PW-SALT 3 5155 [reserved] 4 5156 PA-ENC-UNIX-TIME 5 (depricated) 5157 PA-SANDIA-SECUREID 6 5158 PA-SESAME 7 5159 PA-OSF-DCE 8 5160 PA-CYBERSAFE-SECUREID 9 5161 PA-AFS3-SALT 10 5162 PA-ETYPE-INFO 11 5163 PA-SAM-CHALLENGE 12 (sam/otp) 5164 PA-SAM-RESPONSE 13 (sam/otp) 5165 PA-PK-AS-REQ 14 (pkinit) 5166 PA-PK-AS-REP 15 (pkinit) 5167 PA-USE-SPECIFIED-KVNO 20 5168 PA-SAM-REDIRECT 21 (sam/otp) 5169 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 5170 TD-PADATA 22 (embeds padata) 5171 PA-SAM-ETYPE-INFO 23 (sam/otp) 5172 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 5173 TD-KRB-PRINCIPAL 102 PrincipalName (see Sec.5.9.1) 5174 TD-KRB-REALM 103 Realm (see Sec.5.9.1) 5175 TD-TRUSTED-CERTIFIERS 104 from PKINIT 5176 TD-CERTIFICATE-INDEX 105 from PKINIT 5177 TD-APP-DEFINED-ERROR 106 application specific (see Sec.5.9.1) 5178 TD-REQ-NONCE 107 INTEGER (see Sec.5.9.1) 5179 TD-REQ-SEQ 108 INTEGER (see Sec.5.9.1) 5181 authorization data type ad-type value 5182 AD-IF-RELEVANT 1 5183 AD-INTENDED-FOR-SERVER 2 5184 AD-INTENDED-FOR-APPLICATION-CLASS 3 5185 AD-KDC-ISSUED 4 5186 AD-OR 5 5187 AD-MANDATORY-TICKET-EXTENSIONS 6 5188 AD-IN-TICKET-EXTENSIONS 7 5189 reserved values 8-63 5190 OSF-DCE 64 5191 SESAME 65 5192 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 5193 AD-WIN200-PAC 128 (jbrezak@exchange.microsoft.com) 5195 Ticket Extension Types 5197 TE-TYPE-NULL 0 Null ticket extension 5198 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 5199 [reserved] 2 TE-TYPE-PKCROSS-KDC (I have reservations) 5200 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 5201 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 5202 [reserved] 5 TE-TYPE-DEST-HOST (I have reservations) 5203 alternate authentication type method-type value 5204 reserved values 0-63 5205 ATT-CHALLENGE-RESPONSE 64 5207 transited encoding type tr-type value 5208 DOMAIN-X500-COMPRESS 1 5209 reserved values all others 5211 Label Value Meaning or MIT code 5213 pvno 5 current Kerberos protocol version number 5215 message types (Will be updated to match section 5) 5217 KRB_AS_REQ 10 Request for initial authentication 5218 KRB_AS_REP 11 Response to KRB_AS_REQ request 5219 KRB_TGS_REQ 12 Request for authentication based on TGT 5220 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 5221 KRB_AP_REQ 14 application request to server 5222 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 5223 KRB_SAFE 20 Safe (checksummed) application message 5224 KRB_PRIV 21 Private (encrypted) application message 5225 KRB_CRED 22 Private (encrypted) message to forward credentials 5226 KRB_ERROR 30 Error response 5228 name types 5230 KRB_NT_UNKNOWN 0 Name type not known 5231 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5232 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 5233 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 5234 KRB_NT_SRV_XHST 4 Service with host as remaining components 5235 KRB_NT_UID 5 Unique ID 5236 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5238 error codes 5240 KDC_ERR_NONE 0 No error 5241 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 5242 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 5243 KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported 5244 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 5245 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 5246 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 5247 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 5248 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 5249 KDC_ERR_NULL_KEY 9 The client or server has a null key 5250 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 5251 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 5252 KDC_ERR_POLICY 12 KDC policy rejects request 5253 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 5254 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 5255 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 5256 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 5257 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 5258 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 5259 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 5260 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 5261 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 5262 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 5263 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset 5264 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 5265 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40] 5266 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 5267 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 5268 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 5269 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 5270 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 5271 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 5272 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 5273 KRB_AP_ERR_REPEAT 34 Request is a replay 5274 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 5275 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 5276 KRB_AP_ERR_SKEW 37 Clock skew too great 5277 KRB_AP_ERR_BADADDR 38 Incorrect net address 5278 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 5279 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 5280 KRB_AP_ERR_MODIFIED 41 Message stream modified 5281 KRB_AP_ERR_BADORDER 42 Message out of order 5282 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 5283 KRB_AP_ERR_NOKEY 45 Service key not available 5284 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 5285 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 5286 KRB_AP_ERR_METHOD 48 Alternative authentication method required 5287 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 5288 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 5289 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 5290 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 5291 KRB_ERR_GENERIC 60 Generic error (description in e-text) 5292 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 5293 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 5294 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 5295 KDC_ERROR_INVALID_SIG 64 (pkinit) 5296 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 5297 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 5298 KRB_AP_ERR_NO_TGT 67 (user-to-user) 5299 KDC_ERR_WRONG_REALM 68 (user-to-user) 5300 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 5301 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 5302 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 5303 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 5304 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 5305 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 5306 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 5307 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 5308 9. Interoperability requirements 5310 Version 5 of the Kerberos protocol supports a myriad of options. Among these 5311 are multiple encryption and checksum types, alternative encoding schemes for 5312 the transited field, optional mechanisms for pre-authentication, the 5313 handling of tickets with no addresses, options for mutual authentication, 5314 user to user authentication, support for proxies, forwarding, postdating, 5315 and renewing tickets, the format of realm names, and the handling of 5316 authorization data. 5318 In order to ensure the interoperability of realms, it is necessary to define 5319 a minimal configuration which must be supported by all implementations. This 5320 minimal configuration is subject to change as technology does. For example, 5321 if at some later date it is discovered that one of the required encryption 5322 or checksum algorithms is not secure, it will be replaced. 5324 9.1. Specification 2 5326 This section defines the second specification of these options. 5327 Implementations which are configured in this way can be said to support 5328 Kerberos Version 5 Specification 2 (5.1). Specification 1 (deprecated) may 5329 be found in RFC1510. 5331 Transport 5333 TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance 5334 to specification 2. Kerberos clients claiming conformance to specification 2 5335 must support UDP/IP transport for messages with the KDC and should support 5336 TCP/IP transport. 5338 Encryption and checksum methods 5340 The following encryption and checksum mechanisms must be supported. 5341 Implementations may support other mechanisms as well, but the additional 5342 mechanisms may only be used when communicating with principals known to also 5343 support them: This list is to be determined and should correspond to section 5344 6. 5346 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD, RIJNDAEL(decide identifier) 5347 Checksums: CRC-32, DES-MAC, DES-MAC-K, DES-MD5, HMAC-SHA1-DES3-KD 5349 Realm Names 5351 All implementations must understand hierarchical realms in both the Internet 5352 Domain and the X.500 style. When a ticket granting ticket for an unknown 5353 realm is requested, the KDC must be able to determine the names of the 5354 intermediate realms between the KDCs realm and the requested realm. 5356 Transited field encoding 5358 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 5359 Alternative encodings may be supported, but they may be used only when that 5360 encoding is supported by ALL intermediate realms. 5362 Pre-authentication methods 5364 The TGS-REQ method must be supported. The TGS-REQ method is not used on the 5365 initial request. The PA-ENC-TIMESTAMP method must be supported by clients 5366 but whether it is enabled by default may be determined on a realm by realm 5367 basis. If not used in the initial request and the error 5368 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 5369 acceptable method, the client should retry the initial request using the 5370 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 5371 PA-ENC-TIMESTAMP method, but if not supported the server should ignore the 5372 presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5374 Mutual authentication 5376 Mutual authentication (via the KRB_AP_REP message) must be supported. 5378 Ticket addresses and flags 5380 All KDC's must pass through tickets that carry no addresses (i.e. if a TGT 5381 contains no addresses, the KDC will return derivative tickets), but each 5382 realm may set its own policy for issuing such tickets, and each application 5383 server will set its own policy with respect to accepting them. 5385 Proxies and forwarded tickets must be supported. Individual realms and 5386 application servers can set their own policy on when such tickets will be 5387 accepted. 5389 All implementations must recognize renewable and postdated tickets, but need 5390 not actually implement them. If these options are not supported, the 5391 starttime and endtime in the ticket shall specify a ticket's entire useful 5392 life. When a postdated ticket is decoded by a server, all implementations 5393 shall make the presence of the postdated flag visible to the calling server. 5395 User-to-user authentication 5397 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option) 5398 must be provided by implementations, but individual realms may decide as a 5399 matter of policy to reject such requests on a per-principal or realm-wide 5400 basis. 5402 Authorization data 5404 Implementations must pass all authorization data subfields from 5405 ticket-granting tickets to any derivative tickets unless directed to 5406 suppress a subfield as part of the definition of that registered subfield 5407 type (it is never incorrect to pass on a subfield, and no registered 5408 subfield types presently specify suppression at the KDC). 5410 Implementations must make the contents of any authorization data subfields 5411 available to the server when a ticket is used. Implementations are not 5412 required to allow clients to specify the contents of the authorization data 5413 fields. 5415 Constant ranges 5417 All protocol constants are constrained to 32 bit (signed) values unless 5418 further constrained by the protocol definition. This limit is provided to 5419 allow implementations to make assumptions about the maximum values that will 5420 be received for these constants. Implementation receiving values outside 5421 this range may reject the request, but they must recover cleanly. 5423 9.2. Recommended KDC values 5425 Following is a list of recommended values for a KDC implementation, based on 5426 the list of suggested configuration constants (see section 4.4). 5428 minimum lifetime 5 minutes 5429 maximum renewable lifetime 1 week 5430 maximum ticket lifetime 1 day 5431 empty addresses only when suitable restrictions appear 5432 in authorization data 5433 proxiable, etc. Allowed. 5435 10. IANA considerations 5437 Maybe set up an appendix with all the tables that IANA will need to start 5438 maintaining? 5440 * cryptosystem registration 5441 * usage number registration 5442 11. REFERENCES 5444 [Blumenthal96] 5445 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers", 5446 Proceedings of PRAGOCRYPT '96, 1996. 5447 [Bellare98] 5448 Bellare, M., Desai, A., Pointcheval, D., Rogaway, P., "Relations Among 5449 Notions of Security for Public-Key Encryption Schemes". Extended 5450 abstract published in Advances in Cryptology- Crypto 98 Proceedings, 5451 Lecture Notes in Computer Science Vol. 1462, H. Krawcyzk ed., 5452 Springer-Verlag, 1998. 5453 [DES77] 5454 National Bureau of Standards, U.S. Department of Commerce, "Data 5455 Encryption Standard," Federal Information Processing Standards 5456 Publication 46, Washington, DC (1977). 5457 [DESM80] 5458 National Bureau of Standards, U.S. Department of Com- merce, "DES Modes 5459 of Operation," Federal Information Processing Standards Publication 81, 5460 Springfield, VA (December 1980). 5461 [Dolev91] 5462 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 5463 Proceedings of the 23rd Annual Symposium on Theory of Computing, ACM, 5464 1991. 5465 [DS81] 5466 Dorothy E. Denning and Giovanni Maria Sacco, "Time- stamps in Key 5467 Distribution Protocols," Communications of the ACM, Vol. 24(8), pp. 5468 533-536 (August 1981). 5469 [DS90] 5470 Don Davis and Ralph Swick, "Workstation Services and Kerberos 5471 Authentication at Project Athena," Technical Memorandum TM-424, MIT 5472 Laboratory for Computer Science (February 1990). 5473 [Horowitz96] 5474 Horowitz, M., "Key Derivation for Authentication, Integrity, and 5475 Privacy", draft-horowitz-key-derivation-02.txt, August 1998. 5476 [HorowitzB96] 5477 Horowitz, M., "Key Derivation for Kerberos V5", draft- 5478 horowitz-kerb-key-derivation-01.txt, September 1998. 5479 [IS3309] 5480 International Organization for Standardization, "ISO Information 5481 Processing Systems - Data Communication - High-Level Data Link Control 5482 Procedure - Frame Struc- ture," IS 3309 (October 1984). 3rd Edition. 5483 [KBC96] 5484 H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- Hashing for 5485 Message Authentication," Working Draft 5486 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 5487 [KNT92] 5488 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The Evolution 5489 of the Kerberos Authentication Service," in an IEEE Computer Society 5490 Text soon to be published (June 1992). 5491 [Krawczyk96] 5492 Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: Keyed-Hashing for 5493 Message Authentication", draft-ietf-ipsec-hmac- md5-01.txt, August, 5494 1996. 5495 [LGDSR87] 5496 P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- merfeld, and K. 5497 Raeburn, Section E.1: Service Manage- ment System, M.I.T. Project 5498 Athena, Cambridge, Mas- sachusetts (1987). 5500 [MD4-92] 5501 R. Rivest, "The MD4 Message Digest Algorithm," RFC 1320, MIT Laboratory 5502 for Computer Science (April 1992). 5503 [MD5-92] 5504 R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, MIT Laboratory 5505 for Computer Science (April 1992). 5506 [MNSS87] 5507 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section 5508 E.2.1: Kerberos Authentication and Authorization System, M.I.T. Project 5509 Athena, Cambridge, Massachusetts (December 21, 1987). 5510 [Neu93] 5511 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 5512 Distributed Systems," in Proceedings of the 13th International 5513 Conference on Distributed Com- puting Systems, Pittsburgh, PA (May, 5514 1993). 5515 [NS78] 5516 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5517 Authentication in Large Networks of Com- puters," Communications of the 5518 ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5519 [NT94] 5520 B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- cation Service 5521 for Computer Networks," IEEE Communica- tions Magazine, Vol. 32(9), pp. 5522 33-38 (September 1994). 5523 [Pat92]. 5524 J. Pato, Using Pre-Authentication to Avoid Password Guessing Attacks, 5525 Open Software Foundation DCE Request for Comments 26 (December 1992). 5526 [SG92] 5527 Stuart G. Stubblebine and Virgil D. Gligor, "On Message Integrity in 5528 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 5529 Research in Security and Privacy, Oakland, California (May 1992). 5530 [SNS88] 5531 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- beros: An 5532 Authentication Service for Open Network Sys- tems," pp. 191-202 in 5533 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 5534 [X509-88] 5535 CCITT, Recommendation X.509: The Directory Authentica- tion Framework, 5536 December 1988. 5538 A. Pseudo-code for protocol processing 5540 This appendix provides pseudo-code describing how the messages are to be 5541 constructed and interpreted by clients and servers. 5543 A.1. KRB_AS_REQ generation 5545 request.pvno := protocol version; /* pvno = 5 */ 5546 request.msg-type := message type; /* type = KRB_AS_REQ */ 5548 if(pa_enc_timestamp_required) then 5549 request.padata.padata-type = PA-ENC-TIMESTAMP; 5550 get system_time; 5551 padata-body.patimestamp,pausec = system_time; 5552 encrypt padata-body into request.padata.padata-value 5553 using client.key; /* derived from password */ 5554 endif 5556 body.kdc-options := users's preferences; 5557 body.cname := user's name; 5558 body.realm := user's realm; 5559 body.sname := service's name; /* usually "krbtgt", = 5560 "localrealm" */ 5561 if (body.kdc-options.POSTDATED is set) then 5562 body.from := requested starting time; 5563 else 5564 omit body.from; 5565 endif 5566 body.till := requested end time; 5567 if (body.kdc-options.RENEWABLE is set) then 5568 body.rtime := requested final renewal time; 5569 endif 5570 body.nonce := random_nonce(); 5571 body.etype := requested etypes; 5572 if (user supplied addresses) then 5573 body.addresses := user's addresses; 5574 else 5575 omit body.addresses; 5576 endif 5577 omit body.enc-authorization-data; 5578 request.req-body := body; 5580 kerberos := lookup(name of local kerberos server (or = 5581 servers)); 5582 send(packet,kerberos); 5584 wait(for response); 5585 if (timed_out) then 5586 retry or use alternate server; 5587 endif 5588 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 5590 decode message into req; 5592 client := lookup(req.cname,req.realm); 5593 server := lookup(req.sname,req.realm); 5595 get system_time; 5596 kdc_time := system_time.seconds; 5598 if (!client) then 5599 /* no client in Database */ 5600 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 5601 endif 5602 if (!server) then 5603 /* no server in Database */ 5604 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5605 endif 5607 if(client.pa_enc_timestamp_required and 5608 pa_enc_timestamp not present) then 5609 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 5610 endif 5612 if(pa_enc_timestamp present) then 5613 decrypt req.padata-value into decrypted_enc_timestamp 5614 using client.key; 5615 using auth_hdr.authenticator.subkey; 5616 if (decrypt_error()) then 5617 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5618 if(decrypted_enc_timestamp is not within allowable skew) = 5619 then 5620 error_out(KDC_ERR_PREAUTH_FAILED); 5621 endif 5622 if(decrypted_enc_timestamp and usec is replay) 5623 error_out(KDC_ERR_PREAUTH_FAILED); 5624 endif 5625 add decrypted_enc_timestamp and usec to replay cache; 5626 endif 5628 use_etype := first supported etype in req.etypes; 5630 if (no support for req.etypes) then 5631 error_out(KDC_ERR_ETYPE_NOSUPP); 5632 endif 5634 new_tkt.vno := ticket version; /* = 5 */ 5635 new_tkt.sname := req.sname; 5636 new_tkt.srealm := req.srealm; 5637 reset all flags in new_tkt.flags; 5639 /* It should be noted that local policy may affect the */ 5640 /* processing of any of these flags. For example, some */ 5641 /* realms may refuse to issue renewable tickets */ 5643 if (req.kdc-options.FORWARDABLE is set) then 5644 set new_tkt.flags.FORWARDABLE; 5645 endif 5646 if (req.kdc-options.PROXIABLE is set) then 5647 set new_tkt.flags.PROXIABLE; 5648 endif 5650 if (req.kdc-options.ALLOW-POSTDATE is set) then 5651 set new_tkt.flags.MAY-POSTDATE; 5652 endif 5653 if ((req.kdc-options.RENEW is set) or 5654 (req.kdc-options.VALIDATE is set) or 5655 (req.kdc-options.PROXY is set) or 5656 (req.kdc-options.FORWARDED is set) or 5657 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 5658 error_out(KDC_ERR_BADOPTION); 5659 endif 5661 new_tkt.session := random_session_key(); 5662 new_tkt.cname := req.cname; 5663 new_tkt.crealm := req.crealm; 5664 new_tkt.transited := empty_transited_field(); 5666 new_tkt.authtime := kdc_time; 5668 if (req.kdc-options.POSTDATED is set) then 5669 if (against_postdate_policy(req.from)) then 5670 error_out(KDC_ERR_POLICY); 5671 endif 5672 set new_tkt.flags.POSTDATED; 5673 set new_tkt.flags.INVALID; 5674 new_tkt.starttime := req.from; 5675 else 5676 omit new_tkt.starttime; /* treated as authtime when omitted */ 5677 endif 5678 if (req.till = 0) then 5679 till := infinity; 5680 else 5681 till := req.till; 5682 endif 5684 new_tkt.endtime := min(till, 5685 new_tkt.starttime+client.max_life, 5686 new_tkt.starttime+server.max_life, 5687 new_tkt.starttime+max_life_for_realm); 5689 if ((req.kdc-options.RENEWABLE-OK is set) and 5690 (new_tkt.endtime < req.till)) then 5691 /* we set the RENEWABLE option for later processing */ 5692 set req.kdc-options.RENEWABLE; 5693 req.rtime := req.till; 5694 endif 5696 if (req.rtime = 0) then 5697 rtime := infinity; 5698 else 5699 rtime := req.rtime; 5700 endif 5702 if (req.kdc-options.RENEWABLE is set) then 5703 set new_tkt.flags.RENEWABLE; 5704 new_tkt.renew-till := min(rtime, 5705 new_tkt.starttime+client.max_rlife, 5706 new_tkt.starttime+server.max_rlife, 5707 new_tkt.starttime+max_rlife_for_realm); 5708 else 5709 omit new_tkt.renew-till; /* only present if RENEWABLE */ 5710 endif 5712 if (req.addresses) then 5713 new_tkt.caddr := req.addresses; 5714 else 5715 omit new_tkt.caddr; 5716 endif 5718 new_tkt.authorization_data := empty_authorization_data(); 5720 encode to-be-encrypted part of ticket into OCTET STRING; 5721 new_tkt.enc-part := encrypt OCTET STRING 5722 using etype_for_key(server.key), server.key, server.p_kvno; 5724 /* Start processing the response */ 5726 resp.pvno := 5; 5727 resp.msg-type := KRB_AS_REP; 5728 resp.cname := req.cname; 5729 resp.crealm := req.realm; 5730 resp.ticket := new_tkt; 5732 resp.key := new_tkt.session; 5733 resp.last-req := fetch_last_request_info(client); 5734 resp.nonce := req.nonce; 5735 resp.key-expiration := client.expiration; 5736 resp.flags := new_tkt.flags; 5738 resp.authtime := new_tkt.authtime; 5739 resp.starttime := new_tkt.starttime; 5740 resp.endtime := new_tkt.endtime; 5742 if (new_tkt.flags.RENEWABLE) then 5743 resp.renew-till := new_tkt.renew-till; 5744 endif 5746 resp.realm := new_tkt.realm; 5747 resp.sname := new_tkt.sname; 5749 resp.caddr := new_tkt.caddr; 5751 encode body of reply into OCTET STRING; 5753 resp.enc-part := encrypt OCTET STRING 5754 using use_etype, client.key, client.p_kvno; 5755 send(resp); 5756 A.3. KRB_AS_REP verification 5758 decode response into resp; 5760 if (resp.msg-type = KRB_ERROR) then 5761 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 5762 set pa_enc_timestamp_required; 5763 goto KRB_AS_REQ; 5764 endif 5765 process_error(resp); 5766 return; 5767 endif 5769 /* On error, discard the response, and zero the session key */ 5770 /* from the response immediately */ 5772 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 5773 resp.padata); 5774 unencrypted part of resp := decode of decrypt of resp.enc-part 5775 using resp.enc-part.etype and key; 5776 zero(key); 5778 if (common_as_rep_tgs_rep_checks fail) then 5779 destroy resp.key; 5780 return error; 5781 endif 5783 if near(resp.princ_exp) then 5784 print(warning message); 5785 endif 5786 save_for_later(ticket,session,client,server,times,flags); 5788 A.4. KRB_AS_REP and KRB_TGS_REP common checks 5790 if (decryption_error() or 5791 (req.cname != resp.cname) or 5792 (req.realm != resp.crealm) or 5793 (req.sname != resp.sname) or 5794 (req.realm != resp.realm) or 5795 (req.nonce != resp.nonce) or 5796 (req.addresses != resp.caddr)) then 5797 destroy resp.key; 5798 return KRB_AP_ERR_MODIFIED; 5799 endif 5801 /* make sure no flags are set that shouldn't be, and that all that */ 5802 /* should be are set */ 5803 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 5804 destroy resp.key; 5805 return KRB_AP_ERR_MODIFIED; 5806 endif 5808 if ((req.from = 0) and 5809 (resp.starttime is not within allowable skew)) then 5810 destroy resp.key; 5811 return KRB_AP_ERR_SKEW; 5812 endif 5813 if ((req.from != 0) and (req.from != resp.starttime)) then 5814 destroy resp.key; 5815 return KRB_AP_ERR_MODIFIED; 5816 endif 5817 if ((req.till != 0) and (resp.endtime > req.till)) then 5818 destroy resp.key; 5819 return KRB_AP_ERR_MODIFIED; 5820 endif 5822 if ((req.kdc-options.RENEWABLE is set) and 5823 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 5824 destroy resp.key; 5825 return KRB_AP_ERR_MODIFIED; 5826 endif 5827 if ((req.kdc-options.RENEWABLE-OK is set) and 5828 (resp.flags.RENEWABLE) and 5829 (req.till != 0) and 5830 (resp.renew-till > req.till)) then 5831 destroy resp.key; 5832 return KRB_AP_ERR_MODIFIED; 5833 endif 5835 A.5. KRB_TGS_REQ generation 5837 /* Note that make_application_request might have to recursivly */ 5838 /* call this routine to get the appropriate ticket-granting ticket */ 5840 request.pvno := protocol version; /* pvno = 5 */ 5841 request.msg-type := message type; /* type = KRB_TGS_REQ */ 5843 body.kdc-options := users's preferences; 5844 /* If the TGT is not for the realm of the end-server */ 5845 /* then the sname will be for a TGT for the end-realm */ 5846 /* and the realm of the requested ticket (body.realm) */ 5847 /* will be that of the TGS to which the TGT we are */ 5848 /* sending applies */ 5849 body.sname := service's name; 5850 body.realm := service's realm; 5852 if (body.kdc-options.POSTDATED is set) then 5853 body.from := requested starting time; 5854 else 5855 omit body.from; 5856 endif 5857 body.till := requested end time; 5858 if (body.kdc-options.RENEWABLE is set) then 5859 body.rtime := requested final renewal time; 5860 endif 5861 body.nonce := random_nonce(); 5862 body.etype := requested etypes; 5863 if (user supplied addresses) then 5864 body.addresses := user's addresses; 5865 else 5866 omit body.addresses; 5867 endif 5869 body.enc-authorization-data := user-supplied data; 5870 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5871 body.additional-tickets_ticket := second TGT; 5872 endif 5874 request.req-body := body; 5875 check := generate_checksum (req.body,checksumtype); 5877 request.padata[0].padata-type := PA-TGS-REQ; 5878 request.padata[0].padata-value := create a KRB_AP_REQ using 5879 the TGT and checksum 5881 /* add in any other padata as required/supplied */ 5883 kerberos := lookup(name of local kerberose server (or servers)); 5884 send(packet,kerberos); 5886 wait(for response); 5887 if (timed_out) then 5888 retry or use alternate server; 5889 endif 5891 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5893 /* note that reading the application request requires first 5894 determining the server for which a ticket was issued, and choosing the 5895 correct key for decryption. The name of the server appears in the 5896 plaintext part of the ticket. */ 5898 if (no KRB_AP_REQ in req.padata) then 5899 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5900 endif 5901 verify KRB_AP_REQ in req.padata; 5903 /* Note that the realm in which the Kerberos server is operating is 5904 determined by the instance from the ticket-granting ticket. The realm 5905 in the ticket-granting ticket is the realm under which the ticket 5906 granting ticket was issued. It is possible for a single Kerberos 5907 server to support more than one realm. */ 5909 auth_hdr := KRB_AP_REQ; 5910 tgt := auth_hdr.ticket; 5912 if (tgt.sname is not a TGT for local realm and is not req.sname) then 5913 error_out(KRB_AP_ERR_NOT_US); 5915 realm := realm_tgt_is_for(tgt); 5917 decode remainder of request; 5919 if (auth_hdr.authenticator.cksum is missing) then 5920 error_out(KRB_AP_ERR_INAPP_CKSUM); 5921 endif 5923 if (auth_hdr.authenticator.cksum type is not supported) then 5924 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5925 endif 5926 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then 5927 error_out(KRB_AP_ERR_INAPP_CKSUM); 5928 endif 5929 set computed_checksum := checksum(req); 5930 if (computed_checksum != auth_hdr.authenticatory.cksum) then 5931 error_out(KRB_AP_ERR_MODIFIED); 5932 endif 5934 server := lookup(req.sname,realm); 5936 if (!server) then 5937 if (is_foreign_tgt_name(req.sname)) then 5938 server := best_intermediate_tgs(req.sname); 5939 else 5940 /* no server in Database */ 5941 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5942 endif 5943 endif 5945 session := generate_random_session_key(); 5947 use_etype := first supported etype in req.etypes; 5949 if (no support for req.etypes) then 5950 error_out(KDC_ERR_ETYPE_NOSUPP); 5951 endif 5953 new_tkt.vno := ticket version; /* = 5 */ 5954 new_tkt.sname := req.sname; 5955 new_tkt.srealm := realm; 5956 reset all flags in new_tkt.flags; 5958 /* It should be noted that local policy may affect the */ 5959 /* processing of any of these flags. For example, some */ 5960 /* realms may refuse to issue renewable tickets */ 5962 new_tkt.caddr := tgt.caddr; 5963 resp.caddr := NULL; /* We only include this if they change */ 5964 if (req.kdc-options.FORWARDABLE is set) then 5965 if (tgt.flags.FORWARDABLE is reset) then 5966 error_out(KDC_ERR_BADOPTION); 5967 endif 5968 set new_tkt.flags.FORWARDABLE; 5969 endif 5970 if (req.kdc-options.FORWARDED is set) then 5971 if (tgt.flags.FORWARDABLE is reset) then 5972 error_out(KDC_ERR_BADOPTION); 5973 endif 5974 set new_tkt.flags.FORWARDED; 5975 new_tkt.caddr := req.addresses; 5976 resp.caddr := req.addresses; 5977 endif 5978 if (tgt.flags.FORWARDED is set) then 5979 set new_tkt.flags.FORWARDED; 5980 endif 5982 if (req.kdc-options.PROXIABLE is set) then 5983 if (tgt.flags.PROXIABLE is reset) 5984 error_out(KDC_ERR_BADOPTION); 5985 endif 5986 set new_tkt.flags.PROXIABLE; 5987 endif 5988 if (req.kdc-options.PROXY is set) then 5989 if (tgt.flags.PROXIABLE is reset) then 5990 error_out(KDC_ERR_BADOPTION); 5991 endif 5992 set new_tkt.flags.PROXY; 5993 new_tkt.caddr := req.addresses; 5994 resp.caddr := req.addresses; 5995 endif 5997 if (req.kdc-options.ALLOW-POSTDATE is set) then 5998 if (tgt.flags.MAY-POSTDATE is reset) 5999 error_out(KDC_ERR_BADOPTION); 6000 endif 6001 set new_tkt.flags.MAY-POSTDATE; 6002 endif 6003 if (req.kdc-options.POSTDATED is set) then 6004 if (tgt.flags.MAY-POSTDATE is reset) then 6005 error_out(KDC_ERR_BADOPTION); 6006 endif 6007 set new_tkt.flags.POSTDATED; 6008 set new_tkt.flags.INVALID; 6009 if (against_postdate_policy(req.from)) then 6010 error_out(KDC_ERR_POLICY); 6011 endif 6012 new_tkt.starttime := req.from; 6013 endif 6015 if (req.kdc-options.VALIDATE is set) then 6016 if (tgt.flags.INVALID is reset) then 6017 error_out(KDC_ERR_POLICY); 6018 endif 6019 if (tgt.starttime > kdc_time) then 6020 error_out(KRB_AP_ERR_NYV); 6021 endif 6022 if (check_hot_list(tgt)) then 6023 error_out(KRB_AP_ERR_REPEAT); 6024 endif 6025 tkt := tgt; 6026 reset new_tkt.flags.INVALID; 6027 endif 6029 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 6030 and those already processed) is set) then 6031 error_out(KDC_ERR_BADOPTION); 6032 endif 6034 new_tkt.authtime := tgt.authtime; 6036 if (req.kdc-options.RENEW is set) then 6037 /* Note that if the endtime has already passed, the ticket would */ 6038 /* have been rejected in the initial authentication stage, so */ 6039 /* there is no need to check again here */ 6040 if (tgt.flags.RENEWABLE is reset) then 6041 error_out(KDC_ERR_BADOPTION); 6042 endif 6043 if (tgt.renew-till < kdc_time) then 6044 error_out(KRB_AP_ERR_TKT_EXPIRED); 6045 endif 6046 tkt := tgt; 6047 new_tkt.starttime := kdc_time; 6048 old_life := tgt.endttime - tgt.starttime; 6049 new_tkt.endtime := min(tgt.renew-till, 6050 new_tkt.starttime + old_life); 6051 else 6052 new_tkt.starttime := kdc_time; 6053 if (req.till = 0) then 6054 till := infinity; 6055 else 6056 till := req.till; 6057 endif 6058 new_tkt.endtime := min(till, 6059 new_tkt.starttime+client.max_life, 6060 new_tkt.starttime+server.max_life, 6061 new_tkt.starttime+max_life_for_realm, 6062 tgt.endtime); 6064 if ((req.kdc-options.RENEWABLE-OK is set) and 6065 (new_tkt.endtime < req.till) and 6066 (tgt.flags.RENEWABLE is set) then 6067 /* we set the RENEWABLE option for later processing */ 6068 set req.kdc-options.RENEWABLE; 6069 req.rtime := min(req.till, tgt.renew-till); 6070 endif 6071 endif 6073 if (req.rtime = 0) then 6074 rtime := infinity; 6075 else 6076 rtime := req.rtime; 6077 endif 6079 if ((req.kdc-options.RENEWABLE is set) and 6080 (tgt.flags.RENEWABLE is set)) then 6081 set new_tkt.flags.RENEWABLE; 6082 new_tkt.renew-till := min(rtime, 6083 new_tkt.starttime+client.max_rlife, 6084 new_tkt.starttime+server.max_rlife, 6085 new_tkt.starttime+max_rlife_for_realm, 6086 tgt.renew-till); 6087 else 6088 new_tkt.renew-till := OMIT; /* leave the renew-till field out */ 6089 endif 6090 if (req.enc-authorization-data is present) then 6091 decrypt req.enc-authorization-data into decrypted_authorization_data 6092 using auth_hdr.authenticator.subkey; 6093 if (decrypt_error()) then 6094 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6095 endif 6096 endif 6097 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data + 6098 decrypted_authorization_data; 6100 new_tkt.key := session; 6101 new_tkt.crealm := tgt.crealm; 6102 new_tkt.cname := req.auth_hdr.ticket.cname; 6103 if (realm_tgt_is_for(tgt) := tgt.realm) then 6104 /* tgt issued by local realm */ 6105 new_tkt.transited := tgt.transited; 6106 else 6107 /* was issued for this realm by some other realm */ 6108 if (tgt.transited.tr-type not supported) then 6109 error_out(KDC_ERR_TRTYPE_NOSUPP); 6110 endif 6111 new_tkt.transited := compress_transited(tgt.transited + tgt.realm) 6112 /* Don't check tranited field if TGT for foreign realm,=20 6113 * or requested not to check */ 6114 if (is_not_foreign_tgt_name(new_tkt.server)=20 6115 && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then 6116 /* Check it, so end-server does not have to=20 6117 * but don't fail, end-server may still accept it */ 6118 if (check_transited_field(new_tkt.transited) == OK) 6119 set = 6120 new_tkt.flags.TRANSITED-POLICY-CHECKED; 6121 endif 6122 endif 6123 endif 6125 encode encrypted part of new_tkt into OCTET STRING; 6126 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 6127 if (server not specified) then 6128 server = req.second_ticket.client; 6129 endif 6130 if ((req.second_ticket is not a TGT) or 6131 (req.second_ticket.client != server)) then 6132 error_out(KDC_ERR_POLICY); 6133 endif 6135 new_tkt.enc-part := encrypt OCTET STRING using 6136 using etype_for_key(second-ticket.key), second-ticket.key; 6137 else 6138 new_tkt.enc-part := encrypt OCTET STRING 6139 using etype_for_key(server.key), server.key, server.p_kvno; 6140 endif 6142 resp.pvno := 5; 6143 resp.msg-type := KRB_TGS_REP; 6144 resp.crealm := tgt.crealm; 6145 resp.cname := tgt.cname; 6146 resp.ticket := new_tkt; 6148 resp.key := session; 6149 resp.nonce := req.nonce; 6150 resp.last-req := fetch_last_request_info(client); 6151 resp.flags := new_tkt.flags; 6153 resp.authtime := new_tkt.authtime; 6154 resp.starttime := new_tkt.starttime; 6155 resp.endtime := new_tkt.endtime; 6157 omit resp.key-expiration; 6159 resp.sname := new_tkt.sname; 6160 resp.realm := new_tkt.realm; 6162 if (new_tkt.flags.RENEWABLE) then 6163 resp.renew-till := new_tkt.renew-till; 6164 endif 6166 encode body of reply into OCTET STRING; 6168 if (req.padata.authenticator.subkey) 6169 resp.enc-part := encrypt OCTET STRING using use_etype, 6170 req.padata.authenticator.subkey; 6171 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 6173 send(resp); 6175 A.7. KRB_TGS_REP verification 6177 decode response into resp; 6179 if (resp.msg-type = KRB_ERROR) then 6180 process_error(resp); 6181 return; 6182 endif 6184 /* On error, discard the response, and zero the session key from 6185 the response immediately */ 6187 if (req.padata.authenticator.subkey) 6188 unencrypted part of resp := decode of decrypt of resp.enc-part 6189 using resp.enc-part.etype and subkey; 6190 else unencrypted part of resp := decode of decrypt of resp.enc-part 6191 using resp.enc-part.etype and tgt's session key; 6192 if (common_as_rep_tgs_rep_checks fail) then 6193 destroy resp.key; 6194 return error; 6195 endif 6197 check authorization_data as necessary; 6198 save_for_later(ticket,session,client,server,times,flags); 6200 A.8. Authenticator generation 6202 body.authenticator-vno := authenticator vno; /* = 5 */ 6203 body.cname, body.crealm := client name; 6204 if (supplying checksum) then 6205 body.cksum := checksum; 6206 endif 6207 get system_time; 6208 body.ctime, body.cusec := system_time; 6209 if (selecting sub-session key) then 6210 select sub-session key; 6211 body.subkey := sub-session key; 6212 endif 6213 if (using sequence numbers) then 6214 select initial sequence number; 6215 body.seq-number := initial sequence; 6216 endif 6217 A.9. KRB_AP_REQ generation 6219 obtain ticket and session_key from cache; 6221 packet.pvno := protocol version; /* 5 */ 6222 packet.msg-type := message type; /* KRB_AP_REQ */ 6224 if (desired(MUTUAL_AUTHENTICATION)) then 6225 set packet.ap-options.MUTUAL-REQUIRED; 6226 else 6227 reset packet.ap-options.MUTUAL-REQUIRED; 6228 endif 6229 if (using session key for ticket) then 6230 set packet.ap-options.USE-SESSION-KEY; 6231 else 6232 reset packet.ap-options.USE-SESSION-KEY; 6233 endif 6234 packet.ticket := ticket; /* ticket */ 6235 generate authenticator; 6236 encode authenticator into OCTET STRING; 6237 encrypt OCTET STRING into packet.authenticator using session_key; 6239 A.10. KRB_AP_REQ verification 6241 receive packet; 6242 if (packet.pvno != 5) then 6243 either process using other protocol spec 6244 or error_out(KRB_AP_ERR_BADVERSION); 6245 endif 6246 if (packet.msg-type != KRB_AP_REQ) then 6247 error_out(KRB_AP_ERR_MSG_TYPE); 6248 endif 6249 if (packet.ticket.tkt_vno != 5) then 6250 either process using other protocol spec 6251 or error_out(KRB_AP_ERR_BADVERSION); 6252 endif 6253 if (packet.ap_options.USE-SESSION-KEY is set) then 6254 retrieve session key from ticket-granting ticket for 6255 packet.ticket.{sname,srealm,enc-part.etype}; 6256 else 6257 retrieve service key for 6258 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 6259 endif 6260 if (no_key_available) then 6261 if (cannot_find_specified_skvno) then 6262 error_out(KRB_AP_ERR_BADKEYVER); 6263 else 6264 error_out(KRB_AP_ERR_NOKEY); 6265 endif 6266 endif 6267 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 6268 if (decryption_error()) then 6269 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6270 endif 6271 decrypt packet.authenticator into decr_authenticator 6272 using decr_ticket.key; 6273 if (decryption_error()) then 6274 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6275 endif 6276 if (decr_authenticator.{cname,crealm} != 6277 decr_ticket.{cname,crealm}) then 6278 error_out(KRB_AP_ERR_BADMATCH); 6279 endif 6280 if (decr_ticket.caddr is present) then 6281 if (sender_address(packet) is not in decr_ticket.caddr) then 6282 error_out(KRB_AP_ERR_BADADDR); 6283 endif 6284 elseif (application requires addresses) then 6285 error_out(KRB_AP_ERR_BADADDR); 6286 endif 6287 if (not in_clock_skew(decr_authenticator.ctime, 6288 decr_authenticator.cusec)) then 6289 error_out(KRB_AP_ERR_SKEW); 6290 endif 6291 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 6292 error_out(KRB_AP_ERR_REPEAT); 6293 endif 6294 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 6295 get system_time; 6296 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 6297 (decr_ticket.flags.INVALID is set)) then 6298 /* it hasn't yet become valid */ 6299 error_out(KRB_AP_ERR_TKT_NYV); 6300 endif 6301 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 6302 error_out(KRB_AP_ERR_TKT_EXPIRED); 6303 endif 6304 if (decr_ticket.transited) then 6305 /* caller may ignore the TRANSITED-POLICY-CHECKED and do 6306 * check anyway */ 6307 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then 6308 if (check_transited_field(decr_ticket.transited) then 6309 error_out(KDC_AP_PATH_NOT_ACCPETED); 6310 endif 6311 endif 6312 endif 6313 /* caller must check decr_ticket.flags for any pertinent details */ 6314 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 6316 A.11. KRB_AP_REP generation 6318 packet.pvno := protocol version; /* 5 */ 6319 packet.msg-type := message type; /* KRB_AP_REP */ 6321 body.ctime := packet.ctime; 6322 body.cusec := packet.cusec; 6323 if (selecting sub-session key) then 6324 select sub-session key; 6325 body.subkey := sub-session key; 6326 endif 6327 if (using sequence numbers) then 6328 select initial sequence number; 6329 body.seq-number := initial sequence; 6330 endif 6331 encode body into OCTET STRING; 6333 select encryption type; 6334 encrypt OCTET STRING into packet.enc-part; 6336 A.12. KRB_AP_REP verification 6338 receive packet; 6339 if (packet.pvno != 5) then 6340 either process using other protocol spec 6341 or error_out(KRB_AP_ERR_BADVERSION); 6342 endif 6343 if (packet.msg-type != KRB_AP_REP) then 6344 error_out(KRB_AP_ERR_MSG_TYPE); 6345 endif 6346 cleartext := decrypt(packet.enc-part) using ticket's session key; 6347 if (decryption_error()) then 6348 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6349 endif 6350 if (cleartext.ctime != authenticator.ctime) then 6351 error_out(KRB_AP_ERR_MUT_FAIL); 6352 endif 6353 if (cleartext.cusec != authenticator.cusec) then 6354 error_out(KRB_AP_ERR_MUT_FAIL); 6355 endif 6356 if (cleartext.subkey is present) then 6357 save cleartext.subkey for future use; 6358 endif 6359 if (cleartext.seq-number is present) then 6360 save cleartext.seq-number for future verifications; 6361 endif 6362 return(AUTHENTICATION_SUCCEEDED); 6364 A.13. KRB_SAFE generation 6366 collect user data in buffer; 6368 /* assemble packet: */ 6369 packet.pvno := protocol version; /* 5 */ 6370 packet.msg-type := message type; /* KRB_SAFE */ 6372 body.user-data := buffer; /* DATA */ 6373 if (using timestamp) then 6374 get system_time; 6375 body.timestamp, body.usec := system_time; 6376 endif 6377 if (using sequence numbers) then 6378 body.seq-number := sequence number; 6379 endif 6380 body.s-address := sender host addresses; 6381 if (only one recipient) then 6382 body.r-address := recipient host address; 6383 endif 6384 checksum.cksumtype := checksum type; 6385 compute checksum over body; 6386 checksum.checksum := checksum value; /* checksum.checksum */ 6387 packet.cksum := checksum; 6388 packet.safe-body := body; 6389 A.14. KRB_SAFE verification 6391 receive packet; 6392 if (packet.pvno != 5) then 6393 either process using other protocol spec 6394 or error_out(KRB_AP_ERR_BADVERSION); 6395 endif 6396 if (packet.msg-type != KRB_SAFE) then 6397 error_out(KRB_AP_ERR_MSG_TYPE); 6398 endif 6399 if (packet.checksum.cksumtype is not both collision-proof and keyed) then 6400 error_out(KRB_AP_ERR_INAPP_CKSUM); 6401 endif 6402 if (safe_priv_common_checks_ok(packet)) then 6403 set computed_checksum := checksum(packet.body); 6404 if (computed_checksum != packet.checksum) then 6405 error_out(KRB_AP_ERR_MODIFIED); 6406 endif 6407 return (packet, PACKET_IS_GENUINE); 6408 else 6409 return common_checks_error; 6410 endif 6412 A.15. KRB_SAFE and KRB_PRIV common checks 6414 if (packet.s-address != O/S_sender(packet)) then 6415 /* O/S report of sender not who claims to have sent it */ 6416 error_out(KRB_AP_ERR_BADADDR); 6417 endif 6418 if ((packet.r-address is present) and 6419 (packet.r-address != local_host_address)) then 6420 /* was not sent to proper place */ 6421 error_out(KRB_AP_ERR_BADADDR); 6422 endif 6423 if (((packet.timestamp is present) and 6424 (not in_clock_skew(packet.timestamp,packet.usec))) or 6425 (packet.timestamp is not present and timestamp expected)) then 6426 error_out(KRB_AP_ERR_SKEW); 6427 endif 6428 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6429 error_out(KRB_AP_ERR_REPEAT); 6430 endif 6432 if (((packet.seq-number is present) and 6433 ((not in_sequence(packet.seq-number)))) or 6434 (packet.seq-number is not present and sequence expected)) then 6435 error_out(KRB_AP_ERR_BADORDER); 6436 endif 6437 if (packet.timestamp not present and packet.seq-number not present) then 6438 error_out(KRB_AP_ERR_MODIFIED); 6439 endif 6441 save_identifier(packet.{timestamp,usec,s-address}, 6442 sender_principal(packet)); 6444 return PACKET_IS_OK; 6445 A.16. KRB_PRIV generation 6447 collect user data in buffer; 6449 /* assemble packet: */ 6450 packet.pvno := protocol version; /* 5 */ 6451 packet.msg-type := message type; /* KRB_PRIV */ 6453 packet.enc-part.etype := encryption type; 6455 body.user-data := buffer; 6456 if (using timestamp) then 6457 get system_time; 6458 body.timestamp, body.usec := system_time; 6459 endif 6460 if (using sequence numbers) then 6461 body.seq-number := sequence number; 6462 endif 6463 body.s-address := sender host addresses; 6464 if (only one recipient) then 6465 body.r-address := recipient host address; 6466 endif 6468 encode body into OCTET STRING; 6470 select encryption type; 6471 encrypt OCTET STRING into packet.enc-part.cipher; 6473 A.17. KRB_PRIV verification 6475 receive packet; 6476 if (packet.pvno != 5) then 6477 either process using other protocol spec 6478 or error_out(KRB_AP_ERR_BADVERSION); 6479 endif 6480 if (packet.msg-type != KRB_PRIV) then 6481 error_out(KRB_AP_ERR_MSG_TYPE); 6482 endif 6484 cleartext := decrypt(packet.enc-part) using negotiated key; 6485 if (decryption_error()) then 6486 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6487 endif 6489 if (safe_priv_common_checks_ok(cleartext)) then 6490 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 6491 else 6492 return common_checks_error; 6493 endif 6495 A.18. KRB_CRED generation 6497 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 6499 /* assemble packet: */ 6500 packet.pvno := protocol version; /* 5 */ 6501 packet.msg-type := message type; /* KRB_CRED */ 6502 for (tickets[n] in tickets to be forwarded) do 6503 packet.tickets[n] = tickets[n].ticket; 6504 done 6506 packet.enc-part.etype := encryption type; 6508 for (ticket[n] in tickets to be forwarded) do 6509 body.ticket-info[n].key = tickets[n].session; 6510 body.ticket-info[n].prealm = tickets[n].crealm; 6511 body.ticket-info[n].pname = tickets[n].cname; 6512 body.ticket-info[n].flags = tickets[n].flags; 6513 body.ticket-info[n].authtime = tickets[n].authtime; 6514 body.ticket-info[n].starttime = tickets[n].starttime; 6515 body.ticket-info[n].endtime = tickets[n].endtime; 6516 body.ticket-info[n].renew-till = tickets[n].renew-till; 6517 body.ticket-info[n].srealm = tickets[n].srealm; 6518 body.ticket-info[n].sname = tickets[n].sname; 6519 body.ticket-info[n].caddr = tickets[n].caddr; 6520 done 6522 get system_time; 6523 body.timestamp, body.usec := system_time; 6525 if (using nonce) then 6526 body.nonce := nonce; 6527 endif 6529 if (using s-address) then 6530 body.s-address := sender host addresses; 6531 endif 6532 if (limited recipients) then 6533 body.r-address := recipient host address; 6534 endif 6536 encode body into OCTET STRING; 6538 select encryption type; 6539 encrypt OCTET STRING into packet.enc-part.cipher 6540 using negotiated encryption key; 6542 A.19. KRB_CRED verification 6544 receive packet; 6545 if (packet.pvno != 5) then 6546 either process using other protocol spec 6547 or error_out(KRB_AP_ERR_BADVERSION); 6548 endif 6549 if (packet.msg-type != KRB_CRED) then 6550 error_out(KRB_AP_ERR_MSG_TYPE); 6551 endif 6553 cleartext := decrypt(packet.enc-part) using negotiated key; 6554 if (decryption_error()) then 6555 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6556 endif 6557 if ((packet.r-address is present or required) and 6558 (packet.s-address != O/S_sender(packet)) then 6559 /* O/S report of sender not who claims to have sent it */ 6560 error_out(KRB_AP_ERR_BADADDR); 6561 endif 6562 if ((packet.r-address is present) and 6563 (packet.r-address != local_host_address)) then 6564 /* was not sent to proper place */ 6565 error_out(KRB_AP_ERR_BADADDR); 6566 endif 6567 if (not in_clock_skew(packet.timestamp,packet.usec)) then 6568 error_out(KRB_AP_ERR_SKEW); 6569 endif 6570 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6571 error_out(KRB_AP_ERR_REPEAT); 6572 endif 6573 if (packet.nonce is required or present) and 6574 (packet.nonce != expected-nonce) then 6575 error_out(KRB_AP_ERR_MODIFIED); 6576 endif 6578 for (ticket[n] in tickets that were forwarded) do 6579 save_for_later(ticket[n],key[n],principal[n], 6580 server[n],times[n],flags[n]); 6581 return 6583 A.20. KRB_ERROR generation 6585 /* assemble packet: */ 6586 packet.pvno := protocol version; /* 5 */ 6587 packet.msg-type := message type; /* KRB_ERROR */ 6589 get system_time; 6590 packet.stime, packet.susec := system_time; 6591 packet.realm, packet.sname := server name; 6593 if (client time available) then 6594 packet.ctime, packet.cusec := client_time; 6595 endif 6596 packet.error-code := error code; 6597 if (client name available) then 6598 packet.cname, packet.crealm := client name; 6599 endif 6600 if (error text available) then 6601 packet.e-text := error text; 6602 endif 6603 if (error data available) then 6604 packet.e-data := error data; 6605 endif 6606 B. Definition of common authorization data elements 6608 This appendix contains the definitions of common authorization data 6609 elements. These common authorization data elements are recursivly defined, 6610 meaning the ad-data for these types will itself contain a sequence of 6611 authorization data whose interpretation is affected by the encapsulating 6612 element. Depending on the meaning of the encapsulating element, the 6613 encapsulated elements may be ignored, might be interpreted as issued 6614 directly by the KDC, or they might be stored in a separate plaintext part of 6615 the ticket. The types of the encapsulating elements are specified as part of 6616 the Kerberos specification because the behavior based on these values should 6617 be understood across implementations whereas other elements need only be 6618 understood by the applications which they affect. 6620 In the definitions that follow, the value of the ad-type for the element 6621 will be specified in the subsection number, and the value of the ad-data 6622 will be as shown in the ASN.1 structure that follows the subsection heading. 6624 B.1. If relevant 6626 AD-IF-RELEVANT AuthorizationData 6628 AD elements encapsulated within the if-relevant element are intended for 6629 interpretation only by application servers that understand the particular 6630 ad-type of the embedded element. Application servers that do not understand 6631 the type of an element embedded within the if-relevant element may ignore 6632 the uninterpretable element. This element promotes interoperability across 6633 implementations which may have local extensions for authorization. 6635 B.2. Intended for server 6637 AD-INTENDED-FOR-SERVER SEQUENCE { 6638 intended-server[0] SEQUENCE OF PrincipalName 6639 elements[1] AuthorizationData 6640 } 6642 AD elements encapsulated within the intended-for-server element may be 6643 ignored if the application server is not in the list of principal names of 6644 intended servers. Further, a KDC issuing a ticket for an application server 6645 can remove this element if the application server is not in the list of 6646 intended servers. 6648 Application servers should check for their principal name in the 6649 intended-server field of this element. If their principal name is not found, 6650 this element should be ignored. If found, then the encapsulated elements 6651 should be evaluated in the same manner as if they were present in the top 6652 level authorization data field. Applications and application servers that do 6653 not implement this element should reject tickets that contain authorization 6654 data elements of this type. 6656 B.3. Intended for application class 6658 AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] 6659 SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements 6660 encapsulated within the intended-for-application-class element may be 6661 ignored if the application server is not in one of the named classes of 6662 application servers. Examples of application server classes include 6663 "FILESYSTEM", and other kinds of servers. 6665 This element and the elements it encapulates may be safely ignored by 6666 applications, application servers, and KDCs that do not implement this 6667 element. 6669 B.4. KDC Issued 6671 AD-KDCIssued SEQUENCE { 6672 ad-checksum[0] Checksum, 6673 i-realm[1] Realm OPTIONAL, 6674 i-sname[2] PrincipalName OPTIONAL, 6675 elements[3] AuthorizationData. 6676 } 6678 ad-checksum 6679 A checksum over the elements field using a cryptographic checksum 6680 method that is identical to the checksum used to protect the ticket 6681 itself (i.e. using the same hash function and the same encryption 6682 algorithm used to encrypt the ticket) and using a key derived from the 6683 same key used to protect the ticket. 6684 i-realm, i-sname 6685 The name of the issuing principal if different from the KDC itself. 6686 This field would be used when the KDC can verify the authenticity of 6687 elements signed by the issuing principal and it allows this KDC to 6688 notify the application server of the validity of those elements. 6689 elements 6690 A sequence of authorization data elements issued by the KDC. 6692 The KDC-issued ad-data field is intended to provide a means for Kerberos 6693 principal credentials to embed within themselves privilege attributes and 6694 other mechanisms for positive authorization, amplifying the priveleges of 6695 the principal beyond what can be done using a credentials without such an 6696 a-data element. 6698 This can not be provided without this element because the definition of the 6699 authorization-data field allows elements to be added at will by the bearer 6700 of a TGT at the time that they request service tickets and elements may also 6701 be added to a delegated ticket by inclusion in the authenticator. 6703 For KDC-issued elements this is prevented because the elements are signed by 6704 the KDC by including a checksum encrypted using the server's key (the same 6705 key used to encrypt the ticket - or a key derived from that key). Elements 6706 encapsulated with in the KDC-issued element will be ignored by the 6707 application server if this "signature" is not present. Further, elements 6708 encapsulated within this element from a ticket granting ticket may be 6709 interpreted by the KDC, and used as a basis according to policy for 6710 including new signed elements within derivative tickets, but they will not 6711 be copied to a derivative ticket directly. If they are copied directly to a 6712 derivative ticket by a KDC that is not aware of this element, the signature 6713 will not be correct for the application ticket elements, and the field will 6714 be ignored by the application server. 6716 This element and the elements it encapulates may be safely ignored by 6717 applications, application servers, and KDCs that do not implement this 6718 element. 6720 B.5. And-Or 6722 AD-AND-OR SEQUENCE { 6723 condition-count[0] INTEGER, 6724 elements[1] AuthorizationData 6725 } 6727 When restrictive AD elements encapsulated within the and-or element are 6728 encountered, only the number specified in condition-count of the 6729 encapsulated conditions must be met in order to satisfy this element. This 6730 element may be used to implement an "or" operation by setting the 6731 condition-count field to 1, and it may specify an "and" operation by setting 6732 the condition count to the number of embedded elements. Application servers 6733 that do not implement this element must reject tickets that contain 6734 authorization data elements of this type. 6736 B.6. Mandatory ticket extensions 6738 AD-Mandatory-Ticket-Extensions SEQUENCE { 6739 te-type[0] INTEGER, 6740 te-checksum[0] Checksum 6741 } 6743 An authorization data element of type mandatory-ticket-extensions specifies 6744 the type and a collision-proof checksum using the same hash algorithm used 6745 to protect the integrity of the ticket itself. This checksum will be 6746 calculated over an individual extension field of the type indicated. If 6747 there are more than one extension, multiple Mandatory-Ticket-Extensions 6748 authorization data elements may be present, each with a checksum for a 6749 different extension field. This restriction indicates that the ticket should 6750 not be accepted if a ticket extension is not present in the ticket for which 6751 the type and checksum do not match that checksum specified in the 6752 authorization data element. Note that although the type is redundant for the 6753 purposes of the comparison, it makes the comparison easier when multiple 6754 extensions are present. Application servers that do not implement this 6755 element must reject tickets that contain authorization data elements of this 6756 type. 6758 B.7. Authorization Data in ticket extensions 6760 AD-IN-Ticket-Extensions Checksum 6762 An authorization data element of type in-ticket-extensions specifies a 6763 collision-proof checksum using the same hash algorithm used to protect the 6764 integrity of the ticket itself. This checksum is calculated over a separate 6765 external AuthorizationData field carried in the ticket extensions. 6766 Application servers that do not implement this element must reject tickets 6767 that contain authorization data elements of this type. Application servers 6768 that do implement this element will search the ticket extensions for 6769 authorization data fields, calculate the specified checksum over each 6770 authorization data field and look for one matching the checksum in this 6771 in-ticket-extensions element. If not found, then the ticket must be 6772 rejected. If found, the corresponding authorization data elements will be 6773 interpreted in the same manner as if they were contained in the top level 6774 authorization data field. 6776 Note that if multiple external authorization data fields are present in a 6777 ticket, each will have a corresponding element of type in-ticket-extensions 6778 in the top level authorization data field, and the external entries will be 6779 linked to the corresponding element by their checksums. 6781 C. Definition of common ticket extensions 6783 This appendix contains the definitions of common ticket extensions. Support 6784 for these extensions is optional. However, certain extensions have 6785 associated authorization data elements that may require rejection of a 6786 ticket containing an extension by application servers that do not implement 6787 the particular extension. Other extensions have been defined beyond those 6788 described in this specification. Such extensions are described elswhere and 6789 for some of those extensions the reserved number may be found in the list of 6790 constants. 6792 It is known that older versions of Kerberos did not support this field, and 6793 that some clients will strip this field from a ticket when they parse and 6794 then reassemble a ticket as it is passed to the application servers. The 6795 presence of the extension will not break such clients, but any functionaly 6796 dependent on the extensions will not work when such tickets are handled by 6797 old clients. In such situations, some implementation may use alternate 6798 methods to transmit the information in the extensions field. 6800 C.1. Null ticket extension 6802 TE-NullExtension OctetString -- The empty Octet String 6804 The te-data field in the null ticket extension is an octet string of lenght 6805 zero. This extension may be included in a ticket granting ticket so that the 6806 KDC can determine on presentation of the ticket granting ticket whether the 6807 client software will strip the extensions field. =20 6809 C.2. External Authorization Data 6811 TE-ExternalAuthorizationData AuthorizationData 6813 The te-data field in the external authorization data ticket extension is 6814 field of type AuthorizationData containing one or more authorization data 6815 elements. If present, a corresponding authorization data element will be 6816 present in the primary authorization data for the ticket and that element 6817 will contain a checksum of the external authorization data ticket extension. 6819 D. Significant changes since RFC 1510 6821 Section 1: The preamble and introduction does not define the protocol, 6822 mention is made in the introduction regarding the ability to rely on the KDC 6823 to check the transited field, and on the inclusion of a flag in a ticket 6824 indicating that this check has occurred. This is a new capability not 6825 present in RFC1510. Pre-existing implementation may ignore or not set this 6826 flag without negative security implications. 6828 The definition of the secret key says that in the case of a user the key may 6829 be derived from a password. In 1510, it said that the key was derived from 6830 the password. This change was made to accommodate situations where the user 6831 key might be stored on a smart-card, or otherwise obtained independent of a 6832 password. 6834 The introduction also mentions the use of public key for initial 6835 authentication in Kerberos by reference. RFC1510 did not include such a 6836 reference. 6838 Section 1.2 was added to explain that while Kerberos provides authentication 6839 of a named principal, it is still the responsibility of the application to 6840 ensure that the authenticated name is the entity with which the application 6841 wishes to communicate. 6843 Section 2: No changes were made to existing options and flags specified in 6844 RFC1510, though text was revised to make the description and intent of 6845 existing options clearer, especially with respect to the ENC-TKT-IN-SKEY 6846 option (now section 2.9.3) which is used for user-to-user authentication. 6847 New options and ticket flags added since RFC1510 include transited policy 6848 checking (section 2.7), anonymous tickets (section 2.8) and name 6849 canonicalization (section 2.9.1). 6851 Section 3: Added mention of the optional checksum field in the KRB-ERROR 6852 message. Added mention of name canonicalization and anonymous tickets in 6853 exposition on KDC options. Mention of the name canonicalization case is 6854 included in the description of the KDC reply (3.1.3). A warning regarding 6855 generation of session keys for application use was added, urging the 6856 inclusion of key entropy from the KDC generated session key in the ticket. 6857 An example regarding use of the subsession key was added to section 3.2.6. 6858 Descriptions of the pa-etype-info, and pa-pw-salt preauthentication data 6859 items were added. 6861 Changes to section 4: Added language about who has access to the keys in the 6862 Kerberos database. Also made it clear that KDC's may obtain the information 6863 from some database field through other means - for example, one form of 6864 pkinit may extract some of these fields from a certificate. 6866 Section 5: The message specification section has undergone a major rewrite 6867 to eliminate confusion regarding different versions of ASN.1, and to 6868 highlight those areas where the Kerberos protocol does not strictly follow 6869 ASN.1. These are changes to make the description more clear, rather than 6870 changes to the protocol. 6872 Major changes were made to message numbers, providing a clearer 6873 interoperability path for messages that have new optional fields. The 6874 specific additions to these messages are listed specifically elswhere in 6875 this document. 6877 A statement regarding the carrying of unrecognized additional fields in 6878 ASN.1 encoding through in tickets was added (still waiting on some better 6879 text regarding this). 6881 Ticket flags and KDC options were added to support the new functions 6882 described elsewhere in this document. The encoding of the options flags are 6883 now described to be no less than 32 bits, and the smallest number of bits 6884 beyond 32 needed to encode any set bits. It also describes the encoding of 6885 the bitstring as using "unnamed" bits. 6887 An optional ticket extensions field was added to support the carrying of 6888 auxiliary data that allows the passing of auxiliary that is to accompany a 6889 ticket to the verifier. 6891 (Still pending, Tom Yu's request to change the application codes on KDC 6892 message to indicate which minor rev of the protocol - I think this might 6893 break things, but am not sure). 6895 Definition of the PA-USE-SPECIFIED-KVNO preauthentication data field was 6896 added. 6898 The optional e-cksum field was added to the KRB-ERROR message and the e-data 6899 filed was generalized for use in other than the KDC_ERR_PREAUTH_REQUIRED 6900 error. The TypedData structure was defined. Type tags for TypedData are 6901 defined in the same sequence as the PA-DATA type space to avoid confusion 6902 with the use of the PA-DATA namespace previously used for the e-data field 6903 for the KDC_ERR_PREAUTH_REQUIRED error. 6905 Section 6: Section 6 has undergone a major rewrite to more redily convey how 6906 to add new encryption and checksum methods to Kerberos. New encryption 6907 methods were added. Existing methods that are in use have not changed, but 6908 their descriptions have to yield bettwer symmetry with the discussions of 6909 the new methods. 6911 Section 7: Words were added describing the convention that domain based 6912 realm names for newly created realms should be specified as upper case. This 6913 recommendation does not make lower case realm names illegal. Words were 6914 added highlighting that the slash separated components in the X500 style of 6915 realm names is consistent with existing RFC1510 based implementations, but 6916 that it conflicts with the general recommendation of X.500 name 6917 representation specified in RFC2253. 6919 There were suggestions on the list regarding extensions to or new name 6920 types. These require discussion at the IETF meeting. My own feeling at this 6921 point is that in the absence of a strong consensus for adding new types at 6922 this time, I would rather not add new name types in the current draft, but 6923 leave things open for additions later. 6925 Section 8: Since RFC1510, the definition of the TCP transport for Kerberos 6926 messages was added. 6928 Section 9: Requirements for supporting DES3-CBC-SHA1-KD encryption and 6929 HMAC-SHA1-DES3-KD checksums were added. 6931 I would like to make support for Rijndael mandatory and for us to have a 6932 SINGLE standard for use of Rijndale in these revisions. 6934 ------------------------------------------------------------------------ 6935 [TM] Project Athena, Athena, and Kerberos are trademarks of the 6936 Massachusetts Institute of Technology (MIT). No commercial use of these 6937 trademarks may be made without prior written permission of MIT. 6939 [1.1] Note, however, that many applications use Kerberos' functions only 6940 upon the initiation of a stream-based network connection. Unless an 6941 application subsequently provides integrity protection for the data stream, 6942 the identity verification applies only to the initiation of the connection, 6943 and does not guarantee that subsequent messages on the connection originate 6944 from the same principal. 6946 [1.2] Secret and private are often used interchangeably in the literature. 6947 In our usage, it takes two (or more) to share a secret, thus a shared DES 6948 key is a secret key. Something is only private when no one but its owner 6949 knows it. Thus, in public key cryptosystems, one has a public and a private 6950 key. 6952 [1.3] Of course, with appropriate permission the client could arrange 6953 registration of a separately-named prin- cipal in a remote realm, and engage 6954 in normal exchanges with that realm's services. However, for even small 6955 numbers of clients this becomes cumbersome, and more automatic methods as 6956 described here are necessary. 6958 [2.1] Though it is permissible to request or issue tick- ets with no network 6959 addresses specified. 6961 [2.2] It is important that the KDC be sent the name as typed by the user, 6962 and not only the canonical form of the name. If the domain name system was 6963 used to find the canonical name on the client side, the mapping is 6964 vulnerable. [3.1] The password-changing request must not be honored unless 6965 the requester can provide the old password (the user's current secret key). 6966 Otherwise, it would be possible for someone to walk up to an unattended 6967 session and change another user's password. 6969 [3.2] To authenticate a user logging on to a local system, the credentials 6970 obtained in the AS exchange may first be used in a TGS exchange to obtain 6971 credentials for a local server. Those credentials must then be verified by a 6972 local server through successful completion of the Client/Server exchange. 6974 [3.3] "Random" means that, among other things, it should be impossible to 6975 guess the next session key based on knowledge of past session keys. This can 6976 only be achieved in a pseudo-random number generator if it is based on 6977 cryptographic principles. It is more desirable to use a truly random number 6978 generator, such as one based on measurements of random physical phenomena. 6980 [3.4] Tickets contain both an encrypted and unencrypted portion, so 6981 cleartext here refers to the entire unit, which can be copied from one 6982 message and replayed in another without any cryptographic skill. 6984 [3.5] Note that this can make applications based on unreliable transports 6985 difficult to code correctly. If the transport might deliver duplicated 6986 messages, either a new authenticator must be generated for each retry, or 6987 the application server must match requests and replies and replay the first 6988 reply in response to a detected duplicate. 6990 [3.6] This allows easy implementation of user-to-user authentication [8], 6991 which uses ticket-granting ticket session keys in lieu of secret server keys 6992 in situations where such secret keys could be easily compromised. 6994 [3.7]Note also that the rejection here is restricted to authenticators from 6995 the same principal to the same server. Other client principals communicating 6996 with the same server principal should not be have their authenticators 6997 rejected if the time and microsecond fields happen to match some other 6998 client's authenticator. 7000 [3.8] If this is not done, an attacker could subvert the authentication by 7001 recording the ticket and authenticator sent over the network to a server and 7002 replaying them following an event that caused the server to lose track of 7003 recently seen authenticators. 7005 [3.9] In the Kerberos version 4 protocol, the timestamp in the reply was the 7006 client's timestamp plus one. This is not necessary in version 5 because 7007 version 5 messages are formatted in such a way that it is not possible to 7008 create the reply by judicious message surgery (even in encrypted form) 7009 without knowledge of the appropriate encryption keys. 7011 [3.10] Note that for encrypting the KRB_AP_REP message, the sub-session key 7012 is not used, even if present in the Authenticator. 7014 [3.11] Implementations of the protocol may wish to provide routines to 7015 choose subkeys based on session keys and random numbers and to generate a 7016 negotiated key to be returned in the KRB_AP_REP message. 7018 [3.12]This can be accomplished in several ways. It might be known beforehand 7019 (since the realm is part of the principal identifier), it might be stored in 7020 a nameserver, or it might be obtained from a configuration file. If the 7021 realm to be used is obtained from a nameserver, there is a danger of being 7022 spoofed if the nameservice providing the realm name is not authenticated. 7023 This might result in the use of a realm which has been compromised, and 7024 would result in an attacker's ability to compromise the authentication of 7025 the application server to the client. 7027 [3.13] If the client selects a sub-session key, care must be taken to ensure 7028 the randomness of the selected sub-session key. One approach would be to 7029 generate a random number and XOR it with the session key from the 7030 ticket-granting ticket. 7032 [4.1] The implementation of the Kerberos server need not combine the 7033 database and the server on the same machine; it is feasible to store the 7034 principal database in, say, a network name service, as long as the entries 7035 stored therein are protected from disclosure to and modification by 7036 unauthorized parties. However, we recommend against such strategies, as they 7037 can make system management and threat analysis quite complex. 7039 [4.2] See the discussion of the padata field in section 5.4.2 for details on 7040 why this can be useful.